I made a very simple LSM and I will try it out later today with Bedrock. Is there any bedrock benchmark or end-to-end test where I can check that Bedrock is working correctly with my storage?
Asd
garrison
Looks very nice! You should make a thread for it. There are questions I would ask but I don’t want to clog up this thread 
0
jallum
Take a look at storage.ex for the basic interface (all read-only) that the transaction builder expects, and you’ll want to look at the existing storage implementations for how to manage log-pulling. Storage servers in Bedrock (like fdb) only process transactions that have already been version-stamped and conflict checked, so all you need to worry about is applying those transactions and serving versioned reads.
I checked out the lib, and it’s a great start! I love building this kind of stuff!
At the moment, I don’t have any official benchmarking tools. With things starting to stabilize in 0.3, that’d be a good area to look into (along with automatic sharding, watches, better/simpler cluster config, documentation, etc.)
0
garrison
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.)
0
jallum
Feedback! Yay! Working against this demo/tutorial uncovered a lot of problems, both big and small. Big thanks to @jstimps – his version for :erlfdb was the kick in the butt I needed.
This is a good point. Inside a transaction, there’s no real reason that it has to be passed around. It’s in the process dictionary… and that’s the way that transactions are automatically nested already… so I could easily remove the parameter from both the transaction function as well as the get, put, etc. functions. It’d certainly be less typing. I’ll give that a whirl and see what that looks/feels like.
Hahaha. Because I’ve been staring at it from 2" away, and it’s hard to see these things sometimes? get_range has a certain symmetry. That also sounds like a good tweak to make. Consider it done.
Yeah. I straight copied the notion in my drive to duplicate the demo. Now that it works, it’s time to step back and see if some of these ideas can be made more “elixir-ish” I was thinking of reworking Subspace as a protocol, defimpl’d for binary()… it maybe could use a better name.
Up to 0.3, I was trying to do this very thing with transactions… but I came to think that trying to divine the will of the caller by picking apart the result is just kind of dicey. I can think of all sorts of reasons for wanting to return an error without rolling back. (For example: say i want to try to do something… but fail, but I still want to record the attempt.) The demo shows a raise for "No remaining seats", but this could just as easily be a returned result.
Current behavior is to commit on any normal return without the result being interpreted in any way, and to only roll back on exception or explicit call to Repo.rollback(reason). My thinking here is that if the user wants to rollback, they should just do that. I think this make a lot of sense in context, because a rollback or a no-change commit literally costs nothing, whereas a normal db, resources are tied up by the transaction and network round-trips are required to tear that down.
Yes. This is already in place, for certain classes of “retryable” failures, notable examples being transient errors like: version_too_new or unavailable for reads and of course aborted (due to MVCC conflicts). There’s a scaled back-off (0, 2, 4, 8ms… up to 1s) with jitter. It was pretty much a requirement for the ‘concurrent’ portion of the notebook. It’s also how you can just “run” the notebook and the first get(tx, "hello") works without having to explicitly wait for the system to spin up.
0
garrison
Repo.transaction(fn ->
# ...
{:ok, {:error, "No remaining seats."}}
end)
Read as “transaction succeeded, return value is an error”. This is fine, I think.
This is how Ecto worked but we seem to have (mostly) reached community consensus that it was a mistake and that’s why there is a new Repo.transact() API. There are a couple of individuals on here that dissented, though, so maybe they’ll poke their heads in and disagree
The explicit rollback is essentially using try/catch error-based control flow instead of if/case/with pattern matching control flow. The problem is that in Elixir we generally strongly favor the latter and rarely use the former, so building such a fundamental API (Ecto or Bedrock) on top of errors feels wrong (if we had algebraic effects maybe this would be different). If you use error tuples everywhere you can just use a with pipeline, whereas the rollback-based control flow resulted in the rather byzantine Ecto.Multi situation. This article has a nice visual example.
0
dimitarvp
jallum
I suppose… if I squint a little. 
This is what you get when you use the old Repo.transaction with ecto and return an error… if you return {:error, "No remaining seats."} it wraps it with an {:ok, ...}. Repo.transact makes you do it yourself, in order to commit the transaction and return the error, just returning the error gets you a rollback.
…and how it still works with respect to rollback/1. From within a transact the returned value for Repo.rollback(:reason) is {:error, :reason}. The old transaction behaved the same way with respect to rollback/1, but annoyingly wrapped whatever you returned from your transaction function with an :ok tuple, so return your_result and you get {:ok, your_result}… (return :ok and you get {:ok, :ok}).
The fact that the new transact function just leaves your result alone is kind of a cause for joy, though it seems that there’s no (documented) way to just return :ok to commit without a whole tuple.
Ultimately, I don’t feel super strongly one way or the other and I’m going to lean heavily in the direction of established patterns. It’s really only a couple of lines of code to do things the way transact does. I’ll probably have I added a commit to this PR.
2
jstimps
This is a good point, but instead of removing the tx I do wonder how it would feel to lean in to it, and make the RYW tx immutable data. If it can be done with still an ergonomic API, you could get one of the benefits of nested transactions, the ability to abandon a subset of operations in the tx, without the IMO confusing semantics that would come from true nesting. The ergonomics might not be there though, since the get would have to return {value, tx} or similar. I could understand going either way. Immutability has served us well though.
I think it’s an important API concept to the end user; it leads them down the path of understanding the power of the ordered keyset. And each use of a subspace is equivalent to an index that doesn’t have to be written. Although, I admit I’ve only used FDB subspace in production code via the Directory layer.
In a new system like Bedrock, I agree that transact is the way. However, {:ok, {:error, _}} as an idiomatic pattern is not ideal.
For the record though, I went a different third way with EctoFDB, since :erlfdb already had an established pattern embracing throws. Instead of transaction or transact, the EctoFDB adapter creates a new Repo.transactional to match :erlfdb.transactional. I did this because I didn’t want EctoFDB to be subjected to the future deprecation and removal of Repo.transaction.
In practice, the transactional throws have served me quite well in production code. But perhaps this is my Judgement of Solomon moment 
.
1
jstimps
Cheers! Always happy to be involved in exciting projects!
Some minor feedback on the API. As a new user, I would be confused by using the Key module to encode a value. An excerpt from the tutorial:
key = Subspace.pack(course, class)
value = Key.pack(@total_seats_available)
Repo.put(tx, key, value)
0