Re: Core Data: case insensitive "equals" predicate strings!?
Re: Core Data: case insensitive "equals" predicate strings!?
- Subject: Re: Core Data: case insensitive "equals" predicate strings!?
- From: Frank Reiff <email@hidden>
- Date: Fri, 11 Jan 2008 17:22:21 +0100
Sorry,
I've been off the list for a few days.. using the non-predicate string
syntax:
NSPredicate* predicate = [NSComparisonPredicate
predicateWithLeftExpression: [NSExpression expressionForKeyPath:
@"fullDestinationPath"]
rightExpression: [NSExpression expressionForConstantValue:
newFullPath]
modifier: NSDirectPredicateModifier type:
NSEqualToPredicateOperatorType options:
NSCaseInsensitivePredicateOption];
works and it uses a proper case insensitive (no fooling around with
uppercase, lowercase or escape sequences) equals; this syntax is
unfortunately not available if you use predicate string format, which
in my humble opinion is not a good thing; I have submitted the
improvement request to Apple.
Keeping in mind that this is not for in-memory use but for a CoreData
query which goes to an sqlite backend, using the uppercase/ lowercase
idea or escaping all characters and using LIKE, will very likely yield
a less than perfectly optimized SQL query that is pretty much
guaranteed to be slow. I don't know how well Core Data optimizes
queries, so using the "proper" query rather than tricking Core Data
into doing this might make no difference at all, but at least it gives
it a shot at producing an optimized query.
Using the uppercase (or lowercase) option would yield good performance
results if the original path is stored in all uppercase (or
lowercase); probably faster than the "proper" case insensitive equals
predicate.
HFS+ file paths are however case preserving (if unfortunately not case
sensitive) so I can't just drop the case information. Keeping a
separate field with an all uppercase version of the string would be
possible but is probably a waste of hard disk and CPU time.
Anyway, problem solved.
Best regards,
Frank
On 11 Jan 2008, at 11:46, email@hidden wrote:
Convert both strings to uppercase and stick with ==.
That said, I don't see why like[c] wouldn't do the job. The variable
is being quoted by the parser so wildcards don't count, no?
On Jan 11, 2008 1:55 AM, Ken Thomases <email@hidden> wrote:
On Jan 8, 2008, at 7:53 PM, mmalc crawford wrote:
On Jan 8, 2008, at 4:22 PM, Ken Thomases wrote:
It's not clear what you're trying to achieve.
In what way does the LIKE operator not do what you want?
The concern I would have would be if his "newFullPath" variable
contains characters which would be interpreted by the LIKE
operator as wildcards. It's not as uncommon as one might guess
that a file path contains "*" or "?".
You can escape the wildcards...
That's not actually documented on the Predicate Format String Syntax
or BNF Definition of Cocoa Predicates pages. There's something about
escape sequences for numbers, but not about string contents. I
suppose it's likely that escapes are supported for meta-characters.
I suppose some trial and error would reveal if it works. I'm not
that invested. ;)
-Ken
_______________________________________________
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
_______________________________________________
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
_______________________________________________
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