Reputation: 3573
In short :
Fetching entities and sorting them according to an @property
which is not an attribute
will cause a bug (with NSDictionaryMapNode
involved) at the second run.
Is it normal or a bug ? Do you have any comment or help about that?
In long :
The situation is the following.
I have an Entity
with two attributes attribute1
and attribute2
.
I have generated [1] a classe Entity.m
and added a @property
to it called myProperty
. Hence, myProperty
is a @property
of my class Entity.m
but not an attribute of the entity Entity
. By the way, myProperty
is readonly
(let's say it is something like attribute1
concatenated with attribute2
.
Now, I do the following :
NSManagedObjectContext * myContext = ... ;
NSFetchRequest * myRequest = [NSFetchRequest fetchRequestWithEntityName:@"Entity"];
NSSortDescriptor * mySortDescriptor = [NSSortDescriptor sortDescriptorWithKey:@"myProperty"
ascending:YES] ;
NSError *error ;
[myRequest setSortDescriptors:@[mySortDescriptor]] ;
NSArray * result = [myContext executeFetchRequest:myRequest
error:&error] ;
The first time this code gets executed, I don't have any bug.
The second time, I get the following bug :
[<NSDictionaryMapNode 0x1020cf310> valueForUndefinedKey:]: this class is not key value coding-compliant for the key myProperty.
I understand that the problem comes from myProperty
not being an attribute of Entity
. The aim of my post is to raise this situation and to know if you would have any comment about this situation.
Upvotes: 2
Views: 340
Reputation: 119031
This is known. You can't sort on anything that isn't persistent in the store. It should never work (to work the first time means that you don't have a MOC or something like that).
You should add a new attribute to the entity that is persistent. Do something like implement willSave
or observe the dependent keys and use that trigger to update the value of the new attribute (myProperty
).
See section Fetch Predicates and Sort Descriptors
of Core Data Programming Guide
Upvotes: 2