Tarun,
The only situation where I ever saw what you describe happen was when
using a many-to-many relationship. Normally,
addObjectToBothSidesOfRelationship will end up calling your
setIdeasuser() on your aNewIdea object, and addToIdeas() on your
session's user. Check the documentation for addObjectToBoth...() to
see exactly what EOF's procedure for setting values is. Therefore,
what you state below is kind of self-contradicting.
So, in my eyes, it comes down to one of these:
1. You have a many to many relationship here (which seems weird for a
Person - Idea situation), in which case you really need to manually
call the methods you call to make sure that the object graph reflects
the new situation. If you do not it will only reflect the new
situation once you save changes to the database.
2. You have a screwed up model.
3. Another situation in which the generated setter methods would not
get called by EOF when you addObjectToBoth...(), even if you have a
many-2-one, is if EOF can not find your Java classes, and associate
them with the given entities. This seems unlikely though, as in the
code below your session's User is used as User and not as
EOEnterpriseObject. But, it technically *could* lead to the behavior
you describe. I think.
Maybe somebody else saw this behavior in another situation?
Best regards,
Florijan
I have an app where a User has a list of Ideas associated with it.
I use the following code to set that relationship:
aNewIdea.addObjectToBothSidesOfRelationshipWithKey(session.getUser(),
"Ideasuser");
However, unless I add this:
session.getUser().addToIdeas(aNewIdea);
then even though the database is correctly updated, User.getIdeas,
isn't up to date. Is it best practices to have both of these
relationships set? And do I need to go further and do a
aNewIdea.addUser(session.getUser());
to maintain that reverse relationship in memory? Or am I making
this harder than it seems...
Thanks,
Tarun
_______________________________________________
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/flor385%
40mac.com
This email sent to [EMAIL PROTECTED]
_______________________________________________
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]
