63 Commits

Author SHA1 Message Date
Johan Wikman
2434482dc6 MXS-1475 Attempt to set unknown MXS user variable causes error
By causing an error if an unknown MaxScale user variable is set,
the user will become aware of typos etc.
2018-03-16 14:34:04 +02:00
Johan Wikman
872a51a376 MXS-1475 Enable MaxScale specific user variables
With the changes in this commit it is possible to add and remove
MaxScale specific user variables. A MaxScale specific user variable
is a user variable that is interpreted by MaxScale and that
potentially changes the behaviour of MaxScale.

MaxScale specific user variables are of the format "@maxscale.x.y"
where "@maxscale" is a mandatory prefix, x a scope identifying the
component that handles the variable and y the component specific
variable. So, a variable might be called e.g. "@maxscale.cache.enabled".
The scope "core" is reserved (although not enforced yet) to MaxScale
itself.

The idea is that although MaxScale catches these, they are passed
through to the server. The benefit of this is that we do not need to
detect e.g. "SELECT @maxscale.cache.enabled", but can let the result
be returned from the server.

The interpretation of a provided value is handled by the component that
adds the variable. In a subsequent commit, it will be possible for a
component to reject a value, which will then cause an error to be
returned to the client.

There are 3 new functions:

- session_add_variable() using which a variable is added,
- session_remove_variable() using which a variable is removed, and
- session_set_variable_value().

The two former ones are to be called by components, the last one by
the protocol that catches the "set @maxscale..." statements.
2018-03-16 14:34:04 +02:00
Johan Wikman
5dfa0c1226 MXS-1475 Take SetParser and SqlModeParser into use
These changes are the first in the route toward supporting
MaxScale specific variables such as

    set @MAXSCALE.CACHE.ENABLED=TRUE
2018-03-16 14:34:04 +02:00
Markus Mäkelä
771716e9db
Merge branch '2.2' into develop 2018-02-05 10:22:43 +02:00
Markus Mäkelä
8c8aaeae8e Prevent double closing of client DCB
If the client is closing the connection but routing the COM_QUIT fails,
the DCB would be closed twice.
2018-02-02 12:28:07 +02:00
Markus Mäkelä
9f0a691233 Always stop the session by closing the client DCB
By always starting the session shutdown process by stopping the client
DCB, the manipulation of the session state can be removed from the backend
protocol modules and replaced with a fake hangup event.

Delivering this event via the core allows the actual dcb_close call on the
client DCB to be done only when the client DCB is being handled by a
worker.
2018-02-02 12:28:07 +02:00
Markus Mäkelä
f53e112bf4 Don't write errors to dummy sessions
If a DCB is closed before a response to the handshake packet is received,
the DCB's session will point to the dummy session. In this case no error
should be written to the DCB.
2018-01-31 13:38:28 +02:00
Markus Mäkelä
dfbecc41e2 Format protocol modules
Formatted the MariaDB protocol modules with Astyle.
2018-01-24 11:20:11 +02:00
Dapeng Huang
a52e1ac8d7 add session tracker:SESSION_TRACK_TRANSACTION_CHARACTERISTICS and fix wrong state mapping 2018-01-16 13:56:00 +08:00
Dapeng Huang
6d3c60eb28 remove noneed protocol and the comparison corrent 2018-01-15 22:07:23 +08:00
Dapeng Huang
d234b13027 refactor, check every packet before parser ok packet, move config to service, fix code style, ... 2018-01-15 20:25:44 +08:00
Dapeng Huang
e1aeac8b07 get session transation state from backend via session track mechanism 2018-01-14 12:23:38 +08:00
Johan Wikman
f129dd56be MXS-1595 Rename mysqlclient to mariadbclient
Documentation update will follow.
2018-01-05 10:01:50 +02:00