Re: Help with understanding relationships
Re: Help with understanding relationships
- Subject: Re: Help with understanding relationships
- From: Chuck Hill <email@hidden>
- Date: Sat, 11 Oct 2003 19:48:55 -0700
I'll take stab at this.
First, and most importantly, unless you are doing something funky or are
working on an optimization you should not be using these methods. The most
appropriate methods to use are
addObjectToBothSidesOfRelationshipWithKey
removeObjectFromBothSidesOfRelationshipWithKey
These are documented in EORelationshipManipulation. They maintain object
graph consistency which is usually a very good thing.
Second, these methods are more about object graph consistency than about
database keys. Remember that you are working with Java objects and not
just wrapped rows from the database. In fact, until you save an object
there are no primary or foreign keys at all. Don't focus on the database
view of things, it does not help in understanding EOF. While the existence
of a database join might imply a reciprocal relationship between your Java
objects, it is possible for this to be setup one sided in the actual Java
objects particularly just after creation.
OK, now that I've got that off my chest... :-)
The EORelationshipManipulation docs state (paraphrased somewhat):
The two methods addObjectToBothSidesOfRelationshipWithKey and
removeObjectFromBothSidesOfRelationshipWithKey are implemented in terms of
the two primitives
addObjectToPropertyWithKey and removeObjectFromPropertyWithKey to handle
reciprocal relationships. The primitive methods first check for a method
you might implement, addToKey or removeFromKey, invoking that method if
it's implemented...
So the addObjectToPropertyWithKey and removeObjectFromPropertyWithKey
methods are primitive functions on an EOEnterpriseObject used to implement
the popular addObjectToBothSidesOfRelationshipWithKey and
removeObjectFromBothSidesOfRelationshipWithKey. The only reason to call
the primitive methods directly is if you did not want the inverse
relationship set/cleared. The only reason that I can think of for that is
optimization. In order to change the inverse relationship the objects need
to be fetched into memory. For relationships with lots of objects which
are not already in memory this can get expensive. If the objects are not
already in memory and nothing in the related object needs to be updated (no
key column to be nulled) there is little benefit in fetching the objects
and setting a Java property to null. When these objects are later fetched
their relationships will show the correct value due the presence of lack of
a join in the database. I'm sure you can see other similar situations in
which optimizations are possible.
The methods includeObjectIntoPropertyWithKey and
excludeObjectFromPropertyWithKey are a bit more of a mystery. They are new
in the API in WO 5.2. I think they were added to make implementation of
addToKey and removeFromKey easier and consistent. The docs for
includeObjectIntoPropertyWithKey say, "Adds to the relationship named key
the object eo without affecting inverse relationships, by directly
modifying the property storing the to-many relationship." And, perhaps
more importantly, "this method can be used from inside of methods of the
form addToKey."
So it appears that addObjectToBothSidesOfRelationshipWithKey calls
addObjectToPropertyWithKey on each of the objects involved.
addObjectToPropertyWithKey calls addToKey which *can* (but does not have
to!) be implemented with includeObjectIntoPropertyWithKey. As such, it is
probable that addObjectToPropertyWithKey does little else than pass the
message onto addToKey or includeObjectIntoPropertyWithKey. Calling
addObjectToPropertyWithKey gives the implementing object the opportunity to
provide custom behaviour by implementing addToKey (or, worse,
includeObjectIntoPropertyWithKey). Calling
includeObjectIntoPropertyWithKey directly prevents custom code in addToKey
from being executed.
So, in summary:
- use addObjectToBothSidesOfRelationshipWithKey if at all possible
- use addObjectToPropertyWithKey if you have a well thought out reason to
not set the inverse
- put custom code to be run when a relationship is set in addToKey
- avoid calling or overriding includeObjectIntoPropertyWithKey
The same goes for the remove / exclude.
HTH
Chuck
At 10:14 PM 11/10/2003 +1300, Ray Ackland wrote:
>I have been reading though the API reference material, and am suffering
>a little confusion when reading about some relationship functions.
>
>Firstly, can someone tell me what is the difference between the two
>methods addObjectToPropertyWithKey(Object eo, String key) and
>includeObjectIntoPropertyWithKey(Object eo, String key) and the
>corresponding pair of exclude... & remove....
>
>Also, when the documentation talks about "Adds to the relationship
>named key the object eo without setting inverse relationships", I am
>thinking there is something I don't understand about relationships.
>
>I always thought that two objects would be related if the shared the
>same value in the relevant keys. In a one-to-many relationship the
>primary key of the first entity equals the foreign key in the target
>entity. If this is correct, how does an object get removed from one
>side of the relationship without affecting the reverse?
>
>If A<->>B then a.primaryKey = b.foreignKey. I assume this relationship
>would be broken by changing b.foreignKey to match some other value or
>null. Wouldn't that break the relationship in both directions?
>
>What is it I am overlooking?
>
>Ray.
>_______________________________________________
>webobjects-dev mailing list | email@hidden
>Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/webobjects-dev
>Do not post admin requests to the list. They will be ignored.
>
--
Chuck Hill email@hidden
Global Village Consulting Inc. http://www.global-village.net
_______________________________________________
webobjects-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/webobjects-dev
Do not post admin requests to the list. They will be ignored.