Re: NSPredicate behavior with different stores (CONTAINS vs. LIKE)
Re: NSPredicate behavior with different stores (CONTAINS vs. LIKE)
- Subject: Re: NSPredicate behavior with different stores (CONTAINS vs. LIKE)
- From: Jesse Grosjean <email@hidden>
- Date: Tue, 14 Nov 2006 15:03:11 -0500
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?
I'm not sure, but that sounds like this problem that I ran into:
http://www.cocoabuilder.com/archive/message/cocoa/2006/3/15/158768
Jesse
_______________________________________________
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