The filter converts bulk inserts inside transactions into LOAD DATA LOCAL
INFILE statements. This allows multiple INSERT statements to be streamed
in a more efficient manner.
The module should be in the experimental package as it is still at an
experimental stage.
The module commands now support an optional flag for arguments that when
enabled checks that the argument module name matches the registered domain
name. This can be used to enforce argument type validity for arguments
that are given to modules that expect objects of a certain type.
For example, this is used by the cache and dbfwfilter to prevent valid
filters but of the wrong type being given as arguments.
Tee no longer uses the dummy_filterdef FILTER_DEF member, so
it can be removed. That means that filter_free() can be removed
from the public filter.h include.
Better to use types whose size is unquestionably unambiguous
in plugin interfaces.
As on current platforms sizeof(int32_t) == sizeof(int) plugins
need not immediately be changed to return int32_t:s instead of
int:s.
Added documentation for dbfwfilter and mentioned the new directory in the
release notes. The configuration guide also gives an example of how the
path parameters are resolved.
The filters don't need to process relative paths as the core handles
that. All path parameters are interpreted as relative to the module
configuration directory, /etc/maxscale.modules.d/.
The module configuration directory didn't have a value in the CMake
files. The directory is now also installed by both packages and local
installations.
Only columns that are of string kind are now subject to masking.
With a textual resultset it would be possible to mask anything the
same way, but with a binary resultset it is not. Thus, so that the
result is not dependent upon whether the resultset happens to be
textual or not, only string fields are accessed. Documentation to be
updated in a separate change.
The utility classes have now also been rearranged somewhat.
This directory is intended to be the default working directory for
relative pathname resolution. The actual implementation for
MXS_MODULE_PARAM_PATH is done at a later step.
This removes parts of the nearly identical code from all monitors.
The removal of monitor type specific event checking is done based on the
assumption that only the monitor that is monitoring the server can be the
cause for a state change. This removes the need to actually check that the
state change is relevant for each monitor and allows the event handling to
be moved into the core.
The maskingfilter still does some processing due to the fact that it
accepts relative pathnames. This should ideally done by the core in a
controlled manner and for all path parameters.
The function is intended to be used with string parameters that are
optional and are copied when defined. This removes the need to copy the
string to a local variable to perform checks on the value.
The configuration checks for module parameters are now fully in use. By
removing the hard-coded values from the list of accepted values, the
modules take control of what parameters are accepted.
