Changes to the ChangeMasterOptions made it non-trivial so it cannot be
safely memset anymore. The maxavrocheck was missing the linkage to the
maxscale-common library.
See script directory for method. The script to run in the top level
MaxScale directory is called maxscale-uncrustify.sh, which uses
another script, list-src, from the same directory (so you need to set
your PATH). The uncrustify version was 0.66.
In order to make it visible that the types contain C++
members, the following types were renamed:
CHANGE_MASTER_OPTIONS -> ChangeMasterOptions
MASTER_SERVER_CNF -> MasterServerConfig
Functions where also changed to take const refs were appropriate.
In order support the possiblity for having multiple alternative
masters for the binlog server, we need to have multiple configs
around.
Originally the config values were stored as 'char *':s, which
would have made the lifetime management of the strings laborious
and error prone.
Now, the options are stored as std::string:s, which makes the
lifetime management a non-issue.
Comparing two fixed std::strings would have equal C strings but comparing
with operator== they would be different. This was a result of the string
modification done by fix_object_name.
Converted the internal header into a C++ header, added std::string
overload and fixed use of the function.
The test failed because router instances are now created when the service
is allocated. In addition to this, a debug assertion was hit when a
service was freed if the router instance creation failed.
The test cases allocated servers in a way that doesn't comfortably suit
the way the servers are now allocated. Adding a helper C++ class to load
module defaults makes it easier to do explicit server initialization in
tests.
The binlogrouter was also fixed in this commit as it uses servers much
like a test would use.
The same mechanism that is used for modules can be used for the
configuration of the core objects. This removes the need for the redundant
code that validates various values that is already present in the code
that modules use.
To prepare the router's for the eventual removal of the router_options
parameter, the API option arguments should not be used. The parameters can
be substituted by tokenizing the value of the parameter that is still
stored as a part of the service.
