IBX-11939: [Doctrine Migrations] Added Doctrine Migrations-based schema and data install path (inlined SQL)#785
Draft
Steveb-p wants to merge 4 commits into
Draft
Conversation
… install path Adds an ibexa/doctrine-migrations-based alternative to the event-driven SchemaBuilderEvent mechanism CoreInstaller has used to install the core schema and bootstrap data. Controlled by the new "ibexa.installer.schema_builder_event.enabled" setting (defaults to true, preserving current behavior): - When enabled (default), CoreInstaller keeps dispatching SchemaBuilderEvent and importing cleandata.sql directly, unchanged. - When disabled, schema creation and data import are each modeled as an AbstractVersion migration (InstallSchemaMigration, ImportDataMigration), tagged for discovery, and executed via TaggedMigrationsRunner through the new IbexaOnlyDependencyFactory service - an independent Doctrine Migrations DependencyFactory scoped to only Ibexa-tagged migrations, so a project's own migrations are never accidentally executed. Each migration's execution is recorded in the standard Doctrine Migrations versioning table, making repeated installs idempotent. InstallSchemaMigration's SQL (mysql/postgresql/sqlite, one statement per file) is generated from the existing schema.yaml; ImportDataMigration's from the existing per-DBMS cleandata.sql files (with the mysql statements reused verbatim for sqlite, which previously had no cleandata support at all).
Symfony\Component\DependencyInjection\ServiceLocator is not a generic class, so PHPStan rejects the ServiceLocator<Installer> PHPDoc type used for InstallPlatformCommand::$installers. Removed the invalid generic parameter; the type-hint itself (plain ServiceLocator) is unaffected.
Converts InstallSchemaMigration and ImportDataMigration from Ibexa\Contracts\DoctrineMigrations\Migrations\AbstractVersion (which loads its SQL from a YAML manifest + one-statement-per-file pairs at runtime) to Doctrine\Migrations\AbstractMigration directly, with every statement inlined as an addSql() call in up(), branching on $this->platform (MySqlPlatform/PostgreSqlPlatform/SqlitePlatform). Both still implement IbexaMigrationInterface and are tagged with IbexaMigrationTag::TAG in services.yml, so they remain discoverable by TaggedMigrationsRunner/ServiceMigrationsRepository/IbexaOnlyDependencyFactory exactly as before - no other part of the installer changes. Removes the entire Resources/migrations/ YAML+SQL-file tree (509 files), generated from the same schema.yaml/cleandata.sql sources as before.
CREATE TABLE statements are now pretty-printed one column per line, and other long or naturally multi-line statements (multi-row INSERT, long ALTER TABLE ... ADD CONSTRAINT) use NOWDOC instead of a single escaped string literal, for readability. SQL content is unchanged.
Draft
6 tasks
|
Contributor
Author
|
Companion PR in |
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.
v4.6Alternative to #784, using the same
IbexaMigrationInterface+IbexaMigrationTag+TaggedMigrationsRunner/IbexaOnlyDependencyFactorymechanism, but withInstallSchemaMigration/ImportDataMigrationimplemented as plainDoctrine\Migrations\AbstractMigrationsubclasses with all SQL inlined directly in PHP (viaaddSql()), instead of Ibexa'sAbstractVersion+ YAML manifest + one-SQL-statement-per-file mechanism. This drops the 509 generated YAML/SQL resource files in favor of two self-contained PHP migration classes.Adds an
ibexa/doctrine-migrations-based alternative to the event-drivenSchemaBuilderEventmechanismCoreInstallercurrently uses to install the core schema and bootstrap data, controlled by a newibexa.installer.schema_builder_event.enabledsetting (defaults totrue, preserving current behavior).CoreInstallerkeeps dispatchingSchemaBuilderEventand importingcleandata.sqldirectly - unchanged.InstallSchemaMigration,ImportDataMigration), tagged withIbexaMigrationTagfor discovery, and executed viaTaggedMigrationsRunnerthroughIbexaOnlyDependencyFactory- an independent Doctrine MigrationsDependencyFactoryscoped to only Ibexa-tagged migrations, so a project's own migrations are never accidentally picked up. Each migration's execution is recorded in the standard Doctrine Migrations versioning table, making repeated installs idempotent.InstallSchemaMigration's SQL (mysql/postgresql/sqlite) is generated from the existingschema.yaml;ImportDataMigration's SQL is generated from the existing per-DBMScleandata.sqlfiles, with the mysql statements also reused verbatim for sqlite (which previously had no cleandata support at all). Long or naturally multi-line statements (CREATE TABLE, multi-rowINSERT, longALTER TABLE ... ADD CONSTRAINT) use PHP NOWDOC for readability; verified byte-for-byte equivalent (aside from whitespace) to the SQL produced by #784.Requires
ibexa/doctrine-migrations(currently tracked via itsfeat/doctrine-migrationsbranch, added as a VCS repository).Checklist:
$ composer fix-cs).@ibexa/engineering).