Re: Core Data: case insensitive "equals" predicate strings!?

FROM : Frank Reiff
DATE : Fri Jan 11 17:22:21 2008

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_removed> 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_removed>> 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_removed>)
>>
>> 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:
>> http://lists.apple.com/mailman/options/cocoa-dev/<email_removed>
>>
>> This email sent to <email_removed>
>>

> _______________________________________________
>
> Cocoa-dev mailing list (<email_removed>)
>
> 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:
> http://lists.apple.com/mailman/options/cocoa-dev/<email_removed>
>
> This email sent to <email_removed>