It is now possible to specify what information the caller is interested
in. With this the cost for collecting information during the query parsing
that nobody is interested in can be avoided.
The static capabilities declared in getCapabilities allows certain
capabilities to be queried before instances are created. The intended use
of this capability is to remove the need for the `is_internal_service`
function.
The embedded parser is not capable of parsing preparable statements
containing ?:s as ordinary statements, so they have to be replaced
with something else. Replacing them with a dummy variable cannot be
done as that will affect the type of the statement. Replacing with
0 seems to be a good compromise.
Since the whole preparable statement will be available, it is
superfluous to provide a function using which the operation of
the preparable statement can be obtained.
This function will return the preparable statement of a PREPARE
statement as a COM_QUERY GWBUF. That is, once obtained, the normal
query classifier functions can be used for obtaining information
about the preparable statement itself.
- Only types of fixed size used in API interface
- The actual function return value specifies whether the parsing
process succeeded, while "logical" return values are returned
as out arguments.
The wrapper function currently ignores the function return value.
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 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 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.
The modules are now declared with a common macro. This allows future
additions to the module loading process while also making the loaded
symbol name a constant.
This allows modules to only expose one entry point with a consistent
signature. In the future, this could be used to implement declarations of
module parameters.
qc_get_table_names() and qc_get_database_names() now always set
the number items, also in case of error. That is, it is now always
safe to start iterating using the number of items without first
checking the returned pointer.
To prevent bugs caused by pointers having the wrong type (e.g. uint32_t
instead of uint8_t), some macros are changed into inline functions so that
the normal type-checking is performed.
The macros MYSQL_GET_ERRCODE, MYSQL_GET_STMTOK_NPARAM, MYSQL_GET_STMTOK_NATTR,
and MYSQL_GET_NATTR were not changed, because they may be too specific to
be present in a general purpose header in the first place.
Together with the field names, now qc_get_field_info also returns
field usage information, that is, in what context a field is used.
This allows, for instance, the cache to take action if a a particular
field is selected (SELECT a FROM ...), but not if it is used in a
GROUP BY clause (...GROUP BY a).
This caused a significant modifications of qc_mysqlembedded that
earlier did not walk the parse-tree, but instead looped over of a
list of st_select_lex instances that, the name notwithstanding,
also contain information about other things but SELECTs. The former
approach lost all contextual information, so it was not possible
to know where a particular field was used.
Now the parse tree is walked, which means that the contextual
information is known, and thus the field usage can be updated.
Function is no longer used and it was quite unoptimal, so now
removed.
qc_get_prepare_name, qc_get_prepare_operation and qc_get_field_info
that were missing from qc_dummy added at the same time.
A HAVING clause can only refer to names that already have been mentioned
or if "SELECT *" is used. Either way, the HAVING names need not be separately
collected.
This function returns more detailed information about the fields
of a statement. Supersedes qc_get_affected_fields() that will
be deprecated and removed.
Note that this function now introduced new kind of behaviour; the
returned data belongs to the GWBUF and remains valid for as long as
the GWBUF is alive. That means that unnecessary copying need not
be done.
The operation of the statement to be prepared is no longer
reported as the operation of the PREPARE statement.
Instead, when the type of the statement is
QUERY_TYPE_PREPARE_NAMED_STMT, the operation can be obtained
using qc_get_prepare_operation().
The qc_mysqlembedded implementation will be provided in a
subsequent commit.
When a DESCRIBE <table> or a SHOW COLUMNS IN <table> query is done, the
actual query is performed on tables in the information_schema
database. This might be what actually happens on the backend server but
this information is not really useful when we need to know which database
the query targets.
By passing the actual table names instead of the underlying table names,
the schemarouter is able to detect where these statements should be
routed.
Now more information about a transaction start is provided. When
a transaction start statement is parsed, the type of the statement
with be QUERY_TYPE_BEGIN_TRX anded with QUERY_TYPE_READ or
QUERY_TYPE_WRITE if the transaction was explicitly started as READ
ONLY or READ WRITE.
Now also BEGIN WORK and [COMMIT|ROLLBACK] WORK are recognized.
"AND CHAIN" will still need to be recognized.
