Yeah. That’s been pinching me, too. It’s awkward… but the system already has a Tuple module as part of the runtime, so there’s some name clash at least. It’s not a difficult thing to move or rename… but a good module name… anyone got ideas?
It will happily pack binary() | number() | list() | tuple()
I’m not mad at it… there’s a ton of internal task management that would somehow need to be dealt with… I wouldn’t be able to do anything with timers… right now I can expect to have handlers on the process loop for things like that, but if we went pure functions, that wouldn’t be an option. Hrm…
I just sketched transact semantics out over here. I reworked the tutorials, too, on that branch to give an idea of what it’d look like. I’m not opposed to the idea of letting anything but an {:error, reason} commit… which would give you a little more flexibility to use other result shapes. As it was, in my sketch, I couldn’t resist allowing plain :ok
…and here’s what it would look like if everything were implicit, like ecto:
defmodule Scheduling do
@total_seats_available 100
def signup(attends, course, student, class) do
Repo.transact(fn ->
rec = Subspace.pack(attends, {student, class})
case Repo.get(rec) do
nil ->
# Not signed up yet, proceed with signup
class_key = Subspace.pack(course, class)
seats_data = Repo.get(class_key)
seats_left = Key.unpack(seats_data)
if seats_left == 0 do
{:error, "No remaining seats"}
else
# Decrement seats and record signup
Repo.put(class_key, Key.pack(seats_left - 1))
Repo.put(rec, <<>>)
end
_existing ->
# Already signed up
:ok
end
end)
end
def drop(attends, course, student, class) do
Repo.transact(fn ->
rec = Subspace.pack(attends, {student, class})
case Repo.get(rec) do
nil ->
# Not taking this class
:ok
_existing ->
# Increment seats and remove signup
class_key = Subspace.pack(course, class)
seats_data = Repo.get(class_key)
seats_left = Key.unpack(seats_data)
Repo.put(class_key, Key.pack(seats_left + 1))
Repo.clear(rec)
end
end)
end
def available_classes(course) do
course_range = Subspace.range(course)
Repo.transact(fn ->
classes = Repo.get_range(course_range)
|> Stream.map(fn {packed_class, packed_seats} ->
class = Subspace.unpack(course, packed_class)
availability = Key.unpack(packed_seats)
{class, availability}
end)
|> Stream.filter(fn {_class, availability} -> availability > 0 end)
|> Stream.map(fn {class, _availability} -> class end)
|> Enum.to_list()
{:ok, classes}
end)
end
def init(scheduling, course, class_names) do
scheduling_range = scheduling |> Directory.get_subspace() |> Subspace.range()
Repo.transact(fn ->
# Clear the directory
Repo.clear_range(scheduling_range)
# Add all classes
for class_name <- class_names do
add_class(course, class_name)
end
:ok
end)
end
def add_class(course, class) do
Repo.transact(fn ->
key = Subspace.pack(course, class)
value = Key.pack(@total_seats_available)
Repo.put(key, value)
end)
end
end
…and…
def switch(attends, course, student, old_class, new_class) do
Repo.transact(fn ->
with :ok <- signup(attends, course, student, new_class),
:ok <- drop(attends, course, student, old_class) do
{:ok, :switched}
end
end)
end
…other than the Key.pack for values naming pinchpoint that @jstimps called out, that’s all of of the feedback integrated. If any of the implicit functions are used outside of a transact, they’ll raise.
FINALLY. Now I understand one of the benefits of the new thing. Thanks! 
Finally an actual objective observable tidbit.
It’s not beautiful, no.
I’m beginning to wonder if the underlying problem here is the concept of rolling back. What do we actually use rollbacks for? I suppose they are inherently kinda exception-coded.
Maybe this is a bit avant-garde but I’m wondering if maybe it’s better to think in terms of retries rather than rollbacks. I.e. the same argument as “let it heal” over “let it crash”. Ecto has rollbacks (crashes) but it doesn’t have retries (supervisors).
I have begun to doubt my own argument in favor of transact() here I think. Gonna have to spend more time on this one.
I have been doing exactly this for my internal transaction API for a while now and I don’t really like it. The problem is that it’s way too easy to accidentally “lose” the transaction struct (even on reads) and violate consistency guarantees.
Fundamentally interacting with the DB is a side-effect and trying to pretend that it’s not seems to make things dangerous. A pure transaction API allows you to observe the side-effect of reading the data while forgetting to write down that you’ve read it.
I feel like I’m walking on eggshells using it and I wrote the entire database. Given that, there is no way I’m exposing it to anyone else.
It’s funny because this is one of very few cases I’ve ever come across where a pure-functional API is less safe than one which mutates global state. Another one is Plug’s get_csrf_token().
Hah, I ran into this exact problem and after much consternation landed on Encoding.Keyset. I did consider both Tuple and Key and didn’t like either for the same reasons. I’m still not sure the compromise is any better though (perhaps I am Solomon).
The real problem is that for the value encodings I desperately want to use Record…
Yes, this convinced me. I can see why the immutable approach isn’t right here. The get is not a get, it’s a get+add_read_conflict. However this is an implementation detail, so in a pure API it becomes a leaky abstraction. Very weird! Thanks for the insight!
19 files changed +2160 -616 lines changed
Average commit above. I think that average is about 2k lines of code change a day. Too bad they didn’t invent vibe reading, cause I definitely can’t keep up with this to read and understand all the changes 
*It’s made with Autism, so you know it’s good.
Seriously, though. I love to talk about this stuff, and I’m more than happy to info dump about any aspect of the code, how it works, why I made a particular choice, etc.
FoundationDB’s design is wonderful, but they’re horrible at explaining how their own system works – and my docs aren’t that much better, yet. There’s a lot to take in… and a lot of interesting ideas in this space… so, ask on this thread, start another one, the elixir slack, dm, whatever.
Every time I’ve had a conversation about this beast, I’ve come away with new ideas, better perspectives and things I’ve learned from the person I’m talking to. There are a lot of smart people here that think differently than I do, and it’s fun and interesting to see this project from their point of view. So, if you have a question, don’t hold on to it!
Hey folks 
Quick update on Bedrock! Just released v0.3.0-rc4 with some major API improvements based on community feedback.
What changed:
The transaction API got much cleaner. Instead of threading a transaction handle everywhere:
# Before - explicit transaction threading
transaction(fn tx ->
put(tx, "user:123", user_data)
get(tx, "config:app")
end)
# After - implicit context + Ecto-style returns
{:ok, config} = transact(fn ->
put("user:123", user_data)
config = get("config:app")
{:ok, config}
end)
Subspaces are no more! The new Keyspace system replaces the old Subspace concept and features built-in encoding support:
# Works great with the directory layer
{:ok, app_dir} = Directory.create_or_open(["app"])
users = Keyspace.partition(app_dir, "users", key_encoding: Tuple, value_encoding: BERT)
# Familiar things are still here
alice_key = users |> Keyspace.pack({"alice", 42}) # still makes keys, but you get more control over *how*
# gets / puts / etc. use the Keyspace as context for understanding how to encode and decode your data
%{name: "John", age: 23} = Repo.get(users, 42)
:ok = Repo.put(users, 42, %{name: "John", age: 23})
# Range operations will decode and values for you, too, if you want:
Repo.get_range(users) |> Enum.to_list()
[
{42, %{name: "John", age: 23}}
{63, %{name: "Jane", age: 25}}
]
Also simplified conflict management, improved error handling, and streamlined the range operations.
These changes make Bedrock much more ergonomic for daily use while keeping all the other goodness intact. The API now feels more “Elixir-native” rather than being a direct port of FoundationDB patterns.
The encoding system is particularly nice - you can plug in custom serialization for keys/values while the keyspace handles encoding automatically. Great for when you want structured data but it gets out of your way if want to manage binary keys and values directly. It’s made the class scheduling example very succinct.
This version focuses on the concrete improvements users will see, shows before/after code examples, and explains why the changes matter for real applications. The suggestions here have been phenomenal, and I’ve tried my best to integrate them all.
Always interested in more feedback, especially if you’ve worked with FoundationDB or other distributed stores!
