fix(db): speed up Oracle schema introspection and run the PHPUnit DB suite against Oracle again [10.16]

[oc-tmueller]

Backport of #41808 to 10.16, plus the Oracle fixes needed to make the job usable on this branch.

What is in this PR

1. ci: the Oracle PHPUnit job — php-unit.yml gains a databases input (defaulting to today's five combinations, so the existing matrix is unchanged) and an oracle service on gvenzl/oracle-free:23-slim-faststart, using the same "empty image string disables the service" idiom as the mysql/postgres services. The app user lives in the FREEPDB1 pluggable database, so --database-host is not passed and a connect string carrying SERVICE_NAME is used instead. oci8 is requested from setup-php only for Oracle jobs, and DB_TYPE is exported only for Oracle so test-phpunit.sh narrows the run to --group DB.

ci.yml calls the reusable workflow a second time in a job whose display name is also PHP Unit, so all six databases appear in one group of checks. It is a separate job rather than a sixth matrix entry because this branch has fail-fast: true — a slow or failing Oracle run must not cancel the other databases.

No nightly.yml here, unlike on master: GitHub only runs schedule: from the default branch, so a nightly workflow on a maintenance branch would never fire.

2. fix(db): batched Oracle schema introspection (OC\DB\OracleSchemaManager, wired in through Connection::getSchemaManager()). Without this the job is not viable: occ maintenance:install --database=oci needed over 40 minutes on this branch. doctrine/dbal 2.13 implements listTables() as listTableDetails() per table — four dictionary queries each, with the table name inlined as a literal, so Oracle hard parses every one — and Migrator::getDiff() introspects the whole schema once per applied migration. The subclass reads each category in one batched query over the user_* views and feeds the rows to the very same _getPortableTable*() methods, so the resulting Table objects are unchanged; tests/lib/DB/OracleSchemaManagerTest.php asserts that equivalence. Introspecting a 48-table schema drops from 194 queries to 6 and the install from 43 minutes to ~30 seconds. dbal does this natively from 3.4 on, which is why master never needed it and why this file is 10.16-only.

3. fix: the md5(null) cast in Files\Cache\Cache — the fix: commit of #41808. Kept here so both branches hash the storage root the same way and the code does not depend on PHP 7.4 tolerating an implicit null-to-string conversion; the stored path_hash was never wrong, because md5(null) coerces to md5('').

Not needed here: the feat: commit of #41808, which restores OC\Setup\OCI, the dbSetupClasses entry and --database-connection-string. On 10.16 none of that was ever removed — 95e3cde landed on master only — so this branch can already be installed against Oracle from both the CLI and the web installer.

Verification

Green on this branch. The Oracle job was run three times to see how stable the runtime is:

step	run #1	run #2	run #3	master Oracle
Initialize containers	1 m 05 s	1 m 05 s	2 m 06 s	1 m 07 s
Setup PHP (incl. oci8)	21 s	25 s	1 m 00 s	22 s
maintenance:install --database=oci	55 s	51 s	36 s	53 s
phpunit --group DB	15 m 20 s	13 m 02 s	18 m 41 s	8 m 56 s
total job	18 m 14 s	16 m 08 s	23 m 24 s	11 m 57 s

Runner variance dominates: in run #3 every database was slower, and in run #1 the pre-existing mariadb:10.11 job took 22 m 27 s while Oracle took 18 m 14 s. Side by side, run #3 was sqlite 8 m 41 s, mariadb:10.11 9 m 11 s, postgres:10.21 11 m 23 s, mariadb:10.6 12 m 24 s, mysql:8.0 16 m 58 s, Oracle 23 m 24 s. So Oracle is at the upper end of what this branch already runs but not out of line with it, which is why it is wired into every PR rather than gated behind a full-ci title. Note also that Oracle only runs --group DB, whereas the other databases run the full suite.

PHPUnit passes: Tests: 5412, Assertions: 35280, Skipped: 17, no failures or errors. The skips are the pre-existing platform skips, including the Oracle ones already in the tree.

Two things worth recording, since neither could be predicted before the first run:

• setup-php resolves oci8 for PHP 7.4 in ~20 s (oci8 2.2.0 against Instant Client 23.26) — no source build, so no extension cache is needed. Same as on master, which gets oci8 3.4.0.
• Oracle Database Free 23ai works as-is against this branch's doctrine/dbal 2.13 and OracleMigrator; no fallback to gvenzl/oracle-xe:21 was needed.

Coverage is not a factor: test-phpunit.sh passes --coverage-clover unconditionally, but no coverage driver is installed, so PHPUnit only warns — exactly as it already does for the other databases here.

Types of changes

• Bugfix
• Technical debt

Checklist

• Code changes
• Changelog items
• Documentation (not needed)
• Tests

🤖 Generated with Claude Code

[phil-davis]

https://github.com/owncloud/core/actions/runs/34099036638/job/101669078066?pr=41815

  Cloning into bare repository '/home/runner/.cache/composer/vcs/https---code  
  berg.org-icewind-SMB'...                                                     
  fatal: unable to access 'https://codeberg.org/icewind/SMB/': The requested   
  URL returned error: 504                                                      

Got the codeberg problem here in 10.16 still.
I guess we restart the job, and hope for the best.

[phil-davis]

do we need all the debug stuff?

[DeepDiver1975]

this needs to go - thank you

[oc-tmueller]

No. Removed in ca4a63c.

That step existed to answer one question: whether the hour-long maintenance:install was oci8 / the instant client / the TCP connection on PHP 7.4. It was none of those — it was doctrine/dbal 2.13 introspecting the schema per table, fixed by #41819, which is now in this branch. Install is back under a minute, so the probe has nothing left to tell us.

[phil-davis]

and all this stuff, is it needed?

[oc-tmueller]

The v$session / v$sql sampler is gone too (ca4a63c) — with it the background job, the 90 minute kill timeout and the top-SQL dump. Installing on Oracle is a plain php occ ${install_cmd} again, same as every other database.

What is left in this block is not debug and is needed: the --database-connection-string=…SERVICE_NAME=FREEPDB1… branch. gvenzl/oracle-free creates the app user inside the FREEPDB1 pluggable database, so host + database name would target the CDB root and the install fails. That is why --database-host is deliberately not passed there.