> - The meaning and implementation of CAS at document level (and a transaction > involving multiple documents) might greatly differ from that of at a simple > key level and
Badger provides multi-key transactions, so any high level logic may use it. > - It requires to expose badger transactions (*Txn) objects to the end user - > nullifying the whole point of having document level utilities. 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. > And as noted before, transactions alone can not provide CAS capabilities. 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. -- 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.
