refactor: EXPOSED-710 Move plain SQL for retrieving foreign keys from MysqlDialect

[bog-walk]

Description

Summary of the change: Plain SQL in MysqlDialect.fillConstraintCacheForTables() is now in exposed-jdbc under tableConstraints().

Detailed description:

• Why:

In preparation for R2DBC, JDBC-specific execution of plain SQL needs to be extracted from exposed-core. MysqlDialect.fillConstraintCacheForTables() currently executes a custom SQL query to retrieve foreign key constraints associated with the provided table. This is an override for a protected method that is only called in 1 place: DatabaseDialect.columnConstraints(). The latter is responsible for all SchemaUtils methods that check foreign key consistency.

• How:
  • Query is now located in JDBC tableConstraints(), because this is the metadata query called by the default implementation of fillConstraintCacheForTables(). This is also the only place where tableConstraints() is invoked.
  • Logic was copied to the new location, with 1 extra line. The custom query only returns a mapping of table-column data for every foreign key, where as the JDBC built-in query returns a mapping of table data for every foreign key and every table involved in the foreign key. This can be seen in highlighted tests, which would fail if the result of the query was not adjusted to match. This was done in the event that users call tableConstraints() directly. Calling columnConstraints() of SchemaUtils methods has not changed behavior.

---

Type of Change

Please mark the relevant options with an "X":

• Other: refactor

Affected databases:

• MariaDB
• Mysql5
• Mysql8

Checklist

• Unit tests are in place
• The build is green (including the Detekt check)
• All public methods affected by my PR has up to date API docs

---

Related Issues

EXPOSED-710
R2DBC parent - EXPOSED-517

[bog-walk]

This is the only new line of logic, as mentioned in the PR description. If this was not included, technically any tests that call tableConstraints directly (or if users do this themselves?) would fail.

The custom SQL returns values only for tables that have a foreign key (FK). Whereas DatabaseMetaData.getImportedKeys() below associates a query for each table involved in the FK (i.e. both parent & child), due to SchemaUtils.sortTablesByReferences() at the start. Meaning there will always be a key for the parent table, but with a value of an empty list.

I'm not sure the reason behind this behavior, so I added this line to make sure that there was no breaking change.