Re: KVO and Core data
Re: KVO and Core data
- Subject: Re: KVO and Core data
- From: Michael Swan <email@hidden>
- Date: Mon, 09 Aug 2010 07:24:48 -0400
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, email@hidden wrote:
> Message: 15
> Date: Mon, 9 Aug 2010 20:51:44 +1000
> From: Gideon King <email@hidden>
> Subject: KVO and Core data
> To: cocoa-dev List <email@hidden>
> Message-ID: <email@hidden>
> 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 (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