The Entity Framework Core store needs three tables: DomainEvents, DomainAggregates, and
DomainProjections. This guide covers getting them into a database, whichever way you manage schema.
DomainEventsis new in 1.9.0. Before that the event table was calledevents. A database created by an earlier version needs the rename applied before an upgraded application runs against it — see Upgrade to 1.9.0.
You do not need to write a migration by hand either way.
Your DbContext derives from DomainDbContext, so the store’s model is already part of your model.
EF generates the whole schema for you:
dotnet ef migrations add MemoriaStore
dotnet ef database update
That is the entire install. Memoria deliberately ships no migration files of its own: migrations
belong to the assembly and DbContext that own the connection string, and a second copy of the
schema in this package could drift from OnModelCreating without anyone noticing.
If your context adds entities of its own, they appear in the same migration — that is expected.
For databases managed with DbUp, Flyway, by a DBA, or by hand, run the install script for your engine:
Both are safe to run more than once: every object is guarded, so a re-run adds only what is missing.
Both assume the default table names and the default schema (dbo on SQL Server, public on
PostgreSQL); adjust the identifiers if your DbContext maps them elsewhere.
The SQL Server script contains no GO separators, so it runs as a single batch under sqlcmd, SSMS,
Azure Data Studio, or a plain SqlCommand.
Install, not upgrade. These scripts create what is missing and change nothing that already exists. To move an existing database from an earlier version, use the scripts under
scripts/migrationsand the matching upgrade guide.
Memoria.EventSourcing.Dcb.Store.EntityFrameworkCore has four tables of its own — DcbEvents,
DcbEventTags, DcbTagHeads and DcbSnapshots — and shares nothing with the tables above. If you
use both consistency models, run its script alongside the one for your engine, not instead of it:
If you use EF Core migrations, there is nothing to run: a DbContext deriving from DcbDbContext
already carries these tables in its model.
Do not relax the collation on the two
Tagcolumns. The scripts create them case-sensitively —SQL_Latin1_General_CP1_CS_ASon SQL Server,"C"on PostgreSQL — because tags compare ordinally in .NET. Under SQL Server’s usual case-insensitive default,seat:A1andseat:a1become one row, and every consistency boundary naming them is quietly wider than the code says. A container test asserts the collation on both engines, and another proves the behaviour it protects.
context.Database.EnsureCreatedAsync() creates the schema directly from the model and needs nothing
from this guide. It has no upgrade path, though — it creates a database or does nothing — so it suits
tests and throwaway environments rather than anything you intend to migrate later.
An install script that quietly drifts from the model would be worse than none: it would stand up a database the store then fails against for reasons nobody can see.
So on every CI run, for each engine, the container suite builds one database from the script and
another from the model, then compares every column with its engine type and every index including
primary keys, across every table. Any divergence fails the build. The DCB scripts are held to the
same comparison, plus the collation of their two Tag columns.