Thoughts on the API after reading the (brand) new guide:
I don’t like the tx being passed into the transaction fn. The API is not pure (get() and put() do not return a new transaction) so it feels weird to me. This is especially apparent in the composition example, where the tx is ignored and the called functions then get their own tx (from where?). Why is the explicit tx needed at all if the API is clearly not pure anyway?
You have clear() and clear_range() and then get() and range(). Why not get_range()?
I’m not sure how I feel about Subspaces. I know this comes from the FDB API but it seems like they exist solely to pack a tuple with a prefix. What purpose does a Subspace serve that is not already served by an arbitrary prefix tuple? I might be wrong about this one; I’m curious what @jstimps thinks here.
I think Repo.transaction() should mirror the new Ecto Repo.transact() API where the anonymous function returns :ok/:error tuples to be used for commit/rollback (of course here a rollback is a noop). It composes better, no need to repeat past mistakes there.
Have you given any thought to automatic retries for errors (e.g. conflicts)? One footgun is that some errors may not be retryable (network timeouts and recoveries). FDB had some work on automatic idempotency which was quite interesting. I personally plan to implement idempotency so that I can check linearizability after faults. (See also Tigerbeetle’s end-to-end idempotency, which is clever.)
