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
On Sep 30, 2011, at 12:06 AM, Quincey Morris wrote:
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
On Sep 30, 2011, at 00:17 , Jim Correia wrote:
You are assuming that the only place this information can exist is in the row
cache itself. The information can exist anywhere. At the risk of
over-trivializing the problem—It’s just code™.
All the information necessary to resurrect the
On 2011 Sep 30, at 00:06, Quincey Morris wrote:
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
On Sep 30, 2011, at 5:41 AM, Jerry Krinock wrote:
I'm still working on this issue, trying to find the trigger which moves my
corner case into the corner, hoping for a workaround. It's tedious because
of different operations and states.
But you have a pretty reliable way to reproduce the
I've found the workaround, at least.
Objects are in a tree formation with parent and children relationships. Delete
Rule is Cascade.
Steps to reproduce:
• Open a particular document which contains 4 objects
Root1
OldObject2
OldObject3
OldObject4
• Insert 3 new
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
On 2011 Sep 30, at 14:39, Quincey Morris wrote:
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?
Invoking either -setParent:nil or -setChildren:nil on
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
On 2011 Sep 29, at 11:20, Quincey Morris wrote:
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:]…
If I'm right, you should be clearing the undo stack at
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
I tried to reproduce this problem in my app and couldn't. I got these types of
exceptions in the past when I was using KVO with my managed objects, but I no
longer do that. If you aren't either, then I don't have any other suggestions.
In my app, I have parent objects with many child objects
On 2011 Sep 26, at 11:57, Dave Fernandes wrote:
Does the deleted object have relationships?
Yes. The object is of entity Foo which are classic tree nodes. There is a
root Foo; Foo objects have to-one parents and to-many children, etc.
What is the state of those objects?
It's always the
On Sep 25, 2011, at 11:13 PM, Jerry Krinock wrote:
I'm debugging a corner case wherein undoing a group containing deletion of a
managed object causes a Core Data could not fulfill a fault exception on
this object. It would help to understand exactly how managed objects are
un-deleted.
On 2011 Sep 26, at 03:48, Richard Somers wrote:
My rough testing of a managed object (no undo grouping) produced the
following results…
Thank you, Richard. I agree with those results.
Regarding the contents of the undo and redo stack you could inspect it's
contents using something like
Jerry,
Does the deleted object have relationships? And if so, what is the state of
those objects?
Dave
On 2011-09-26, at 2:27 PM, Jerry Krinock wrote:
On 2011 Sep 26, at 03:48, Richard Somers wrote:
My rough testing of a managed object (no undo grouping) produced the
following results…
On Sep 26, 2011, at 12:34 PM, Jerry Krinock wrote:
Note: It looks like we have a private discussion going on here. I'm not sure
if that was intentional. Anyhow…
Another individual took it private for some reason.
As I said, nothing is being fetched at this point. As I said in my other
I'm debugging a corner case wherein undoing a group containing deletion of a
managed object causes a Core Data could not fulfill a fault exception on this
object. It would help to understand exactly how managed objects are un-deleted.
If I delete a managed object, and then save (or if Cocoa
18 matches
Mail list logo
