Newest first, grouped by year. Search or filter by topic.
FastEndpoints.OData is ninety lines that bolt Microsoft's OData query engine onto a REPR endpoint - a sealed Configure(), a fake ParameterInfo, and an endpoint filter that fishes the response out of HttpContext.Items. Reading it is a masterclass in integrating with a framework through its narrowest seam. Part 7 of FastEndpoints — The Missing Chapters.
When Postsale was carved out of Sales, sixteen types came with it - and every place the twins differ marks a decision the extraction forced, including one base class that stopped draining and a repository that silently depends on it.
A decision record mandates UTC everywhere and an IClock abstraction, and thirty files honour it - then one process-global AppContext switch in shared plumbing makes every timestamp column forget it was UTC.
Because the write model exposes nothing, the read side could not go through the aggregate - so a second POCO maps the same physical table through a second DbContext. CQRS as an outcome rather than a choice.
The third persistence strategy is the plainest one, and the only one a background poller can interrogate - plus what that poller costs when it has no watermark, no paging and no index.
Mapping a fully encapsulated aggregate to relational tables with Property of T of a string - eight tables for one aggregate, eighteen columns, seventeen of them named after private C# fields.
Sales stores four aggregate roots and twenty-five value objects in three tables, by serialising whole aggregates into jsonb - and the reflection resolver that makes reconstitution work bypasses every invariant on the way in.
What the document strategy really costs - a promoted column, a side table, an in-memory dictionary with a TODO on it, and six update methods that look the row up without its id.
Postsale's aggregate has ten private fields and exactly one public member. Reservation, in the same estate, has eighteen. Following that difference all the way down to the database.
A teaching repo that implements one airline-charter domain three ways on purpose - CRUD, CRUD-plus-rich, and Clean Architecture - and persists it three ways to match. Part 1 of a source-reading series.
One published type from the Communication module is mapped as an owned entity into TimeManagement's schema - so adding a field to your own contract now needs a migration you do not own.
Conferences registers in-memory and EF repositories for the same interfaces and lets last-registration-wins pick - a live lesson in DI as strategy selector, dead registrations as fossils, and a no-op UpdateAsync nobody deleted.
One Postgres database, one schema per module, and entity configurations that are all empty bodies - what ModularMonolith's data layer declares about future service boundaries, and what its migrations quietly gave away.
Retention as a first-class column: how ArchiveKit stamps ExpiresAt at archive time from a TtlDays attribute, hard-deletes expired rows in bounded batches, and runs the whole thing on Lambda with the hosted services switched off. Also, the rows TTL doesn't clean yet. Part 8 of the Archive-on-Delete with ArchiveKit series.
The read side of archive-on-delete: querying archives through promoted typed columns, digging into jsonb payloads for everything else, polling snapshots with a 202 pattern, and an honest accounting of the restore path ArchiveKit doesn't have yet. Part 9 wraps up the Archive-on-Delete with ArchiveKit series.
ArchiveKit's snapshot service assembles a full JSON tree of a deleted object graph using nothing but archive rows - the primary data is already gone. Job tickets, a four-state machine, retries with a terminal Failed state, and the single-table assembly limitation I still owe a fix for. Part 7 of the Archive-on-Delete with ArchiveKit series.
Correlation ids and cascade archiving in ArchiveKit - how one Guid per save turns scattered archive rows into a reconstructable object graph, why cascade happens through the EF change tracker rather than the database, and two honest limits: a naive root heuristic and a CascadeArchive flag the interceptor doesn't read yet. Part 6 of the Archive-on-Delete with ArchiveKit series.
How ArchiveKit wires itself up - the [Archivable] attribute's three knobs, an assembly scanner that fails fast at startup instead of quietly at delete time, the static registry behind every lookup, and the AddArchiveKit configuration surface. Plus an honest note about the source generator that doesn't exist yet. Part 5 of the Archive-on-Delete with ArchiveKit series.
The storage design behind ArchiveKit - typed queryable columns and a jsonb payload from a single write, why the archive's EntityId is an index but deliberately not a foreign key, and the reflective model configuration that builds every archive table from one method call. Part 4 of the Archive-on-Delete with ArchiveKit series.
Why ArchiveKit's inline archive limit defaults to exactly 14, how EF Core's MaxBatchSize turns archiving into arithmetic, and an honest inventory of every deletion path the interceptor cannot see - synchronous saves, ExecuteDelete, and raw SQL. Part 3 of the Archive-on-Delete with ArchiveKit series.
The anatomy of ArchiveKit's SaveChangesInterceptor - detecting soft-deleted entities in the change tracker, building archive rows with zero extra database reads, and the one line of state-flip ordering that keeps EF from cascade-deleting the archive you just wrote. Part 2 of the Archive-on-Delete with ArchiveKit series.
Hard deletes destroy the audit trail; soft deletes clutter live tables forever. Introducing ArchiveKit, a .NET library that intercepts deletions and stores immutable archive snapshots with TTL policies and cascade archiving.
Archive tables are meant to empty out - a background worker migrates their rows into the current table while live traffic reads and write-through updates race it. This part walks the EF backfill's insert-then-conditional-delete choreography and the timestamp that keeps it honest. Part 9 of the Entity Versioning with VersionKit series.
A point lookup that might hit any of three tables, a list query that should span them all, and writes that must keep a registry honest - this part walks VersionKit's version-aware reader and writer, and the generated UNION view that makes every schema era queryable as if it were current. Part 8 of the Entity Versioning with VersionKit series.
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.
