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 o
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
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 objects,
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 th
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 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 o
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
> exam
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 e
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
>
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
On Sep 29, 2011, at 06:22 , Jerry Krinock wrote:
> That's interesting that this occurs even if the object has never even been
> faulted in. Further confirmation of my conclusion, and yours, that Core
> Data is saving attributes elsewhere. I recall that the heavy lifter in a
> Core Data undo
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 5
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 tha
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 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
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 re
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 li
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
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 a
19 matches
Mail list logo
