A statement like
SELECT ... INTO OUTFILE|DUMPFILE ...
is now classified as a QUERY_TYPE_WRITE, instead of as
QUERY_TYPE_GSYSVAR_WRITE so that it will be sent only to the
master.
SELECT...FOR UPDATE locks the rows for update, but only if
autocommit==0 or a transaction is active, so in principle even if
it were classified as READ it'd still be sent to master when it
actually matters.
However, even if autocommit==1 and/or no transaction is active, a
slave in read only mode will reject the statement if the user is
subject to the read only restriction (a user with super privileges
is not), which might be considered a server bug. By classifying the
statement as a write, it'll be sent to master and always succeed.
Only for qc_sqlite.
After a second look qc_mysqlembedded will not support dupping
the statement information. Without additional changes, simply stashing
an info object away, parsing another new GWBUF, deleting that and
then using the stashed away info object will not work; the THD object
will be corrupted. As qc_mysqlembedded is _only_ used for verifying the
sqlite-based parser this is not important anyway.
The query classifier stores information about the statement carried
by a GWBUF in the GWBUF itself. We need to be able to store that
object out side the lifetime of the GWBUF. So, we require that a
query classifier is capable of duplicating references to that object.
sqlite does not treat # as the start of a to-end-of-line
comment. It cannot trivially be treated as such because at
startup sqlite parses statements containing the #-character.
Thus, only after sqlite has been initialized can it be treated
the same way as --.
The two operations return different types of results and need to be
treated differently in order for them to be handled correctly in 2.2.
This fixes the unexpected internal state errors that happened in all 2.2
versions due to a wrong assumption made by readwritesplit. This fix is not
necessary for newer versions as the LOAD DATA LOCAL INFILE processing is
done with a simpler, and more robust, method.
Earlier only "SELECT NEXT VALUE FOR SEQ" was parsed
properly, while "SELECT PREVIOUS VALUE FOR SEQ" was not.
Now the latter statement is also parsed properly.
Fixed string truncation warnings by reducing max parameter lengths by one
where applicable. The binlogrouter filename lengths are slightly different
so using memcpy to work around the warnings is an adequate "solution"
until the root of the problem is solved.
Removed unnecessary CMake policy settings from qc_sqlite. Adding a
self-dependency on the source file of an external project has no effect
and only caused warnings to be logged.
ENGINE is a keyword but not a reserved word, so it must
silently convert into an identifier if it is used in a
context where it cannot be used as a keyword.
"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.
After a temporary table is created, readwritesplit will check whether a
query drops or targets that temporary table. The check for query type was
missing from the table dropping part of the code. The temporary table read
part was checking that the query is a text form query.
Added a debug assertion to the query parsing function in qc_sqlite to
catch this type of interface misuse.
When the parsing of a query failed, the message would treat the parameter
as a string as the printf format was `%*s` instead of `%.*s`.
The manpage of printf states the following about the precision specifier:
... or the maximum number of characters to be printed from a string
for `s` and `S` conversions.
This means that the field length specifier is somewhat meaningless for
strings.
If the API versions do not match, MaxScale will treat this as an
error. The API versioning would allow backwards compatible changes but the
functionality to handle that is not implemented in MaxScale.
Updated API versions based on changes done to module APIs in 2.2.
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.
