• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: EOSharedEditingContext and ObjectsChangedInStoreNotification
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: EOSharedEditingContext and ObjectsChangedInStoreNotification


  • Subject: Re: EOSharedEditingContext and ObjectsChangedInStoreNotification
  • From: Hunter Hillegas <email@hidden>
  • Date: Tue, 14 Sep 2004 09:43:04 -0700

Dov,

The objects are explicitly fetched into a Shared EC using bindObjectsWithFetchSpecification().

Basically the flow goes like this:

App 1 starts up.

App 2 starts up. On startup it binds/fetches a list of hotels into the default shared editing context.

App 1 fetches a hotel into the session default editing context for a user. User makes a change to a text field. Change is saved to the database. Your framework sends a JMS message to the JMS topic.

App 2 sees that there was something posted to the JMS topic. It reads the change notification and I see that the global ID for the EO has been invalidated.

A component is requested by user of App 2. This results in objectsByEntityNameAndFetchSpecificationName() being called on the default shared editing context and sub-sequently the list of hotels is pulled from the shared EC. The hotel in question that was changed is displayed in the page and it is displaying the old values.

Based on that scenario, I am pretty sure that the EO should be coming from the shared EC... I would have expected objectsByEntityNameAndFetchSpecificationName() to notice that the EO's globalID was invalidated and have it refault the hotel that had been changed...

Am I misunderstanding how this should work?

hunter

On Sep 13, 2004, at 6: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:
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
  • Follow-Ups:
    • Re: EOSharedEditingContext and ObjectsChangedInStoreNotification
      • From: Dov Rosenberg <email@hidden>
References: 
 >Re: EOSharedEditingContext and ObjectsChangedInStoreNotification (From: Dov Rosenberg <email@hidden>)

  • Prev by Date: Re: Strange Bug (?)
  • Next by Date: Re: EOSharedEditingContext and ObjectsChangedInStoreNotification
  • Previous by thread: Re: EOSharedEditingContext and ObjectsChangedInStoreNotification
  • Next by thread: Re: EOSharedEditingContext and ObjectsChangedInStoreNotification
  • Index(es):
    • Date
    • Thread