Repository navigation
Conversation
This was referenced Jul 20, 2026
Merged
Open
Open
Steveb-p
force-pushed
the
feature/schema-migration-6.0
branch
2 times, most recently
from
July 24, 2026 10:51
d81ff36 to
441302a
Compare
Steveb-p
marked this pull request as ready for review
July 24, 2026 12:18
|
Steveb-p
force-pushed
the
base/ibx-11939-4.6-5.0-merged-6.0
branch
from
September 18, 2026 19:02
7c6ad95 to
8732c82
Compare
Steveb-p
force-pushed
the
feature/schema-migration-6.0
branch
from
September 18, 2026 19:04
08ce156 to
bf568b8
Compare
Steveb-p
force-pushed
the
feature/schema-migration-6.0
branch
from
October 6, 2026 11:50
4e5157f to
6765e1d
Compare
Steveb-p
changed the title
Steveb-p
marked this pull request as draft
October 6, 2026 11:50
|
❌ The last analysis has failed. |
Doctrine DBAL 4 creates autoincrement columns on PostgreSQL as GENERATED BY DEFAULT AS IDENTITY, where the 4.6 and 5.0 install migrations created SERIAL ones. This is a migration of its own, so it can be left out to keep SERIAL.
Steveb-p
force-pushed
the
feature/schema-migration-6.0
branch
from
October 6, 2026 12:27
6765e1d to
fd3e346
Compare
|
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
3 participants
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-5.0-merged-6.0) is not the real6.0branch — it's6.0with the4.6(#128) and5.0(#129) feature branches merged in. This PR intentionally shows only the changes introduced on top of "4.6 and 5.0, once merged forward" — review #128 and #129 first. Once those merge for real and are merged forward into6.0, this PR's base will be updated to point at the real6.0branch.Warning
Schema drift between migrated and fresh 6.0 databases, fixed here. A 6.0 database built through Doctrine Migrations, installed fresh or upgraded from 5.0, differs from a fresh
SchemaBuilderEventinstall, mostly because Doctrine DBAL 4 writes some things differently from the 4.6 and 5.0 install migrations.The PostgreSQL SERIAL → identity conversion is a migration and a commit of its own (
ConvertPostgreSqlSerialColumnsToIdentityMigration), so it's easy to spot, or to drop to keep SERIAL columns, which work the same for inserts.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:
#40⏭️#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:
Reopened, as 6.0 turned out to need changes of its own after all. Everything else this package needs on 6.0 still arrives through the merge-up of #129, and this PR's base now has the current
6.0and #129 merged in, so it shows only these migrations.A 6.0 database built through Doctrine Migrations, installed fresh or upgraded from 5.0, differs from a fresh
SchemaBuilderEventinstall here:ConvertPostgreSqlSerialColumnsToIdentityMigration): on PostgreSQL, Doctrine DBAL 4 creates autoincrement columns asGENERATED BY DEFAULT AS IDENTITY, where the 4.6 and 5.0 install migrations made these 2 SERIAL. A PL/pgSQL block insql/convert-serial-columns-to-identity-postgresql.sqlturns each into an identity column that carries on from its sequence's current value, and drops the old sequence.Each migration keeps its SQL in
sql/*.sqlfiles, so it can be read or run by hand; the PHP only checks whether it's needed, and does nothing where the database already matches.Locally, with every package's 6.0 work and the 5.0 work merged up as the merge-ups will, on MySQL 8.0, MariaDB 10.11 and PostgreSQL 16: a fresh install through migrations, a fresh
SchemaBuilderEventinstall migrated afterwards, and 5.0 databases from both install paths upgraded to 6.0 all give the same schema as a freshSchemaBuilderEventinstall, by Doctrine DBAL's comparison and by constraint, index and column name. The only difference left is ibexa/messenger's composite index name. The upgrades need ibexa/doctrine-migrations#23.Related 6.0 fixes:
ibexa:doctrine:migrations:*see the whole schema on 6.0)