Re: KVO and Core data
Re: KVO and Core data
- Subject: Re: KVO and Core data
- From: Gideon King <email@hidden>
- Date: Tue, 10 Aug 2010 03:23:12 +1000
OK, it's well after 3am now, so I'll leave more detailed analysis until after some sleep.
The scenario is that of a simple Save As. As far as I am aware, I am not doing anything unusual in the process. I do not forcibly invalidate objects. It's a bit hard to track exactly what's happening, but I am able to look at the situation after willTurnIntoFault, and the observationInfo shows that the object at the destination of the to one relationship still has the key paths as registered by its parent established when it is made into a fault - i.e. I successfully established the observing at the parent level, which got automatically transferred to the child (without the first part of the key path), and then the child was faulted without the observing being removed...which is why I thought it might be some inconsistency with my model. I didn't establish that particular observation myself, so should not have to remove it myself.
I guess the topic did broaden from there to general issues around what is the right way to use KVO, as I have some other issues in my app related to it in other areas, and I'm looking for the recommended design patterns for KVO amongst core data entities, and between a core data backend and a gui controller front end.
I don't quite get why I should be passing in something for the context when setting up observing. I would have thought that that would be only for cases where either:
a) you actually want to use some context data
b) you have more than one key path the same and the observation object isn't enough information to give you the necessary context.
...neither of which is the case for my application.
Anyway, brain's fried...thanks for the help, and I'll check into it more in the morning...
Regards
Gideon
On 10/08/2010, at 2:57 AM, Quincey Morris wrote:
>
> But you haven't addressed Keary's excellent point that the problem is not with faulting, but with the observed object being invalidated (apparently). If faulting an observed object caused a crash, then I don't see how Core Data could work at all.
>
> Similarly, keyPathsForValuesAffecting<Key> seems like a red herring. It uses observation internally (perhaps setting it up via a fast path not available to applications), so it doesn't really change the picture.
>
> I think you will have to analyze the crash scenario more carefully. Essentially, you crashed in -[NMTopicNodeMO willTurnIntoFault], which I assume is one of your classes. What phase of the migration is this in -- is the object in the store being migrated from, or to? Does migration do something differently (such as forcibly invalidating objects) that doesn't happen in normal Core Data behavior, and therefore that your code doesn't expect or co-exist well with? Has the observation that's being "removed" at the time of the crash even been established, or is your willTurnIntoFault cause making an incorrect assumption about what happened earlier. Is it necessary, when an object turns into a fault during a migration, to just add a validation check that the observed object's ID is valid, before trying to remove the observation?
>
> TBH, I think you're going to have to be more disciplined in your analysis, and investigate one question at a time, rather than trying a scattershot approach.
>
> Note that, given the black-box nature of much Core Data behavior, it might not even be possible to formulate an answer about what's gone wrong. You may be better off submitting a bug report claiming that your app's reasonable behavior produces an unreasonable crash.
>
> One final point, which I doubt has anything to do with your crash, but may possibly be relevant:
>
>> [self addObserver:self forKeyPath:@"toOne.attribute" options:0 context:NULL];
>
>
> "NULL" is a terrible choice for the context parameter. Use a value that's unique (some people use a globally unique string, I use the class object of the observer -- the considerations are a larger discussion) to the observer. This is a defect in the KVO mechanism, BTW.
_______________________________________________
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