-
Notifications
You must be signed in to change notification settings - Fork 369
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 <mikhailpolivakha@gmail.com>
Thanks a lot for having a look and picking up on maintenance, this is really helpful.
Thanks for this.
I had to apply some changes:
-
The integration tests for Sql Server and Oracle failed to errors in the SQL scripts. You can run all integration tests by running
./mvnw clean verify -Pall-dbs
. -
Formatting was a little off. Wildcard imports weren't applied as they should. You might want to check your setup.
This is merged.
Thanks again.
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!