On Sep 30, 2011, at 13:22 , Jerry Krinock wrote: > The trick is the order in which they are deleted. If the child NewObject7 is > deleted before its parent NewObject6, Undo will succeed. If the parent is > deleted first, Undo will fail. In my app, the order is random due to > enumerating an NSSet.
Yes, based on your last post I figured something like this, but I've been pondering where the "blame" lies. It would be interesting to know this: if you manually break the parent-child relationships before actually deleting either the parent or the child, does the order of the deletions matter? Presumably not. Also, do you invoke 'processPendingChanges' yourself during the enumeration, or do you just let it happen automatically? Also, what's the delete rule for the child's "parent" relationship? Surely not "Cascade"? If the delete rule for the parent's "children" relationship is "Cascade", then you're (conceptually) asking for the child to be deleted twice (once when the parent is explicitly deleted, once when the child is explicitly deleted during the enumeration). I've no doubt this is safe enough in terms of the deletions themselves, but I'm wondering if the way the sequence of undo steps get recorded for this just isn't robust enough in the case where the deleted objects are expunged (faulted out and removed from the persistent store) before the undo happens. _______________________________________________ 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
