The read-only mount: a KvBackend and a RecordStore that answer every read and
refuse every write.
A base shared by N forks is only shared if nothing can write it, and the honest way to guarantee that is structurally rather than by review: an overlay composes over one of these, so a write path that forgot to divert fails loudly at the seam instead of silently mutating what every other fork is reading. That is invariant 1 of docs/overlay.md, held by construction.
Two calls are deliberately not refusals.
next-id on the frozen record store. It hands out a handle nobody holds and
touches no stored record, and it is what the overlay's id watermark is seeded from
(vaelii.impl.overlay.store) — the alternative, a max over the base's whole live-id
set, is O(base) at every mount. Two JVMs mounting one base each bump their own
in-RAM counter to the same value and then diverge into their own overlays, which is
exactly what independent forks are.kv-entries / sentex-ids and friends. Enumeration is a read.This is a decorator, not a file mode: it says nothing about how the underlying store was opened. Opening the base's files read-only at the OS level is the disk backend's business and orthogonal — this is what makes the composition safe whatever the base is (memory, disk, or a later SQL store).
The read-only mount: a `KvBackend` and a `RecordStore` that answer every read and **refuse every write**. A base shared by N forks is only shared if nothing can write it, and the honest way to guarantee that is structurally rather than by review: an overlay composes over one of these, so a write path that forgot to divert fails loudly at the seam instead of silently mutating what every other fork is reading. That is invariant 1 of docs/overlay.md, held by construction. Two calls are deliberately *not* refusals. * `next-id` on the frozen record store. It hands out a handle nobody holds and touches no stored record, and it is what the overlay's id watermark is seeded from (`vaelii.impl.overlay.store`) — the alternative, a `max` over the base's whole live-id set, is O(base) at every mount. Two JVMs mounting one base each bump their own in-RAM counter to the same value and then diverge into their own overlays, which is exactly what independent forks are. * `kv-entries` / `sentex-ids` and friends. Enumeration is a read. This is a decorator, not a file mode: it says nothing about how the underlying store was opened. Opening the base's files read-only at the OS level is the disk backend's business and orthogonal — this is what makes the *composition* safe whatever the base is (memory, disk, or a later SQL store).
(frozen-kv base)base as a read-only KvBackend.
`base` as a read-only `KvBackend`.
(frozen-records base)base as a read-only RecordStore.
`base` as a read-only `RecordStore`.
cljdoc builds & hosts documentation for Clojure/Script libraries
| Ctrl+k | Jump to recent docs |
| ← | Move to previous article |
| → | Move to next article |
| Ctrl+/ | Jump to the search field |