Re: Core Data Fetches + Transient Properties + NSPredicateEditor = Sadness
Re: Core Data Fetches + Transient Properties + NSPredicateEditor = Sadness
- Subject: Re: Core Data Fetches + Transient Properties + NSPredicateEditor = Sadness
- From: Jerry Krinock <email@hidden>
- Date: Tue, 28 Apr 2009 14:15:29 -0700
On 2009 Apr 23, at 13:53, Melissa J. Turner wrote:
Unwinding to the original message, the most correct thing to do
would be to add a derived property letterGrade which is
automatically updated whenever grade is, which then allows you to
search against that.
I don't know if a "derived property" is a managed property that
appears in the .xcdatamodel, or a regular instance variable.
If Melissa is referring to a managed property, if it is non-transient,
then yes this could be used in the predicate of a Core Data fetch.
The disadvantage is that now every object in every store has this
redundant (derived) attribute. More important than the wasted bits is
that custom setters are now required to keep the derived attribute in
sync with its source attribute, opening a way to introduce bugs into
future versions.
If Melissa is referring to a regular instance variable, then it cannot
be used in the predicate of a Core Data fetch and thus filtering must
be done in RAM by -[NSArray filteredArrayWithPredicate], resulting in
limited scalability.
For my application, I chose the latter.
Am I misunderstanding anything?
_______________________________________________
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