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. 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. 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. 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. 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. Welcome to the world of Core Data. :) _______________________________________________ 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
