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 protected])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
