Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

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

See original GitHub issue

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).

Issue Analytics

State:
Created 8 years ago
Comments:9 (9 by maintainers)

Top GitHub Comments

1reaction

tseavercommented, Jul 19, 2016

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.

0reactions

garyecommented, Jul 19, 2016

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