[CONJ-1088] Implement databaseTerm option Created: 2023-07-11  Updated: 2023-12-15  Resolved: 2023-07-28

Status: Closed
Project: MariaDB Connector/J
Component/s: configuration, MySQL compatibility
Affects Version/s: None
Fix Version/s: 3.2.0

Type: Task Priority: Major
Reporter: Diego Dupin Assignee: Diego Dupin
Resolution: Fixed Votes: 0
Labels: None

Issue Links:
Relates
relates to CONJ-892 getSchemaTerm returns "schema" instea... Closed

 Description   

SQL defined catalog and schema.

MariaDB doesn't support catalog, using a constant catalog 'def'.
see for example `select t.TABLE_CATALOG, t.TABLE_SCHEMA, t.TABLE_NAME from information_schema.tables t`;

+---------------+----------------------------------------+------------------------------------------------------+
| TABLE_CATALOG | TABLE_SCHEMA                           | TABLE_NAME                                           |
+---------------+----------------------------------------+------------------------------------------------------+
| def           | information_schema                     | ALL_PLUGINS                                          |
| def           | information_schema                     | APPLICABLE_ROLES                                     |
| def           | information_schema                     | CHARACTER_SETS                                       |
...

historically in jdbc driver, connection.catalog has been use, while schema is not (connection.getSchema() return null while connection.setSchema() doesn't do any action (and same thing in all metadata methods using catalog and schema). The good use in JDBC driver would be to use schema while not using catalog.

mysql driver has a new option since 8.0.17 `databaseTerm` that default using historical catalog, but permiting if set to 'SCHEMA' to change to expected schema, ignoring catalog. One curious thing is returning "CATALOG" for DatabaseMetaData.getCatalogTerm() even if CATALOG is not supported in mysql.

metadata getSchemaTerm() must change accordingly


Generated at Thu Feb 08 03:20:31 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.