shoney.arickathil
1749440351
- 9b spec gains section 6 "Ownership, borrows, and GC across the engine boundary": two one-way copy gates (no VM pointer enters a row, everything a select returns is copied out), so the collector never traces engine memory and the engine never touches refcounts - row views are borrows WITHOUT a runtime net: rows share the VM's field encoding but not its header, so no borrow word backs them -- the compile-time escape rule is load-bearing alone - cursor stability settled: scans materialize their id list before the body, row updates through the view stay legal (raise mode updates an indexed column mid-scan and is the proving fixture), insert/delete on a table with an open cursor is a new WO-E5xx - GC-pause interaction recorded: collector runs between statements, a long scan delays slices -- accepted, documented - iteration-7b ordering constraint: GC inference must classify before table-field validation, diagnostic names the inference reason -- noted in 7b story, iteration-9 plan constraints, 9b plan tasks - stories 09/09b Info sections point at the analysis; 9b plan Tasks 3/5 carry the enforceable checkboxes (ASan boundary assertion) Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2.9 KiB
2.9 KiB
Iteration 9 — database engine
Format:
product/story-iteration-template. Part of Story — one language, one runtime, one database, one binary.
Goals
- The language's oldest promise executes on the new runtime: every class is
a table.
insertandselectstop trapping (DB_STUBretires) and run against class-shaped row storage inside the VM's shards. - Data survives anything: a typed write-ahead log with ack-after-fsync, parallel boot replay, and a crash battery proving no committed row is ever lost and no half-applied transaction ever visible.
Acceptance Criteria
- What to achieve?
- Given a class annotated
@tableand a method inserting rows, - when the method runs,
- then the insert is WAL-logged before acknowledgment, visible to
subsequent
select, and the pricing fixture that previously trappedDB_STUBnow passes with real data.
- Given a class annotated
- What to achieve?
- Given kill -9 at arbitrary points during committed writes,
- when the process reboots and replays,
- then every acknowledged commit is present, no unacknowledged partial write is visible, and replay across shards completes without manual steps.
- What to achieve?
- Given a
@uniquefield and a duplicate insert, - when it executes,
- then the insert traps with the unique-violation code and secondary indexes remain consistent (maintained only through the engine's row choke points).
- Given a
Out Of Scope
- Cypher/document query paradigms and
LIVEsubscriptions (the query layer's later phases;prototypes/wo-dbstays the reference). - Cross-shard 2PC transactions; Postgres mirroring (exists on the Rust side; ports after parity).
Info
- Doctrine: RAM is authoritative; the WAL makes it durable; indexes drift unless writes go through the row API — the Rust runtime learned this lesson, the C engine enforces it.
- The wo-db overlap manifest keeps the C++ prototype and this engine answer-compatible where features overlap.
- Ownership/GC analysis (2026-08-15): the engine and the VM heap are two
memory worlds crossed only by copy — rows store no VM pointers, GC-managed
values in stored fields are a compile error, and everything a query returns
is copied out — so the collector never traces rows and the engine never
counts references. The full analysis (row views as borrows without a
runtime net, cursor stability, GC-pause interaction) lives in the 9b
design's section 6:
2026-08-15-table-relations-query-design.md.
Proposed Solution
- Execute the existing plan:
docs/superpowers/plans/2026-08-01-db-engine-binding.md(class-shaped row slabs with a choke-point row API, typed WAL + parallel replay + crash battery, insert execution, doctrine-enforced indexes +@uniquetrap, select subset, db corpus).