Conversation
…128) * Add Doctrine Migrations for the user-invitation schema (baseline + 5.0.0 rename) Adds InstallSchemaMigration (4.6.0 baseline) and, on 5.0+, RenameSchemaTo5_0Migration renaming ibexa_user_invitations(_assignments) to singular. ibexa/installer's shipped upgrade SQL was missing the rename of the assignment table's Doctrine-hashed FK-backing index (its hash changes with the table name: IDX_DA5A7872A35D7AF0 -> IDX_9E1E6F70A35D7AF0) - added that. SQLite equivalent derived and verified end-to-end - resulting schema matches a fresh dump-sql of the current schema.yaml exactly. Existing schema.yaml + BuildSchemaSubscriber left untouched. * Fix CI: add ibexa/doctrine-migrations dependency, remove extra blank 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. * Fix CI: correct DBAL 2.x platform class names for the 4.6 branch InstallSchemaMigration was generated with the same template used for all three branches, hardcoding DBAL 3.x class names (AbstractMySQLPlatform/ PostgreSQLPlatform). This branch pins doctrine/dbal 2.13.9, where the correct names are MySqlPlatform/PostgreSqlPlatform (matching ibexa/core's own 4.6 baseline) - the 3.x names don't exist in that version, causing "Class ... not found" in static analysis and tests. Verified against a real DBAL 2.x connection. * IBX-11939: Adopted AbstractSqlMigration for platform-separated SQL 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. * IBX-11939: Aborted migration on unsupported database platform 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. * IBX-11939: Added trailing semicolons to migration SQL files 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. * IBX-11939: Added schema-presence guards to skip already-applied migrations 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. * IBX-11939: Recorded schema-guarded migrations as applied, not skipped 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"). * IBX-11939: Fixed 4.6 baseline guards to check the branch's own table name Live end-to-end testing (fresh legacy install -> doctrine:migrations:migrate on 4.6) surfaced that these baseline guards checked the FINAL, post-5.0- rename table name (e.g. "ibexa_content") -- correct on 5.0/6.0, but wrong on 4.6, which has no rename at all: there, the table this migration creates already IS the branch's permanent, current name (e.g. "ezcontentobject"), so the guard never fired and the baseline collided with an already-installed legacy 4.6 schema. Checks the branch's own table name instead, exactly like every other baseline guard that has no later rename to worry about. For core's ImportDataMigration specifically, this required a proper data check rather than a schema-shape check: "ezcontentobject" is 4.6's real, permanent name, so it always exists once the baseline has run there, regardless of whether this migration's own bootstrap INSERTs ran yet. Checks for the actual seed row (root content, id = 1) instead, combined with the table's outright absence (the 5.0/6.0 legacy signal) via OR. * IBX-11939: Removed ibexa/doctrine-migrations VCS repository entry 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. * IBX-11939: Switched the install SQL to utf8mb4 The MySQL install SQL hardcoded "DEFAULT CHARACTER SET utf8 COLLATE utf8_unicode_ci". On MySQL 8 "utf8" is an alias for utf8mb3, so a Doctrine Migrations install produced 3-byte columns while a SchemaBuilderEvent install produced utf8mb4 - the latter reads the configured database_charset/database_collation, which default to utf8mb4 and utf8mb4_unicode_520_ci. The practical effect was that a migrations-based install could not store 4-byte characters (emoji, CJK extensions) at all, and sorted/compared text differently. Verified against a real MySQL 8.0 server: the schema a migrations install produces now matches a SchemaBuilderEvent one. * IBX-11939: Required ibexa/doctrine-migrations from the 4.6 branch The requirement pinned dev-feat/doctrine-migrations, a branch that does not exist on the remote - only feat/doctrine-migrations-5.0 does. Composer could not resolve it, so every CI job that installs dependencies failed, including all three SQLite integration test runs and the code style check. Uses the tier constraint the other 4.6 packages use. * IBX-11939: Replaced SqlPlatform with doctrine-schema's DatabasePlatformName (#153) * IBX-11939: Wrapped long lines in the Doctrine Migrations SQL files Each CREATE TABLE now lists one column, index or constraint per line, and ALTER TABLE and CREATE INDEX statements longer than 120 characters are wrapped. Only whitespace changes, apart from the comma moving in front of SQLite's --(DC2Type:...) comments, which keeps each comment with its column. * IBX-11939: Added MariaDB to the platforms the migrations support ibexa/doctrine-migrations#19 makes MariaDB a platform of its own, so each migration now lists SqlPlatform::MARIADB and runs its MySQL SQL there too.
…keys (#155) The SQLite install schema was generated with DBAL's own SqlitePlatform, which reports no foreign key support and so leaves every ON UPDATE action out. The SchemaBuilderEvent path uses doctrine-schema's SqliteDbPlatform, which keeps them, so on SQLite the two install paths created different foreign keys. This adds the action each foreign key declares in schema.yaml.
|
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.
Caution
This is a merge pull request
Related PRs: