On Oct 29, 2009, at 16:55 , Sean McBride wrote:
> On 10/22/09 4:59 PM, Melissa J. Turner said:
>
>>> I have an entity 'Scene' with a to-many relationship to an entity
>>> 'Target'. The inverse relationship is also to-many. Both relationships
>>> are optional and the delete rule for both sides is nullify.
>>>
>>> To repro, I delete all Scenes then try to save. It gives:
>>>
>>> "Dangling reference to an invalid object." = <null>;
>>> NSAffectedObjectsErrorKey = (
>>> <BSScene: 0x2004ff940> (entity: Scene; id: 0x2004f32a0 <x-coredata://
>>> FCE3E0E3-F187-4C44-BFC3-60D7AF3E579F/Scene/p343> ; ...
>>>
>>> This error gives only 4 hits with Google. :(
>>>
>>> The problem is that some Targets still have relationships to some
>>> Scenes! How can that happen? It seems like the delete rule is not
>>> doing its job.
>>
>> Does the object with the ID <x-coredata://FCE3E0E3-F187-4C44-
>> BFC3-60D7AF3E579F/Scene/p343> exist in the affected store? What happens
>> when you call existingObjectWithID:error:?
>>
>> Do you know what version of the OS the bad documents were created on? A
>> lot changed in the relationship handling area in 10.6 (for the better,
>> really and truly ;-), so knowing whether your customers created them on
>> 10.5.x or 10.6.x would help narrow down the possibilities.
>
> Thanks Melissa and Ben for your replies!
>
> I have been working on this issue for days now and am getting
> increasingly confused. :)
>
> My coworker found a way to create a document (in 10.6.1) with almost the
> same problem as originally described (it complains about the inverse
> relationship instead).
>
> Examination of the XML document (as text) suggests that the object graph
> is ok.
>
> To repro: 1) open said document 2) delete a particular managed object 3)
> attempt to save -> receive "dangling reference" error. Repros 100%.
>
> I've also found that changing a particular line of my code prevents
> (100%) the error from occurring. Said line only runs when the document
> is opened (as a result of a controller getting a KVO notification).
>
> The entities in question are Scene and Target. Scene has a to-many
> 'targetsWeak' relationship. Target has a to-many 'scenesWeak'
> relationship. They are inverses. They are optional and nullify.
>
> The code snippet in question:
>
> NSSet* currentTargets = [scene targetsWeak];
> NSSet* additionallyDesiredTargets = <some fetch result>;
> BOOL isEqual = [currentTargets isEqualToSet:
> additionallyDesiredTargets];
> assert (isEqual);
> //if (!equal)
> {
> [scene addTargetsWeak:additionallyDesiredTargets];
> }
>
> It turns out that isEqual is always YES in this limited repro case.
> Therefore, I don't really need to change 'targetsWeak' (the 'if' body).
> But if I do anyway (the commented 'if'), I get the 'dangling reference'
> error. If I don't, I don't.
>
> Even if I do [scene addTargetsWeak:[scene targetsWeak]] I get the error.
>
> Does this make any sense to anyone?
The only caveat is you cannot change relationships from within -awakeFromFetch.
This is documented:
<http://developer.apple.com/mac/library/documentation/Cocoa/Reference/CoreDataFramework/Classes/NSManagedObject_Class/Reference/NSManagedObject.html#//apple_ref/occ/instm/NSManagedObject/awakeFromFetch>
Otherwise, if this repros 100% of the time, file a bug and we'll take a look at
it.
- Ben
_______________________________________________
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
