> > Badger provides multi-key transactions, so any high level logic may use it. > > Already doing that.
It requires you expose your own transactions that use Badger's one. > It will be sick if you build non-transactional storage on top of > transactional. > It is transactional. If transactions are serializable, then one may safely read value and write > derived value in the same transaction without fear to loose consistency. > And Badger pretends to implement serializable transactions. > If you use CAS across several transactions (ie read value in one > transaction, and save derived value in other), then it is just syntax sugar > over read+check+write in "write" transaction. > It is indeed some sugar to do things the CouchDB way (similar to) - not just any design. Still I do not understand how transactions can help with optimistic concurrency. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
