> On 10/29/09 5:23 PM, Ben Trumbull said: > >>> 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: > > Ben, > > This is something I know and avoid, but it turns out this is what's > happening afterall! Thanks! > > Is there some way to catch such violations? I suppose I could implement > all relationship mutating methods, call backtrace(), and look for > awakeFromFetch. :)
Not really. But you can file a bug, and we can add an assertion to the debug library easily enough. Or we can enable change tracking in -awakeFromFetch. But that would mean generic setters will dirty newly fetched objects, and their containing documents, which people objected to, and resulted in the current behavior. > Basically, I have a controller class that uses KVO to observe all kinds > of things. And I'm suffering from a kind of spaghetti chain of KVO and > faulting. In my observeValueForKeyPath:ofObject:change:context: I > sometimes end up firing a fault of some object, which causes me to > reenter my observeValueForKeyPath: for some other 'context', which ends > up firing a fault of some other object, etc. At some point > awakeFromFetch is in the backtrace and at some later point I mutate a > relationship. Ick. Well, you can use prefetching to disentangle dependent controllers from firing too much stuff too lazily, or custom controller classes that override - (BOOL)fetchWithRequest:(NSFetchRequest *)fetchRequest merge:(BOOL)merge error:(NSError **)error; - 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
