CONNECT - External Table Types
Because so many ODBC and JDBC drivers exist and only the main ones have been heavily tested, these table types cannot be ranked as stable. Use them with care in production applications.
These types can be used to access tables belonging to the current or another database server. Six types are currently provided:
ODBC: To be used to access tables from a database management system providing an ODBC connector. ODBC is a standard of Microsoft and is currently available on Windows. On Linux, it can also be used provided a specific application emulating ODBC is installed. Currently only unixODBC is supported.
JDBC: To be used to access tables from a database management system providing a JDBC connector. JDBC is an Oracle standard implemented in Java and principally meant to be used by Java applications. Using it directly from C or C++ application seems to be almost impossible due to an Oracle bug still not fixed. However, this can be achieved using a Java wrapper class used as an interface between C++ and JDBC. On another hand, JDBC is available on all platforms and operating systems.
Mongo: To access MongoDB collections as tables via their MongoDB C Driver. Because this requires both MongoDB and the C Driver to be installed and operational, this table type is not currently available in binary distributions but only when compiling MariaDB from source.
MySQL: This type is the preferred way to access tables belonging to another MySQL or MariaDB server. It uses the MySQL API to access the external table. Even though this can be obtained using the FEDERATED(X) plugin, this specific type is used internally by CONNECT because it also makes it possible to access tables belonging to the current server.
PROXY: Internally used by some table types to access other tables from one table.
External Table Specification
The four main external table types – odbc, jdbc, mongo and mysql – are specified giving the following information:
- The data source. This is specified in the connection option.
- The remote table or view to access. This can be specified within the connection string or using specific CONNECT options.
- The column definitions. This can be also left to CONNECT to find them using the discovery MariaDB feature.
The way this works is by establishing a connection to the external data source and by sending it an SQL statement (or its equivalent using API functions for MONGO) enabling it to execute the original query. To enhance performance, it is necessary to have the remote data source do the maximum processing. This is needed in particular to reduce the amount of data returned by the data source.
This is why, for SELECT queries, CONNECT uses the cond_push MariaDB feature to retrieve the maximum of the where clause of the original query that can be added to the query sent to the data source. This is automatic and does not require anything to be done by the user.
However, more can be done. In addition to accessing a remote table, CONNECT offers the possibility to specify what the remote server must do. This is done by specifying it as a view in the srcdef option. For example:
CREATE TABLE custnum ENGINE=CONNECT TABLE_TYPE=XXX CONNECTION='connecton string' SRCDEF='select pays as country, count(*) as customers from custnum group by pays';
Doing so, the group by clause will be done by the remote server considerably reducing the amount of data sent back on the connection.
This may even be increased by adding to the srcdef part of the “compatible” part of the query where clauses like this are done for table-based tables. Note that for MariaDB, this table has two columns, country and customers. Supposing the original query is:
SELECT * FROM custnum WHERE (country = 'UK' OR country = 'USA') AND customers > 5;
How can we make the where clause be added to the sent srcdef? There are many problems:
- Where to include the additional information.
- What about the use of alias.
- How to know what will be a where clause or a having clause.
The first problem is solved by preparing the srcdef view to receive clauses. The above example srcdef becomes:
SRCDEF='select pays as country, count(*) as customers from custnum where %s group by pays having %s';
The %s in the srcdef are place holders for eventual compatible parts of the original query where clause. If the select query does not specify a where clause, or a gives an unacceptable where clause, place holders will be filled by dummy clauses (1=1).
The other problems must be solved by adding to the create table a list of columns that must be translated because they are aliases or/and aliases on aggregate functions that must become a having clause. For example, in this case:
CREATE TABLE custnum ENGINE=CONNECT TABLE_TYPE=XXX CONNECTION='connecton string' SRCDEF='select pays as country, count(*) as customers from custnum where %s group by pays having %s' OPTION_LIST='Alias=customers=*count(*);country=pays';
This is specified by the alias option, to be used in the option list. It is made of a semi-colon separated list of items containing:
- The local column name (alias in the remote server)
- An equal sign.
- An eventual ‘*’ indicating this is column correspond to an aggregate function.
- The remote column name.
With this information, CONNECT will be able to make the query sent to the remote data source:
select pays as country, count(*) as customers from custnum where (pays = 'UK' OR pays = 'USA') group by country having count(*) > 5
Note: Some data sources, including MySQL and MariaDB, accept aliases in the having clause. In that case, the alias option could have been specified as:
Another option exists, phpos, enabling to specify what place holders are present and in what order. To be specified as “W”, “WH”, “H”, or “HW”. It is rarely used because by default CONNECT can set it from the srcdef content. The only cases it is needed is when the srcdef contains only a having place holder or when the having place holder occurs before the where place holder, which can occur on queries containing joins. CONNECT cannot handle more than one place holder of each type.
SRCDEF is not available for MONGO tables, but other ways of achieving this exist and are described in the MONGO table type chapter.