std::db, and a driver that checks the SQL while the program is builtOpen and answer this issue on GitHub.
libraries, note · opened 2026-09-30 · updated 2026-10-06 · 0 comments
Owner’s order: first of the five big pieces, since every later demo stores something in it. Records: ADR-143 (all of it) and ADR-254 (where the connection goes). Nothing built.
The compiler knows no SQL: a dialect is a grammar in a driver package. A grammar declares a result column with meta::column(name, type), the third and last intrinsic of the hybrid binding, and the compiler derives the statement’s row type from the columns as it derives the parameter type from the holes. A dsl block takes build-time arguments, named, no ; (dsl sqlite(schema: app) { … } eod), resolved from comptime values, and the driver’s grammar reads the schema with its own DDL grammar and refuses a missing column at the query. std::db is the protocol only (traits, statement, row values); sqlite and the rest are packages. No expression capture, no ORM; raw(text) for dynamic SQL. The connection is the statement’s subject and is typed by its schema (ADR-254): by_age.execute(db; min_age: 18), and a connection of another schema is refused at the call.
What was blocking is gone: running a grammar while the program is built is built (ADR-177), and the shape this needs, a flat list of declared columns and parameters, is one of the five that cross. What is left is the driver’s own work.
Order of work is in the sub-issues (ADR-143 §5). examples/fortunes.nika waits on this and on the HTTP handler work.
Open question: how a schema is bound while the program is built (let app = comptime asset(…) vs comptime APP: db::Schema = asset(…)) is on docs/open-decisions.md, recommendation (1), the item form.