-
Notifications
You must be signed in to change notification settings - Fork 36
WIP: [DEVEX-227] Getting state from events and running busines logic #334
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Draft
oskardudycz
wants to merge
46
commits into
master
Choose a base branch
from
DEVEX-227-GettingStateAndMakingDecisions
base: master
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Conversation
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
dropped support for net6.0 and net7.0 added some helpers to fluentdocker playing around the idea of keeping the container on tests
…et into DEVEX-185-Rebranding
…et into DEVEX-185-Rebranding
* [DEVEX-222] Added configuration options for KurrentClientSettings Create method This should enable easier customisation like changing serializer settings. * [DEVEX-222] Added overloads of Append methods that take regular events They currently use dummy serialisation * [DEVEX-222] Added TryDeserialize method to ResolvedEvent Currently it's implemented in a dummy way * [DEVEX-222] Added first working, but not yet complete JSON built-in serialization It's not fully ready, as it has hardcoded schema serializer. Main question will be how much from schema registry I need to move here. * [DEVEX-222] Added autoserialization settings and removed serializer from ResolvedEvent Per @RagingKore suggestion it'll be better not to keep the reference to serializer in ResolvedEvent to keep the clear intention behind it. Now, the serializer is resolved from schema registry based on the auto-serialization settings. Made possible to register more than one serializer per content type. Currently it doesn't support more schema definition types. To be discussed how to include them later on. * [DEVEX-222] Made serialization settings to create specific serializers That will make resolution easier and give users ability to inject their own serializers implementation * [DEVEX-222] Added override of the serialization settings to Persistent Subscriptions * [DEVEX-222] Added serialization type and merged serialization into Serialization Context Previously we had DeserializationContext, but after consideration, it'll be better to merge those concepts to make easier customizations per operations (e.g. append, subscribe, etc.). * [DEVEX-222] Added message type name resolution strategy Refactored the code accordingly. It takes the full object instead of the limited number of parameters, as you may be using metadata to get parameters about clrtype. * [DEVEX-222] Refactored Event Type Mapper to not be responsible for resolution of CLR types * [DEVEX-222] Added automatic message clr type resolution * [DEVEX-222] Added metadata extensions to allow injecting type informations * [DEVEX-222] Made CLR type be resolved based on the message type metadata header * [DEVEX-222] Added the MessageTypeResolutionStrategyWrapper for caching resolved types * [DEVEX-222] Added MessageSerializationContext to pass additional information like category name * [DEVEX-222] Refactored SerializationContext into MessageSerializerWrapper to make clearer responsibilities Actually, it's just wrapping message serializer based on the client settings. * [DEVEX-222] Added message type maps registration * [DEVEX-222] Added helpers for custom type resolutions strategy Removed also obsolete SerializationSettings * [DEVEX-222] Replaced MessageSerializerWrapper usage with more generic IMessageSerializer There's no need to force all code to know about wrapper existence, it's okay to just create it during the setup. * [DEVEX-222] Made Message to be record instead of Struct * [DEVEX-222] Refactored new AppendToStreamAsync method to have simplified syntax Now they don't require all the fancy, but redundant in most cases Stream Positions, Directions, EventData etc. * [DEVEX-222] Refactored Reading events signatures to use options instead of parameters Thanks to that safe defaults are already provided * [DEVEX-222] Renamed MessageTypeResolutionStrategy to MessageTypeNamingStrategy * [DEVEX-222] Made old Read methods be wrapper of the new one, instead the other way round * [DEVEX-222] Added serialization configuration overrides Old append and read methods won't be doing default serialization by default. The new one will use auto-seriailization and allow to customize or disable it. * [DEVEX-222] Removed storing CLR type in metadata and moved it to message type name Now the FullTypeName is placed in the event type name. Not perfect but here it is. * [DEVEX-222] Added possibility to register types for category name Thanks to that they will be resolved automatically by the registered convention. Then user doesn't need to provide the string name by hand. Added MessageTypeNamingResolution context besides the MessageSerializationContext as it's orthogonal and just overlapping context. * [DEVEX-222] Added SubscribeToAllOptions and Subscription Listener This is a similar API as we already have in Java client, to simplify the handlers registration. * [DEVEX-222] Addes SubscribeToStreamOptions and applied it accordingly to subscirbe to all changes * [DEVEX-222] Renamed DeserializedEvent to Message in ResolvedEvent I think that in the longer term, this will make intention clearer * [DEVEX-222] Added persistent subscription litener and capability to customize serialization for Persistent Subscriptions * [DEVEX-222] Extended Serialization tests for Appends and Reads * [DEVEX-222] Added capability to automatically deserialize message metadata By default it'll try to resolve the TraceMetadata, it can be override with the general type or using custom resolution strategy. * [DEVEX-222] For unknown reason the reverse Enumerable.Reverse wasn't taken but Array.Reverse 🤷 * [DEVEX-222] Fixed type resolution to correclty find types by assembly * [DEVEX-222] Added tests for serialization compatibility between manual and automatic deserialization * [DEVEX-222] Added tests for appends with autoserialization * Revert "[DEVEX-222] Added tests for appends with autoserialization" This reverts commit 04e0685. I'm reverting it as old methods are wrappers for new ones, so the test scenarios are covered by the old test suite. * [DEVEX-222] Extended serialization test suite * [DEVEX-222] Added tests for auto-serialization in Catch-up subscriptions * [DEVEX-222] Added tests for auto-serialization in persistent subscriptions * [DEVEX-222] Added Expected prefix to StreamState and StreamRevision in AppendToStreamOptions * [DEVEX-222] Merged namespaces Fixed also XML docs comments * [DEVEX-222] Renamed NulloMessageSerializer to NullMesageSerializer * [DEVEX-222] Added AppendToStream methods that has expected stream revision as a parameter * [DEVEX-222] Added XML documentation for Serialization settings * [DEVEX-222] Added Unit tests * [DEVEX-222] Added tests for type resolution Used also two external assemlies - one that's loaded, - one that's never loaded. To double-check behaviour of loading types from different assemblies. * [DEVEX-222] Added SchemaRegistry tests
* [DEVEX-222] Added configuration options for KurrentClientSettings Create method This should enable easier customisation like changing serializer settings. * [DEVEX-222] Added overloads of Append methods that take regular events They currently use dummy serialisation * [DEVEX-222] Added TryDeserialize method to ResolvedEvent Currently it's implemented in a dummy way * [DEVEX-222] Added first working, but not yet complete JSON built-in serialization It's not fully ready, as it has hardcoded schema serializer. Main question will be how much from schema registry I need to move here. * [DEVEX-222] Added autoserialization settings and removed serializer from ResolvedEvent Per @RagingKore suggestion it'll be better not to keep the reference to serializer in ResolvedEvent to keep the clear intention behind it. Now, the serializer is resolved from schema registry based on the auto-serialization settings. Made possible to register more than one serializer per content type. Currently it doesn't support more schema definition types. To be discussed how to include them later on. * [DEVEX-222] Made serialization settings to create specific serializers That will make resolution easier and give users ability to inject their own serializers implementation * [DEVEX-222] Added override of the serialization settings to Persistent Subscriptions * [DEVEX-222] Added serialization type and merged serialization into Serialization Context Previously we had DeserializationContext, but after consideration, it'll be better to merge those concepts to make easier customizations per operations (e.g. append, subscribe, etc.). * [DEVEX-222] Added message type name resolution strategy Refactored the code accordingly. It takes the full object instead of the limited number of parameters, as you may be using metadata to get parameters about clrtype. * [DEVEX-222] Refactored Event Type Mapper to not be responsible for resolution of CLR types * [DEVEX-222] Added automatic message clr type resolution * [DEVEX-222] Added metadata extensions to allow injecting type informations * [DEVEX-222] Made CLR type be resolved based on the message type metadata header * [DEVEX-222] Added the MessageTypeResolutionStrategyWrapper for caching resolved types * [DEVEX-222] Added MessageSerializationContext to pass additional information like category name * [DEVEX-222] Refactored SerializationContext into MessageSerializerWrapper to make clearer responsibilities Actually, it's just wrapping message serializer based on the client settings. * [DEVEX-222] Added message type maps registration * [DEVEX-222] Added helpers for custom type resolutions strategy Removed also obsolete SerializationSettings * [DEVEX-222] Replaced MessageSerializerWrapper usage with more generic IMessageSerializer There's no need to force all code to know about wrapper existence, it's okay to just create it during the setup. * [DEVEX-222] Made Message to be record instead of Struct * [DEVEX-222] Refactored new AppendToStreamAsync method to have simplified syntax Now they don't require all the fancy, but redundant in most cases Stream Positions, Directions, EventData etc. * [DEVEX-222] Refactored Reading events signatures to use options instead of parameters Thanks to that safe defaults are already provided * [DEVEX-222] Renamed MessageTypeResolutionStrategy to MessageTypeNamingStrategy * [DEVEX-222] Made old Read methods be wrapper of the new one, instead the other way round * [DEVEX-222] Added serialization configuration overrides Old append and read methods won't be doing default serialization by default. The new one will use auto-seriailization and allow to customize or disable it. * [DEVEX-222] Removed storing CLR type in metadata and moved it to message type name Now the FullTypeName is placed in the event type name. Not perfect but here it is. * [DEVEX-222] Added possibility to register types for category name Thanks to that they will be resolved automatically by the registered convention. Then user doesn't need to provide the string name by hand. Added MessageTypeNamingResolution context besides the MessageSerializationContext as it's orthogonal and just overlapping context. * [DEVEX-222] Added SubscribeToAllOptions and Subscription Listener This is a similar API as we already have in Java client, to simplify the handlers registration. * [DEVEX-222] Addes SubscribeToStreamOptions and applied it accordingly to subscirbe to all changes * [DEVEX-222] Renamed DeserializedEvent to Message in ResolvedEvent I think that in the longer term, this will make intention clearer * [DEVEX-222] Added persistent subscription litener and capability to customize serialization for Persistent Subscriptions * [DEVEX-222] Extended Serialization tests for Appends and Reads * [DEVEX-222] Added capability to automatically deserialize message metadata By default it'll try to resolve the TraceMetadata, it can be override with the general type or using custom resolution strategy. * [DEVEX-222] For unknown reason the reverse Enumerable.Reverse wasn't taken but Array.Reverse 🤷 * [DEVEX-222] Fixed type resolution to correclty find types by assembly * [DEVEX-222] Added tests for serialization compatibility between manual and automatic deserialization * [DEVEX-222] Added tests for appends with autoserialization * Revert "[DEVEX-222] Added tests for appends with autoserialization" This reverts commit 04e0685. I'm reverting it as old methods are wrappers for new ones, so the test scenarios are covered by the old test suite. * [DEVEX-222] Extended serialization test suite * [DEVEX-222] Added tests for auto-serialization in Catch-up subscriptions * [DEVEX-222] Added tests for auto-serialization in persistent subscriptions * [DEVEX-222] Added Expected prefix to StreamState and StreamRevision in AppendToStreamOptions * [DEVEX-222] Merged namespaces Fixed also XML docs comments * [DEVEX-222] Renamed NulloMessageSerializer to NullMesageSerializer * [DEVEX-222] Added AppendToStream methods that has expected stream revision as a parameter * [DEVEX-222] Added XML documentation for Serialization settings * [DEVEX-222] Added Unit tests * [DEVEX-222] Added tests for type resolution Used also two external assemlies - one that's loaded, - one that's never loaded. To double-check behaviour of loading types from different assemblies. * [DEVEX-222] Added SchemaRegistry tests --------- Co-authored-by: Oskar Dudycz <oskar.dudycz@eventstore.com>
…nsions They're redundant as most of them should be handled by the ReadStreamOptions. Expected checks can be made on the append side and also passed to decide options to only read as many events as needed.
…tween StateBuilder and AsyncStateBuilder
…g and decision making
Also simplified the StateBuilder abstraction to reduce the number of classes. Reshaped Decider implementation, now AsyncDecider uses raw code and regular Decider wraps around it.
Now AsyncEnumerable part will always assume that it gets the exact initial state, it needs to be read first either from state builder or snapshot. That makes it explicit on the responsibilities.
…re to a dedicated file
…e overloads to extension methods
d71db29
to
a84083a
Compare
… extension method for regular events
Made also other smaller improvements like: - removing event from state store interface, - made both StateStore and AggregateStore method virtual, - decoupled Decider from AsyncDecider moving the mapping method to extension classes.
… of the single state That gives possibility to cache multiple single stream projection states instead of rolling always a single one
f69a63a
to
dd8cf4c
Compare
8c7d67a
to
7b1b13c
Compare
7b1b13c
to
0a5bc23
Compare
…ggregate Store Also split the Decider information and Decision processing
86c22ab
to
a8a4f4a
Compare
a8a4f4a
to
d2f9d4e
Compare
ed64c8d
to
4094c38
Compare
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.
🚧 WIP