Re: EOSharedEditingContext and ObjectsChangedInStoreNotification
Re: EOSharedEditingContext and ObjectsChangedInStoreNotification
- Subject: Re: EOSharedEditingContext and ObjectsChangedInStoreNotification
- From: Dov Rosenberg <email@hidden>
- Date: Tue, 14 Sep 2004 11:24:07 -0400
When we use the JMS Change Notification we use 2 different editingcontexts.
If the data is read only we use the shared editing context otherwise we use
a regular editing context.
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
>
> On Sep 13, 2004, at 9:46 PM, Dov Rosenberg wrote:
>
>> Hunter,
>>
>> I our code we don't worry about inserts or deletes since most of our
>> application is read only. We created a delegate to implement our update
>> processing. If your shared context is not reflecting the changes, make
>> sure
>> the objects are actually in a shared editing context. I seem to
>> remember
>> somewhere that if an EO is retrieved in a regular editingcontext and is
>> changed EOF won't put the EO in the shared editing context.
>>
>>
>>
>> On 9/13/04 7:49 PM, "Chuck Hill" <email@hidden> wrote:
>>
>>> You could register an object with NSNotificationCenter as an
>>> omniscient
>>> listener and log out all notifications. That might show something.
>>>
>>>
>>> On Sep 13, 2004, at 4:17 PM, Hunter Hillegas wrote:
>>>
>>>> Chuck,
>>>>
>>>> Interesting thought. I looked and it wasn't explicitly set, so I
>>>> modified the code.
>>>>
>>>> Still, App 1 makes a change and App 2 sees it and invalidates the
>>>> GlobalID but the change doesn't show up in the Shared EC.
>>>>
>>>> Do you know of any logging I could turn up to see if the chain is
>>>> broken somewhere inside App 2?
>>>>
>>>> Hunter
>>>>
>>>> On Sep 13, 2004, at 10:51 AM, Chuck Hill wrote:
>>>>
>>>>> One thing that comes to mind is that the framework might not be
>>>>> refetching the objects into an ec with its shared editing context
>>>>> set
>>>>> to null. For details see:
>>>>>
>>>>> http://www.wodev.com/cgi-bin/WebObjects/WODev.woa/wa/Main?
>>>>> wikiPage=HowToUseSharedEditingContexts
>>>>>
>>>>>
>>>>> Chuck
>>>>>
>>>>> On Sep 13, 2004, at 10:34 AM, Hunter Hillegas wrote:
>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> According to the docs for EOSharedEditingContext, it will listen
>>>>>> for
>>>>>> notifications of the type ObjectsChangedInStoreNotification.
>>>>>>
>>>>>> I am using Dov's JMS change notification framework posted at
>>>>>> WOCode.com - it is based on the code from Wonder with some
>>>>>> important
>>>>>> changes.
>>>>>>
>>>>>> Anyway, the JMS messages are flowing and being processed. When
>>>>>> changes are made in one app, the other app receives the JMS message
>>>>>> and calls invalidateObjectsWithGlobalIDs.
>>>>>>
>>>>>> The thing is, the contents of the EOSharedEditingContext don't
>>>>>> appear to change.
>>>>>>
>>>>>> Subsequent calls to objectsByEntityNameAndFetchSpecificationName()
>>>>>> seem to return the unchanged/original data.
>>>>>>
>>>>>> I was under the impression that invalidateObjectsWithGlobalIDs
>>>>>> would
>>>>>> send a ObjectsChangedInStoreNotification and the Shared EC would do
>>>>>> as the docs state:
>>>>>>
>>>>>> "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."
>>>>>>
>>>>>> I don't see any evidence of a refault (output is the original
>>>>>> values).
>>>>>>
>>>>>> So... Any ideas on how to troubleshoot this?
>>>>>>
>>>>>> Is there a way to watch/print out
>>>>>> ObjectsChangedInStoreNotifications
>>>>>> as they are dispatched? Is there a way to watch when the shared EC
>>>>>> invalidates/refaults some of its contents?
>>>>>>
>>>>>> Am I mistaken about how this should work?
>>>>>>
>>>>>> Thanks,
>>>>>> Hunter
>>>>>>
>>>>>> _______________________________________________
>>>>>> Do not post admin requests to the list. They will be ignored.
>>>>>> Webobjects-dev mailing list (email@hidden)
>>>>>> Help/Unsubscribe/Update your Subscription:
>>>>>> email@hidden
>>>>>>
>>>>>> This email sent to email@hidden
>>>>>
>>>>
>>>
>>> _______________________________________________
>>> Do not post admin requests to the list. They will be ignored.
>>> Webobjects-dev mailing list (email@hidden)
>>> Help/Unsubscribe/Update your Subscription:
>>> 40conviveo
>>> 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:
>> 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