Repository navigation
Respect split stream events when building decision models - #925
Closed
DavidBadura wants to merge 1 commit into
Closed
DavidBadura wants to merge 1 commit into
DavidBadura wants to merge 1 commit into
Conversation
An event marked with #[SplitStream] holds the whole state that is relevant from that point on. Aggregates already use it to skip older events, but decision models always read the complete history of their projections. Before reading, the builders now look up the last split event of every projection that handles one, using the projection's own tags, and read from there. Projections only get events from their own split event onwards, so a projection without split events in the same decision model still gets its whole history. Nothing is archived, the append condition stays the same. A projection can opt out by overriding splitEvents().
DavidBadura
marked this pull request as draft
October 3, 2026 19:33
|
Hello 👋 here is the most recent benchmark result:
This comment gets update everytime a new commit comes in! |
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
1 participant
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.
Builds on #924, the base will switch to 4.0.x once that is merged.
An event marked with
#[SplitStream]holds the whole state that is relevant from that point on. Aggregates use that to skip older events, but in DCB it had no effect at all:StoreEventAppenderdoesn't run message decorators,append()doesn't archive andquery()ignores the archived flag. Archiving wouldn't be the right tool here anyway. It works per stream, while an event in DCB often belongs to several boundaries (e.g.account:1andcustomer:7), so archiving it for one projection would hide it from the others.So the cut happens per projection while building the decision model, the store doesn't need to know anything about split events:
BasicProjection::splitEvents()returns the event classes of its apply methods that have#[SplitStream].onlyLastEventquery.query($query, $from)and every projection only gets messages from its own split event onwards.The append condition doesn't change. Events before the split are older than
afteranyway, and anything appended concurrently is newer. If one projection in the decision model has no split events, the read starts at 0, so mixed decision models are correct but don't save anything yet. A projection that handles a split event but needs the whole history, e.g. to count them, can overridesplitEvents()and return[].The same applies to
StoreProjectionBuilder.