Renamed to MariaDBServer. The objects have a pointer to the underlying
MXS_MONITORED_SERVER. The purpose is to have the monitor mainly use
MariaDBServer instead of the current mix of MXS_MONITORED_SERVER* and
MySqlServerInfo and to simplify the mapping between the two. Also,
many methods can be moved to the MariaDBServer class later on.
Some functions have been converted from MXS_MONITORED_SERVER* to
MariaDBServer.
When a multi-statement query consisting completely of UPDATE statements is
received, the packets can be received in two separate buffers. To cope
with this situation, the state change into REPLY_STATE_RSET_COLDEF must
only be done if the buffer contains more than a single packet.
Exposing the canonicalization code in the luafilter allows it to be used
on the Lua side of things. This should enable some pretty cool stuff to be
done with it.
When a multi-statement query consisting completely of UPDATE statements is
received, the packets can be received in two separate buffers. To cope
with this situation, the state change into REPLY_STATE_RSET_COLDEF must
only be done if the buffer contains more than a single packet.
In theory, the value of m_master could change between reading it to
local variable and stopping monitor. To be on the safe side, stop the
monitor first.
The canonicalization process now strips non-executable comments from the
SQL and replaces all constants in executable comments.
Enabled the comment test and updated expected output of the select and
alter tests.
Updated tests with new expected output. Also took new function into use
and removed the old one.
Since the comment removal isn't added yet, one of the tests is expected to
fail and it is temporarily disabled.
The new canonicalization function now processes negative numbers
correctly. It uses a look-behind operation to detect whether the operation
is a negation of a number or a subtraction from another value.
The function uses a hand-written parser that picks out the values and
replaces them with question marks. This function is not yet able to
process negative values; a `-?` token will be generated for all negative
numbers.
The new function will canonicalize the query in such a way that string and
number constants cannot be distinguished which means that it won't pass
the current test cases.
Cleaned up and updated the test; the code was written with a pre-C99
standard in mind.
Added a get() method into mxs::Buffer to make it easier to use with
non-C++ functions.
The DCB pointer in the MySQLProtocol struct doesn't appear to be updated
in all cases which causes it to be an unreliable source. As the session
itself is always available and it always has the service pointer properly
set, it should be used instead.
Also removed the dead protocol compression code and replaced the
parameters with the service capability bits.
By making it conditional, we prevent the problems that arise when the
replication protocol is used in combination with the session state change
tracking. In addition to this, it prevents unnecessary work for routers
and filters that don't need it.
Add missing listener JSON diagnostics call. Check that the
diagnostics_json function exists before calling it.
As the protocol modules don't have diagnostics functions, they aren't
called.
Replace hard-coded strings with constant parameters. This makes it
slightly cleaner.
1. Move some remaining class data private.
2. Linebreak long lines.
3. Move current master autoselection inside class method.
4. Remove single-use constant #defines.
5. Monitor status is only written inside loop.
The database-level query now only takes rows with either a global
select privileges or non-null database privileges. The table-level
query only accepts non-null databases and no global privileges,
as users with global select are added by the previous section.
Now it is possible to control the soft and hard ttl of the
cache on a session basis. That is, it is possible to use
different TTLs for different SELECTs.
As the TTL is checked at lookup time, it need not be hardwired
when the storage instance is created. With this changed it is
possible to introduce @maxscale.cache.(soft|hard)_ttl user
variables using which a client can control what TTL should be
applied for a particular kind of data, which is requested by
MXS-1475.
In case the entry in the cache can not be used because the hard
TTL has kicked in, we fetch the data and update the cache
irrespected of the value if @maxscale.cache.populate. That way
an entry that once was put in the cache, will remain in the cache
(as long as there is space).
The earlier @maxscale.cache.enabled has now been replaced with
@maxscale.cache.populate and @maxscale.cache.use that provide
for more flexibility.
With the former it is possible to control in what circumstances
the cache is populated and with the latter one when it is used.
Together they can be used for having a completely client driven
caching.
