-
Notifications
You must be signed in to change notification settings - Fork 360
GH-2064 BeforeConvertCallback should be applied after the RootAggrega… #2065
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
Conversation
…the RootAggregateChange creation Signed-off-by: mipo256 <[email protected]>
Thanks a lot for having a look and picking up on maintenance, this is really helpful. |
Signed-off-by: mipo256 <[email protected]> Commit message edited by Jens Schauder. Original pull request #2065 Closes #2064
Thanks for this. I had to apply some changes:
This is merged. |
Signed-off-by: mipo256 <[email protected]> Commit message edited by Jens Schauder. Original pull request #2065 Closes #2064
Signed-off-by: mipo256 <[email protected]> Commit message edited by Jens Schauder. Original pull request #2065 Closes #2064
Closes #2064
Hey @mp911de, @schauder.
After giving it a couple of tries, I've come up with this solution. The idea is to separate the
doInBatch
andsaveInBatch
. The reason is that indoInBatch
there is an implicit assumption, that theFunction
that accepts the entity to create anAggregateChange
will just create anAggregateChange
. But in case ofsaveAll
, there were a conditional logic also applied in theFunction
(like what change to create,UPDATE
orINSERT
).So, in case of any suggestions or question, feel free to reach out, thanks!