X-CGP-ClamAV-Result: CLEAN X-VirusScanner: Niversoft's CGPClamav Helper v1.22.2a (ClamAV engine v0.102.2) X-Junk-Score: 0 [] X-KAS-Score: 0 [] From: "OCsite" Received: from smtp-beta-1.zoner.com ([217.198.120.69] verified) by post.selbstdenker.com (CommuniGate Pro SMTP 6.3.3) with ESMTPS id 25411221 for webobjects-dev@wocommunity.org; Mon, 15 Feb 2021 15:54:13 +0100 Received-SPF: none receiver=post.selbstdenker.com; client-ip=217.198.120.69; envelope-from=ocs@ocs.cz Received: from smtp.zoner.com (smtp.zoner.com [217.198.120.6]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp-beta-1.zoner.com (Postfix) with ESMTPS id 79B441801271 for ; Mon, 15 Feb 2021 15:53:52 +0100 (CET) Received: from macbook-pro.ocsluj (smtp2stechovice.cli-eurosignal.cz [77.240.99.254]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: ocs@ocs.cz) by smtp.zoner.com (Postfix) with ESMTPSA id 2E0833000077 for ; Mon, 15 Feb 2021 15:53:52 +0100 (CET) Content-Type: multipart/alternative; boundary="Apple-Mail=_DA539879-49E4-4E8A-BDE6-4F97913E7E28" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: Re: [WO-DEV] EOQualifier.qualifierWithQualifierFormat ignores proper AND/OR precedence?!? Date: Mon, 15 Feb 2021 15:53:51 +0100 References: To: WebObjects & WOnder Development In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.3608.80.23.2.2) --Apple-Mail=_DA539879-49E4-4E8A-BDE6-4F97913E7E28 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 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 =E2=80=94 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 > On 15 Feb 2021, at 15:14, Jesse Tayler = wrote: >=20 > I think I=E2=80=99d expect that SQL and I=E2=80=99d guess you can put = in your own braces to be explicit. >=20 > I typically generate qualifiers using the ERX qualifier classes, = ERXKeys and the .dot() method which is just great. >=20 > I=E2=80=99d only use text if I were doing something that lends = specifically to string formats >=20 >=20 >=20 >> On Feb 15, 2021, at 8:47 AM, OCsite > wrote: >>=20 >> Hi there, >>=20 >> is it normal that >>=20 >> EOQualifier.qualifierWithQualifierFormat("userType =3D 12 OR userType = =3D 6 AND subjectType =3D 3",null) >>=20 >> creates >>=20 >> (((userType =3D 12) or (userType =3D 6)) and (subjectType =3D 3)) >>=20 >> ? 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. >>=20 >> Thanks, >> OC >>=20 >=20 --Apple-Mail=_DA539879-49E4-4E8A-BDE6-4F97913E7E28 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 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 =E2=80=94 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

On 15 Feb 2021, at 15:14, Jesse Tayler <webobjects-dev@wocommunity.org> wrote:

I think I=E2=80=99d = expect that SQL and I=E2=80=99d 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=E2=80=99d only use text if I were = doing something that lends specifically to string formats



On Feb 15, 2021, at 8:47 AM, OCsite <webobjects-dev@wocommunity.org> wrote:

Hi there,

is it normal = that

EOQualifier.qualifierWithQualifierFormat("userType =3D = 12 OR userType =3D 6 AND subjectType =3D 3",null)

creates

(((userType =3D 12) or (userType =3D 6)) and (subjectType =3D = 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



= --Apple-Mail=_DA539879-49E4-4E8A-BDE6-4F97913E7E28--