On Jun 27, 2006, at 5:06 AM, Jerry W. Walker wrote:

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

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.

Are you aware of any reference documentation or experimental results to support this position?

Not really. Others have made this assertion over the years. And I've read things like the following from the EORelationship.anyInverseRelationship() method description:

"Searches the relationship's destination entity for any back- referencing relationship joining on the same keys. It first looks for a relationship defined in the model. If none is found, it looks for a "hidden" inverse relationship that was manufactured by the Framework. If none is found, the Framework creates a "hidden" inverse relationship for internal use and returns that."

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.

EOF appears to use inverse relationships, be they explicit or "hidden" (i.e., created by EOF) for some useful purpose. So if an inverse relationship isn't explicitly defined (e.g., in an eomodel or in custom code), EOF seems likely to create one ("hidden"). So it doesn't seem like additional resources would be consumed by explicitly creating inverse relationships.

Aloha,
Art

_______________________________________________
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