Cloud Bigtable docs on Single-row Transactions says:
Cloud Bigtable also supports some write operations that would require a transaction in other databases:
Read-modify-write operations, including increments and appends. A read-modify-write operation reads an existing value; increments or appends to the existing value; and writes the updated value to the table.
Check-and-mutate operations, also known as conditional mutations or conditional writes. In a check-and-mutate operation, Cloud Bigtable checks a row to see if it meets a specified condition. If the condition is met, Cloud Bigtable writes new values to the row.
So, if I understand correctly, if I use "Read-modify-write" or "Check-and-mutate" operations, enabling single-row transactions is required.
Those operations are API methods like CheckAndMutateRow, right? So what if a program uses that method and single-row transactions is not enabled? Will the app fail? Am on the right direction?
My goal is to understand how, when and where (in an app) the single-row transaction setting on the app profile is being utilized.
Thanks!
Gabriel
You should enable single-row transactions only if you make calls to CheckAndMutateRow or ReadModifyWriteRow from your app, as those calls will fail without the setting enabled. I would even go so far as to disable them if you don't use them, as it will reduce the number of warnings you see when using replication.
Note as Jeff pointed out in his comment that these are enabled by default, in particular if your instance was created with a single cluster. That's simply to avoid breakage of legacy clients, as this distinction didn't matter prior to the launch of replication.
For a little more color as to why this setting exists, see the section here on conflicts between single-row transactions when using replication.