Re: [iOS] Strange behavior of NSFetchedResultsController
Re: [iOS] Strange behavior of NSFetchedResultsController
- Subject: Re: [iOS] Strange behavior of NSFetchedResultsController
- From: WT <email@hidden>
- Date: Thu, 10 Feb 2011 19:55:23 -0200
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 (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