-
Notifications
You must be signed in to change notification settings - Fork 0
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
View models: sequential processing, discovering (and fixing) "holes" in events #1
Comments
cqrs-eventdenormalizer and cqrs-saga both have a revisionGuard. |
The serialization (my first question) is a nice-to-have optional feature. Sometimes it can simplify the view model code quite a bit. What about the second question though, detecting holes within an aggregate, or unhandled events for not-yet-seen aggregates? |
There are multiple ways to detect holes within an event stream:
|
When I have a hole because I missed the "create" item, and "update" is received, the
Secondly, since network and processes can go down any time, I am really concerned that the read model can be missing something any time for random reasons, without me knowing about it. By the way, this is a nice property of a globally ordered event store. When the last (global) event in store is #12050 and a view model is at #12036, you know that you are missing something. And it's easy to query things without getting duplicates or missing anything, since relying on server-assigned |
Oh... there is an undocumented feature... |
I have some questions regarding the view model "side" of CQRS in your libraries. Let's use the sample app as an example.
I'm using the term "view model" here in the CQRS sense, but it may involve "denormalizer" and "view model" (and possibly even some other libs?) since I am not yet sure what their respective responsibilities and boundaries are.
Suppose the following commands are executed in the following order:
On the view model, do the libraries support globally sequential processing of these events, so that for example (3) is guaranteed to execute after (2)?
Let's say there has been a network partition or the view model has been down for a while. In the meanwhile, the following events have been written:
How can the view model detect this situation and catch up?
The text was updated successfully, but these errors were encountered: