Re: EOSharedEditingContext and ObjectsChangedInStoreNotification
Re: EOSharedEditingContext and ObjectsChangedInStoreNotification
- Subject: Re: EOSharedEditingContext and ObjectsChangedInStoreNotification
- From: Hunter Hillegas <email@hidden>
- Date: Tue, 14 Sep 2004 14:00:39 -0700
Dov,
I think the error message text is mis-leading in this case.
I just did a test as follows where the shared EC is bound/fetched into
at app startup and NOTHING else is fetched into any other EC.
Fired off a change in App 1 and App 2 received it and threw the same
error. Since nothing else had been fetched, I would think that the a
condition where a related EO was in another EC would be impossible.
Using an EC that doesn't have the shared editing context set to null to
update an EO that is in a shared EC seems to directly contradict
Apple's instructions. But it works for you?
Hunter
On Sep 14, 2004, at 11:52 AM, Dov Rosenberg wrote:
I think what that error message is saying is that the EO you are
dealing
with might have a relation to another EO that is not in the shared
context
or vica versa.
For example, you have a Hotel entity in App2 that was retrieved into
the
shared context. If Hotel has a relationship to another entity - say
HotelEvent that was retrieved using a regular editing context, you
might get
the error shown below.
Since shared editing contexts are supposed to be read only, you need
to make
sure that regular editing contexts are used when you have any form
actions
that update any data via EOF.
Shared Editing Contexts are pretty useful but you need to be real
careful
about what gets retrieved with them and their relationships. The key
is to
use shared editing contexts ONLY with data that isn't going to be
changed
(including the relationships).
Our app does not use the session.defaultEditingcontext() as a general
rule.
The primary reason was to make sure we didn't mix shared and non
shared Eos.
On 9/14/04 2:27 PM, "Hunter Hillegas" <email@hidden> wrote:
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)
--
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