The Oracle table compression is checked and updated in the wrong schema

On Oracle, OracleHibernateAdapter#updateDatabaseAfter makes sure the tables configured as compressed in the Hibernate mapping really are compressed. Both halves of that check address the wrong schema.

1) The ALTER TABLE statement is not qualified

ALTER TABLE XWIKIRCS COMPRESS

It is executed on a session obtained straight from the session factory (AbstractHibernateAdapter#updateDatabase does sessionFactory.openSession()), and nothing sets the schema on that session. Oracle therefore resolves the table against the current_schema of the pooled JDBC connection, which is whatever schema the previous borrower of that connection was working on: XWiki selects the schema with HibernateStore#setWiki -> alter session set current_schema = ..., and DBCP2 does not reset it when the connection goes back to the pool.

So the statement can compress (or uncompress) a table of another wiki while the wiki actually being updated keeps its wrong compression setting, or fail with ORA-00942 when the leaked schema no longer exists.

This is the Oracle counterpart of XWIKI-24632, which fixes the same problem for MySQL/MariaDB.

2) getCompressedTables() reads the wrong schema

SELECT DISTINCT table_name FROM user_tables WHERE compression = 'ENABLED'

USER_TABLES lists the tables owned by the connected user, which is not the schema the wiki data lives in as soon as there is more than one wiki: XWiki connects with a single user and switches schema with alter session set current_schema. The compression status is therefore read from the login user's schema, independently of the wiki being updated.

The two bugs combine into a check that reads schema A to decide whether to alter a table in schema B.

Impact

Limited but real: isCompressionAllowed() defaults to false for Oracle (AbstractHibernateAdapter only returns true when xwiki.compressionAllowed is explicitly set), so this code only runs on Oracle installs that opted in to compression. On those, the compression configuration of subwiki tables is never correctly applied.

Proposed fix

Use the schema returned by getDatabaseFromWikiName() — the very schema HibernateStore#setWiki sets as current_schema for that wiki — for both halves:

• qualify the ALTER TABLE statement with it;
• filter ALL_TABLES on OWNER instead of reading USER_TABLES.

ALL_TABLES is granted to PUBLIC and lists the tables the connected user has privileges on, so for a single-wiki install where the login user owns the tables it returns exactly what USER_TABLES returned.