Repository navigation
IBX-11939: [Doctrine Migrations] Added Doctrine Migrations-based schema and data install path (inlined SQL) - #787
Open
Steveb-p wants to merge 12 commits into
Conversation
This was referenced Jul 20, 2026
Merged
Open
Open
Steveb-p
changed the title
This was referenced Jul 21, 2026
Steveb-p
force-pushed
the
feature/fix-schema-rename-migration-5.0-postgres
branch
2 times, most recently
from
July 24, 2026 11:37
2e5073b to
be5d0a0
Compare
Steveb-p
marked this pull request as ready for review
July 24, 2026 12:14
Steveb-p
added a commit
that referenced
this pull request
Jul 28, 2026
…for PR #787) # Conflicts: # composer.json # phpstan-baseline.neon # src/bundle/RepositoryInstaller/Command/InstallPlatformCommand.php # src/bundle/RepositoryInstaller/DependencyInjection/Compiler/InstallerTagPass.php # src/bundle/RepositoryInstaller/Installer/CoreInstaller.php # tests/bundle/RepositoryInstaller/DependencyInjection/Compiler/InstallerTagPassTest.php # tests/bundle/RepositoryInstaller/DependencyInjection/IbexaInstallerExtensionTest.php # tests/bundle/RepositoryInstaller/IbexaRepositoryInstallerBundleTest.php
Steveb-p
force-pushed
the
base/ibx-11939-4.6-merged-5.0
branch
from
July 28, 2026 14:51
4e1d96a to
42fc503
Compare
Steveb-p
force-pushed
the
feature/fix-schema-rename-migration-5.0-postgres
branch
from
July 28, 2026 16:28
648a27c to
402fbc2
Compare
|
Steveb-p
force-pushed
the
base/ibx-11939-4.6-merged-5.0
branch
from
September 18, 2026 23:09
d071e3d to
ecc0e95
Compare
Steveb-p
force-pushed
the
feature/fix-schema-rename-migration-5.0-postgres
branch
from
September 18, 2026 23:11
58bc2fb to
b9778ac
Compare
Steveb-p
added a commit
that referenced
this pull request
Sep 25, 2026
Steveb-p
force-pushed
the
base/ibx-11939-4.6-merged-5.0
branch
from
September 25, 2026 16:16
aeecd6f to
efe6338
Compare
Steveb-p
force-pushed
the
feature/fix-schema-rename-migration-5.0-postgres
branch
from
September 25, 2026 16:16
a1d6729 to
3e897ff
Compare
This was referenced Sep 28, 2026
Uses 5.0's readonly class / promoted constructor style, passes array_values() of the foreign key columns (DBAL 4 requires a list), and the test uses APIs present in both DBAL 3 and 4 (getCreateTablesSQL(), connection-provided SQLite platform) with XSD validation enabled, so it carries over to 6.0 unchanged.
…Command #785 replaced InstallerTagPass with a !tagged_locator for the command's $installers argument, and both of those reached this branch through the base - but InstallPlatformCommand kept 5.0's array-typed constructor, so ibexa:install failed with a TypeError before doing anything. Ported the matching change from #785: ServiceLocator in, has()/get() for the lookup, and getProvidedServices() for listing the available types.
Declares the installers ServiceLocator's value type on the constructor, drops the baseline entry for the old array-typed parameter, and removes a stray blank line in CoreInstaller that the code style check flagged.
…on_ml's language FK The 5.0 rename replaced the ezcontentclass_attribute_ml_lang_fk foreign key, but on MySQL and PostgreSQL the index behind it kept its old name - MySQL reuses the leftover index for the new constraint, and PostgreSQL's was created explicitly by the install schema. schema.yaml expects ibexa_content_type_field_definition_ml_lang_fk for both. SQLite already dropped and recreated it.
DBAL 3 no longer includes the SQL in its exception message, so the runner now takes it from DriverException::getQuery() and puts it in its own message.
doctrine-migrations 5.0 takes SqlPlatform now, so the migrations that only exist on this branch list SqlPlatform::MARIADB and run their MySQL SQL there too, like the ones from 4.6.
Steveb-p
force-pushed
the
base/ibx-11939-4.6-merged-5.0
branch
from
October 5, 2026 12:31
f801939 to
fbac366
Compare
Steveb-p
force-pushed
the
feature/fix-schema-rename-migration-5.0-postgres
branch
from
October 5, 2026 12:31
7d77111 to
4ac802f
Compare
…XT on MariaDB On MariaDB, 4.6's InstallSchemaMigration creates JSON columns as LONGTEXT, as Doctrine DBAL 2.13 does, and 5.0's creates them as JSON, as DBAL 3 does: MariaDB stores that as LONGTEXT in utf8mb4_bin, with a json_valid() check. It's the same migration, so it doesn't run again on a 4.6 database upgraded to 5.0, and those columns kept their 4.6 form. ConvertMariaDbJsonColumnsMigration converts them. It skips columns that already have the check, so a fresh 5.0 install is unaffected. ibexa/installer's 4.6 to 5.0 upgrade script doesn't convert these columns either. A database upgraded through it gets them converted once it runs the Doctrine Migrations.
The column definitions were a constant in the migration class, and the statements were built in PHP. They're plain SQL in sql/ now, so they can be read or run by hand; the class only checks whether the last column is converted yet and loads the file if it isn't.
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Warning
Stacked on the
4.6→5.0merge-up #863. Its base branch (base/ibx-11939-4.6-merged-5.0) is the merge-up's branch —5.0with4.6merged in, including #785 and #856 — so this PR shows only what 5.0 needs on top. Fast-forward #863 into5.0first, then retarget this PR to5.0.Warning
This is the 5.0 follow-up to #785 (4.6). It carries the same migration forward onto this branch.
Warning
MariaDB schema drift between upgraded and fresh installs, fixed here by a new migration. On MariaDB, 4.6 creates
ibexa_setting.valueasLONGTEXT … COMMENT '(DC2Type:json)', and 5.0 asJSON, which MariaDB stores asLONGTEXTinutf8mb4_binwith ajson_valid()check.InstallSchemaMigrationdoesn't run again on upgrade, and ibexa/installer'sibexa-4.6.latest-to-5.0.0.sqldoesn't convert it either, so a 4.6 database upgraded to 5.0 kept the 4.6 form.ConvertMariaDbJsonColumnsMigrationconverts it, and fails if a row holds invalid JSON. On MariaDB 10.11 an upgraded 4.6 database ends up identical to a fresh 5.0 install, data included; on a fresh install, on a re-run and on other databases it does nothing.Note
Test-side companion —
ibexa/test-core#57.Moves the baseline fixture import into its own
BaseFixtureHook(priority 950, between theschema hooks and
FixtureHook), switchable with aload_base_fixtureoption.It matters here because under the Doctrine Migrations path the baseline repository content
arrives as core's
ImportDataMigrationrather than as a loaded fixture, andFixtureImportertruncates every table a fixture touches before inserting — so a package's own fixture writing
into those tables would take the baseline's rows with it unless it implements
AppendOnlyFixture.Packages whose integration tests load their own fixtures depend on it; the rest are unaffected.
Note
Shared library —
ibexa/doctrine-migrations.Every migration in the table below extends the
AbstractSqlMigration/SqlPlatformbase it provides.It is already merged on all three branches, so nothing in this effort is blocked on it:
#1 (4.6 baseline) · #3 (6.0 baseline) · #4 (
enable_service_migrationsfix) · #6 (DBAL 4).The fix reached 5.0 and 6.0 via merge-ups #9 and #10 — which is why
#5was closed rather than merged.Related PRs:
#440⏭️#18⏭️#191⏭️🔄 = this branch adds an upgrade migration (renames/FK-retargets existing schema), not just a fresh baseline.
⚠️ = fixes a different, related problem (missing
🩹 = this branch also received a backported delta migration, converted from a legacy
ibexa/installerupgrade/db/*.sqlscript (4.6.0 or later) that the original baseline-only migration didn't cover. See IBX-11939 upgrade-scripts backport report or that package's own PR description for details.SchemaBuilderEventsupport for a plain Doctrine ORM entity/table) — not a Doctrine Migrations baseline/upgrade migration like the rest of this table. See that package's own PR description for details.⏭️ =
struck throughand closed as unnecessary — that tier needs no changes of its own. Everything it requires arrives through the normal merge-up from the tier below; the branch is kept, so the PR can be reopened if genuinely tier-specific work turns up.Description:
Fixes a gap in #785's Doctrine Migrations installer path. On the
5.0and6.0branches,InstallSchemaMigration/ImportDataMigrationhad been independently rewritten to create the already-renamed (ibexa_*) schema from scratch — instead of replaying the real 4.6→5.0 rename. This meant a project already running 4.6 (with legacyez*table names) had no actual migration path to 5.0/6.0 via this mechanism, only a fresh-install script.This PR:
RenameSchemaTo5_0Migration(and carried through in the restoredInstallSchemaMigration/ImportDataMigrationbaseline); verified against all three, not just one engine.InstallSchemaMigration/ImportDataMigrationto the 4.6-shaped baseline (still tagged4.6.0, legacyez*table names — unchanged from the4.6branch).RenameSchemaTo5_0Migration(tagged5.0.0) with the real rename diff, sourced fromibexa/installer's own shipped upgrade SQL (upgrade/db/{mysql,postgresql}/ibexa-4.6.latest-to-5.0.0.sql), filtered to core-owned tables, plus a hand-derived SQLite equivalent (SQLite has noRENAME INDEX, so those becomeDROP INDEX+CREATE INDEX; FK constraint-name-only renames are skipped as cosmetic, since SQLite auto-updates FK/column references across the schema onRENAME TABLE/RENAME COLUMN).ez_lock→ibexa_lockobject-state identifier;ezstring→ibexa_stringfield-type identifier, in two tables).OrmEntitiesSchemaSubscriber's 5.0 adaptation (readonlyclass,array_values()on the foreign key columns for DBAL 4) is no longer part of this PR: the subscriber landed on 4.6 via IBX-11939: Added a shared SchemaBuilderEvent subscriber for plain ORM entities #852, and 5.0 got the adapted version through the regular merge-up.InstallPlatformCommand's installers as aServiceLocator, as IBX-11939: [Doctrine Migrations] Added Doctrine Migrations-based schema and data install path (inlined SQL) #785 does. IBX-11939: [Doctrine Migrations] Added Doctrine Migrations-based schema and data install path (inlined SQL) #785's!tagged_locatorwiring (replacingInstallerTagPass) reached this branch through the base, but the command kept 5.0'sarray-typed constructor, soibexa:installfailed with aTypeErrorbefore doing anything.TaggedMigrationsRunnerarrives from IBX-11939: [Doctrine Migrations] Added Doctrine Migrations-based schema and data install path (inlined SQL) #785 through the base, but DBAL 3 no longer includes the SQL in its exception message, soMigrationFailedExceptionadds it fromDriverException::getQuery().IbexaMigrationComparatororders migrations bygetTargetVersion()thengetCreationDate(), soTaggedMigrationsRunnerreplays these correctly both for a fresh 6.0 install (both migrations run) and for an existing 4.6→6.0 upgrade (only the5.0.0rename runs; already-applied migrations are skipped via the standard Doctrine Migrations metadata table).Verification caught two real gaps in the installer's own shipped SQL, both fixed here:
ezcontentclass_attribute_ml_lang_fk) needed renaming, not just the FK constraint itself.ibexa_content_type_field_definition_ct_id, but the liveschema.yamlactually expects..._ctid(no underscore) — used the live schema as ground truth.For QA:
Ran both migrations end-to-end against a real SQLite connection and diffed the resulting table/index names against a fresh
bin/console ibexa:doctrine:schema:dump-sql src/bundle/Core/Resources/config/storage/legacy/schema.yaml --force-platform=sqlite— they match exactly.To verify manually: set
ibexa.installer.schema_builder_event.enabled: false, runibexa:install, and confirm the resulting schema matches an install with the flag left at its defaulttrue.Documentation:
N/A — internal installer implementation detail.