On 2011 Sep 28, at 19:21, Dave Fernandes wrote: > I tried to reproduce this problem in my app and couldn't.
I'm not surprised because it took me two years to find this corner case. After adding sufficient AppleScriptability to my app, I'm now able to reproduce it with a failure rate of about 59% vs. 0% by switching a #if. I'm slowly closing in on it. > I got these types of exceptions in the past when I was using KVO with my > managed objects, but I no longer do that. Thanks – I'll look for those. > I deleted a child object and saved the document. Then I performed an undo > operation, and the child and its component were both correctly brought back > to life (I could edit both of them), even though the component had never been > faulted in before the delete. So Core Data is saving their attributes > somewhere other than the persistent store. 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. _______________________________________________ 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
