This change now ties the pieces together and implements tha
functionality required of the masking filter. Note thought that
this is still work in progress and changes will follow.
- LEncInt : Class for dealing with length encoded integers
- LEncString : Class for dealing with length encoded strings
- ComPacket : Base-class for all packet classes.
- ComRequest : Base-class for all requests.
- ComResponse : Base-class for all responses.
- ComQueryResponse
- ComQueryResponse::ColumnDef
- ComQueryResponse::Row
Common to these all is that they are very thin, and basically only
make it easier to what anyway needs to be done, if the equivalent
is used by directly accessing the packet buffer.
Now these are private for the masking filter, but may be moved under
masxcale/include if/when the general usefulness has been established.
Closer is a template using which C-style resources can be managed
in a C++ context where exceptions can occur. By placing a C resource
in a Closer instance, it is certain the resource will be freed when
the closing scope is exited irrespective of whether that occurs due
to the normal control flow, due to a return statement or an exception
having been thrown.
To be used with Closer, the CloserTraits template must be specialized
for the type in question. With this change specializations are provided
for FILE*, json_t*, pcre_code* and pcre2_match_data*.
MXS-1070
Now both qc_mysqlembedded and qc_sqlite return the same stuff
for the same statement, and both include also operators in
addition to pure functions. Whether that is the right approach,
is still subject to debate.
However, if we want to make it possible to disable e.g. the
use of concat as in "select concat(a) from t", where a is a string,
to prevent the bypassing of the masking filter, then conceptually
it should be possible to prevent "select a+0 from t", where a is an
int, as well.
The setting up and the initialization of the query classifier has
now been separated. The gateway explicitly sets up the query
classifier (i.e. chooses which one to use and what arguments to
provide), but the actual initialization is performed as part of
the general module initialization.
The cache filter now uses the module parameters. Due to the relative path
support for the `rules` parameter, it is still manually parsed.
The `storage_options` list is also manually parsed. The core could
possible parse simple comma separated lists and return them as a string
array. This should be done in a later commit.
The filters should use the same configuration parameters as other modules
use. This allows them to use the common configuration management functions
to get values from it.
The schemarouter now accepts all router_options values as parameters.
Also fixed a mistake in the documentation where the router options section
was listed twice.
The parameters that readwritesplit uses now use the new system. This
removes the need for the qualified parameter processing found in config.c.
All values for router_options are now also accepted as parameters. The
router_options is deprecated and support for it will be removed in a
future version.
If the enums are converted to the acutual enum values before they are
returned, this removes the need for the modules to process the enum
strings to enum values. This allows modules to use enumerations with
minimal effort.
The MXS_MODULDE object now contains optinal pointers for functions
to be called att process and thread startup and shutdown. Since the
functions were added to the end, strictly speaking, all structures
would not have needed to have been modified, but better to be
explicit. In a subsequent change, these will be called.
C++ does not support flexible arrays, so for the time being C++
modules are restricted to 10 parameters. Better approach is to
factor out the parameters to a separate array and then just store
a pointer to that array in MXS_MODULE.
The variables now use the actual option and parameter names. This should
help make the code more readable and easier to understand in relation to
the used options.
The path type is validated if the module requested path
validation. Service checks can be done both on startup and at
runtime. This allows dynamic changes to module parameters to be validated
without a configuration context.
The options allow the modules to impose type specific restrictions on the
parameters. This can be used to offload file permission and mandatory
parameter checks to the core.
All monitors now declare the parameters that they use. This allows the
core to check the validity of the parameters before they are passed to the
monitor. It also simplifies the processing of the parameters as they are
guaranteed to be valid.
The declared parameters are now used to check whether the configuration is
valid. As the filters and monitors don't use the new declarations, the
code needs to be commented out. Once the parameter processing has been
migrated to the new system, the code can be enabled.
Filters, monitors and routers can now declare parameters and those
parameters will always be present. Currently, this removes the need to
parse simple values like booleans and integers.
Some of the more common parameter types could be added in the future
e.g. paths to files.
The MXS_MODULE structure now contains a member for parameters. This can be
used by the modules to declare accepted parameters, their types and the
default values. Currently only count, integer, boolean, string and enum
values are supported.
AES_CTR routines are part of openssl 1.0.
If an old library is in use the AES_CTR cannot be specified for
encryption.
Additionally compilation is done without errors.
The MXS_MODULE structure of each module is now globally exposed by the
`get_module` function. This allows the module information of any module to
be queried.
This information can then be used to validate various things but the main
goal is to provide a way for modules to declare accepted parameters in the
MXS_MODULE structure. This will be done in a later commit.
Also the function documentation is now in the header file. This should
make it easier to read.
The MODULE_INFO is now the main object which is used by modules to convey
information to the MaxScale core. The MXS_MODULE name is more apt as it
now contains the actual module definition.
The old MODULES structure was moved into load_utils.c as an internal
implementation and was renamed so that it is not confused with the new
MODULE structure.
