Hi, Art,

On Jun 26, 2006, at 5:41 PM, Art Isbell wrote:

On Jun 25, 2006, at 10:32 PM, [EMAIL PROTECTED] 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 PROTECTED]
    203 278-4085        office



_______________________________________________
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]

Reply via email to