feat(efcore): db-ef-migration add | script | baseline CLI command - #378
Merged
Conversation
Closes #365. First implementation phase of the EF Core migration generation epic (#371), building on the #364 spike results. - New MigrationOperationTranslation in Weasel.EntityFrameworkCore: walks the provider-neutral surface (ITable/ITableColumn/ITableIndex/ ForeignKeyBase/SequenceBase) and produces EF Core MigrationOperation instances — the reverse of MapToTable. Raw store type strings (ColumnType) everywhere so EF's CLR mapping is bypassed and DDL matches Weasel exactly; the CLR type is a best-effort inverse used only for the Column<T>() generic in emitted C# - CreateTable with nested columns / primary key / check constraints / foreign keys, one CreateIndex per index, EnsureSchema per non-default schema (deduplicated; default public/dbo emitted as null Schema like EF's own scaffolding), CreateSequence from SequenceBase - Provider specifics: identity → Npgsql:ValueGenerationStrategy or SqlServer:Identity annotations; computed columns → ComputedColumnSql + IsStored (always stored on PG); index includes/method annotations; CascadeAction → ReferentialAction with SQL Server Restrict ≡ NoAction mirroring mapDeleteBehavior - Raw-SQL fallback: non-table/non-sequence objects (functions, sprocs, table types) and anything matched by the ForceRawSql hook (e.g. partitioned tables) are wrapped in SqlOperation carrying the object's own WriteCreateStatement DDL; expression indexes throw with guidance to use the hook - ToDropMigrationOperations for Down() bodies: reverse-order DropTable / DropSequence / raw drops; schemas never dropped (may be shared with Marten/Wolverine) - Weasel.Core additions: ITable.Columns and ITableIndex.Columns expose the column collections on the neutral surface (implicitly satisfied by every provider's concrete types) 13 new DB-free unit tests; all provider suites green locally. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Closes #366. Second implementation phase of the EF Core migration generation epic (#371), rendering the #365 operation lists into compilable attribute-only migration files. - EfMigrationFileEmitter.EmitMigration renders Up/Down operation lists over the stable public MigrationBuilder surface — deliberately not EF's pubternal CSharpMigrationsGenerator (dotnet/efcore#23595). Generated migrations carry [DbContext]/[Migration] attributes and no BuildTargetModel body, per the #364 spike verification - Renders EnsureSchema, CreateTable (nested columns with raw store types, PK incl. composite, check constraints, FKs with referential actions), CreateIndex (unique/filter + annotations), CreateSequence, Sql (verbatim strings), DropTable, DropSequence; the Npgsql:ValueGenerationStrategy annotation is rendered as the real NpgsqlValueGenerationStrategy enum literal with the using added on demand; unknown operations/annotations throw rather than emitting wrong code - Column names map to anonymous-type members with @-escaping for reserved words and name:-argument fallback for non-identifier names - Migration ids are yyyyMMddHHmmss_Name UTC with a monotonicity guard: LastMigrationId bumps the timestamp until the new id sorts strictly after (EF orders by plain string sort) - EmitStubContext generates the no-entity host context: provider configured, history table relocated into the critter-stack schema, EF 9+ PendingModelChangesWarning suppressed, registration snippet in the XML docs, plus an IDesignTimeDbContextFactory reading WEASEL_EF_CONNECTION so dotnet ef update/script/bundle work without an application host Testing: the generated sample files (from a Weasel schema with sequence, identity, checks, FK, filtered index) are CHECKED IN and compiled as part of the test project — the "generated files compile" acceptance — with a drift-guard test proving they are byte-for-byte emitter output, and an end-to-end test applying them through the real EF runtime against PostgreSQL, round-tripping the schema against Weasel's own delta detection (no changes), and migrating back down to zero. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Closes #367. Third implementation phase of the EF Core migration generation epic (#371). - EfSchemaSnapshot: JSON-serialized design-time snapshot of the Weasel typed model (tables/columns/indexes/FKs/checks/PK, sequences, and raw-SQL objects captured as their CREATE/DROP DDL) — Weasel's analog of EF's ModelSnapshot, written beside the generated migrations and never compiled. The Sable lesson without the shadow database - The snapshot DTOs are now the canonical IR: the #365 ITable translation routes through SnapshotTable.From(...) into shared operation builders, so first-migration translation and the incremental differ can never drift apart - EfSnapshotDiffer.Diff(baseline, target): in-memory diff producing incremental Up/Down operations — Add/Alter/DropColumn (Alter carries the old definition), Create/DropIndex (recreate on change), Add/DropForeignKey, Add/DropCheckConstraint, Drop+AddPrimaryKey, Create/Drop/AlterSequence, EnsureSchema for new schemas (never dropped), and raw-object add/remove via Sql(). Down runs in reverse order of Up. Changed raw-SQL objects are refused with guidance — the snapshot diff cannot infer a safe transform for partitioned tables or function bodies - EfSnapshotDiffer.DiffAgainstDatabaseAsync: the live-database baseline mode — Weasel's own CreateMigrationAsync SQL (updates + rollbacks) wrapped in Sql() operations, covering everything the snapshot diff refuses (partition additive/rebuild, function changes) - Emitter renders the incremental operations: AddColumn/AlterColumn/ DropColumn, DropIndex, AddForeignKey/DropForeignKey standalone, Add/DropPrimaryKey, Add/DropCheckConstraint, AlterSequence Renames are deliberately not inferred (the model carries no rename intent); the seam arrives with the CLI phase where renames can be declared explicitly. Tests: snapshot JSON round-trip yields a zero diff; add-column / changed-index / new-table+FK / altered-column scenarios; changed raw object refusal; incremental ops render through the emitter with the id monotonicity guard; and an end-to-end acceptance test that applies the initial generated migration via EF, diffs a changed model against the snapshot, executes the incremental operations through the real Npgsql migrations SQL generator, has Weasel's own delta detection report None, then rolls back down and round-trips again. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Closes #368. Fourth implementation phase of the EF Core migration generation epic (#371). - New db-ef-migration JasperFx command in Weasel.EntityFrameworkCore (discovered via [assembly: JasperFxAssembly]; Weasel.Core stays EF-free), using the same WeaselInput / TryChooseSingleDatabase database-selection machinery as db-patch — IDatabase is the single source of schema objects, so Marten/Wolverine/Polecat tables all flow in through one door - `add <Name>`: first run scaffolds the stub context (history table relocated into the first non-default schema of the database's objects), the initial create-everything migration, and the JSON snapshot; later runs diff against the snapshot (or the live database with --against-database) and emit an incremental migration with the id monotonicity guard. --output/--namespace/--context/ --history-schema flags - `script`: documents the canonical EF toolchain path (dotnet ef migrations script --idempotent / bundle) verified by the #364 spike — idempotent scripting needs the compiled migrations, which only exist in the consuming project - `baseline`: adopts a pre-existing database by inserting __EFMigrationsHistory rows (create-if-missing relocated history table) for every generated migration file without executing them — the EF-sanctioned baselining technique, idempotent across runs - EfMigrationGenerator is the testable engine behind the command: provider detection from the Migrator type, structural partition detection as the default ForceRawSql routing (no provider references), connection resolution via IConnectionSource Tests: provider detection, partition detection, first-run scaffold → no-change no-op → model change → incremental add with ordered ids, and baselining against live PostgreSQL (rows recorded once, idempotent second pass, verified in the relocated history table). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This was referenced Jul 18, 2026
…ilePath Deterministic CI builds rewrite [CallerFilePath] to the virtual /_/ source root, which does not exist on disk — the drift-guard tests failed on CI with an IO error. Walk up from AppContext.BaseDirectory to the repo root instead. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
…-migrations # Conflicts: # src/Weasel.EntityFrameworkCore/EfMigrationFileEmitter.cs # src/Weasel.EntityFrameworkCore/MigrationOperationTranslation.cs
jeremydmiller
changed the base branch from
feat/ef-incremental-migrations
to
master
July 18, 2026 23:55
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
1 participant
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.
Closes #368. Fourth phase of the EF Core migration generation epic (#371). Stacked on #377 → #376 → #375; merge in order and retarget as the stack lands.
What's here
A new
db-ef-migrationJasperFx command inWeasel.EntityFrameworkCore(discovered via[assembly: JasperFxAssembly]when the package is referenced —Weasel.Corestays EF-free), following the existingdb-*pattern: sameWeaselInput/TryChooseSingleDatabasedatabase-selection UX asdb-patch, withIDatabaseas the single source of schema objects so Marten system tables, Wolverine envelope storage, and Polecat event storage all flow through one door. Multiple registrations use the existing--databaseselection.db-ef-migration add <Name>DbContext(history table relocated into the first non-default schema of the database's objects — neverpublic/dbo), the initial create-everything migration, and the JSON schema snapshot.IDatabase.AllObjects()model against the snapshot entirely in memory and emit an incremental migration (LastMigrationIdmonotonicity guard included), then rewrite the snapshot.--against-databaseswitches to the live-DB baseline mode from feat(efcore): incremental migrations — serialized schema snapshot + differ #377.--output(default./WeaselMigrations),--namespace,--context,--history-schema.Partitioning/SqlServerPartitioning/PartitionStrategymembers probed reflectively), keeping the assembly free of provider references.db-ef-migration scriptPer the issue's "decide during implementation" note: the canonical idempotent script comes from the EF toolchain itself (
dotnet ef migrations script --idempotent, bundles likewise), because it requires the compiled migrations that only exist in the consuming project — exactly the path the #364 spike verified end-to-end, including the relocated-history-table guards. The command prints that guidance with the resolved context name rather than duplicating a second-rate scripter.db-ef-migration baselineAdopts a pre-existing database: inserts
__EFMigrationsHistoryrows (creating the relocated history table if missing) for every generated migration file without executing them — the EF-sanctioned baselining technique and the equivalent of Sable'sbackfill. Idempotent across runs. Connection comes from the database's ownIConnectionSourceresolved structurally, with PG and SQL Server SQL dialect variants.EfMigrationGeneratoris the testable engine behind the command and is public for programmatic use.Testing
Provider detection from the Migrator type, structural partition detection, and two integration flows against PostgreSQL: (1) first-run scaffold → assert context/migration/snapshot content → no-change no-op → model change → incremental add with correctly ordered ids; (2)
baselinerecording history rows in the relocated schema exactly once, verified by direct query. Full EF suite (PG+SS) green locally: 95 passed.🤖 Generated with Claude Code