Aggregator Versioning
Aggregator versioning is the most important thing in StackSaga. All the applications are being updated with new features time to time. Any kind of changes that you make regarding the entire transaction, it caused for a version update of the particular aggregator.
Why it’s necessary to update the aggregator version?
You already know that Stacksaga does support event sourcing and event retrying to overcome the eventual consistency. To identify the event’s version is most important when the event is retried. Because all the time the aggregator state that comes to the executor is not equal to the current version of the aggregator. Therefore, You should know sometimes what is the aggregator version that transaction has been initialized.
For instance, just imagine that a transaction is initiated with aggregator version 1.0.0 and the transaction is failed while executing due to a network issue. Then the transaction is temporally stopped for a while until the scheduler is triggered. just think a new version will be
What is the event’s version?
The first event of the aggregator is saved with the version of the aggregator when the transaction is initialized. It is called as event’s version. That means what was the aggregator version that was when the transaction is initialized.
For instance, let’s have a look at the placing order example.
The aggregator version can be updated due to two main reasons. Changing the aggregator structure, Changing the executor structure
Not only the aggregators, even if you make some changes in one of the executors, It also causes a version update. Because every change you make related to the aggregator, it will change the aggregator state. If the aggregator-state is changed, the version must be updated.
As an example, if you have PlaceOrderAggregator, the following changes can be caused to a version update.
When the aggregator version should be updated
Aggregator Structure Changing
If the aggregator’s data set is changed, the aggregator version should be updated.
| Changing the Structure is the reason for the event-casting. |
Adding new data to the aggregator
If some new data is added to the aggregator object, the aggregator version should be updated. Changing the structure of the aggregator by adding new data is the reason for event-upcasting
Removing existing data from the aggregator
If some existing data is removed from the aggregator object, the aggregator version should be updated. Changing the structure of the aggregator by removing the existing data is the reason for event-down-casting
Executor Changing
Without changing the aggregator structure, if it makes some changes related to the executors, at this time also the aggregator version should be updated. It can be happened both changing the count of executors or changing something in existing executor(s).
|
It is possible to update an existing query-executor to command-executor.
But it is not possible to update command-executor to query-executor. Even it is possible to update query-executor to command-executor, The StackSaga team does not recommend changing the existing executor type. |
Changing something inside the existing executor
If you make some changes inside the existing executor, It also can be a cause for a version update. It depends based on your requirement. If the new update should not be impacted on the old events that are remains to be executed, you have to change the aggregator version. Then you can filter the old event from the new events. If the changes that you made are for all events, there is a possibility to ignore the updating.
The following diagram shows some change has been done inside the command-executor 3 than the old one.
Changing Executors count
If the executor count is changed for an aggregator, it should be a cause for an aggregator version update.
Adding new executor(s)
If some new executor(s) are added to the entire transaction, it should be a cause for an aggregator version update. It can be any executor either command-executor or query-executor or any sub-executor.
The following diagram shows that a new command-executor has been added called command-executor-4.
Removing existing executor(s)
If some executor is removed from the entire transaction flow, it should be a cause for an aggregator version update. Even though it can be done theoretically, there is something important that you should know when removing existing executor(s).
| Removing existing executor is one of the most important. Because it should be done carefully. The reason is that all the executors are exposed to event-retrying. If there are some old events related to the executor that you are going to remove, the old events can not be run without that executor. Therefore, it is recommended to keep the executor as it is even though if it’s not used for the new version. |
The following diagram shows that the executor called revert-before-executor-2.1 has been removed which was in the old version.
