Stratara.Orleans.EntityFrameworkCore
4.4.5
Prefix Reserved
dotnet add package Stratara.Orleans.EntityFrameworkCore --version 4.4.5
NuGet\Install-Package Stratara.Orleans.EntityFrameworkCore -Version 4.4.5
<PackageReference Include="Stratara.Orleans.EntityFrameworkCore" Version="4.4.5" />
<PackageVersion Include="Stratara.Orleans.EntityFrameworkCore" Version="4.4.5" />
<PackageReference Include="Stratara.Orleans.EntityFrameworkCore" />
paket add Stratara.Orleans.EntityFrameworkCore --version 4.4.5
#r "nuget: Stratara.Orleans.EntityFrameworkCore, 4.4.5"
#:package Stratara.Orleans.EntityFrameworkCore@4.4.5
#addin nuget:?package=Stratara.Orleans.EntityFrameworkCore&version=4.4.5
#tool nuget:?package=Stratara.Orleans.EntityFrameworkCore&version=4.4.5
Stratara.Orleans.EntityFrameworkCore
Derived. The behaviour described here is specified under
openspec/specs/, in theorleans-executionandevent-sourcing-storecapabilities. Those specifications are the source; this page explains them.
License: MIT.
Entity Framework Core persistence for the Stratara Orleans execution model: the readers that return
the event store in commit order and the checkpoint store the store-reading projections and sagas
resume from. The columns and tables they need are declared by the framework's write and read
contexts in Stratara.EventSourcing.EntityFrameworkCore, so a context derived from those carries
them without further configuration.
What's in the box
| Part | What it does |
|---|---|
PostgresTransactionIdReader<TContext> |
Reads in commit order on PostgreSQL, adding no work to an append |
PortableCounterReader<TContext>, AddStrataraPortableCounterReader<TWriteContext>() |
Reads in commit order on any relational provider, through a per-partition counter; verified on PostgreSQL and on SQLite |
PartitionCounterInterceptor |
Maintains the per-partition counter inside the appending transaction — in every process that appends |
PartitionCounterBackfill |
Positions unpositioned entries after the partition's counter, never moving a position already handed out, so checkpoints stay true |
CommitTransactionIdBackfill |
Stamps the entries a PostgreSQL store held before the commit record existed, in append order and bounded batches, once |
AddStrataraProjectionCheckpoints<TReadContext>() |
Keeps the checkpoints in the read context |
AddStrataraIntentStore<TWriteContext>() |
Records the commands the execution model's dispatcher accepts, in the outbox table, and claims a due batch in two statements |
AddStrataraExecutionModelReset<TReadContext>() |
Clears reminders, membership, directory and the host's checkpoints while no silo runs |
Quick start
The read side — projections that read the store in commit order from a checkpoint:
builder.Services
.AddSingleton<ICommittedPositionReader, PostgresTransactionIdReader<AppWriteDbContext>>()
.AddStrataraProjectionCheckpoints<AppReadDbContext>()
.AddStrataraProjectionGrains();
The write side — commands recorded before the dispatch returns and resumed after a crash:
builder.Services
.AddStrataraOrleansCommandDispatcher()
.AddStrataraIntentStore<AppWriteDbContext>()
.AddStrataraSingletonWork<OutboxDrainWork>(OutboxDrainWork.WorkName);
The record is committed in a transaction of its own, not with what the caller writes.
| Product | Versions Compatible and additional computed target framework versions. |
|---|---|
| .NET | net10.0 is compatible. net10.0-android was computed. net10.0-browser was computed. net10.0-ios was computed. net10.0-maccatalyst was computed. net10.0-macos was computed. net10.0-tvos was computed. net10.0-windows was computed. |
-
net10.0
- Stratara.EventSourcing.EntityFrameworkCore (>= 4.4.5)
- Stratara.Orleans (>= 4.4.5)
NuGet packages (1)
Showing the top 1 NuGet packages that depend on Stratara.Orleans.EntityFrameworkCore:
| Package | Downloads |
|---|---|
|
Stratara.Testing.Orleans
Run the Stratara Orleans execution model in a test's own process — one silo with in-memory reminders and grain directory, the real write stack, commit-order reader and checkpoint store on in-memory SQLite, and every period shortened to seconds. Register handlers, projections, sagas and timers with the production calls; no cluster, broker or database server. Builds on Stratara.Testing.EntityFrameworkCore. |
GitHub repositories
This package is not used by any popular GitHub repositories.
A command can now say whose data its protected fields are. Until now a command's `[EncryptData]` fields were
encrypted for the session that dispatched it, so a session with no tenant could not protect anything and a session
with another tenant protected under the wrong one. Additive and opt-in; no schema change and no migration. One
ordering rule applies once a host starts using it (see *Changed*).
### Added
- **A command can name the owner of its protected fields.** A command that implements the new `INamesDataOwner`
(`Stratara.Abstractions.Security`: `Guid DataOwnerTenantId`, optional `Guid? DataOwnerUserId`) has its
`[EncryptData]` fields encrypted for that owner wherever the framework serializes it — the copy the outbox, the
bus and the Orleans record carry to its handler, and the copy the command audit records — whatever session
dispatched it. It is to a command what `IAggregateCreationEvent` is to a stream's first event. Three cases it
answers: a session with no tenant (an anonymous endpoint, or a saga reacting to a fact one recorded) could not
encrypt a `TenantScoped` field at all outside development; a session with another tenant than the data's owner
encrypted it under that tenant's key, silently, so the real owner's erasure left the audit record readable; and
the two copies of one command were written for different users. For a command that names its owner, both copies
are written for the same tenant and the same user.
- **The audit record of such a command is attributed to the named owner.** Its data-owner tenant and user are the
owner the command names; its actor is the session's, as before. A tenant's view of the command log then holds the
commands that carried its data, whoever issued them, and each record can be read back from its own columns.
- **`CommandEnvelope.DataOwnerTenantId` and `.DataOwnerUserId`** carry the owner beside the session context. They
are set only for a command that names an owner and are omitted from the JSON otherwise; the constructor and
`Deconstruct` are unchanged. The handling host reads the command's protected fields for the owner the envelope
carries and runs the handler under the session it carries.
- **`CommandDataOwner`** (`Stratara.Shared.Security`) is the one resolution every writer and reader of a command
uses, for a host that serializes commands itself.
### Changed
- **The bus-envelope signature covers a named owner.** A signed command does not verify when it is presented with
another data owner, or with its owner removed. A command that names no owner has the canonical form it had before,
so publishers and consumers on either side of this release verify each other's signatures for it and a fleet in
`Strict` mode upgrades without a pass through `Permissive`.
- **Upgrade the hosts that handle commands before a host dispatches a command that names an owner.** A command
worker or silo on an earlier release cannot read the owner. It does not run the handler with the fields emptied:
in `Strict` mode the signature does not verify, otherwise the read fails authentication, and the message is
retried and then kept. Two deployments are the simple order — this release first, the declarations after.
- **Nothing changes for a command that names no owner.** It is serialized, stored, published and signed as before.
That includes a divergence this release states rather than removes: its travelling copy is written for the
session's tenant and the *acting* user, its audit record for the session's tenant and the session's *data-owner*
user — for an ordinary signed-in request, a user and nobody. Aligning that default would re-key every protected
command field in transit and is left to a major version; a command that names its owner is not affected.
### Security
- **An erasure now reaches a command's protected fields where the command names its owner.** `ISubjectEraser`'s
documentation said the command audit log and the outbox are left alone. Their rows still are; what it now also
says is what happens to protected fields in them. A command that names its owner has them under that owner's key
in both places, so the owner's erasure leaves the record of the command with those fields unreadable, and a
command still waiting reaches its handler with them absent.
- **A command that names an empty tenant, or an empty user, as its owner is refused.** It fails with
`ArgumentException` naming the command type where it is recorded and where it is dispatched, and nothing is
recorded or sent. It does not fall back to the session, which would hide a caller's mistake in valid ciphertext
under the wrong tenant's key.
- **Naming an owner authorizes nothing, and the owner is taken as stated.** Nothing compares the named owner
against the session; the handler runs under the dispatching session, and authorization and tenant isolation decide
as they do for any other command. Nothing checks that the named tenant exists either, and key material is created
for it on first use — name an owner the code resolved from something it trusts, never one copied from a request.
- **A command encrypted as a whole does not outlive its owner.** With `[EncryptData]` on individual fields, a
command still waiting when its owner is erased reaches its handler with those fields absent. With `[EncryptData]`
on the class there is nothing left to rebuild: the command is retried and then kept, and its handler does not run.
That is how a command whose session tenant was erased already behaved; it is now stated.