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 (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
