Re: EOSharedEditingContext and ObjectsChangedInStoreNotification
Re: EOSharedEditingContext and ObjectsChangedInStoreNotification
- Subject: Re: EOSharedEditingContext and ObjectsChangedInStoreNotification
- From: Hunter Hillegas <email@hidden>
- Date: Tue, 14 Sep 2004 11:27:01 -0700
Interesting.
When I pass in an EC without the shared editing context set to null, I
get an exception:
61998 [Thread-1] DEBUG NSLog - Exception invalidating objects in
editing context. java.lang.IllegalArgumentException: EOEditingContext:
initializeObject: attempt to initialize object with global ID
_EOIntegralKeyGlobalID[Hotel (java.lang.Integer)1383] that exists in a
shared context via a non-shared context. The object model may have a
relationship from a shared entity to a non-shared entity. Disable or
remove the relationship from the model.
Based on Apple's documentation, I would actually expect this as it says
in there that you have to set the shared EC to null to get the changes
to propagate. I wonder if I am doing something wrong... I'm surprised
your technique is working and mine is not.
On Sep 14, 2004, at 11:19 AM, Dov Rosenberg wrote:
The editingcontext we send into the JMS subscriber DOES NOT have its
shared
editing context set to null. The ObjectStoreCoordinator notifies the
shared
context of the changes we generate in the editingcontext used by the
change
subscriber
Dov
On 9/14/04 1:41 PM, "Hunter Hillegas" <email@hidden> wrote:
Is the below true? If so, is it a bug?
It seems to be opposed by Apple's docs on EOSharedEditingContext:
"It is possible to modify shared objects while an application is
running, but only indirectly. A regular editing context can be created
that doesn't share objects by setting it's sharedEditingContext to
null. Fetch the object that is to be changed into the regular context,
modify or delete it, and save. Since shared editing contexts listen
for
ObjectsChangedInStoreNotifications, the shared editing context
updates
when it learns that an object was modified. The shared context removes
from its objectsByEntityName and
objectsByEntityNameAndFetchSpecificationName dictionaries any objects
that have been deleted, and it refaults any objects that have been
updated. However, to register newly inserted objects in the shared
editing context, it should be refetched."
http://developer.apple.com/documentation/WebObjects/Reference/API/com/
webobjects/eocontrol/EOSharedEditingContext.html
On Sep 14, 2004, at 8:24 AM, Dov Rosenberg wrote:
On 9/14/04 9:21 AM, "Karl Gretton" <email@hidden> wrote:
Dov is right. If you change an object after taking a local copy
into
an EC with the shared editing context set to null, no notification
is
sent to the shared EC and it will not reflect the update. You must
specifically retrieve the EO into the shared EO using a regular
fetch
specification.
Karl
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
dov.rosenberg@conviveo
n.com
This email sent to email@hidden
--
Dov Rosenberg
Conviveon Corporation
370 Centerpointe Circle, suite 1178
Altamonte Springs, FL 32701
http://www.conviveon.com
email@hidden
AOL IM: dovrosenberg
(407) 339-1177 x102
(407) 339-6704 (fax)
(800) 475-9890
(407) 310-8316 (cell)
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden