- FK restrict: deleting a row a non-nullable `ref` still points at traps WO_T_FK (11), catchable. The compiler now records a `ref` field's target class in the class-table field_class metadata; the engine (wo_row_has_referrers) scans referencing scalar columns before a delete. Correctness-first full scan; the backlink-index optimization is recorded for later - docs/examples/employee now COMPILES AND RUNS all six modes against a WAL-durable database: seed (+@unique trap across restart), report (per-dept aggregates + payroll), staff (unique probe + backlink + ref nav), raise (update-through-row), drop (FK restrict), and persistence via replay - group-by SYNTAX parked to a future iteration (user decision): the report mode is hand-rolled from the shipped primitives meanwhile (same numbers). "table relations and FK" is complete - scripts/employee-accept.sh (8 checks) + a `just employee` module; manifest parser tolerates iteration 9c's [share]/[[share.clients]] sections so `woc .` builds the sample on this branch - fixtures trap/db-fk-restrict (code 11) + run/db-fk-restrict-catch; oop-e2e 79/0, woc-test 566/0, 15 runtime suites, log-watcher 7/0, employee-accept 8/0 - 9b story + status board updated Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|---|---|---|
| .. | ||
| target | ||
| justfile | ||
| main.wo | ||
| README.md | ||
| types.wo | ||
| wo.toml | ||
employee — the database track's acceptance workload
Status: target workload — does not compile on today's toolchain. This sample is written ahead of the features it exercises, exactly as log-watcher was written ahead of iterations 5–7: the sample is the test, and the plans compile toward it. It becomes buildable when iteration 9 (engine:
2026-08-01-db-engine-binding.md) and iteration 9b (query surface:2026-08-15-employee-relations-query.md) land. Normative semantics: the 9b spec.
Two @table classes and every 9b feature load-bearing:
| Mode | What it proves |
|---|---|
employee seed |
insert + WAL-before-ack; a second run catches the departments.name @unique trap (SEED-DUP, exit 3) |
employee report |
group … by … into g lowered as one hash pass; count/avg/min/max per department; order by avg(g.salary) desc; whole-query sum for payroll |
employee staff <dept> |
unique-name index probe (asserted via the engine's probe counter, not assumed), backlink scan one way, e.dept.name ref navigation the other |
employee raise <dept> <pct> |
update through a query result; a missing department takes the empty-query path |
employee drop <dept> |
delete restrict: a department with staff traps (exit 4); the trap code is the acceptance's assertion |
The engine lives in database/ (statically linked into wovm — still one
binary). Rows are RAM-authoritative, WAL-durable; a kill -9 between seed
and report followed by an identical report is part of the acceptance
script (iteration 9's replay, proven on this workload).
Data shape: Department { name @unique, staff: backlink Employee.dept },
Employee { name, salary (cents), hired (epoch ms), dept: ref Department },
indexes [name], [dept], [dept, salary]. Salaries wrap like all language
arithmetic; avg/min/max are ?Int because an empty group is data, not
a fault.