On Sep 29, 2011, at 06:22 , Jerry Krinock wrote: > That's interesting that this occurs even if the object has never even been > faulted in. Further confirmation of my conclusion, and yours, that Core > Data is saving attributes elsewhere. I recall that the heavy lifter in a > Core Data undo invocation seems to be -[NSManagedObjectContext _undoUpdates], > which has no parameters. So, it's like NSManagedObjectContext has its own > internal undo stack which, among other things, stashes the attributes of > faulted objects, in case they need to be resurrected to fulfill an undo. In > my corner case, at least one of those attributes are unavailable 59% of the > time. > > If anyone knows any more about this mechanism, the info would be appreciated.
I think the answer to your original question is that You're Doing It Wrong™. :) I'm pretty sure (though I never really thought about it before today) that Core Data undo *doesn't* work across 'save:' boundaries. The documentation for [NSManagedObjectContext undo:] says this: > "Sends an undo message to the receiver’s undo manager, asking it to reverse > the latest uncommitted changes applied to objects in the object graph." Note that word "uncommitted". After 'save:', all changes are committed, so you're not permitted to undo past that point. At least, that's how I read it. I think I can also advance an explanation why it works part of the time. This is based on my Core Data entrail-readings from Leopard days, so it's only guesswork, and things may have changed since then. Take this with a grain of salt. Core Data accesses property data at least 3 levels: (#1) what's in the persistent store (i.e. on disk); (#2) what pointed to by fault-fulfilled objects (i.e. value objects in memory); (#3) an internal cache of property data previous read from the store. This last is not tied to the existence of any particular object, it's just a historical cache. If you delete an object (thereby allowing its property values to be flushed from memory), then try to undo the deletion, the object may not be able to be restored to its original state from #2, because those value objects have been released. If you've *also* done a 'save:' after the deletion but before the undo, that's certainly the case, plus the object can't be restored to its original state from #1, because it doesn't exist there any more. However, the object *can* (apparently, I'm guessing) be restored from #3 *if* its properties happen to still be in the cache. In many, many cases of undoing fairly soon after the deletion (perhaps 41% of the time in your testing scenario), the property data will still be available. The rest of the time, well, you'll suck a big fulfillment failure. If I'm right, you should be clearing the undo stack at a save, at least if there are deleted objects in the picture. Alternately, I'm completely wrong. _______________________________________________ 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
