Possible regression in 5.4 (and 5.3) compared to 5.2 (QoQ)


u=queryExecute("select * from q1 union select * from q2",{},{dbtype:'query'})

Runs without error in Lucee 4.x, and I strongly expect 5.4.2.x, but seems to be failing in with ‘Cannot perform union as number of columns in selects do not match. on line 4’ (it means 3, lines 1 and 5 are cfscript tags).

I used trycf.com for the v4.x check, and it only showed up in one of our pre-live environments after the Lucee version was bumped from an earlier 5.x

Using the lucee/lucee:5.2-nginx Docker image (docker run -p 80:80 -v/tmp/:/var/www lucee/lucee:...), if I dump u I get a query with 3 columns. No error, obviously.

lucee/lucee:5.3-nginx and lucee/lucee: and lucee/lucee: all error.

Yep, that would fail on most RDBMs servers, the QoQ engine in Lucee is now stricter and behaves like most common database engines

u=queryExecute("select * from q1 union select q2.* from q2, q1 where q1.a=q2.b",{},{dbtype:'query'})

throws the same type of error when it’s falls back to the hsqldb engine due to the join, so it’s consistent between native qoq and the hsqldb

column number mismatch detected in rows of UNION, INTERSECT, EXCEPT, or VALUES operation on line 4

Makes sense.

I don’t think we should fix it. For us it was easy to work around, but I hadn’t seen anyone else mention it.

Leaving this here for future searches :slight_smile:

1 Like


QoQ was for a long time quite a strange and unloved quirky beast, #teamQoQ aka @Brad_Wood and I love QoQ and have been working hard to improve both it’s performance and behaviour to be more standard.

Hopefully these days, it much easier to take a normal query from a server engine and use it with QoQ

There’s also a lot of changes with HSQLDB which we had to upgrade (from the 1.8.0 version, circa 2009!! due to CVEs) as part of the CVE free goal for 5.4