feat: EventStoreOptions.AddEventType / AddEventTypes (#395) - #396
Merged
Conversation
`StoreOptions.Events` exposed `RegisterTagType` and a pile of flags but no
`AddEventType`, so the Marten-documented pre-registration pattern
opts.Events.AddEventType<StudentEnrolled>();
did not compile on Polecat. Users had to go around the facade to
`opts.EventGraph.AddEventType(typeof(...))`, which works but is not
discoverable and is not what any Marten-derived sample shows.
Adds three void delegations on `EventStoreOptions`, mirroring the existing
`RegisterTagType` pattern. Deliberately `void` rather than returning
`IEventStoreOptions` for fluent chaining — that return type is what makes a
generic DIM on `IEventRegistry` (marten#5114) source-breaking to add, so
keeping these void matches the shared interface and leaves the door open.
Drops the workaround (and its explanatory comment) from the compliance
fixture's registrar, and documents pre-registration in events/storage.md.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Merged
jeremydmiller
added a commit
that referenced
this pull request
Aug 3, 2026
Minor rather than patch: 5.9.1's line added public surface (IEventBinarySerializer, EventStoreOptions.AddEventType/AddEventTypes) and moved the whole JasperFx/Weasel matrix forward. Since 5.9.1: - feat: pluggable binary event serialization via IEventBinarySerializer (#388/#402) - feat: EventStoreOptions.AddEventType / AddEventTypes (#395/#396) - fix: escape interpolated identifiers and literals in constructed SQL (#390/#403) - fix: throw a lone DcbConcurrencyException unwrapped from SaveChangesAsync (#394/#397) - deps: JasperFx 2.37.2 -> 2.38.0, Weasel 9.23.0 -> 9.23.2 (#405, #407) - Polecat's ProjectionScenario is now a thin subclass of the lifted JasperFx.Events.TestSupport harness rather than a seven-file copy of Marten's (#404/#408, jasperfx#616) -- a behavior change for anyone already using it, see the release notes - test infrastructure: compliance waves 1-3 (#393, #400, #407), parallel-safe test suite (#389), IntegrationContext.StoreOptions document cleaning (#398/#401)
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.
Closes #395.
The gap
StoreOptions.Eventsis anEventStoreOptionsfacade exposingRegisterTagType<TTag>()and a pile of flags — but noAddEventType. A user following Marten's documented pattern:had to go around the facade to
opts.EventGraph.AddEventType(typeof(StudentEnrolled)). That works (StoreOptions.EventGraphis public andEventGraphimplementsIEventRegistry) but is undiscoverable and matches no Marten-derived docs or samples. It also matters beyond ergonomics: pre-registration is the documented mitigation for the async daemon meeting an event type it has not yet seen appended, and that mitigation was unreachable from the options facade.The change
Three
voiddelegations onEventStoreOptions, mirroring the existingRegisterTagTypedelegation pattern (EventGraph!— assigned in theStoreOptionsconstructor, so non-null at configure time):AddEventType<TEvent>()AddEventType(Type)AddEventTypes(IEnumerable<Type>)Deliberately not returning
IEventStoreOptionsfor fluent chaining. Marten'sAddEventType<T>()does, and that return type is precisely what makes marten#5114 (a generic DIM onIEventRegistry) impossible to land there without a source-breaking change. Keeping thesevoidmatches the shared interface and leaves the door open.Also:
PolecatComplianceFixture.PolecatComplianceRegistrar.AddEventTypenow goes through the facade; its comment explaining the detour is gone with the detour.docs/events/storage.md.Tests
Four unit tests in
StoreOptionsTestscovering the generic overload, theTypeoverload, the batch overload, and idempotency (re-registering the same type does not duplicate it).Locally on net10.0:
StoreOptionsTests16/16,Polecat.Tests.Compliance42/42.🤖 Generated with Claude Code