IBX-11939: [Doctrine Migrations] Added Doctrine Migrations-based schema and data install path (inlined SQL) - #787
Open
Steveb-p wants to merge 8 commits into
Conversation
This was referenced Jul 20, 2026
Open
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
….6 base Squashes the net effect of the 16 commits previously on this branch (since the old base/ibx-11939-4.6-merged-5.0 merge point) into one commit. Most of those commits were parallel duplicates of work already landed on the 4.6 feature branch and merged forward via the rebuilt base branch; only the genuinely 5.0-specific delta is carried here: - RenameSchemaTo5_0Migration + supporting SQL: renames the legacy ez* schema to the ibexa_* naming scheme introduced in 5.0. - FixLegacyIdentifiersMigration + supporting SQL: fixes legacy identifiers as part of that rename. - InstallSchemaMigration: idempotency guard checks the post-rename "ibexa_content" table name instead of "ezcontentobject". - services.yml: registers both new migrations as tagged services. - composer.json: points ibexa/doctrine-migrations at its 5.0 branch.
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
Converts installer's upgrade/db/ibexa-4.5.1-to-4.5.2.sql and upgrade/db/ibexa-4.6.20-to-4.6.21.sql into guarded Doctrine migrations targeting the pre-rename (4.6.0) table names, for installs whose schema already predates these indexes. Needed on this branch too, independently of the 4.6 branch: RenameSchemaTo5_0Migration's RENAME INDEX statements assume these indexes already exist under their old names.
$schema->getTable() throws TableDoesNotExist rather than returning null, so a guard that calls it directly (without checking hasTable() first) crashes -- rather than skipping -- on any install that never had the table under this name at all. Caught via live testing against a real database. Guard now checks hasTable() first. Same content as the 4.6 branch.
…into baseline Same rationale as ibexa/product-catalog: doctrine migrations only exist starting at 4.6, so InstallSchemaMigration's baseline already includes these indexes (originally shipped via installer's upgrade/db/ibexa-4.5.0-to-4.5.1.sql). A standalone migration for pre-4.6 content can never have real work to do on a genuine 4.6+ install.
The feat/doctrine-migrations-5.0 branch it previously required has been merged into and deleted from the primary 5.0 branch upstream, so the old constraint no longer resolves.
$migration->up(new Schema()) gave every migration's hasTable()/ getTable() guard checks an always-empty schema to inspect, regardless of what earlier migrations in the same run (or a prior run) actually created against the real database -- guards written the correct way (checking hasTable() before trusting a table exists) would incorrectly conclude the table is missing and either skip work that still needs doing, or crash outright on getTable() for a table that does exist. Introspect the live database instead, the same way the standalone 'doctrine:migrations:migrate' command already does via DBALSchemaDiffProvider::createFromSchema().
InstallSchemaMigration, AddUrlAliasMlLinkIndexMigration, RenameSchemaTo5_0Migration, ImportDataMigration, and FixLegacyIdentifiersMigration only depend on the persistence connection -- they don't need anything from IbexaRepositoryInstallerBundle (CoreInstaller, BuildSchemaSubscriber), which is scoped to installer-time concerns and additionally requires DoctrineSchemaBundle to boot at all. Declaring them in IbexaCoreBundle instead matches how every other package in this effort declares its own InstallSchemaMigration in its own bundle, and lets any consumer discover core's schema migrations via ibexa:doctrine:migrations:migrate without needing the installer bundle registered -- useful for integration test kernels that don't otherwise need CoreInstaller.
… SQL install-schema-sqlite.sql and import-data-sqlite.sql were generated from the MySQL source without adapting to SQLite's stricter SQL semantics: - import-data-sqlite.sql used MySQL-style backslash escapes (\" and \n) inside string literals. SQLite (unlike MySQL) does not interpret backslash as an escape character at all, so these were stored as literal two-byte sequences, corrupting PHP-serialized content-type names/descriptions (unserialize() failures) and embedded XML field data (DOMDocument parse failures, e.g. the admin user's own ezimage field). - install-schema-sqlite.sql collapsed the composite primary keys on ezcontentclass, ezcontentclass_attribute and ezcontentobject_attribute (id, version) down to a single-column `id INTEGER PRIMARY KEY AUTOINCREMENT`, dropping the `version` component entirely -- unlike the mysql/postgresql variants, which both correctly declare `PRIMARY KEY(id, version)`. This made SQLite reject the second row (e.g. publishing a content-type draft, which legitimately reuses the same id with a different version/status) as a duplicate primary key. Both only affect the SQLite platform; MySQL and PostgreSQL were already correct.
|
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
This PR's base branch (
base/ibx-11939-4.6-merged-5.0) is not the real5.0branch — it's5.0with the4.6feature branch (#785) merged in. This PR intentionally shows only the changes introduced on top of "4.6, once merged forward" — review #785 first. Once #785 merges for real and is merged forward into5.0, this PR's base will be updated to point at the real5.0branch.Warning
This is the 5.0 follow-up to #785 (4.6). Review that PR first — this carries the same migration forward onto this branch.
Related PRs:
🔄 = 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.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).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.