When to model both sides of a relationship (was Java Packages for Dummies)
When to model both sides of a relationship (was Java Packages for Dummies)
- Subject: When to model both sides of a relationship (was Java Packages for Dummies)
- From: David Avendasora <email@hidden>
- Date: Wed, 5 Dec 2007 10:29:30 -0500
I didn't mean that modeling the inverse is something that should
"never" be done, but more that the Best Practice is to think about
the relationship, before you simply put it in the model.
One of the great things about using an EOGenerator-type tool is that
you can setup the relationship initially as one-way, and when you get
to the point where you need to call the inverse, you can make a
decision at that point to add it to the model, or to use a fetch,
depending upon the number of objects and the way in which the result
set will be used. You aren't putting off writing a huge chunk of
code, you are simply putting off adding the inverse relationship in
the model. The EOGenerator tool will take care of writing either the
accessor, or the fetch (if you put your fetches in the model/template).
It could also be listed as a first place to look for optimizations.
The project I am working on has several look-up table
implementations, as well as logging ("write mostly") implementations.
I've found that being choosy in which to-one relationships get their
inverse has made a big difference in the over-all performance of my
application, especially in the Java Client portion.
Dave
On Dec 5, 2007, at 8:44 AM, Mike Schrag wrote:
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.
I agree that you certainly should write the easy way first and only
fix it if it's a problem ... But the >1k objects can definitely
happen, and for me at least, it tends to be rare that you ever even
WANT that inverse relationship. For instance, the case that comes
to mind is in our task tracking system, we have EO's that represent
the task statuses (this was pre ERXConstant incidentally, though
the original requirements were that the list was extendable
anyway). It turns out to be almost never the case that you want to
fetch all "Open Tasks". It tends to be the case for us that you
almost always want to have additional qualifiers on those searches,
which ends up that you fault a HUGE (many thousands) of EO's in
just to turn back around and filter them down in memory. Instead,
I can remove that relationship completely and provide just the
variant of the to-many that takes a qualifier.
The warning flags go up for "lookup table objects" (like bug type,
etc -- anything that you think "enumerated type" when you see --
though you should look at ERXConstant for most of these now) and
"write mostly" data (like audit trails, etc -- constantly growing
to-many relationships that you rarely actually read the data back
out).
But I do recall you fixing that NSArray bug, now, and I actually
haven't timed this out ... Might be interesting to see a graph of
fault speed as that array size grows on a "normal" sized EO.
ms
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
40avendasora.com
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