IBX-11939: Added Doctrine Migrations baseline for ibexa/messenger - #22
Open
Steveb-p wants to merge 11 commits into
Open
IBX-11939: Added Doctrine Migrations baseline for ibexa/messenger#22Steveb-p wants to merge 11 commits into
Steveb-p wants to merge 11 commits into
Conversation
This was referenced Jul 20, 2026
Open
Open
Open
Adds InstallSchemaMigration tagged 5.0.0 (the package's introduction version, no pre-5.0 legacy state to reconcile). SQL generated via ibexa:doctrine:schema:dump-sql from the current schema.yaml and verified end-to-end against a real SQLite connection - resulting tables match a fresh dump-sql exactly. Existing schema.yaml + BuildSchemaEventSubscriber left untouched.
…lines composer.json was missing ibexa/doctrine-migrations (require + matching VCS repository entry for its unreleased dev branch), causing "Class Doctrine\Migrations\AbstractMigration not found" across static analysis, unit tests, and browser tests - mirrors ibexa/core's own composer.json pattern exactly (same dev-branch constraint per major version). Also removes extra blank lines the generator scripts introduced (before each } elseif and the up() method's closing brace) that php-cs-fixer's no_extra_blank_lines rule flagged.
Extends AbstractSqlMigration (added in ibexa/doctrine-migrations) instead of the plain Doctrine AbstractMigration, replacing `$this->platform instanceof ...` checks with isMySQL()/isPostgreSQL()/isSqlite(), and moving each platform Statement block out of the PHP file into its own sql/*.sql file loaded via addSqlFile(). Mechanical, content-preserving change: every migration was run before and after against all three platforms and the resulting SQL statement lists are byte-for-byte identical.
Call abortIfUnsupportedPlatform() as the first statement of up(), so installs on a database this migration doesn't build SQL for fail loudly instead of silently queuing zero statements.
Each statement now ends with `;`, matching ibexa:doctrine:schema:dump-sql's own convention, so the files are directly executable via mysql/psql/sqlite3 CLI clients. addSqlFile() still splits on the delimiter and passes one statement per addSql() call, unaffected by the trailing terminator.
…tions Checks $schema (already the live, introspected database) before running, and skipIf()s when the tables/columns/FK targets this migration would create already exist -- so installs that built their schema the old way (SchemaBuilderEvent) can adopt Doctrine Migrations without every migration aborting or duplicating existing schema objects.
Doctrine Migrations only calls MetadataStorage::complete() (the write to
doctrine_migration_versions) when a migration's up() returns normally --
never when it throws SkipMigration. So every migration using skipIf() was
being silently re-evaluated on every future doctrine:migrations:migrate
run instead of being permanently recorded as applied, even though its
guard condition (the schema already being in place) never changes back.
Replaces every `$this->skipIf($condition, $message);` with
`if ($condition) { return; }`: up() now returns normally with zero queued
SQL when the guard fires, so the migration is correctly recorded as
executed (with a "did not result in any SQL statements" warning logged,
which is expected and harmless) and never re-evaluated again.
Verified end-to-end: fresh ibexa:install (schema_builder_event enabled)
followed by doctrine:migrations:migrate now records all 44 tagged
migrations in doctrine_migration_versions in one pass, and a second
migrate run does zero work at all ("Already at the latest version").
Steveb-p
force-pushed
the
feature/schema-migration-5.0
branch
from
July 24, 2026 11:03
cf6c64a to
ca5d33c
Compare
Steveb-p
marked this pull request as ready for review
July 24, 2026 12:15
ibexa/doctrine-migrations is now published on Packagist (which mirrors all of its branches, not just tags), so the explicit VCS repository pointing composer directly at GitHub is no longer needed to resolve the dev-branch require constraint.
…hema.yaml schema.yaml declared 3 separate, explicitly-named single-column indexes (created_at/available_at/delivered_at), but this table is Symfony's own Doctrine Messenger transport table - its real shape (as created by symfony/doctrine-messenger's own Connection::buildSchemaTable()) is ONE composite index over (queue_name, available_at, delivered_at, id). Replaced the 3-index declaration with a single named index matching that exact column set and order, so a legacy SchemaBuilderEvent install now produces a schema consistent with what Symfony's own transport expects, instead of a permanently-diverging one. Verified via ibexa:doctrine:schema:dump-sql.
…essages indexes Correcting schema.yaml alone (previous commit) only fixes NEW installs going through the legacy SchemaBuilderEvent path - it does nothing for installs that already ran the old InstallSchemaMigration (guarded against re-running once the table exists) or an old legacy install that already created the wrong 3-index shape. - InstallSchemaMigration's own baseline SQL files (all 3 platforms) now create the correct single composite index directly, so a brand-new Doctrine-Migrations install never creates the wrong shape in the first place. - New FixMessengerMessagesIndexesMigration (tagged 5.0.0, dated after the baseline) drops the 3 incorrect indexes and creates the correct composite one, guarded to skip if the correct index is already present - so it's a no-op on fresh installs (baseline already got it right) and a real fix on anything installed before this correction (whichever install path it went through). Verified against a real SQLite connection: fresh install produces 0 pending statements from the fix migration; a table seeded with the old wrong shape produces exactly 4 statements (3 drops + 1 create) and becomes correct; re-running the fix migration afterwards is a no-op (idempotent).
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.
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:
Adds
InstallSchemaMigrationtagged5.0.0— the package's introduction version, so a single baseline covers it (no pre-5.0 legacy state to reconcile, and schema.yaml is unchanged since). SQL generated viaibexa:doctrine:schema:dump-sqlfrom the currentschema.yamland verified end-to-end against a real SQLite connection.The existing
schema.yaml+BuildSchemaEventSubscriberare untouched.For QA:
Ran the migration end-to-end against a real SQLite connection; resulting tables match a fresh
ibexa:doctrine:schema:dump-sql --force-platform=sqliteof the currentschema.yamlexactly.Documentation:
N/A — internal installer implementation detail.