Re: Relation oddity
Re: Relation oddity
- Subject: Re: Relation oddity
- From: Art Isbell <email@hidden>
- Date: Mon, 26 Jun 2006 11:41:57 -1000
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.
Aloha,
Art
_______________________________________________
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