Repository navigation
IBX-11939: Renamed the PostgreSQL primary keys left with their 4.6 names and fixed the MariaDB bookmark foreign keys - #864
Draft
Steveb-p wants to merge 14 commits into
Conversation
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.
…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.
PostgreSQL keeps a renamed table's constraint names, so the 5.0 table renames left the primary keys with their 4.6 names, both on a fresh install through Doctrine Migrations and on a database upgraded from 4.6. A fresh install through the schema builder names them after the 5.0 tables.
…MariaDB A fresh install through the schema builder declares it. It behaves the same as leaving it out, but MariaDB reports a foreign key without it as RESTRICT, so the schemas differ.
Steveb-p
force-pushed
the
feature/schema-drift-5.0
branch
from
October 6, 2026 12:18
1d094ec to
34516cd
Compare
|
Steveb-p
force-pushed
the
feature/fix-schema-rename-migration-5.0-postgres
branch
from
October 7, 2026 09:46
23ba5c5 to
ad4d491
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
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.
Note
Stacked on #787: it targets #787's branch and lands right after it.
Warning
Schema drift between migrated and fresh 5.0 databases, fixed here by new migrations. A 5.0 database built through Doctrine Migrations, whether installed fresh or upgraded from 4.6, differs from a fresh
SchemaBuilderEventinstall in the names and definitions listed below.Related PRs:
Description:
A fresh 5.0 install through Doctrine Migrations, and a 4.6 database upgraded with them, end up with the same schema. It differs from a fresh install through
SchemaBuilderEventhere:ezcontentobject_pkeyonibexa_content. PostgreSQL keeps a renamed table's constraint names, andRenameSchemaTo5_0Migrationrenames the tables, not the primary keys.RenamePostgreSqlPrimaryKeysMigrationrenames all 48 to<table>_pkey, as PostgreSQL names them when it creates the tables. The renames are plain statements insql/rename-primary-keys-postgresql.sql; a database has either all the 4.6 names or none, so the migration checks the first one.ibexa_content_bookmarkforeign keys lack theON UPDATE NO ACTIONschema.yamldeclares. It behaves the same as leaving it out, but MariaDB then reports them asRESTRICT.RecreateMariaDbBookmarkForeignKeysMigrationdrops them and adds them again with it. It's purely cosmetic, so it's a commit of its own, easy to drop if we'd rather not rebuild those two foreign keys.ibexa/installer's upgrade scripts don't fix any of this either, so a site upgraded the old way has the same differences. 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, as on a freshSchemaBuilderEventinstall that runs the migrations afterwards.Locally, with every package's follow-up applied, on MySQL 8.0, MariaDB 10.11 and PostgreSQL 16: a fresh install through migrations, a fresh
SchemaBuilderEventinstall migrated afterwards, and 4.6 installs from both paths upgraded to 5.0 all give the same schema as a freshSchemaBuilderEventinstall, by Doctrine DBAL's comparison and with the same constraint and index names.