hcq/MaxScale
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

MXS-935: Implement column matching

Browse Source 
With the advent of qc_get_field_info, columns can now be matched.
However, there is still some undeterminism caused by the table
information not containing contextual information (exactly where
is the table used).

Further, suppose table X contains the column A and table Y contains
the column B, then given a statement like

    SELECT a, b from X, Z;

we cannot know whether a is in X or Z, or b in X or Z, without being
aware of the schema, which we currently are not.

Consequently, as long as MaxScale is not aware of the schema, some
heuristics must be applied. For instance, if exactly one table is
referred to, then we can assume that columns that are not explicitly
qualified are from that table.

The rule tests are currently rather rudimentary and need to be
expanded.
This commit is contained in:
Johan Wikman
2016-11-14 16:17:31 +02:00
parent 548182afe3
commit c4999232ce
4 changed files with 827 additions and 153 deletions
Download Patch File Download Diff File Expand all files Collapse all files

38
Documentation/Filters/Cache.md
View File

@ -173,8 +173,11 @@ where,
* the _op_ can be `=`, `!=`, `like` or `unlike`, and
* the _value_ a string.
If _op_ is `=` or `!=` then _value_ is used verbatim; if it is `like`
If _op_ is `=` or `!=` then _value_ is used as a string; if it is `like`
or `unlike`, then _value_ is interpreted as a _pcre2_ regular expression.
Note though that if _attribute_ is `database`, `table` or `column`, then
the string is interpreted as a name, where a dot `.` denotes qualification
or scoping.
The objects in the `store` array are processed in order. If the result
of a comparison is _true_, no further processing will be made and the
@ -206,6 +209,39 @@ select * from tbl where b = 3 and a = 2;
as well. Although they conceptually are identical, there will be two
cache entries.
### Qualified Names
When using `=` or `!=` in the rule object in conjunction with `database`,
`table` and `column`, the provided string is interpreted as a name, that is,
dot (`.`) denotes qualification or scope.
In practice that means that if _attribute_ is `database` then _value_ may
not contain a dot, if _attribute_ is `table` then _value_ may contain one
dot, used for separating the database and table names respectively, and
if _attribute_ is `column` then _value_ may contain one or two dots, used
for separating table and column names, or database, table and column names.
Note that if a qualified name is used as a _value_, then all parts of the
name must be available for a match. Currently Maria DB MaxScale may not
always be capable of deducing in what table a particular column is. If
that is the case, then a value like `tbl.field` may not necessarily
be a match even if the field is `field` and the table actually is `tbl`.
### Implication of the _default_ database.
If the rules concerns the `database`, then only if the statement refers
to *no* specific database, will the default database be considered.
### Regexp Matching
The string used for matching the regular expression contains as much
information as there is available. For instance, in a situation like
```
use somedb;
select fld from tbl;
```
the string matched against the regular expression will be `somedb.tbl.fld`.
### Examples
Cache all queries targeting a particular database.