Epic: EF Core migration generation from Weasel schema objects

[jeremydmiller]

Goal

First-class EF Core migration artifact generation from Weasel schema objects: translate everything an IDatabase knows about (tables, columns, indexes, FKs, sequences, functions, partitions) into compilable EF Core migration classes/files, so that Marten, Polecat, and Wolverine users can ship schema changes through the standard EF toolchain — dotnet ef database update, idempotent scripts, migration bundles, __EFMigrationsHistory.

This is the reverse of the existing Weasel.EntityFrameworkCore direction (MapToTable: EF DbContext → Weasel tables, where Weasel applies the migration). Here Weasel authors the migrations and EF applies them.

Why

• Teams mixing EF Core with Marten/Polecat/Wolverine in one application get a single artifact format and deployment pipeline for all schema changes.
• DBA/CI-review workflows built around EF migrations (scripts, bundles) work for critter-stack schema objects.
• Prior art gap: nothing in the ecosystem generates EF migration files from an external schema definition. Bloomberg's Sable (archived July 2026) is the closest workflow precedent, but it emitted plain SQL and its diff engine was Marten's own marten-patch — i.e., Weasel already owns the hard part.

Architecture (decided)

• Direct emission: Weasel typed model/deltas → hand-rolled C# emitter of MigrationBuilder calls + [DbContext]/[Migration] attributes. No EF design-time scaffolding APIs (pubternal; Scaffolding Migrations programmatically in Asp.Net Core 5 and EF Core 5 dotnet/efcore#23595 closed as not-planned).
• Attribute-only migrations with empty BuildTargetModel — runtime-valid; verified by spike (Spike: attribute-only EF Core migrations without a real EF model #364). EF 9+ requires suppressing RelationalEventId.PendingModelChangesWarning in the generated stub context.
• Coexistence via multi-context EF: one Weasel-owned stub DbContext per IDatabase, history table relocated into the critter-stack schema, so generated migrations never collide with the user's own app-context migrations. Supports any mix of EF Core + Marten + Polecat + Wolverine.
• EF Core projections round-trip automatically: projection DbContext → MapToTable → IDatabase.AllObjects() → generated artifacts.
• Raw-SQL fallback (migrationBuilder.Sql()) for everything EF can't model: PG partitioning, PL/pgSQL functions, SQL Server procedures/table types, sequence default expressions, rich index options.
• Snapshot baseline without a shadow database: serialized Weasel schema snapshot (JSON) diffed in memory via TableDelta — improves on Sable's Testcontainers-replay approach.
• IDatabase is the single source of schema objects, same as the existing db-* commands.
• v1 providers: PostgreSQL + SQL Server; SQLite pending spike outcome; Oracle/MySQL later.

Phases

• Computed/generated column support (PostgreSQL + SQL Server) #363 — Computed/generated column support in Weasel (PostgreSQL + SQL Server; prerequisite capability, pure Weasel work)
• Spike: attribute-only EF Core migrations without a real EF model #364 — Spike: attribute-only EF migrations without a real EF model (de-risks the whole approach)
• EF migration generation: Weasel model → MigrationBuilder operation translation layer #365 — Operation translation layer (Weasel model → MigrationBuilder operations)
• EF migration generation: C# migration file emitter + stub DbContext #366 — C# migration file emitter + stub DbContext generation
• EF migration generation: incremental migrations from TableDelta + serialized schema snapshot #367 — Incremental migrations: TableDelta → operations + serialized schema snapshot
• EF migration generation: db-ef-migration add | script | baseline CLI commands #368 — CLI: db-ef-migration add | script | baseline
• EF migration generation: inverted schema-comparison validation harness + CI #369 — Validation: inverted schema-comparison harness + CI
• EF migration generation: documentation #370 — Documentation

Rough ordering: #363 and #364 can run in parallel and first; #365 → #366 → #367 → #368 build on each other; #369 grows alongside #365–#368; #370 lands last.

Out of scope (tracked downstream)

• Marten / Polecat / Wolverine consumption docs and any thin registration helpers — no engine changes expected there, since everything flows through IDatabase.
• dotnet ef migrations add/remove against the Weasel stub context is explicitly unsupported (documented in EF migration generation: documentation #370).