Skip to content

IBX-12530: Added SchemaApplier for executing a built Schema against a connection - #49

Open
Steveb-p wants to merge 1 commit into
4.6from
feature/schema-applier-4.6
Open

Steveb-p wants to merge 1 commit into
4.6from
feature/schema-applier-4.6

Conversation

@Steveb-p

@Steveb-p Steveb-p commented Sep 9, 2026

Copy link
Copy Markdown
Contributor
🎫 Issue IBX-12530

Related PRs:

Description:

SchemaBuilderInterface produces a Schema but has no way of putting it into a database, so every
caller reimplements the same toSql()-and-execute loop. There are already two, and they differ in
one detail:

  • ibexa/test-core's DatabaseSchemaHook — runs once per suite against a freshly created database,
    so a plain create is enough.
  • ibexa/core's LegacySchemaImporter — runs per test case from IbexaKernelTestTrait::loadSchema(),
    so it drops the schema's tables first (in reverse order, for FKs) and recreates them.

SchemaApplier covers both, with $dropExistingTables selecting between them. It lives here
because this package owns SchemaBuilder, and because it is the only place both consumers can
reach: ibexa/core cannot depend on ibexa/test-core (the dependency runs the other way), and both
already require ibexa/doctrine-schema — core in require, test-core in require-dev.

public function applySchema(Schema $schema, bool $dropExistingTables = false): void;

Registered as Ibexa\Contracts\DoctrineSchema\Builder\SchemaApplierInterface, alongside the
existing SchemaBuilderInterface alias.

Nothing existing changes behaviour — this is purely additive; the two consumers switch over in
their own PRs.

For QA:

composer test — 32 tests / 31 assertions / 4 skipped, unchanged apart from the 4 new ones.
PHPStan and code style clean.

The new SchemaApplierTest covers the behaviour that matters, against in-memory SQLite: a plain
apply creates the tables; applying twice without dropping fails; applying twice with dropping
succeeds and leaves the table empty (proving it really was dropped and recreated, not just
tolerated); and dropping is skipped for tables that do not exist yet.

SchemaBuilderInterface produces a Schema but has no way to apply it, so every caller
reimplements the same toSql()-and-execute loop. Two already do: ibexa/test-core's
DatabaseSchemaHook, and ibexa/core's LegacySchemaImporter, which additionally drops the
schema's tables first so it can run per test case.

SchemaApplier covers both, with $dropExistingTables selecting between them.
@sonarqubecloud

sonarqubecloud Bot commented Sep 9, 2026

Copy link
Copy Markdown

@Steveb-p Steveb-p changed the title Added SchemaApplier for executing a built Schema against a connection IBX-12530: Added SchemaApplier for executing a built Schema against a connection Sep 9, 2026
@Steveb-p
Steveb-p marked this pull request as ready for review September 10, 2026 08:17
@Steveb-p
Steveb-p requested a review from a team September 10, 2026 10:55
Steveb-p added a commit to ibexa/test-core that referenced this pull request Sep 10, 2026
…ema#49

Points CI at the branch that adds SchemaApplier, so this PR's tests can run before that PR
merges. Must be removed before merging.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants