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: Quincey Morris <email@hidden>
- Date: Fri, 30 Sep 2011 00:06:59 -0700
On Sep 29, 2011, at 22:52 , Jim Correia wrote:
> 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.
"Should", yes. And perhaps what I've been suggesting is too outrageous for belief. However, there are a number of well-known examples of outrageousness. The most relevant one that I can think of is that NSPersistentDocument was originally released without (and may still not have, for all I know) support for NSDocument's "Save To…" behavior, as well as "Save As…" behavior that (apparently) went only as far as a successful default migration could carry it. In a different arena, there's the well known dangerousness of NSData under GC, and the fact that libSystem is marked as GC-compatible but isn't, not even nearly.
It would be nice if every violation of the API contract were enforced, but it's not so. Sometimes, it's necessary to read the documentation and be self-policing.
But I'd be more than happy to be shown wrong about this. :)
> A trivial NSPersistentDocument sample application handles undo correctly across save boundaries for both property changes and deletes.
The actual failure scenario I described has 2 necessary conditions. One is a save boundary. The other is the flushing of cached property information for the deleted object. The latter is difficult to cause, especially in a trivial example, since there's no API for affecting the cache directly, except for resetting the MOC, which would probably break undo for different reasons.
I guess the question here is this:
If it's true that deleting a managed object causes it to be turned into a fault at some point (at the next save boundary at the latest), and saving a managed context with a deleted object actually causes the object's persistent representation to be deleted from the persistent store, and post-save the object is still referenced by an undo action, what possible mechanism can re-populate the object's properties if the undo action is undone? By definition, the necessary information no longer exists.
_______________________________________________
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