Re: CoreData - NSManagedObjectContext notifications - Save vs DidChange ?
Re: CoreData - NSManagedObjectContext notifications - Save vs DidChange ?
- Subject: Re: CoreData - NSManagedObjectContext notifications - Save vs DidChange ?
- From: Simon Liu <email@hidden>
- Date: Thu, 6 Oct 2005 12:55:11 +0100
Hi Chris,
I think I need clarification on core data behaviour as I might be
expecting something to happen when it shouldn't. It's not a UI issue
as I've checked the attribute values.
I have several managed object contexts, backed by a single persistent
store coordinator. Are changes made in one context reflected in the
others after invoking -refreshObject: when receiving Change and Save
notifications? Originally I thought yes...
However it seems that its only possible after invoking -save: on the
private context first. The docs for -refreshObject:mergeChanges:
state:
"If flag is falseNO, then object is invalidated (in its current state
in the context) and returned to the value from the store (or the last
cached state)—any pending changes are lost."
My change notifications are triggered by changes in my private
context, so when I then get the objectIDs and try to refresh the
corresponding objects in the public context, nothing happens as the
store hasn't been updated yet. The store contains the old value, so
the public context just uses that value, while my private context
contains the new value.
Is this the correct behaviour? That changes made in different
contexts to a single store need to be saved in order for the changes
to be seen by all contexts (assuming they refresh the changed
objects)?
--Simon
On 10/6/05, Chris Hanson <email@hidden> wrote:
> On Oct 5, 2005, at 1:38 PM, Simon Liu wrote:
>
> > This works okay if during my background thread's computation, I invoke
> > -save: on the private context. I have a notification handler to handle
> > NSManagedObjectContextDidSaveNotification. The handler is
> > responsible for
> > taking the updated objects from the private context and refreshing
> > them in
> > the application's shared context. So all good...
>
> Notifications are delivered in the same thread in which they are
> posted. They are not enqueued across threads or anything of the
> sort. So when handling a notification from the thread's context, you
> need to use a cross-thread communication mechanism to update your
> human interface.
>
> One possibility is to use -
> performSelectorOnMainThread:withObject:waitUntilDone: from within
> your notification handler.
>
> -- Chris
>
>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden