The MySQL/MariaDB table row format can be updated in the wrong database

On MySQL/MariaDB, MySQLHibernateAdapter.updateRowFormats() produces an unqualified statement:

ALTER TABLE xwikircs ROW_FORMAT=Dynamic

It is executed on a session obtained straight from the session factory (AbstractHibernateAdapter#updateDatabase does sessionFactory.openSession()), and nothing sets the database on that session. MySQL/MariaDB therefore resolves the table against the current catalog of the pooled JDBC connection, which is whatever database the previous borrower of that connection was working on: XWiki selects the database with HibernateStore#setWiki -> Connection#setCatalog, and DBCP2 does not reset it when the connection goes back to the pool (no defaultCatalog is configured).

Consequences, when initializing or updating the schema of a subwiki:

• If the leaked catalog points at an existing database, the ALTER TABLE silently succeeds on the wrong wiki's table, and the wiki being initialized keeps its wrong row format. This is the common case and it goes completely unnoticed.
• If the leaked catalog points at a database that has since been dropped (a deleted wiki), the statement fails and the whole wiki initialization is aborted with a misleading error.

The second case was caught by a flickering functional test on the CI (org.xwiki.wiki.test.ui.AllIT$NestedWikiManagerRestIT#testCreateWiki on MariaDB). While creating wiki foo, the row format update ran against the previously deleted mynewwiki database:

ERROR .HibernateDataMigrationManager - The empty database foo seems to be not writable, please check your configuration!
com.xpn.xwiki.store.migration.DataMigrationException: Unable to update schema of wiki [foo]
    at com.xpn.xwiki.store.migration.hibernate.HibernateDataMigrationManager.updateSchema(HibernateDataMigrationManager.java:199)
    ...
Caused by: java.sql.SQLSyntaxErrorException: (conn=8) Table 'mynewwiki.xwikircs' doesn't exist
    at org.xwiki.store.hibernate.internal.MySQLHibernateAdapter.updateRowFormats(MySQLHibernateAdapter.java:86)
    at org.xwiki.store.hibernate.internal.MySQLHibernateAdapter.updateDatabaseAfter(MySQLHibernateAdapter.java:58)

The standard Hibernate DDL is not affected: it emits catalog-qualified names taken from the metadata, which is why only this post-DDL step fails.

The same ALTER TABLE statement is also produced for AbstractResizeMigration.

Fix: qualify the statement with the database of the wiki being updated, which is already the database used by getRowFormats() to read the current row formats.

Note that OracleHibernateAdapter#updateTableCompression has the same unqualified ALTER TABLE pattern (and reads user_tables, i.e. the login schema rather than the current schema). It is dormant in practice since isCompressionAllowed() defaults to false for Oracle, so it is left out of this issue.