Re: Relation oddity
Re: Relation oddity
- Subject: Re: Relation oddity
- From: "Jerry W. Walker" <email@hidden>
- Date: Tue, 27 Jun 2006 11:06:58 -0400
Hi, Art,
On Jun 26, 2006, at 5:41 PM, Art Isbell wrote:
On Jun 25, 2006, at 10:32 PM, email@hidden wrote:
If you have a 'to many' relationship for which there may be
1,000,000 EO's in the fault then it is typically quite impractical
to actually use this relationship because the poor system would
need to load in 1,000,000 objects all the time! This is a typical
scenario where a one-way relationship (the 'to-one') is a better
idea.
Another case where a reverse relationship is bad news is when you
have 'reference data' entities such as "ConsignmentType" for a
"Consignment" EO. In such a situation, the "ConsignmentType"
might be read-only, cache in memory and reside in the 'shared
editing context'. One rule here is that you should not have a
relationship going from entities that live in a regular editing
context going into the shared editing context. So again, a non
reflexive relationship is the way to go there as well.
I believe that a distinction needs to be made between no inverse
relationship and an inverse relationship that's not marked as a
class property. By making the to-many inverse relationship not a
class property, EOF won't use it to keep the object graph
consistent (i.e., it won't fetch those 1,000,000 objects), but I
think EOF may still use this inverse relationship in ways that can
be beneficial. So I always include inverse relationships in my
eomodels but don't mark as class properties those to-many inverse
relationships that might cause unacceptable fetching activity.
Seems to work well for me.
That's an interesting conjecture. Are you aware of any reference
documentation or experimental results to support this position? It
seems equally likely (in my current state of ignorance) to provide
beneficial results, to simply consume extra unused resources or to
have no discernible effect. If beneficial results, I'd love to know
what they are. If extra unused resource consumption, then we'd all
probably be better to avoid the distinction as well as the inverse
relationship.
Regards,
Jerry
--
__ Jerry W. Walker,
WebObjects Developer/Instructor for High Performance Industrial
Strength Internet Enabled Systems
email@hidden
203 278-4085 office
_______________________________________________
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