writeonce/docs/examples/employee-list/README.md
shoney.arickathil 746dc2b42b docs(databasev2): third track — the database beyond RAM, with per-table storage modes
- docs/stories/databasev2/, numbered from 1. Six PENDING database iterations
  moved from the language track and renumbered, keeping the old id in
  `was_language_iteration:` so a search for "iteration 32" still finds it:
  32 -> 3 WAL checkpoint, 23 -> 4 io_uring commit, 33 -> 7 single-file store,
  27 -> 8 query grammar, 20 -> 9 cross-program, 21 -> 10 keypair auth.
  Done work (9, 9b, 22) stays as v1 history; language 18 left whole
- the problem, read off the engine not guessed: rows are malloc'd slabs with
  addresses stable forever, NO eviction/spill/paging anywhere in database/src,
  the WAL never checkpoints so boot replays all history, and durability is one
  process-global WO_DATA so no table can say it matters more than another.
  An allocation failure IS a clean catchable WO_T_OOM — but swap thrash
  arrives first and carries no error signal at all, which is the real hazard
- four new iterations:
  1 measure the ceiling FIRST (curve not cliff; the three exits; kill -9 at
    exhaustion) — every later default should follow from a number
  2 `@table(mode: ram | durable | cold)` — the grammar ask. Small surface
    (Ast.table_cfg gains a key, the parser already rejects unknown args), big
    semantics: `durable` defaults so nothing changes silently, and the
    compiler refuses a durable row holding a `ref` into a ram table
  5 bounded tables + refuse/evict/back-pressure, shedding BEFORE the OS acts
  6 cold tiering — mostly forks, incl. whether the language surfaces the
    fault cost and whether @unique on cold is refused outright. A paged
    B-tree stays rejected: if tiering needs one, reject tiering
- 39 links repointed, link TEXT renumbered to track-local ids; arc gains one
  pointer row replacing the six moved; board + board-views cover three tracks
- linkcheck 0 broken / 0 anchors; no code blocks in any story

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-26 20:52:48 +02:00

42 lines
2.3 KiB
Markdown

# employee-list — program B: attach, authenticate, read
> **Status: target workload — does not compile on today's toolchain.**
> Written ahead of iterations
> [9 (cross-program tables)](../../stories/databasev2/09-cross-program-tables.md)
> and [10 (keypair attach auth)](../../stories/databasev2/10-keypair-attach-auth.md),
> the way every acceptance sample here precedes its features. It also leans
> on 9/9b (the [employee sample](../employee/) it attaches to must run
> first).
Two programs, one database, one writer:
```
employee (A) employee-list (B)
owns WO_DATA + WAL no database of its own
[share] listen = unix:...sock [connect.employee] ipc = unix:...sock
[[share.clients]] public_key = <A's fingerprint, pinned>
public_key = <B's fingerprint> project = ../employee (shapes)
rights = "read"
▲ │
└── every statement executes here ◄───┘ (typed, over the wire)
```
The manifests are the design: **A grants, B pins.** A's `[share]` names B's
public-key fingerprint with rights (`read` here); B's `[connect.employee]`
names A's IPC string AND A's fingerprint, so neither side talks to an
impostor. Fingerprints are printed by each program's `--identity` after
first boot (keys are generated into `WO_DATA`, never written into a toml)
and pasted — the `PASTE-…-HERE` placeholders mark exactly where. The
connect-section name is the code's namespace: `[connect.employee]` is why
the source says `employee.Employee`.
| Mode | What it proves |
| --- | --- |
| `employee-list list` | typed reads over the wire, `e.dept.name` ref navigation executing inside A |
| `employee-list report` | **byte-identical output to A's own `report`** — attach + GroupBy compose, the wire changes nothing |
| `employee-list staff <dept>` | unique-name index probe + `staff` backlink scan, both in A |
| `employee-list probe-write` | the rights matrix: registered read-only, so the insert traps with access-denied (caught, `DENIED …`, exit 4) and A's row count is unchanged |
The 21 acceptance drives the rest from the outside: wrong key, no key,
same-uid-wrong-key, impostor socket, handshake replay, key rotation — see
the iteration's criteria; this sample is the workload they run against.