Soil: transactions and how a commit happens

Soil: transactions and how a commit happens The last post gave every object a stable id and a way to find its current bytes through the index. That's enough to read and write single objects. What's still missing is the thing that makes a database out of that: a way to change several objects at once and have it count as one atomic step. That's a transaction, and this post is about what one actually

Soil v5 released

Soil v5 released I announced this release at ESUG 2026 in Plovdiv, but only now found the time to actually write it up. Soil v5 is out. Quick side note on what that even means: Soil doesn't do releases as git tags or semantic versioning. We never found MAJOR.MINOR.PATCH to be as clear as it pretends to be, so instead there's just a branch per version - v1, v2, v3, and so on - each one a moving poi

Soil: identity and the heap

Soil: identity and the heap The last post ended with two loose ends. A reference from one cluster to another is stored as an "id", but I never said what an id is. And I kept talking about clusters "on disk" without saying where on disk, or how you get from an id to the actual bytes. Both ends meet in the same place, so let's tie them off together. Why a reference can't just be a position The tempt

Soil: serializing a graph

Soil: serializing a graph In the last post we turned a single object into a self-describing stream of bytes and read it back. That was the easy half. Real objects don't live alone. They point at other objects, those point at more, and before long you have a graph. Sometimes that graph shares a node from two places, and sometimes it points back at itself in a cycle. This post is about writing such

Soil: turning an object into bytes

Soil: turning an object into bytes A few years ago I wrote two posts about building an object database from scratch, BYOB - build your own (data)base and BYOB - object serialization, and then went quiet and just built the thing. Soil is real now: a file-based, transactional object database for Pharo, running in production. I want to go through its architecture properly this time, from the beginnin

BYOB - object serialization

BYOB - object serialiazion In the initial post I described the motivation behind developing a new OO database from scratch in pharo. At the end of that post I've sketched a possible API for Soil. Let's pick that and see how we can make it happen. I copied the snippet over here: "create a new database path and initialize its content" soil := Soil new path: 'soil'; initializeFilesystem. "create a

BYOB - build your own (data)base

BYOB - build your own (data)base Persistency is not simple. We can make programs that create data structures and operate on it rather easy. But persisting the same thing is not easy. If the data structure you are dealing with is not super simple, persisting gets complicated really quick. Why is that? Why do we even need to persist data? At one time in history storage technology divided itself into