Now takes a structure that, if present, enables the query
classification caching and specifies the properties of the
cache.
For the time being no actual properties are yet available.
"INTERVAL N <unit>" is now handled as an expression in itself and
as asuch will cause both statements such as
"SELECT '2008-12-31 23:59:59' + INTERVAL 1 SECOND;"
and
"select id from db2.t1 where DATE_ADD("2017-06-15", INTERVAL 10 DAY) < "2017-06-15";"
to be handled correctly. The compare test program contains some
heuristic checking, as the the embedded parser will in all cases
report date manipulation as the use of the add_date_interval()
function.
The follwing statements
SELECT GET_LOCK('lock1',10);
SELECT IS_FREE_LOCK('lock1');
SELECT IS_USED_LOCK('lock1');
SELECT RELEASE_LOCK('lock1');
are now classified as QUERY_TYPE_READ|QUERY_TYPE_WRITE. That will
make cooperative locking work if these functions are used inside
non-read-only transactions and outside transanctions.
By moving the initialization into Worker::run, all threads, including the
main thread, are properly initialized. This was not noticed before as
qc_sqlite initialized the main thread in the process initialization
callback.
The enums exposed by the connector are not intended to be used by the
users of the library. The fact that the protocol, and other, modules used
it was in violation of how the library is intended to be used.
Adding an internal mapping into MaxScale also removes some of the
dependencies that the core has on the connector.
Basically it would be trivial to report far more operations
explicitly, but for the fact that the values in qc_query_op_t
currently, quite unnecessarily, form a bitmask.
In 2.2 that is no longer the case, so other operations will be
added there.
Before this change, only db2.t2 was reported as table name for a
select like
select * from db1.t1 union select * from db2.t2
With this change, db1.t1 and db2.t2 are reported.
There are some issues still
- With recursive CTEs qc_mysqlembedded and qc_sqlite agree upon
the real columns, but disagree on the CTE related "virtual"
columns. That's largely irrelevant though.
- qc_sqlite cannot parse "SET STATEMENT var=... FOR stmt",
but it will be classified as QUERY_TYPE_GSYSVAR_WRITE.
This is not directly CTE related.
The "parser" of compare cannot handle the following:
prepare stmt1 from "
with t as (select a from t1 where b >= 'c')
select * from t2,t where t2.c=t.a;
";
That is, that a line *not* terminating the full statement (the
line 'select * from t2,t where t2.c=t.a;' above) ends with a ';'.
Thus, it needs to be changed into e.g.
prepare stmt1 from "
with t as (select a from t1 where b >= 'c')
select * from t2,t where t2.c=t.a;";
In the context of subselects and CTEs it is somewhat difficult to
make qc_sqlite and qc_mysqlembedded to agree upon in what context
a particular field is used. As that information is not used anywhere,
a usage discrepancy is for now treated as a warning.
