Re: EOSharedEditingContext and ObjectsChangedInStoreNotification
Re: EOSharedEditingContext and ObjectsChangedInStoreNotification
- Subject: Re: EOSharedEditingContext and ObjectsChangedInStoreNotification
- From: Dov Rosenberg <email@hidden>
- Date: Tue, 14 Sep 2004 14:52:18 -0400
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