On Sep 29, 2011, at 11:20 AM, Quincey Morris wrote: > 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.
That documentation is unfortunately confusing. Someone should file a bug to have it clarified. Core Data’s undo stack does allow you to undo past the last save point. And if it didn’t, it would remove actions from the undo manager, resulting in a disabled undo menu, not leave a bunch of actions on the undo stack that would generate exceptions if the user had the nerve to actually keep undoing past the last save point. > If I'm right, you should be clearing the undo stack at a save, at least if > there are deleted objects in the picture. If you in fact had to do this, this would be a pretty grievous bug. If the MOC registers actions with its undo manager that it can no longer deal with, it should be the one who removes them or clears the stack. A trivial NSPersistentDocument sample application handles undo correctly across save boundaries for both property changes and deletes. Jerry Krinock wrote: > It's always the same "exceptional" object which whose deletion is unable to > be undone because Core Data could not fulfill a fault. Its parent is an > object that was not deleted and therefore does not need to be restored. It > has one child which has already been successfully restored at the time the > exception occurs. Have you broken at the point of objc_exception_throw for the NSObjectInaccessibleException and examined what, specifically, is firing the fault? Start here and work backwards and you may be able to infer why someone has a reference to a stale object. At the very least you’ll know who. (You’ve already got the type and ID of the stale object.) If you can isolate this into a standalone sample, (and in the process haven’t found a bug in your code causing it) you can file a radar and post a link to the sample here and maybe we can offer further advice. —Jim_______________________________________________ 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
