lucee
QoQ shouldn't fall back to HSQLDB after queryparam error
This pull adds a new exception type IllegalQoQException which indicates a QoQ is illegal and needs to fail right away without attempting to fail back to HSQLDB which will obfuscate the original error. I have added test cases for every place QoQ currently fails and we know there is no reason to try again with HSQLDB.
The following QoQ errors which used to fall back to HSQLDB will now throw the original, and much more useful exception, directly from the native QoQ implementation.
- Divide by zero -
1/0 - Mod zero -
1%0 - Too many count columns -
count( col1, col2 ) - Too many count distinct columns -
count( DISTINCT col1, col2 ) - Cast with missing type -
cast( col ) - Union with mismatched column counts in the selects
- Union with invalid order by
- Order by with invalid ordinal position -
ORDER BY 9001 - Positional param value with wrong type
- Named param value with wrong type
@zspitzer Once this first pull is merged and the commits get rebased into the other pull, it will pass as well since it uses some of this new code (the ability to prevent the HSQLDB fallback)