What should be done about non-atomicity of Table.counter_set()

[dhermes]

See #1541 for discussion.

There is a note from the HappyBase source code

Note that application code should never store a incremented or decremented counter value directly; use the atomic Table.counter_inc and Table.counter_dec methods for that.

and we just went one step further and just made Table.counter_set() a not implemented method (it raises NotImplementedError when called).

[tseaver]

Similar to #1524?

[dhermes]

Nope. This is an issue of a single request not being transactional while that one is the issue of having to send N + 1 requests at once to match an HBase / Thrift feature.

[tseaver]

@dhermes Could we map happybase.table.Table.counter_set onto a CheckAndMutateRow request, where the predicate checked that there was no value alraeady set? We would leave false_mutations empty in that case.

[dhermes]

We should verify that that would actually be atomic though. I'd guess the "check" and "mutate" don't actually happen atomically (would be a high cost to pay for every CheckAndMutateRow made).

[tseaver]

The docs for the Bigtable data interface say:

rpc CheckAndMutateRow(CheckAndMutateRowRequest) returns (CheckAndMutateRowResponse)

Mutates a row atomically based on the output of a predicate Reader filter.

[dhermes]

@tseaver It could mean that the set of mutations are either all applied or none, not implying anything about the atomicity of the "check and mutate" as a single operation.

@mbrukman @tswast can you weigh in?

[mbrukman]

It's unclear to me how Table.counter_set() would map to a CheckAndMutate—it only accepts a row, column, and value, but not the previous value, so there's nothing to check against, unless I'm missing something. What would we check against as the previous value?

The use case that it presumably addresses is to enable a user to reset a counter to 0, or initialize the state from some non-zero value if they're migrating data from elsewhere and want to start from a known state, rather than increment their way up to it.

[tseaver]

From #1989 just now: @garye wrote:

It seems like a CheckAndMutateRow with a pass_all filter (more explicit than leaving it unset) and a single mutation setting the value would do the trick. The check and mutate steps happen in a transaction so the semantics of counter_set should hold.

[garye]

I took it back over on #1989, see if you think that makes sense.