Skip to content

SchemaKit: fail at startup when another package has replaced the model differ or the migrations SQL generator #57

Open

Description

@CaffeinatedCoder

Problem

When another package calls ReplaceService<IMigrationsModelDiffer, …> or ReplaceService<IMigrationsSqlGenerator, …> after SchemaKit's registration, EF Core uses that package's service, and every SchemaKit declaration disappears from migrations without an error. EFCore.ComplexIndexes 5.x has the same exposure today.

Change

When the two services are first resolved, at runtime and at design time, check that the resolved differ and SQL generator are SchemaKit's. If they aren't, throw, naming the type that replaced them and pointing to the plugin contract (#56).

Cover runtime ReplaceService, registration through design-time IDesignTimeServices, and a provider that registers its own after ours.

Tests

A context that replaces each service after SchemaKit's registration throws at the first migrations operation, with the replacing type's name; one test per entry point (runtime, design time). Remove the check and show that migrations add then loses the declaration silently.

Not covered

A package that replaced the services before SchemaKit loses to SchemaKit's replacement, and the check can't see it. The README says so. The answer there is the other package's own guard: CodoMetis packages never replace either service (CodoMetis.ValueRanges enforces this with a convention test, CaffeinatedCoder/CodoMetis.ValueRanges#334).

Metadata

Metadata

Assignees

No one assigned

    Labels

    area/migrationsThe differs, snapshot format, EnsureCreated and design-time wiringenhancementNew feature or requestpackage/coreAffects EFCore.ComplexIndexespackage/postgresqlAffects EFCore.ComplexIndexes.PostgreSQLpackage/sqlserverAffects EFCore.ComplexIndexes.SqlServer

    Projects

    No projects

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions