Replies: 1 comment
-
txn = op.begin().await?;
txn.write("k1", "v1").await?;
txn.write("k2", "v2").await?;
let v3 = txn.write("k2", "v2").await?;
txn.commit().await?; It seems interesting, but I'm a bit worried about how it can be extended to other services. Maybe we can expose a So we will have:
Services that doesn't support transaction could simply return |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
I'm looking into unifying databases we currently work with (SledDb and TiKV), we depend on writing and reading several times from one transaction scope.
Sled exposes a method:
While
TiKV
has a more fine grained object:What would be the best way to handle Operators that can conditionally declare "start a transaction" and "commit transaction",
should the
Builder
trait be implemented on the closure and struct referenced above? if an operator could spawn a transaction object itself would be great:similar to this TiKV snippet:
Beta Was this translation helpful? Give feedback.
All reactions