Re: Java Packages for Dummies
Re: Java Packages for Dummies
- Subject: Re: Java Packages for Dummies
- From: Anjo Krank <email@hidden>
- Date: Wed, 5 Dec 2007 14:34:24 +0100
Which may or may not be a good idea because you will fetch *every*
time you touch the relationship and this might suck a lot when used in
bindings (which you don't find via "Open Call Hierarchy") or you have
to cache it yourself but then have a bitch of a time to invalidate it
when you actually needs to insert something.
Also it's an urban legend that simply faulting the objects is slow.
This is only true when you either have batch operations where you are
not really interested in the relationship but it will get fetched
because validation needs it. Or you have *huge* relationships (say >1k
objects).
For those that remember from Max Muellers talk how EOF was expensive
when inserting into huge relationship - a customer with 20k songs had
to wait a long time: this was a only because of a stupid error in
NSArray which had O(n^2) and has been fixed in Wonder for a year now.
Cheers, Anjo
Am 05.12.2007 um 12:39 schrieb David Avendasora:
I think this is a key "best practice". It is something that I
struggled with for a while, while trying to figure out why my
application was so slow. It's logical to add both relationships, but
once you understand what is happening, it is logical to leave the
heavy relationship off and use a Fetch Specification instead.
Looks like the Best Practices portion of the Wiki would use a little
work. I'll try to get to it later today...
Dave
On Dec 4, 2007, at 7:33 PM, Mike Schrag wrote:
I prefer not modeling the inverse relationship in these cases. The
problem is that if the heavy side has already faulted, it will now
just be out of sync, so if you DO have to get the results from it,
it won't contain your recent update. So I usually don't model the
heavy relationship and instead write the equivalent cover methods
on the Java class that just fetch them with a fetch spec so they're
always fresh.
_______________________________________________
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
_______________________________________________
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