3 ms·
Has the lack of interactive transactions and only supporting entirely deterministic transactions been a big issue for your customers? My understanding is you'r
by ryanworl 8y ago
Has the lack of interactive transactions and only supporting entirely deterministic transactions been a big issue for your customers?
My understanding is you're essentially shipping a "stored procedure" to the database where every input and condition is known up-front.
It seems like a reasonable trade-off for lowering the latency of WAN transactions, but it might make application development more complicated.
- evanweaver 8y agoNo, it hasn't. It is possible to layer an optimistic concurrency model for session transactions on top of our protocol, but the database standard library is sufficiently full-feature that it's easy to express most application logic as a pure function over the current state of the database. Most read/modify/write cycles end up being essentially that, but with the added confusion of local application threading and standard library. We eliminate that, but preserve the general ability to express a complex query in application code (which also increases application concurrency since the database executes transactions with maximum parallelism.) Transactions do not have to be pre-registered as stored procedures.
- jchrisa 8y agoThis FaunaDB ledger tutorial gives a feel for how you'd build out your application logic: https://fauna.com/blog/tutorial-how-to-create-and-query-a-ledger-with-faunadb https://fauna.com/blog/tutorial-how-to-create-and-query-a-le... If you want to see a query with precondition checks etc, the code at the end of this post is another example: https://fauna.com/blog/distributed-ledger-without-the-blockchain https://fauna.com/blog/distributed-ledger-without-the-blockc...