re: KVO and Core data
re: KVO and Core data
- Subject: re: KVO and Core data
- From: Ben Trumbull <email@hidden>
- Date: Mon, 9 Aug 2010 15:43:57 -0700
> Hi all,
>
> I have a KVO registration like this:
>
> [self addObserver:self forKeyPath:@"toOne.attribute" options:0 context:NULL];
>
> I establish this on -awakeFromInsert or -awakeFromFetch, and have the corresponding removeObserver called on -willTurnIntoFault.
>
> The problem is that when I do a Save As on my document, it migrates the persistent store, which appears to cause the object at the destination of the toOne relationship to be turned into a fault before the object that registered as an observer is. Now when I check the observationInfo for the object that is being faulted (at the end of the toOne relationship), it has itself registered as an observer for "attribute".
>
> I guess this means that behind the scenes, the KVO establishes observation information automatically at every level of a key path (something I hadn't realized before, but which appears to make sense).
>
> Then something behind the scenes tries to access the attribute on an object that has been turned into a fault, and invalidated, and everything comes crashing down.
>
> So I have two questions:
>
> 1. Is it the "right way" for me to be adding observation on the awake methods and removing it on willTurnToFault?
>
> 2. If this is OK, then what could be affecting the system such that it doesn't remove the observation information in the destination of the to-one relationship? I'm wondering if there could be something in my data model that could be affecting it. This relationship is modeled as a one to one, with a delete rule of cascade from the parent to the child, and the inverse relationship is also modeled, with a deny rule. There's also another optional relationship from the child to the parent with a deny rule, modeled in one direction only (and not used in the data I am testing with anyway).
Your problem here is this MOC is being torn down, and the "toOne" managed object is already toast. So it's not possible to get its "attribute". KVO isn't really in a position to deal with this.
Probably the best solution is for the toOne object to traverse the inverse and tell it's parent when to add or remove the KVO observation. So this way when "attribute" is nuked, parent stops observing it.
Another possibility is to just have the accessor methods on "toOne" for the setter for "attribute" traverse the inverse manually and inform the parent outside of KVO.
- 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