Thanks Ben, after thought, this is indeed very logical and can be expected when you know Core Data. I came to the same conclusion but you phrased it much better than me :)
Aurélien, Objective Decision Team Le 21 déc. 2010 à 01:45, Ben Trumbull a écrit : > > On Dec 19, 2010, at 9:49 PM, Aurélien Hugelé wrote: > >> Hi! >> >> I think mergeChangesFromContextDidSaveNotification: does not work as most >> people expect: >> I have a mainthread and a subthread. My subthread updates a managed object >> (change one of the property value) and save. >> In the mainthread, I use [mainThreadContext >> mergeChangesFromContextDidSaveNotification:subThreadNotification]; and it >> merges the main thread context as expected (binded UI is updated) >> >> What is not expected is : >> >> 1/ asking the main thread for its updatedObjects (just after the >> mergeChangesFromContext... but before the save:) does not show the changes >> made in the subthread! So updated objects in subthread are not seen as >> updated in the main thread after the mergeChangesFromContext call! >> 2/ Saving the main thread generates a did save notification, that does not >> contain changes made in the subthread (and merged) ! >> >> The subthread is temporary (does it job in an NSOperation that terminates >> quickly), its context is also temporary. >> >> In the mainthread, *many* controllers are observers of the did save >> notification of the main thread context. How am I supposed to make them >> listen to changes made in a temporary, dumb, subthreaded managed context >> without using mergeChangesFromContext... call ??? >> >> I'm pertty sure, most developers expect the >> mergeChangesFromContextDidSaveNotification: API to really merge the data in >> the main thread context and set the merged updated objects as *really* >> updated, as if the change really occured in the main thread! > > > The method is merging the state into the receiving context purely from the > perspective of results. Deleted objects are deleted, updated objects have > new values, inserted objects exist. It does not replay the individual > changes, nor does it guarantee any particular path or implementation for > getting the state of MOC B to look like the state of MOC A. For efficiency, > it prefers refreshing existing objects from the PSC's cache over replaying > individual changes whenever possible. > > Refreshing is observable by KVO. These objects are also noted in the > NSManagedObjectContextObjectsDidChangeNotification with the > NSRefreshedObjectsKey. This is how NSArrayController observes these kinds of > events. > > The objects aren't "updated" in the sense that they'll be saved again. > Because they won't. They've already been saved a first time. They *were* > updated, and NSManagedObjectContext's -updatedObjects reports the state about > next upcoming save, not the last save. > > - Ben > _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
