Add checkpoints for decision models - #927
Open
DavidBadura wants to merge 2 commits into
Open
DavidBadura wants to merge 2 commits into
DavidBadura wants to merge 2 commits into
Conversation
A projection that has to load a long history can now mark an apply method with #[Checkpoint]. Its event has to contain the whole state the projection needs, so everything before the last of these events is skipped. Before reading, the builders look up the last checkpoint event of every projection with the projection's own tags and read from there. Each projection only gets events from its own checkpoint onwards, so other projections in the same decision model still get their whole history. Nothing is archived and the append condition stays the same. This is deliberately separate from #[SplitStream]: that one cuts off a whole stream for aggregates, a checkpoint only affects the projection declaring it.
|
Hello 👋 here is the most recent benchmark result:
This comment gets update everytime a new commit comes in! |
The existing taggable store benchmarks only cover aggregates and plain appends. Decisions are different: their cost depends on the size of the whole table and on how selective the tags are, not just on the matching events. The new benchmark fills the store with 1.000 courses, 1.000 invoices and two courses with a long history, and measures building small, composite and long decision models, checkpoints, only-last-event projections and conditional appends against that data.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Replaces #925, which reused
#[SplitStream]for this. That gave the same attribute two meanings when aggregates and DCB share a store: for an aggregate it cuts off the whole stream, for DCB it would only have cut off projections that handle the event. So this adds a separate, explicit attribute on the projection instead and leaves#[SplitStream]untouched.The event of a checkpoint method has to contain the whole state the projection needs. When building a decision model:
onlyLastEventquery.query($query, $from)from Allow reading events from a position with AppendStore::query() #924).The store doesn't know anything about checkpoints, nothing is archived and the append condition is unchanged. Events before a checkpoint are older than
afteranyway, and anything appended concurrently is newer. If one projection in the decision model has no checkpoint, the read starts at 0, so that case is correct but doesn't save anything yet. The same applies toStoreProjectionBuilder.#[Checkpoint]without#[Apply]throws anApplyMethodDetectionError.This also adds
DynamicConsistencyBoundaryBench. The existing taggable store benchmarks only cover aggregates and plain appends, but the cost of a decision depends on the size of the whole table and on how selective the tags are. The benchmark fills the store with 1.000 courses, 1.000 invoices and two courses with a long history (one of them with a checkpoint every 100 events) and measures small, composite and long decision models, checkpoints,onlyLastEventand conditional appends against that.