• 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: Lachlan Deck <email@hidden>
  • Date: Tue, 28 Aug 2007 10:39:32 +1000

On 24/08/2007, at 2:09 AM, Alan Ward wrote:

On Aug 23, 2007, at 6:41 AM, Lachlan Deck wrote:

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...

That depends on your particular situation. If you ever work on a WebObjects app where you deploy thousands of instances then you might
change your opinion.

Yup. I imagine you're right.

At that point you'll find that you have copious amounts of spare CPU cycles on your application hosts and you'll be trying
to squeeze every possible performance gain from your DB queries. Sorting in the database is not a cheap as most people think. Many times
it results in disk i/o that would not have happened where it not for the sort.

Right. Good point. I hadn't considered performance benefits from distributing this kind of thing amongst lots of instances vs the db penalty of sorting the results of the fetch. However, this particular app is utilising the shared ec quite a bit so I'd assumed round-trips to the db would hopefully be limited anyway. I don't envisage a time when we'd need ~1000 instances for the app, but we can dream ;-)


I suppose the question is: at what point does the benefit of sorting in the db vs the gui make better sense?

Also, you don't have to sort every time. It's quite trivial to cache the sorted array and invalidate that cache when the relationship
changes (or is refaulted).

Sure. Are you referring to delegate methods and notifications or more specifically per component?


I've achieved this for now by simply subclassing EODatabaseContext's objectsForFetchSpecification [1] but do you/people think this be better via a delegate method of some kind?

Thanks.

[1] if the context is the shared ec and the sort orderings of the fetch spec is empty, cloning the fetchspec prior to calling super and adding the default ordering if one's defined. Seems to work well.

with regards,
--

Lachlan Deck

_______________________________________________
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


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>)
 >Re: setting default order of entity fetches (From: Alan Ward <email@hidden>)

  • Prev by Date: Re: How does WO enforce serial request processing per session?
  • Next by Date: Re: How does WO enforce serial request processing per session?
  • Previous by thread: Re: setting default order of entity fetches
  • Next by thread: Re: setting default order of entity fetches
  • Index(es):
    • Date
    • Thread