Re: Core Data: Custom to-many relationship setter not being invoked
Re: Core Data: Custom to-many relationship setter not being invoked
- Subject: Re: Core Data: Custom to-many relationship setter not being invoked
- From: Ken Tabb <email@hidden>
- Date: Tue, 23 Feb 2010 19:08:10 +0000
On 23 Feb 2010, at 6:19, Quincey Morris wrote:
>> Adding is via a button going to an Employee array controller's -add. In the interface there are 2 array controllers (1 for Departments, 1 for Employees). The Employees controller is set to use the selection in the Departments controller (i.e. showing the subset belonging to the selected dept).
>
> You haven't actually told us the whole story. Calling the Employee array controller's 'add:' method causes a new Employee object to be created with default attributes and no relationships -- no Department. That means the code to assign it to a Department is elsewhere.
Sorry perhaps I didn't make myself clear. The button calls -add on an Employee array controller (standard NSArrayController), whose content set is bound to controller key "selection" and model key path "employees" of another standard array controller, containing Departments. So when the button tells the Employee controller to add a new employee, it adds it to the selected Department. i.e. standard Core Data demo stuff. So a new employee is automatically belonging to a department (the selected one in the GUI when the button was hit).
The Employee -awakeFromInsert isn't doing anything wacky, and doesn't touch the "department" attribute (it just calls super and then sets a data attribute to "today"). There is no -awakeFromFetch in Employee as nothing custom needs to be done upon fetching an Employee object.
Neither the Department nor Employee classes actually do any setting of attributes (i.e. nothing in my code is setting the specific Department for an Employee, nor which Employees belong to a Department). All that is being done by standard IB / Bindings methods (which I'm not overriding / subclassing). And as I say, if I look in the XML store after I have quit, all is well and properly hooked up (on each side).
If there's anything I'm missing out telling you here, by all means shout but I can't think of anything I'm withholding.
>> Adding and deleting Departments and Employees is fine (everything gets hooked up / added / deleted properly), and if I look in the XML Core Data store, all is well. It's just my custom accessors (the 4 mentioned below) don't get used, whereas -setEmployees does.
>
> If you did not try this already, set a breakpoint inside 'setEmployees:'. When you hit it, type the debugger command 'po [self class]' in the Xcode console window to find out the actual class of the Department object.
It tells me it's a Department object :)
>> Do you reckon it's because the adding is happening from the Employee side of things rather than the Department side of things? Shouldn't both sides have their accessor methods called (thanks to the inverse relationship)?
>
> There are no "sides" as far as adding objects is concerned. There are "sides" when you talk about establishing relationships, but we don't know how you do this yet. Also, the puzzle here is not whether accessor methods are being called, but which accessor methods are being called. The setter, for a to-many property, is kind of the worst-case fallback accessor, and KVC should prefer the more nuanced add/remove accessors if they are available.
>
>> I can't believe it's relevant, but the Department's 'employees' relationship is mandatory, as is the inverse relationship.
>
> No, it's not relevant -- such validation requirements are checked only when the Core Data store is about to be saved.
These last 2 theories were what I presumed, but you know how desperate the theories start to become after a while :)
Thanks again for your help and time,
Ken
. . . . . . . . . . . . . . . . . . . . . . . . . . .
Dr. Ken Tabb
Mac & UNIX programmer
Neural network & computer vision researcher
University of Hertfordshire, UK
_______________________________________________
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