Skip to content

IBX-11939: Added Doctrine Migrations baseline for ibexa/messenger#22

Open
Steveb-p wants to merge 7 commits into
5.0from
feature/schema-migration-5.0
Open

IBX-11939: Added Doctrine Migrations baseline for ibexa/messenger#22
Steveb-p wants to merge 7 commits into
5.0from
feature/schema-migration-5.0

Conversation

@Steveb-p

@Steveb-p Steveb-p commented Jul 20, 2026

Copy link
Copy Markdown
Contributor
🎫 Issue IBX-11939

Related PRs:

Package 4.6 5.0 6.0
ibexa/activity-log #166 #167 #168
ibexa/cart #172 #173 🔄 #174
ibexa/collaboration #115 #116
ibexa/connector-ai #198 #199
ibexa/core #785 #787 🔄 #788
ibexa/corporate-account #369 #370 🔄 #371
ibexa/discounts #341 #342
ibexa/discounts-codes #50 #51
ibexa/doctrine-migrations #1 #2 #3
ibexa/doctrine-schema #41 #42 #43
ibexa/fieldtype-page #208 #209 🔄 #210
ibexa/form-builder #240 #241 🔄 #242
ibexa/measurement #133 #134 🔄 #135
ibexa/messenger #22this PR #23
ibexa/migrations #438 #439 #440
ibexa/order-management #188 #189 🔄 #190
ibexa/payment #204 #205 🔄 #206
ibexa/product-catalog #1543 #1544 🔄 #1545
ibexa/product-catalog-date-time-attribute #53 #54
ibexa/product-catalog-symbol-attribute #17 #18
ibexa/scheduler #168 #169 🔄 #170
ibexa/segmentation #186 #187 🔄 #188
ibexa/share #190 #191
ibexa/shipping #154 #155 🔄 #156
ibexa/site-context #121
ibexa/site-factory #172 #173 🔄 #174
ibexa/user #128 #129 🔄 #130
ibexa/workflow #191 #192 🔄 #193

🔄 = this branch adds an upgrade migration (renames/FK-retargets existing schema), not just a fresh baseline.

Description:

Adds InstallSchemaMigration tagged 5.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 via ibexa:doctrine:schema:dump-sql from the current schema.yaml and verified end-to-end against a real SQLite connection.

The existing schema.yaml + BuildSchemaEventSubscriber are 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=sqlite of the current schema.yaml exactly.

Documentation:

N/A — internal installer implementation detail.

Steveb-p added 7 commits July 24, 2026 13:03
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
Steveb-p force-pushed the feature/schema-migration-5.0 branch from cf6c64a to ca5d33c Compare July 24, 2026 11:03
@Steveb-p
Steveb-p marked this pull request as ready for review July 24, 2026 12:15
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant