Re: setting foreign key using an object in shared editing context (5.2.1)
Re: setting foreign key using an object in shared editing context (5.2.1)
- Subject: Re: setting foreign key using an object in shared editing context (5.2.1)
- From: Art Isbell <email@hidden>
- Date: Wed, 9 Jul 2003 20:37:18 -1000
On Wednesday, July 9, 2003, at 11:18 AM, Nick Pilch wrote:
I've come across a strange problem. I have an object that has a
relationship to a shared object. Both the foreign key in the main
object and the primary key of the shared object are *not* marked as
class properties. I am trying to populate the foreign key of a new
main object by calling takeValueForKey() with an existing shared
object. I see that the relationship is populated, but on
saveChanges(), the foreign key is never set! The SQL output shows EOF
just setting the foreign key to null.
(BTW, I've tried addObjectsToBothSidesOfRelationshipWithKey() instead
of takeValueForKey(), but there's no difference. There's no back
relationship anyway)
I make extensive use of shared objects in WO 5.2.1. I create
relationships between non-shared and shared objects with no problem
(i.e., the foreign key is set correctly). However, I always model an
inverse relationship for each relationship. Usually, I set only one of
these as a class property for performance reasons. Maybe not having an
inverse relationship is causing the foreign key to remain null.
Something that may come into play is that I am doing this in a
multi-threaded app in which each session has its own
EOObjectStoreCoordinator. However, I am testing using a single request
with no other requests being handled concurrently.
I don't think concurrent request handling is to blame, but I don't see
how having multiple object store coordinators could work without your
workaround (except for the one object store coordinator that is the
shared editing context's parent). The documentation for the
EOSharedEditingContext constructor states:
"Creates a new EOSharedEditingContext object with the default parent
object store as its parent object store."
So you're probably stuck setting the shared editing context of each
session's default editing context to null and creating local instances
of each shared object. This makes life much more difficult but is
probably unavoidable. At least each session doesn't have to fetch a
copy of each shared object.
Aloha,
Art
_______________________________________________
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.