Newest first, grouped by year. Search or filter by topic.
JSON payloads can migrate lazily because the reader controls the shape - relational rows cannot, because the table is the shape. VersionKit's EF Core answer is table-per-version - archive Orders as Orders_v2 on a schema bump, track every row's home in a registry, and let old rows stay old until something moves them. Part 7 of the Entity Versioning with VersionKit series.
Shipping a migration to one database is a deploy step. Shipping it to every schema in every group database is an orchestration problem — cross-database MigrateAsync, an HTTP migration surface, a per-tenant audit ledger, and the honest gap where the fan-out loop should be.
EF Core wants one database, one model and one migrations history table. Schema-per-tenant breaks all three assumptions. Constructor-injected migrations, a per-schema history table and a replaced IMigrationsAssembly put one migration set in charge of every tenant schema.
You built schema-aware migrations, provisioned tenant A, and everything worked. Tenant B provisions without a single error — and gets no tables. EF Core's model cache is the silent culprit, and IModelCacheKeyFactory is the three-field fix.
A decimal surrogate key beside the natural key that does the work, scaffolded index cruft with a placeholder name, a DbSet of List of string, and lazy proxies in a projection minefield.
