You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
For storing non trivial aggregates many operations need to get performed.
Those should be performed using JDBC batch operations to minimise database roundtrips.
There will be issues for the different kind of operations:
Not all JDBC drivers return generated ids for batch operations.
Therefore we'll need a Dialect property describing if a dialect supports this.
If an id is to be generated by the database and the database does not support batch inserts with generated keys we need to fall back to sequential operations.
This builds on the verification of #1155
Note that this is about batching for a single aggregate, while #537 takes this concept across aggregates.
The text was updated successfully, but these errors were encountered:
Insert for entities of same type within an aggregate get inserted using JDBC batch operations when possible.
Inserts are supported when no id needs to be generated by the database or if the Dialect supports generation of ids in batch operations.
Closes#1159
Original pull request # 1191
For storing non trivial aggregates many operations need to get performed.
Those should be performed using JDBC batch operations to minimise database roundtrips.
There will be issues for the different kind of operations:
Not all JDBC drivers return generated ids for batch operations.
Therefore we'll need a
Dialect
property describing if a dialect supports this.If an id is to be generated by the database and the database does not support batch inserts with generated keys we need to fall back to sequential operations.
This builds on the verification of #1155
Note that this is about batching for a single aggregate, while #537 takes this concept across aggregates.
The text was updated successfully, but these errors were encountered: