[TASK] Guard SchemaMigrator::install() with applySafe() - #739
Conversation
TYPO3 v15 reworks the database analyzer stack and replaces the internal SchemaMigrator::install() with applySafe(). install() is deprecated in v15 and is removed there, while v14 only knows install(). Call applySafe() when the migrator provides it and keep install() as the fallback, so functional test databases are created on both core versions. The guard is a capability check and deliberately not a core version check: v15 nightlies and every v15 dev state predating the rework report v15 while still only having install(), so a version check would break them.
|
TYPO3 Core test results against this branch, as promised above. The core side is a ten change relation chain on Gerrit under topic All ten changes are Verified +1 by TYPO3 CI. That includes the Locally, each of the ten commits was additionally checked out on its own and run through cgl, In this repository, on the branch itself: Once this is merged and released, the core change raises the constraint from the branch to the |
Problem
TYPO3 v15 reworks the database analyzer stack. As part of it, the internal
SchemaMigrator::install()is replaced byapplySafe():install()is kept as a@deprecatedthin wrapper for exactly one reason — this package creates the databaseof every functional test through it — and is removed in a follow-up change.
Classes/Core/Testbase.php::createDatabaseStructure()is the only call site:TYPO3 v14 only knows
install(), and themainbranch here supports14.*.*@dev || 15.*.*@dev, so the call has to work against both.Change
Call
applySafe()when the migrator provides it, keepinstall()as the fallback:Behaviour is unchanged on both sides:
install()in v15 does nothing but delegate toapplySafe(), this call site never passed the v14$createOnlyargument, and thereturn value was not evaluated before either.
Why a capability check and not a core version check
A
Typo3Versioncheck would be wrong here, not just less elegant. v15 nightlies andevery v15 dev state predating the analyzer rework report
15.xwhile still only havinginstall()— a version check would break them.method_exists()on the migratorinstance is true exactly when the call is valid.
method_exists()on the object is also preferred overclass_exists()on one of thenew DTOs: the DTOs and
applySafe()happen to land in the same core change today, butthe core side is a patch series still under review, and a split that introduces the
classes before the method would make a
class_exists()probe return true one linebefore a fatal. It follows the same shape as the existing
method_exists(Bootstrap::class, 'loadExtTables')guard a few lines above.Verification
Run in this repository, all green:
typo3/cms-core14.3.x-dev (fallback branch)composerUpdate,cgl,lint,phpstan,unittypo3/cms-coredev-main (v15)composerUpdate,lint,unitNo
phpstan-baseline.neonentry is needed:$container->get()is PSR-11 and returnsmixed, so the probe is not statically resolvable and produces nofunction.alreadyNarrowedType.The TYPO3 Core functional suite result against this branch is added as a comment once
the corresponding core change has run through CI.
Coordination
This has to be merged and released before the core change that removes
SchemaMigrator::install()can be merged. The core side references this pull request inits commit message.