On Sep 28, 2009, at 17:20, Luke Evans wrote:
I have an entity (A) that has a to-one relationship with another
very simple abstract entity (B), a kind of an enumeration, whose
mere type represents the value. As a kind of enumeration value, the
B entity has a fixed number of concrete subentities, with no
properties, and the B entity has a single relationship property
pointing back to A (i.e. this inverse relationship). The
relationship from A to B is set as required (non-optional) as I want
to make sure that any saved A, is defined properly with a particular
B enumeration value which controls behaviour.
None of that is _probably_ relevant, but it provides a little
background.
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.
From the Department of FWIW:
-- This sort of behavior is typical (in other contexts) of duplicate
objects, the one you're looking at that's OK and the one you're not
looking at that's causing the error.
-- I wonder if the B object is *really* in the same MOC as A, or if
the new B object happens to be flagged as deleted.
-- If you're in a position to play around with the Core Data model,
you could try making the relationship optional, and see if the save
succeeds and what you get back the next time you fetch from the store.
-- What happens if you make B concrete? If you create a B instance
instead of a sub-entity instance? (I have no reason to suspect
abstract parent entities of malfunctioning, but they do seem to sit
somewhat uneasily in the Core Data universe.)
-- Perhaps the save error means something other than what it appears
to mean, or refers to a property other than the one it appears to
reference.
_______________________________________________
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
