On Feb 10, 2011, at 7:28 PM, Quincey Morris wrote: > On Feb 10, 2011, at 12:59, WT wrote: > >> So, why doesn't it sort them correctly when it's accessing the "indexOrName" >> stored value? > > You *cannot* have an attribute that's both a derived property and a stored > property at the same time. The two things are mutually contradictory.
Good point. I feel silly now, because that's something I should have realized on my own. > What you've actually done is create two different properties, one derived and > one stored, with the same name, which ends up breaking Core Data in the ways > you're seeing. Yes, I see that now. > You need to choose one. > > If you choose the derived property, then you should get rid of the property > from your Core Data model. (So it's defined in your managed object subclass, > but Core Data knows nothing about it.) In that case, I suspect, you'll get an > error message if you try to use the property name in your fetch results > controller's sort keys. I haven't tried/checked but I'm pretty sure you're right that I won't be able to use the derived property as a sorting key in the fetched results controller. > If you choose the stored property, then you should get rid of your > 'indexOrName' getter, and instead customize the setters for your "index" and > "name" properties to maintain the "indexOrName" property directly. Yes, I think this is the path I'll follow. > Choose one. > > For either choice, though, you also need to pay attention the the KVO > compliance of your "indexOrName" property. If you choose option #1, you'll > likely use keyPathsForValuesAffectingIndexOrName to make that property > properly dependent on changes to the values of the underlying properties. If > you choose option #2, your custom setters must generate KVO notifications > (use setIndexOrName: or will/didChangeValueForKey:) whenever it changes the > stored value. Ah, more documentation to read then... I'm not comfortable with KVO just yet, so this is a good opportunity to learn more. I just wish I hadn't already spent so much time on this one issue. > Welcome to the world of Core Data. :) Heh.. yeah, tricky world it is sometimes. Thanks for all your help. WT _______________________________________________ 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
