Hi!
CoreData - the reincarnated EOF - actually uses sets. Rightfully so.
To the model to-many relationships have no order. Actually to a
database a to-many relationship is not all that real. It's a by-
product of ato-one relationship. Ever noticed that adding an object
to a to-many without also adding to the inverse relationship has no
effect on persistence?
The mapping of to-many relationships is convenience as they are a
business reality. I actually think EOF could do a better job at that.
E.g. keeping the object graph consistent.
On the business level it often happens that to-many relationships do
come with a natural sort ordering. It would have been nice for EOF to
support this. E.g. the model could store a default sort order for to-
many relationships. Might be a fun thing trying to enhance EOF to do
just that.
A couple of years back Christian Trotobas and I wrote some code that
could be reused to do just that. What we wanted were filtered
relationships. Objects would have dates of validity. One could
specify a current date on the editing context and from then on see
only applicable objects in to-many relationships. The code was pretty
convoluted and included a subclass of _EOCheapMutableArray and a
custom fault handler. If there is interest I might try to dig this
stuff up.
Of course there is the much simpler solution of just sorting in
memory and caching the sorted member of the relationship.
Pierre
On Aug 24, 2007, at 7:22 PM, Chuck Hill wrote:
On Aug 23, 2007, at 5:41 AM, Lachlan Deck wrote:
On 23/08/2007, at 1:38 PM, Chuck Hill wrote:
On Aug 22, 2007, at 6:22 PM, Lachlan Deck wrote:
On 23/08/2007, at 10:46 AM, Chuck Hill wrote:
On Aug 22, 2007, at 5:09 PM, Lachlan Deck wrote:
Hi there,
EOEntity has a restrictingQualifier that's applied to every
fetch for the relevant entity.
Is there any similar mechanism for installing a default
ordering for fetched objects of each entity (e.g., when
following a toMany relationship)? Or any delegate methods
somewhere?
No. And don't override the EOF methods to do this or you risk
messing with EOF. And we all know how that ends up. :-) The
reason for the lack of sorting, as I understand it, is that
EOF would then need to keep the list sorted each time something
was added to it.
It's already keeping them sorted (think about it...). Just not
how I'd like.
No, they are not sorted.
Furthermore, it's impossible to fetch records from a database
without them sorted in some kind of order.
Where on earth did you get that idea from? An unordered list is
not sorted. If there is no ORDER BY clause on a SELECT, the
order in the result set is undefined. It most databases it will
change over time as the query optimizer changes strategies.
I understand the theory - but I'm talking about reality ;-)
Well... I would agree that one of us is. :-)
The point is that once the array has been faulted into memory they
have a fixed order whenever that particular relationship is
accessed. I would simply like to control the order that these
objects are kept in memory so that for the majority of cases no
further ordering is necessary.
Fixed order? Consider:
public NSArray items() // the to-many relationship
EOEnterpriseObject eo = items().objectAtIndex(0);
removeFromItems(eo);
addToItems(eo);
OK, now it is the same relationship, the same members, but a
different order. Your reality based applications ;-) might be
different, but my theoretical ones manipulate to-many
relationships. In order to make your idea work, EOF will have to
resort the array every time addToItems() is called or (and this is
a a big one) when any of the objects in the array have their values
changed. That is going to suck up a lot of processor time. If it
does not do that, the sorting is useless as you can't depend on it.
To many relationships probably should have been implemented as
NSSet not NSArray. Properly they are sets and using NSArray
deludes people into thinking it really is an ordered list. I'd
guess that they used NSArray to avoid the NSSet overhead of
verifying that an object is not in the set before adding it.
I'm simply wanting to override the arbitrary sort order that the
database wants to return to suit this particular application.
And what if you wanted alternate sorts?
Simply apply the default sorting in the absence of a specific
sort orderings array. Not hard conceptually.
Not sure how that differs from what I suggested and it means two
sorts so additional unneeded load on the machine.
Huh. Where's the second sort? i.e., if you happen to have built a
custom EOFetchSpecification somewhere in your application that
happens to include a non-empty sort orderings array then that
would run as normal. Otherwise, the default one applies whilst
faulting from the database (not in memory).
Fetch? We are talking about to-many relationships. If I have the
objects in a relationship and I want them sorted, why would I fetch
them to sort them? I'd just sort them in memory. But they are
already sorted another way which was a waste of resources.
The standard approach is to have a cover method that sorts the
contents of the relationship and returns it.
Which kinda makes *every* toMany relationship generated from
each EOEntity useless don't you think?
I dunno, I have always found them to be be pretty useful. YMMV.
Like Ken said, ordering is a UI thing.
Personally, I can't see the benefit of continually sorting a
keyPath in memory via some ui option every time you access that
array rather than once from the fetch where possible...
But then how do you know it is still sorted?
Chuck
--
Practical WebObjects - for developers who want to increase their
overall knowledge of WebObjects or who are trying to solve specific
problems.
http://www.global-village.net/products/practical_webobjects
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/webobjects-
lists%40houdah.com
This email sent to [EMAIL PROTECTED]
- - -
Houdah Software s. à r. l.
http://www.houdah.com
HoudahGeo: One-stop photo geocoding
HoudahSpot: Powerful Spotlight frontend
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
