-
Notifications
You must be signed in to change notification settings - Fork 59
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
Conflict resolution #12
Comments
charlessolar
added a commit
that referenced
this issue
Oct 4, 2016
…ne an addition Conflict(Event e) method alongside Handle(Event e) the difference being that Conflict will indicate the event is attempting to merge with the stream. If no Conflict handler is defined by the user, or if they throw AbandonConflictException we'll give up on conflict resolution and send the command to immediate retry. If the conflict handler throws DiscardEventException then the conflicting event won't be added to the stream We'll see how this works out
Better conflict resolution has been implemented - new system supports a range of different options, can be found here https://github.com/volak/Aggregates.NET/blob/master/src/Aggregates.NET.Domain/Internal/ConflictResolvers.cs |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Removed the logic for conflict resolution because I realized simply hydrating the conflicting commands on a fresh stream and retrying the commit is a pretty bad policy.
The correct thing to do is to re-run the business logic executed by the command.
To do that off the top of my head we'd have to re-run the command's handle method for the specific instance that changed the stream.. which is just not possible to do correctly either.
Will have to look at other resolution strategies.
I guess the best way would be to let the user define his own custom conflict resolvers so he can explicitly define when a version conflict can be accepted and when it can't
The text was updated successfully, but these errors were encountered: