Spike: attribute-only EF Core migrations without a real EF model

[jeremydmiller]

Part of the EF Core migration generation epic — tracking issue #371.

De-risking spike for the whole epic: verify that a hand-written, attribute-only EF Core migration with no real EF model is a first-class citizen of the EF toolchain. Research strongly indicates yes (empty BuildTargetModel bodies are legal; the ModelSnapshot is design-time only; runtime discovery needs only the [DbContext] + [Migration] attributes), but this converts belief into verified fact before we build the generator.

What to build

A throwaway test project containing:

1. A stub DbContext (no entities) configured for Npgsql and SqlServer, with ConfigureWarnings(w => w.Ignore(RelationalEventId.PendingModelChangesWarning)) — required on EF Core 9+, which otherwise throws from Migrate() when the context model doesn't match the last migration.
2. One or two hand-written Migration subclasses carrying [DbContext]/[Migration("yyyyMMddHHmmss_Name")] attributes, with Up/Down bodies using MigrationBuilder calls (including raw store types via ColumnType) and a migrationBuilder.Sql(...) block.

Verify on both Npgsql and SqlServer EF providers (EF 9 and 10)

• dotnet ef database update applies them and records __EFMigrationsHistory rows
• Runtime Migrate() / MigrateAsync() works (no pending-model-changes throw with the suppression in place)
• dotnet ef migrations script --idempotent produces a correct script
• Migration bundles (dotnet ef migrations bundle) work
• Down() / migrating backwards works
• A second context in the same database with its own history table location coexists cleanly (the mixed EF + Marten/Wolverine scenario)

Stretch

• Check the SQLite EF provider: its ALTER-emulation (table rebuild) is the most model-hungry code path and may not tolerate an empty TargetModel. Outcome decides whether SQLite is in or out for v1 of the generator.

The spike code does not need to merge; the deliverable is a written summary of results on this issue.

[jeremydmiller]

Spike results: attribute-only EF Core migrations are a first-class citizen ✅

Built the throwaway project described here (stub DbContext with no entities, hand-written Migration subclasses carrying only [DbContext] + [Migration] attributes, no .Designer.cs, no ModelSnapshot, BuildTargetModel never overridden) and ran the full checklist against the local Docker PostgreSQL and SQL Server (Azure SQL Edge) instances, on both EF Core 9 (9.0.1/Npgsql 9.0.4) and EF Core 10 (10.0.0/Npgsql 10.0.0), net9.0/net10.0.

Checklist — all verified on both Npgsql and SqlServer providers, EF 9 and EF 10

• ✅ dotnet ef database update applies the migrations and records history rows in the relocated history table (MigrationsHistoryTable("spike_history", "efspike")), including update 0 reverting everything and update re-applying.
• ✅ Runtime MigrateAsync() applies both migrations, history rows carry the right ProductVersion (9.0.1 / 10.0.0).
• ✅ dotnet ef migrations script --idempotent produces a correct guarded script — including CREATE TABLE IF NOT EXISTS for the relocated history table and per-migration IF NOT EXISTS (SELECT 1 FROM efspike.spike_history WHERE ...) guards.
• ✅ Migration bundles (dotnet ef migrations bundle) build and execute correctly (applied both migrations from zero state).
• ✅ Down() / migrating backwards works via IMigrator.MigrateAsync(target) and via the CLI, to an intermediate migration and to 0, on both providers.
• ✅ A second context in the same database with its own history table location (efspike2.second_history) coexists cleanly with the first — the mixed EF + Marten/Wolverine scenario. Separate id-spaces, separate history, no interference.

The migrations exercised raw store types via ColumnType (uuid, jsonb, timestamp with time zone / uniqueidentifier, nvarchar(max), datetimeoffset), defaultValueSql, CreateIndex, EnsureSchema, provider annotations (Npgsql:ValueGenerationStrategy identity), and migrationBuilder.Sql(...) blocks — all fine with an empty target model.

Nuance: the PendingModelChangesWarning suppression is defensive, not required

A control context without ConfigureWarnings(w => w.Ignore(RelationalEventId.PendingModelChangesWarning)) migrated cleanly on both EF 9 and EF 10. Reason: the pending-model-changes check compares the context model against the last migration's ModelSnapshot — and in the attribute-only setup there is no snapshot at all, so the check has nothing to fire on. The generator should still emit the suppression in the stub context (it's harmless, and protects users who later add entities or a snapshot to the same context), but its absence is not fatal.

Stretch: SQLite

• ✅ Provider-native operations (CreateTable, AddColumn, DropTable, CreateIndex) work with an empty target model on EF 9 and EF 10.
• ❌ AlterColumn throws System.NotSupportedException: SQLite does not support this migration operation ('AlterColumnOperation') — the ALTER-emulation table-rebuild path needs a populated target model to reconstruct the table, exactly as suspected.

Verdict for v1: SQLite is out for the general generator, or in only for purely-additive migrations (create table / add column / create index). Anything that would trigger the rebuild path must be refused with a clear error. This matches Weasel.Sqlite's own delta story (table recreation), so the generator can simply gate SQLite emission to additive operations if we want partial support.

Conclusion

The epic is de-risked. Hand-written attribute-only migrations with empty target models are fully supported by the EF toolchain — runtime, CLI, idempotent scripting, and bundles — on both target providers and both EF versions, with relocated history tables for the mixed-store scenario. #365 (translation layer) and #366 (emitter + stub context) can proceed on this design with no fallback needed.

Spike code was throwaway per the issue; not merged.

🤖 Generated with Claude Code

[jeremydmiller]

Closing — spike complete, results above. No code to merge by design.