Gideon, It looks like you have an NSManagedObject that is observing itself. If this is in fact the case what is the objective? There may be a better way to accomplish your goal if you let us know what it is.
Mike Swan ETCP Certified Entertainment Electrician http://www.michaelsswan.com "As human beings our greatness lies not so much in being able to remake the world... as being able to remake ourselves" - Gandhi On Aug 9, 2010, at 6:59 AM, cocoa-dev-requ...@lists.apple.com wrote: > Message: 15 > Date: Mon, 9 Aug 2010 20:51:44 +1000 > From: Gideon King <gid...@novamind.com> > Subject: KVO and Core data > To: cocoa-dev List <cocoa-dev@lists.apple.com> > Message-ID: <55ff7ff0-18be-4e88-93b5-28d1da2bf...@novamind.com> > Content-Type: text/plain; charset=us-ascii > > 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). > > > A sample trace: > > The NSManagedObject with ID:0x1240033c0 > <x-coredata://53D12C5C-31DB-4287-89B2-E03CF59EB066/TopicMapView/pDC99795E-2B94-4721-BCFF-AB3945EC74D2> > has been invalidated. > 0 CoreFoundation 0x00007fff88f0fcc4 > __exceptionPreprocess + 180 > 1 libobjc.A.dylib 0x00007fff823880f3 > objc_exception_throw + 45 > 2 CoreData 0x00007fff8836911a > -[_NSInvalidationFaultHandler fulfillFault:withContext:] + 106 > 3 CoreData 0x00007fff8830bdbe > _PF_FulfillDeferredFault + 254 > 4 CoreData 0x00007fff8830fab7 > _sharedIMPL_pvfk_core + 87 > 5 CoreData 0x00007fff8830fc28 > -[NSManagedObject(_PFDynamicAccessorsAndPropertySupport) > _genericValueForKey:withIndex:flags:] + 40 > 6 CoreData 0x00007fff883154be -[NSManagedObject > valueForKey:] + 270 > 7 Foundation 0x00007fff868594e5 > -[NSKeyValueNestedProperty object:didRemoveObservance:recurse:] + 86 > 8 Foundation 0x00007fff86858d3b > -[NSObject(NSKeyValueObserverRegistration) _removeObserver:forProperty:] + 190 > 9 Foundation 0x00007fff86858c1f > -[NSObject(NSKeyValueObserverRegistration) removeObserver:forKeyPath:] + 135 > 10 Foundation 0x00007fff86859502 > -[NSKeyValueNestedProperty object:didRemoveObservance:recurse:] + 115 > 11 Foundation 0x00007fff86858d3b > -[NSObject(NSKeyValueObserverRegistration) _removeObserver:forProperty:] + 190 > 12 Foundation 0x00007fff86858c1f > -[NSObject(NSKeyValueObserverRegistration) removeObserver:forKeyPath:] + 135 > 13 NMFoundation 0x00000001002bbe6f -[NMTopicNodeMO > stopObserving] + 279 > 14 NMFoundation 0x00000001002b1f23 -[NMManagedObject > willTurnIntoFault] + 235 > 15 NMFoundation 0x00000001002bc070 -[NMTopicNodeMO > willTurnIntoFault] + 347 > 16 CoreData 0x00007fff88316be0 -[NSFaultHandler > turnObject:intoFaultWithContext:] + 96 > 17 CoreData 0x00007fff88316572 > -[NSManagedObjectContext reset] + 578 > 18 CoreData 0x00007fff8836e0d3 > -[NSPersistentStoreCoordinator(_NSInternalMethods) > _retainedAllMigratedObjectsInStore:toStore:] + 1379 > 19 CoreData 0x00007fff8836bb54 > -[NSPersistentStoreCoordinator > migratePersistentStore:toURL:options:withType:error:] + 676 > 20 AppKit 0x00007fff837fdd5c > -[NSPersistentDocument > writeToURL:ofType:forSaveOperation:originalContentsURL:error:] + 432 > > > > TIA > > Gideon _______________________________________________ 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
