Continuing the discussion from
2018 - September I Love Lucee:
Three reasons you shouldn’t use “Query of Queries”:
it is slow
it is slow, and;
it is slow
Version 2.4.1 is fully multithreaded and supports high performance 2PL and MVCC (multiversion concurrency control) transaction control models.
I always thought one of the reasons QofQ was slow is it gets single threaded under HSQLDB 1.8.0. Would upgrading to use 2.4.1 give us access to multithreaded support?
Is it worth upgrading the HSQLDB engine Lucee uses for this feature? Or are we better off to keep coding it out of existence?
To be honest i thought we’d already upgraded? Or is this just a reference to the embedded database and JDBC driver that is available?
HSQLDB is known for its small size, ability to execute completely or partly in memory, its flexibility and speed. The Lucee core needs a HSQLDB jar to run the CFML “query of queries” (QoQ) feature, but the jar itself is not registered as a JDBC source and no component for the admin exists… yet.
Good thing about JDBC sources, you don’t have to install an extension to use it. You can create your own datasource with something simple like this:
HyperSQL (HSQLDB) is a real workhorse; a …
I could write a big bullshit, but updating hsqldb from version 1.8.0 to version 2.4.1 could you have a speed improvement with QoQ?
I’d also be interested in what improvements could be made to QoQ to speed things up. We are stuck with it for
A LOT of work as one of our main functions is using Lucee as middleware to connect disparate systems that use several different db’s as back ends (e.g. MySQL, FoxPro, Oracle, etc.)
The only way I know of joining resultsets is through QoQ.
oh, hsqldb 1.8.0 was released 10 years ago, i doubt there have been any performance improvements since then