Spring data cloud spanner: add configuration to favour mutations or dml statements
Is your feature request related to a problem? Please describe.
Like stated in the spanner documenation (https://cloud.google.com/spanner/docs/dml-versus-mutations), it should avoided to uses mutations and dml statements in the same transaction. There is some behavior in Spring Data Cloud Spanner that
mutations are executed using dml statements by default
most of the times a transaction is created for the dml statement execution that causes nested transactions when a transaction content is open that is quite common because reads and updates should be executed in the same transaction to ensure data integrity
Describe the solution you'd like
From an application development, if there is no explicit need to execute a dml statement to make use of the benefits of dml statements vs mutations, it should be easy to use mutations if possible.
Because I can imagine that applications were already but around, and applications already use dml statements and mutations, maybe without even knowing, I want to request a configuration property, to control the default behavior of the execution of UPDATE, INSERT and DELETE queries.
Describe alternatives you've considered
Alternatives we are using right now is, to add custom methods to the Repository interface using the @Query annotation and set the dmlStatement to false.
Additional context
DML statements and mutations are 2 different APIs. By default, to reduce risk that comes with mixing mutation/query API. Also, engineers should be able to use the dml API if needed, but this is another API/Option they can slowly adopt. By executing dml statements although it's not explicitly visible, there are confusions about the execution path, nested transactions (transaction handling).
Spring data cloud spanner: add configuration to favour mutations or dml statements
Is your feature request related to a problem? Please describe.
Like stated in the spanner documenation (https://cloud.google.com/spanner/docs/dml-versus-mutations), it should avoided to uses mutations and dml statements in the same transaction. There is some behavior in Spring Data Cloud Spanner that
Describe the solution you'd like From an application development, if there is no explicit need to execute a dml statement to make use of the benefits of dml statements vs mutations, it should be easy to use mutations if possible.
Because I can imagine that applications were already but around, and applications already use dml statements and mutations, maybe without even knowing, I want to request a configuration property, to control the default behavior of the execution of UPDATE, INSERT and DELETE queries.
suggestion:
Describe alternatives you've considered Alternatives we are using right now is, to add custom methods to the Repository interface using the
@Query
annotation and set the dmlStatement to false.Additional context DML statements and mutations are 2 different APIs. By default, to reduce risk that comes with mixing mutation/query API. Also, engineers should be able to use the dml API if needed, but this is another API/Option they can slowly adopt. By executing dml statements although it's not explicitly visible, there are confusions about the execution path, nested transactions (transaction handling).