• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: setting default order of entity fetches
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: setting default order of entity fetches


  • Subject: Re: setting default order of entity fetches
  • From: Chuck Hill <email@hidden>
  • Date: Fri, 24 Aug 2007 10:22:32 -0700


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      (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden


  • Follow-Ups:
    • Re: setting default order of entity fetches
      • From: Lachlan Deck <email@hidden>
    • Re: setting default order of entity fetches
      • From: Pierre Bernard <email@hidden>
    • Re: setting default order of entity fetches
      • From: Mike Schrag <email@hidden>
References: 
 >setting default order of entity fetches (From: Lachlan Deck <email@hidden>)
 >Re: setting default order of entity fetches (From: Chuck Hill <email@hidden>)
 >Re: setting default order of entity fetches (From: Lachlan Deck <email@hidden>)
 >Re: setting default order of entity fetches (From: Chuck Hill <email@hidden>)
 >Re: setting default order of entity fetches (From: Lachlan Deck <email@hidden>)

  • Prev by Date: Disabling items in a WOPopUpMenu
  • Next by Date: Re: setting default order of entity fetches
  • Previous by thread: Re: setting default order of entity fetches
  • Next by thread: Re: setting default order of entity fetches
  • Index(es):
    • Date
    • Thread