Soil: the journal, and what makes it a WAL

Soil: the journal, and what makes it a WAL The transactions post left this one dangling: "Every new or changed object, every index update, and the new database version becomes an entry in a journal - an in-memory list first, not yet on disk [...] The journal is central enough to deserve a full post of its own later." This is that post. From transaction to journal entries The thing a transaction as

What's hitting my static blog, and where it's coming from

What's hitting my static blog, and where it's coming from Anyone running a publicly reachable webserver gets visitors fast. Not necessarily human ones. This blog is produced by a static site generator and served by nginx: a handful of HTML files, some CSS, a few images, nothing else. No WordPress, no PHP, no CMS, no application behind the webserver at all - there's no login form to brute-force, no

Soil: knowing what changed

Soil: knowing what changed The transactions post left this on the table with a one-line mention: "'Dirty' itself comes from one of two tracking strategies - either you mark an object dirty yourself, or, as of the current version, Soil detects changes on its own by hashing an object's content and noticing when that hash no longer matches." That's the whole subject of this post: what those two strat

ESUG 2026 in Plovdiv, Bulgaria

ESUG 2026 in Plovdiv, Bulgaria Plovdiv was a very pleasant visit. Living in Cologne, I'm fairly used to having a lot of history around - a bit over 2,000 years of it. Plovdiv is a whole level more extreme: 8,000 years of continuous settlement, and with a location like that, centuries of shifting rule and changing hands to match. A guided city tour walked us through a good chunk of that: Thracian r

Soil: catching write conflicts, optimistically

Soil: catching write conflicts, optimistically Every transaction in Soil gets to act as if it has the whole database to itself - read whatever it wants, take its time deciding what to change, and work all of that out without ever announcing itself to anyone else running at the same time. That's a comfortable illusion right up until two transactions both decide to change the same thing. Something h

Soil: MVCC and snapshot isolation

Soil: MVCC and snapshot isolation The last post walked through what a commit actually does: serialize outside any lock, then take one global lock just long enough to bump the database version, check for conflicts, write the journal, and apply it. Only one writer gets to be in that critical section at a time - the same trade-off SQLite makes. Readers, though, were said to bypass that lock entirely

OpenAPI, brought up to spec

OpenAPI, brought up to spec The last post told JSONSchema's origin story: it exists because ApptiveGrid needed OpenAPI, and OpenAPI needs a way to describe request and response bodies. OpenAPI is the other half of that story - a Pharo implementation of the OpenAPI 3 specification, three packages deep: OpenAPI-Core models a document as an object tree and can validate a whole document against the sp

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

JSONSchema, picked back up

JSONSchema, picked back up JSONSchema didn't start as its own thing. It exists because ApptiveGrid needed OpenAPI, and OpenAPI needs a way to describe request and response bodies - which means it needs JSON Schema. Building a JSON Schema engine in Pharo was table stakes for having a documented API at all, so that's what got built: a small, generic core, cleanly separate from ApptiveGrid itself, pl