 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Mac Forum / Programming / Mac Programming / December 2007NSPredicate, string compare
Hallo NG, I wonder why a simple expression dose not work for me. I want to filter a array of managed objects with like this: NSArray * subArray = [totalArray filteredArrayUsingPredicate: [NSPredicate predicateWithFormat:@"(FullName == 'John Smith')"]]; This will work for all kind of booleans,numbers or test for NULL, but not for string comparison - why? It will work if I use %K and %@. What dose %K? Thanx Florian. In article <DBB86EF7-3428-4B82-A49D-43D245EBAA90%edv@zschocke-berlin.de>, > Hallo NG, > [quoted text clipped - 8 lines] > It will work if I use %K and %@. > What dose %K? According to the documentation, %K is replaced by a key path. My hunch is that it doesn't like your use of single quotes (although by the docs, it should). Try replacing ' with \" and see what happens. Gregory Weston <uce@splook.com> schrieb: > In article > <DBB86EF7-3428-4B82-A49D-43D245EBAA90%edv@zschocke-berlin.de>, [quoted text clipped - 16 lines] > My hunch is that it doesn't like your use of single quotes (although by > the docs, it should). Try replacing ' with \" and see what happens. You know what is really funny is that, if I use \" it gets really buggy. The result array contains a few objects with a totally different FullName, but non with the correct. With ' or \' it just returns no objects. I have tested also with "like" but that dose not make a difference. Can I express the "keypath" as string? Thanx Florian Gregory Weston <uce@splook.com> schrieb: > In article > <DBB86EF7-3428-4B82-A49D-43D245EBAA90%edv@zschocke-berlin.de>, [quoted text clipped - 16 lines] > My hunch is that it doesn't like your use of single quotes (although by > the docs, it should). Try replacing ' with \" and see what happens. The only thing that is working for me is if I use: FullName contains 'John Smith' ^^^^^^^^ So I think this is really a bug. Can someone confirm that? Thanx Florian > The only thing that is working for me is if I use: > > FullName contains 'John Smith' > ^^^^^^^^ > So I think this is really a bug. Can someone confirm that? Looking at this page: <http://developer.apple.com/documentation/Cocoa/Conceptual/Predicates/Ar ticles/pSyntax.html> It seems that string comparison requires a separate syntax. Instead of = or == you should use 'like': [NSPredicate predicateWithFormat:@"FullName like 'John Smith'"]; patrick noreply@mail.invalid (Patrick Machielse) schrieb: >> The only thing that is working for me is if I use: >> [quoted text clipped - 13 lines] > > patrick Thanx Patrick, but I tried that too before. "Like" is not working for me. I have tried that with different kinds of managed objects - but nope. > >> The only thing that is working for me is if I use: > >> [quoted text clipped - 6 lines] > Thanx Patrick, but I tried that too before. "Like" is not working for me. > I have tried that with different kinds of managed objects - but nope. That would suggest that the FullName property/ivar is _more_ than 'John Smith' (' John Smith' or 'John Smith '?). Betting against the framework is usually a loosing proposition ;-) patrick noreply@mail.invalid (Patrick Machielse) schrieb: >> >> The only thing that is working for me is if I use: >> >> [quoted text clipped - 11 lines] > > Betting against the framework is usually a loosing proposition ;-) No, the string is taken from the objects. If it is ' John Smith', it should find ' John Smith'. Thanx Florian noreply@mail.invalid (Patrick Machielse) schrieb: >> >> The only thing that is working for me is if I use: >> >> [quoted text clipped - 5 lines] > > patrick I'm no gambler but in this case: Do you want to bet with me? "Contains" is buggy too. It shows false results sometimes. For a "contains 'John Smith'" I get the data of "Lara Miller" too in perhaps one of 30 queries. Florian > noreply@mail.invalid (Patrick Machielse) schrieb: > > > Betting against the framework is usually a loosing proposition ;-) > > I'm no gambler but in this case: Do you want to bet with me? I'm not saying that Apple's frameworks don't contain bugs. I've reported quite a few myself, sometimes surprising ones. But the vast majority of those bugs occured in edge cases or when using more obscure (== less used) APIs. If simple NSPredicate string queries with 'like' or 'contains' would be broken, many Apple apps would be broken too. Someone would probably have noticed... > "Contains" is buggy too. It shows false results sometimes. For a "contains > 'John Smith'" I get the data of "Lara Miller" too in perhaps one of 30 > queries. Try to reduce this in a minimal test case and you either *) end up with a really good submission for Bug Tracker or *) find your mistake along the way. For now, my 'money' is on the 2nd option ;-) Does FullName really return what you think it does? Is it a computed value? patrick noreply@mail.invalid (Patrick Machielse) schrieb: >> > Betting against the framework is usually a loosing proposition ;-) >> [quoted text clipped - 6 lines] > 'contains' would be broken, many Apple apps would be broken too. Someone > would probably have noticed... Yes I know. That is the reason why I'm asking. Meanwhile I'm experienced enough to know that in 99,9% of the cases the "bug" is nothing else than a fatamorgana in the vacuum shell between my eyes. >> "Contains" is buggy too. It shows false results sometimes. For a "contains >> 'John Smith'" I get the data of "Lara Miller" too in perhaps one of 30 [quoted text clipped - 4 lines] > the way. For now, my 'money' is on the 2nd option ;-) > I did that before and came to the conclusion that I have to use %K and %@ to overcome this. I this case == as operator works great, also for strings. Now the point is that I don't need a placeholder because the the query dose not change that much and I want to store it in a string. > Does FullName really return what you think it does? Is it a computed > value? > It is a key-value compliant string value of a managed object. Yes, that is proved and no, it is not computed. Perhaps I tell you what I do. In a first step I fetch a a bigger group of managed objects out of the moc. In a second step I want to query this array for many different kinds of values. In the case of numeric, boolean or checking against nil I'm able to do this without the placeholder with a simple NSPredicate predicateWithFormat: @"(age == 80) and (Adress == nil)"] --- (just an example). If I want to make a string compare it that is not working. It is working with strings only if I use the placeholder %K and %@. For my code that would produce a ugly code, if I had to use it this way and also the documentations says something else. Thanx Florian > Yes I know. That is the reason why I'm asking. Meanwhile I'm experienced > enough to know that in 99,9% of the cases the "bug" is nothing else than a > fatamorgana in the vacuum shell between my eyes. I know the sinking feeling when the excitement of 'it's an Apple bug!' turns into the disappointment of 'oh no, it's mine...' all too well ;-) > this without the placeholder with a simple NSPredicate predicateWithFormat: > @"(age == 80) and (Adress == nil)"] --- (just an example). > If I want to make a string compare it that is not working. It is working with > strings only if I use the placeholder %K and %@. You can always check your assumptions with -[NSPredicate predicateFormat]. That would tell you the exact string that is constructed when %K and %@ are replaced and you'd know how to hard-code it. patrick noreply@mail.invalid (Patrick Machielse) schrieb: >> Yes I know. That is the reason why I'm asking. Meanwhile I'm experienced >> enough to know that in 99,9% of the cases the "bug" is nothing else than a [quoted text clipped - 12 lines] > constructed when %K and %@ are replaced and you'd know how to hard-code > it. So, %K dose nothing and %@ set quotes. Interesting what it makes from "contains" (in) and a date compare (CAST()). It strips all the quotes. I can't see any other differences. It is really wired. I can't believe that such a silly thing keeps me debugging for hours. If I find a solution I will poste it here. Thanx Florian Florian Zschocke <edv@zschocke-berlin.de> schrieb: >> I know the sinking feeling when the excitement of 'it's an Apple bug!' >> turns into the disappointment of 'oh no, it's mine...' all too well ;-) Indeed, in my case I was looking for objects I had removed form the array before. The "bug" has melted down. There is some uncertainty left about the false positive results when I use "contains" or like in combination with a wildcard (Fullname like 'John Smith*'). Thanx a lot for your patience and help. Florian In article <5F71A10F-2E6F-4B74-B00A-B5B840F03388%edv@zschocke-berlin.de>, > noreply@mail.invalid (Patrick Machielse) schrieb: > [quoted text clipped - 10 lines] > It is really wired. I can't believe that such a silly thing keeps me > debugging for hours. I haven't used NSPredicate, but have you read <http://developer.apple.com/documentation/Cocoa/Conceptual/Predicates/ind ex.html>, in particular <http://developer.apple.com/documentation/Cocoa/Conceptual/Predicates/Art icles/pCreating.html#//apple_ref/doc/uid/TP40001793-DontLinkElementID_4> (The 'Format String Summary' in the 'Creating Predicates' <http://developer.apple.com/documentation/Cocoa/Conceptual/Predicates/Art icles/pCreating.html> page)? Reinder |
Reply to this Message |
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2010 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.