The possibility to have multiple cache rules in a cache
configuration file is now handled throughout the cache
filter.
The major difference is that while you earlier directly
queried the Cache whether data should be stored to the
cache and whether data in the cache should be used, you
now query the Cache whether data should be stored to the
cache and, if so, get a CacheRules object from which you
subsequently query whether data from the cache should
be used.
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.
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.
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.
If there are several 'users' lines in a rule file, for a particular
user, the rules each matching line will be checked independently
until a rule match is found.
That is, the rules of each 'users' line are treated in an OR-fashion
with respect to each other.
Adds an option 'reply_time' to log_data. When enabled, query execution time
in milliseconds is logged. Execution time is measured as the time between
routeQuery and the first clientReply.
Using 'not_function' it is possible to match functions other than
a specific set of ones. That will make it significantly easier to
allow certain functions to be used with certain columns.
The special handling of no arguments to `function` in conjunction
with an allowing filter has been removed. The same effect can now
be achieved, without special handling, using `not_function`, no
arguments and a blocking filter.
Implementation will follow in a subsequent commit.
From the documentation:
* `never`: When there is an active transaction, no data will be returned
from the cache, but all requests will always be sent to the backend.
The cache will be populated inside _explicitly_ read-only transactions.
Inside transactions that are not explicitly read-only, the cache will
be populated _until_ the first non-SELECT statement.
* `read_only_transactions`: The cache will be used and populated inside
_explicitly_ read-only transactions. Inside transactions that are not
explicitly read-only, the cache will be populated, but not used
_until_ the first non-SELECT statement.
* `all_transactions`: The cache will be used and populated inside
_explicitly_ read-only transactions. Inside transactions that are not
explicitly read-only, the cache will be used and populated _until_ the
first non-SELECT statement.
When the database firewall filter is used in white-list mode,
'USE <db>' should be allowed. When connecting, it is always
possible to specify the database anyway so restricting
'USE <db>' serves no purpose.
Disabling the tee filter at runtime is desirable for cases where the
branched service is not always needed. Migrations and pre-production
setups are one where changes to the branched service are expected and
splitting the queries would result in an error.
The function type rule now accepts an empty list of functions, allowing
all functions to be blocked by defining an empty function type rule and
setting action=allow.
A function type rule matches a query if the query uses a function defined
in the rule. This is the desired behavior for blacklist mode operation
with `action=block`.
When in whitelist mode, all queries must match a rule to be allowed
through. For function type rules, this fact is problematic as queries that
don't use functions are blocked. The desired behavior is to allow the use
of certain functions while preventing the use of others.
The allowed set of functions should always contain the "empty set" (no
functions are used) when the filter is in whitelist mode.
The tee filter was missing the match/exclude functionality that was in the
previous implementation. The filter was upgraded to use PCRE2 regular
expressions instead of POSIX regular expressions.
Documented that the match/exclude patterns should use PCRE2 syntax.
MXS-1067. The CCRFilter will now look at the hints in a write-type
query. The parameter-value combinations "ccr=match" and "ccr=ignore"
are recognized and will override any regex match and ignore settings.
For the hints to work, the HintFilter needs to be present in the filter
chain before the CCRFilter.
Also ran astyle and updated documentation.
