Re: Core Data : Undo Delete : Cannot fulfill a fault
Re: Core Data : Undo Delete : Cannot fulfill a fault
- Subject: Re: Core Data : Undo Delete : Cannot fulfill a fault
- From: Jim Correia <email@hidden>
- Date: Thu, 29 Sep 2011 22:52:45 -0700
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 (email@hidden)
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:
This email sent to email@hidden