On Aug 9, 2010, at 08:13, Gideon King wrote: > Yes, Ben helped me a lot with sorting out the underlying issues, which turned > out to be a number of misunderstandings about what various methods in the > atomic store are supposed to do, what is required, etc etc. And at the time, > we had got to a point where we could save, save as, open and save, and it all > worked, but this is the first time we have revisited the whole file saving > thing after making a bunch of changes to the model and lots of KVO stuff, and > either there were inherent problems that we didn't see before because we > weren't observing attributes like this, or we may have introduced issues that > weren't there before. > > Dave's idea of using + (NSSet*)keyPathsForValuesAffecting<Key> may help in > some situations, but I don't think it's practical for all, especially where > I'm using KVO for my front end to observe changes in the back end and react, > where I sometimes need to know the before and after values. I'd have to think > about that some more... > > I hadn't thought about the faulting and refetching issue, and I do need to > support 10.5, so don't have the awakeFromSnapshotEvents available to me. > > [...] > > On 10/08/2010, at 12:20 AM, Keary Suska wrote: > >> >> The trace shows that the destination has been invalidated before your object >> is faulted, and so the exception is raised when it tries to remove >> observation. Invalidated object references should be rare--I would expect >> Core Data to "clean up" relationships when a MOC is reset but that does not >> appear to be the case (at least not all the time). Have you re-looked at the >> issues around the question you asked back in >> April:http://www.cocoabuilder.com/archive/cocoa/284398-invalidated-managed-objects.html >> ?
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 (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
