feat(spanner): single-RPC, batched commit of mutation groups #12930
Conversation
`spanner::Client::CommitAtLeastOnce(std::vector<Mutations>)` Add support for committing mutation groups, batched efficiently into transactions with at-least-once semantics, using a single RPC. All mutations within a group are committed atomically, but there is no atomicity or ordering between groups, so they must be independent of each other. Partial failure is possible. That is, some batches can commit while others fail. The results of individual batches are returned via the response stream as their transactions complete. Mutation groups are not replay protected. That is, it is possible that any mutation group may be applied more than once. They should be idempotent to avoid replay complications.
Codecov ReportAttention:
Additional details and impacted files@@ Coverage Diff @@
## main #12930 +/- ##
==========================================
- Coverage 93.62% 93.58% -0.04%
==========================================
Files 2067 2067
Lines 180220 180498 +278
==========================================
+ Hits 168726 168925 +199
- Misses 11494 11573 +79
☔ View full report in Codecov by Sentry. |
|
Here is the summary of changes. You are about to add 1 region tag.
This comment is generated by snippet-bot.
|
| @@ -307,13 +307,22 @@ StatusOr<CommitResult> Client::Commit(Transaction transaction, | |||
| StatusOr<CommitResult> Client::CommitAtLeastOnce( | |||
| Transaction::ReadWriteOptions transaction_options, Mutations mutations, | |||
| Options opts) { | |||
| // Note: This implementation differs from `CommitAtLeastOnce({mutations})` | |||
| // for historical reasons. | |||
There was a problem hiding this comment.
If you have a link explaining the differences that might be helpful. Leave it alone if it is just "path dependent"
There was a problem hiding this comment.
I know of no such explanation. Indeed, I'm only intimating that the existing CommitAtLeastOnce(mutations) and the new CommitAtLeastOnce({mutations}) must behave the same (modulo the former being able to return CommitStats) because anything else would be crazy. If they had thought of the new batching interface first, then I imagine the single-mutations call would never exist.
| @@ -634,6 +634,43 @@ class Client { | |||
| Transaction::ReadWriteOptions transaction_options, Mutations mutations, | |||
| Options opts = {}); | |||
|
|
|||
| /** | |||
| * Commits the mutation groups, batched efficiently into transactions with | |||
There was a problem hiding this comment.
Thanks for the clear documentation.
|
|
||
| /// If OK, the Cloud Spanner timestamp at which the transaction committed, | ||
| /// and otherwise the reason why the commit failed. | ||
| StatusOr<Timestamp> commit_timestamp; |
There was a problem hiding this comment.
Speaking to myself: I wonder if we really need a streaming API in the library. I know the proto is streaming, but maybe we can simply collect all the results and return all of them. Hmmm... there is the problem of blocking until they all arrive. Sold.
spanner::Client::CommitAtLeastOnce(std::vector<Mutations>)Add support for committing mutation groups, batched efficiently into transactions with at-least-once semantics, using a single RPC.
All mutations within a group are committed atomically, but there is no atomicity or ordering between groups, so they must be independent of each other.
Partial failure is possible. That is, some batches can commit while others fail. The results of individual batches are returned via the response stream as their transactions complete.
Mutation groups are not replay protected. That is, it is possible that any mutation group may be applied more than once. They should be idempotent to avoid replay complications.
This change is