docs: clarify how the event argument is identified in conventional methods (#4562)#4563
Merged
Merged
Conversation
…thods (#4562) The conventional projection method docs explained which argument *combinations* are allowed, but never stated how Marten decides which parameter is the event. Document the shared, type-based rule used by SingleStreamProjection, MultiStreamProjection, and EventProjection, and the conventional event parameter names (@event / event / e / ev) that only matter for disambiguating signatures type inference can't resolve. - conventions.md: new "How Marten Identifies the Event Argument" section - event-projections.md: "Identifying the Event Parameter" note linking to it - migration-guide.md: new subsection under the projection-conventions migration Docs-only. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The "linting, spell check and build" check failed on two dash-style list items (docs/migration-guide.md:377-378). The repo's markdownlint config enforces asterisk unordered-list bullets (MD004/ul-style); switch the two bullets to `*`. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
jeremydmiller
added a commit
that referenced
this pull request
May 27, 2026
Bump the four JasperFx packages Marten depends on to the aligned 2.1.2 release (they now lock to a single $(JasperFxVersion) upstream): - JasperFx 2.0.1 -> 2.1.2 - JasperFx.Events 2.1.1 -> 2.1.2 - JasperFx.Events.SourceGenerator 2.1.1 -> 2.1.2 - JasperFx.SourceGenerator 2.0.1 -> 2.1.2 JasperFx.RuntimeCompiler is intentionally left alone — it versions independently upstream and is not part of the 2.1.2 set (and master no longer references it). 2.1.2 carries the #4562 event-parameter-naming generator support (accepts `ev` as a conventional event parameter name) whose docs landed in #4563. Full solution builds clean against 2.1.2 (0 errors, all 45 projects); no API adaptation needed. Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
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.
Documentation-only. Closes the docs half of #4562.
Why
The conventional projection method docs explain which argument combinations are allowed, but never state how Marten decides which parameter is the event — which leads people to think they must name the parameter
@event. They don't: the event is identified by type, and a parameter name only matters to disambiguate unusual signatures.What
Documents the single, shared rule used by
SingleStreamProjection,MultiStreamProjection, andEventProjection:IEvent<T>parameter is the event (Tis the event type);IQuerySession/IDocumentOperations), isn'tIEvent, isn'tCancellationToken, and isn't the aggregate type;@event,event,e, orev.Changes:
events/projections/conventions.md— new "How Marten Identifies the Event Argument" section near the top.events/projections/event-projections.md— "Identifying the Event Parameter" note forCreate()/Project(), linking to the shared rule.migration-guide.md— new subsection under the projection-conventions migration, since this trips people up when moving off inline lambdas.Related
evname is being added to the accepted names in JasperFx (Accept "ev" as a conventional event parameter name (#4562) jasperfx#369); this documents the convention includingev.🤖 Generated with Claude Code