IBX-11939: [Doctrine Migrations] Added Doctrine Migrations-based schema and data install path#784
Draft
Steveb-p wants to merge 2 commits into
Draft
IBX-11939: [Doctrine Migrations] Added Doctrine Migrations-based schema and data install path#784Steveb-p wants to merge 2 commits into
Steveb-p wants to merge 2 commits into
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.
|
6 tasks
Steveb-p
changed the title
ibexa-workflow-automation-1
Bot
requested review from
ViniTou,
alongosz,
barw4,
bnowak,
ciastektk,
konradoboza,
mikadamczyk,
tbialcz and
wiewiurdp
and removed request for
a team
July 20, 2026 07:34
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
4 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.
v4.6See also #785 for an alternative implementation that inlines all SQL directly into the migration classes (via
addSql()) instead of using theAbstractVersion+ YAML manifest + one-SQL-statement-per-file mechanism used here.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.AbstractVersionmigration (InstallSchemaMigration,ImportDataMigration), tagged withIbexaMigrationTagfor discovery, and executed via the newTaggedMigrationsRunnerthroughIbexaOnlyDependencyFactory- 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, one statement per file, grouped in the YAML manifest by table/index/constraint across platforms) 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).Requires
ibexa/doctrine-migrations(currently tracked via itsfeat/doctrine-migrationsbranch, added as a VCS repository).Checklist:
$ composer fix-cs).@ibexa/engineering).