Re: Strange Core Data save behaviour ("required relationship nil"... when it is set the line before saving)
Re: Strange Core Data save behaviour ("required relationship nil"... when it is set the line before saving)
- Subject: Re: Strange Core Data save behaviour ("required relationship nil"... when it is set the line before saving)
- From: Luke Evans <email@hidden>
- Date: Tue, 29 Sep 2009 17:22:35 -0700
Hello Ben.
What happens if you add a call to -processPendingChanges in between
#2 and #3 ?
... well then everything works wonderfully (oh joy!!) :-)
OK. I need to get a proper mental picture of why this is needed in
this case.
I guess I was vaguely aware of this method from previous passes though
the Core Data docs, but...
- The method documentation itself doesn't _really_ suggest it may be
essential in some cases. Rather, the talk is about getting the undo
manager into step, and even then the statement is made that this is
done by default at the end of the run loop.
- deleteObject docs, or indeed the guide section on deleting (Creating
and Deleting Managed Objects) makes no mention of a need to call this
method
- I had tried manually setting the old deleted objects 'back
relationship' to nil, before deleting it, and before setting A's
relationship to the new B. This hadn't worked, but was my attempt to
keep the relationships consistent - at least in in the MOC that
induced the change.
It's tempting to just think that you should _always_ do a -
processPendingChanges before a -save:, but I'd prefer to understand
what's really happening here.
If you have insights on the above, then that would be great.
Regardless, you've just improved my humour by several degrees ;-)
-- Luke
On 2009-09-29, at 3:59 PM, Ben Trumbull wrote:
Now, I have some code that changes the value of the 'B enumeration
value' that A is using. This does the following:
1. Create a new instance of the B subentity that represents the value
we want (in the same MOC as A)
2. Delete the old B object that A was pointing to, i.e. [moc
deleteObject:B];
3. Set A's to-one relationship to point to the new B object (and for
good measure, set B's inverse relationship - though this should be
done automagically).
4. Save the moc
4. is where badness happens (failed to save). The error tells me
that
A's relationship property to B is nil... but just before I do the
save
I log the value of the object referenced by this relationship and
it's
the new 'B' object!
I have no idea what I've done to upset Core Data such that it
claims a
relationship is nil when I save, but the line before the [moc
save:&err], the relationship shows as referencing a perfectly good
object.
So you delete B, which has an inverse relationship to A. Then you
set a new B on A. Then you save, and delete propagation cleans up
the graph, nullifying the old B's inverse relationship ?
What happens if you add a call to -processPendingChanges in between
#2 and #3 ?
- Ben
_______________________________________________
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