Breaking QoQ change between 5.3.7.48 and 5.3.8.189 +

dev support
2

This regression is due to this ticket
https://luceeserver.atlassian.net/browse/LDEV-3042

which is more fully explained here:

Generally speaking, QoQ doesn’t care if you have complex values in your query objects, BUT part of this rewrite was fixing the behavior where UNION is meant to also distinct the result. As part of partitioning the query, a string representation needs to be made for every value in the row, so each row can be compared for uniqueness. The Lucee Caster.toString() method does not work for queries, so it throws an error (that you don’t see). Once the native QoQ implementation errors out, Lucee moves on to the HSQLDB implementation which does NOT allow complex values to be in a cell, which also errors out for the same basic reason with a similar exception (that you do see).

So the workaround for you is quite simple, so long as you are OK with duplicate records in your final result (and since older versions of Lucee didn’t distinct the results of unions, I assume you are :slight_smile: ), is simply to use UNION ALL instead which completely bypasses the partitioning of the query

select * from arguments.q1
UNION ALL
select * from arguments.q2

Now, as far as the error goes, we need to make a decision and choose one of the following paths forward (cc/ @Zackster )

  • Continue to throw an exception, but possibly a better-worded one that explains you can’t DISTINCT or GROUP a select when some of the cells contain complex values which cannot be turned into a string for easy comparison.
  • OR we implement some janky attempt at representing complex values as a string so we can still attempt to compare them for uniqueness
  • OR we just ignore complex values and don’t even try to represent them internally for the sake of determining uniqueness and just document that complex values won’t be taken into account when distincting or grouping a query. This would avoid the error, but may not work like someone expects.

I don’t have a super strong opinion, but I’m inclined to say the 2nd bullet is the “best” solution, even though it’s tiny bit more work (and still may not cover 100% of possible cases)

3 Likes