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.
