calling willChangeValueForKey on NSManagedObject causes fetch of unrelated to-many relationships
calling willChangeValueForKey on NSManagedObject causes fetch of unrelated to-many relationships
- Subject: calling willChangeValueForKey on NSManagedObject causes fetch of unrelated to-many relationships
- From: "Barry Wark" <email@hidden>
- Date: Wed, 19 Sep 2007 12:44:31 -0700
I'm in search of help debugging a CoreData problem. Clearly, the fault
is mine but because of bindings and CoreData, I'm having a really hard
time tracking down the cause of the problem. Any suggestions or
pointers for strategy would be greatly appreciated. Here's a
simplified description of my problem:
In the schema of my CoreData app, I have an entity Foo with to-many
relationships to Bar and Bazz entities, as well as to-one
relationships to other entities. Foo also has a boolean property
fooProperty. I have generated NSManagedObject subclasses for all
entities. Calling [fooInstance setFooProperty:] seems to take a
surprising amount of time. I set the -com.apple.CoreData.SQLDebug 1
argument for my app's executable and find that the call to
setFooProperty fires the fault for all of the to-many relationships
for fooInstance. Stepping through setFooProperty in the debugger, I
see that the fault is fired on the call to
willChangeValueForKey:@"fooProperty".
In the app's UI, I have an NSArrayController bound to an array of Foo
in my document which is the data source for an NSTableView.
Can anyone suggest, from this obviously simplified example, why the
to-many relationships faults would fire when I try to set a property's
value? I'd guess that I've mistakenly created some observer for the
fooProperty that tries to access the bar and baz relationships. How
can I find this observer? I tried overriding valueForKey/KeyPath: and
mutableSetValueForKey/KeyPath in Foo and setting a breakpoint if the
key was one of the to-many relationships, but apparently none of these
methods are called in firing the fault. I'm now at a bit of a loss to
figure out why these faults are firing...
Thanks,
Barry
_______________________________________________
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