Part of the EF Core migration generation epic — tracking issue #371.
Command-line surface for the generator, following the existing db-* command pattern (PatchCommand, ApplyCommand, etc. in Weasel.Core/CommandLine). IDatabase is the source of all schema objects, exactly like db-patch today — so Marten system tables, Wolverine envelope storage, Polecat event storage, and EF-projection tables all flow in through one door.
The commands live in Weasel.EntityFrameworkCore (they need EF references; Weasel.Core stays EF-free) and are discovered by the JasperFx command line when the package is referenced.
Commands
db-ef-migration add <Name> — generate the next migration for the selected IDatabase (snapshot diff by default, --against-database for live-DB baseline). Uses the same WeaselInput/TryChooseSingleDatabase database-selection machinery as the existing commands. First run scaffolds the stub context + initial "create everything" migration + snapshot.db-ef-migration script — convenience passthrough producing an idempotent SQL script from the generated migrations (or document dotnet ef migrations script --idempotent as the canonical path — decide during implementation).db-ef-migration baseline — adopt a pre-existing database: insert __EFMigrationsHistory rows for already-applied migrations without executing them (the EF docs sanction hand-inserted history rows for squashing/baselining; this is the equivalent of Sable's backfill).
Notes
- Multiple
IDatabase registrations (any mix of Marten + Polecat + Wolverine) → per-database migration sets and stub contexts; reuse the existing database-selection UX.
- Multi-tenancy: one migration set, applied per tenant database — same artifacts, N connection strings.
- Output paths configurable via options on the command input.
Acceptance
- In a sample app registering Marten (or any
IDatabase), dotnet run -- db-ef-migration add Initial produces compiling artifacts; dotnet ef database update --context <Stub> applies them; db-ef-migration baseline makes an existing database report no pending migrations.
Part of the EF Core migration generation epic — tracking issue #371.
Command-line surface for the generator, following the existing
db-*command pattern (PatchCommand,ApplyCommand, etc. inWeasel.Core/CommandLine).IDatabaseis the source of all schema objects, exactly likedb-patchtoday — so Marten system tables, Wolverine envelope storage, Polecat event storage, and EF-projection tables all flow in through one door.The commands live in
Weasel.EntityFrameworkCore(they need EF references;Weasel.Corestays EF-free) and are discovered by the JasperFx command line when the package is referenced.Commands
db-ef-migration add <Name>— generate the next migration for the selectedIDatabase(snapshot diff by default,--against-databasefor live-DB baseline). Uses the sameWeaselInput/TryChooseSingleDatabasedatabase-selection machinery as the existing commands. First run scaffolds the stub context + initial "create everything" migration + snapshot.db-ef-migration script— convenience passthrough producing an idempotent SQL script from the generated migrations (or documentdotnet ef migrations script --idempotentas the canonical path — decide during implementation).db-ef-migration baseline— adopt a pre-existing database: insert__EFMigrationsHistoryrows for already-applied migrations without executing them (the EF docs sanction hand-inserted history rows for squashing/baselining; this is the equivalent of Sable'sbackfill).Notes
IDatabaseregistrations (any mix of Marten + Polecat + Wolverine) → per-database migration sets and stub contexts; reuse the existing database-selection UX.Acceptance
IDatabase),dotnet run -- db-ef-migration add Initialproduces compiling artifacts;dotnet ef database update --context <Stub>applies them;db-ef-migration baselinemakes an existing database report no pending migrations.