| Jesse, Susanne,
I believe SQL does interpret the operator precedence properly, both by standard and by the actual implementation of all SQL servers I've ever used.
Alas, this is EOF-level: the qualifier gets improperly created far far before it might get sent to SQL — it simply embeds an EOOrQualifier inside of an EOAndQualifier, although the proper result would be the very opposite, the root qualifier should be EOOrQualifier and the embedded one the EOAndQualifier, unless the standard order of logical operations is changed by parentheses.
Of course, the parentheses or other ways to construct qualifiers can be used to work-around easily, there's no problem in that. The problem is solely the case of a qualifierWithQualifierFormat containing logical operations without superfluous parentheses, which for me seems to generate improper results (turning effectively those superfluous parentheses to mandatory ones). Ick :(
Thanks, OC
I think I’d expect that SQL and I’d guess you can put in your own braces to be explicit.
I typically generate qualifiers using the ERX qualifier classes, ERXKeys and the .dot() method which is just great.
I’d only use text if I were doing something that lends specifically to string formats
Hi there,
is it normal that
EOQualifier.qualifierWithQualifierFormat("userType = 12 OR userType = 6 AND subjectType = 3",null)
creates
(((userType = 12) or (userType = 6)) and (subjectType = 3))
? Seems wrong, does it not? AND should always have higher operator precedence than OR, should it not? I was just bit in my tender parts by this, and I wonder whether this is the standard behaviour or some weird quirk.
Thanks, OC
|