Appreciate the comprehensive reply there Quincey. My new post 'crossed over' with my receipt of your response, so I didn't have a change to read your notes before I posted my update - but the long and the short of it is that I've now fixed my problem but was still fishing for the 'why'.
I infer from your response something along these lines: Getting hold of (some) set object that holds the instantaneous references to the objects involved in a to-many relationship does not mean that you have got a hold of the relationship itself - merely a snapshot of the state of the relationship. That would suggest that the reason the working binding actually works is that internally the derived array controller posts messages *through the ** keypath* that is really what represents the relationship (or... I guess the object vended by -mutableSetValueForKey does the same). I guess I was under the impression that the _NSFaultingMutableSet was actually the same kind of proxy as the object returned by -mutableSetValueForKey, but evidence definitely suggests otherwise. Anyway, thanks again for your responses (I see another has just dropped into by inbox)... definitely helped to adjust my mental picture and interpretation of what to-many binding means. On Thu, Mar 17, 2011 at 10:25 PM, Quincey Morris < quinceymor...@earthlink.net> wrote: > On Mar 17, 2011, at 11:01, Luke Evans wrote: > > > The column for Territories in the master SalesRep table is bound so that > > cell values should be the relationship set. > > I'm not sure I can nail the problem down exactly, since your setup is > fairly complex, but I'm pretty sure the above is the cause of the problem. > There *isn't* any such thing as the relationship set, not really. > > If you request [salesRep valueForKey: @"Territories"] -- the property > really ought to be a lower-case "territories", BTW -- you'll get a set, but > it's just a set. Nothing promises that the set represents the relationship. > It's just a set of the things in the relationship, and could be a transient > object created only in response to your request for the related territories. > Since it's showing up as a _NSFaultingMutableSet, it's probably some kind of > set proxy whose internal implementation fetches actual objects lazily from > the Core Data store. > > Something like this: > > [[salesRep valueForKey: @"Territories"] addObject: someObject] > > doesn't mutate the relationship. For that, you need to use a mutable set > proxy: > > [[salesRep mutableSetValueForKey: @"Territories"] addObject: > someObject] > > That's what array controllers normally to do change relationships, I > believe. In your case, you've defeated this by using your so-called > relationship set directly. In other words, you've just connected your array > controller to a contentSet; you haven't actually bound anything that matters > to the "Territories" property of the salesRep object. > > At least, I think that's what's wrong. To fix it, I think you need to do > either of two equivalent things: > > a. pass the salesRep object and the name of the property "Territories" > through to the cell, rather than passing the transient set through, and > access the property via KVC, further downstream > > b. pass a mutable set proxy for the relationship through to the cell, and > connect the array controller to that > > Sorry if that all sounds a bit vague. > > > _______________________________________________ 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
