NSPredicate behavior with different stores (CONTAINS vs. LIKE)
NSPredicate behavior with different stores (CONTAINS vs. LIKE)
- Subject: NSPredicate behavior with different stores (CONTAINS vs. LIKE)
- From: "Stephen F. Booth" <email@hidden>
- Date: Sat, 4 Nov 2006 08:45:02 -0800
All,
I have run into a problem that has me stumped. I am attempting to
fetch records matching user-specified criteria for a smart playlist
implementation, and depending on the key paths and the type of
backing store I am seeing different behavior! I am aware of the
notes regarding using Cocoa-specific methods such as
localizedCompare: in predicates, and I don't believe that is the
problem (though it may be).
This code works fine using any store I've tested:
playlistObject = [NSEntityDescription
insertNewObjectForEntityForName:@"DynamicPlaylist"
inManagedObjectContext:managedObjectContext];
[playlistObject setPredicate:[NSPredicate predicateWithFormat:@"url
CONTAINS[c] %@", @"nat"]];
Here is where the weirdness emerges: the following predicate works
correctly using a binary store, but fails to return any results using
an SQLite store:
playlistObject = [NSEntityDescription
insertNewObjectForEntityForName:@"DynamicPlaylist"
inManagedObjectContext:managedObjectContext];
[playlistObject setPredicate:[NSPredicate
predicateWithFormat:@"metadata.title CONTAINS[c] %@", @"nat"]];
However, the simple change of predicate to
[playlistObject setPredicate:[NSPredicate
predicateWithFormat:@"metadata.title LIKE[c] %@", @"*nat*"]];
returns the expected results.
Is there an issue with using CONTAINS predicates with key paths for
an SQLite store? Or have I just missed something obvious?
Thanks,
Stephen
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden