Tracks the follow-on phases for the built-in <DB> effect. #229 adds Phase 1; this issue collects the work deliberately left out of it.
Phase 1 (#229) covers positional Array<Option<String>> rows and parameters on SQLite (sqlite::memory: / sqlite:///path), with DB.query and DB.execute returning Result. It is intentionally minimal: every cell is an Option<String>, rows are addressed positionally, and SQLite is the only backend.
Phase 2 — named columns / typed rows
- Column access by name rather than by position (a
Row abstraction, or a Map-keyed result).
- Typed cell coercions (
Int, Float64, Bool) instead of stringly-typed Option<String> everywhere, with an explicit, checked conversion story that preserves DESIGN principle 2 (no implicit behaviour).
Phase 3 — connection & backend surface
- Additional backends behind
VERA_DB_URL (PostgreSQL, MySQL) through the host driver.
- Multiple / pooled connections (Phase 1 uses a single connection per program run).
- Transactions (
BEGIN / COMMIT / ROLLBACK) as first-class operations.
Related
Tracks the follow-on phases for the built-in
<DB>effect. #229 adds Phase 1; this issue collects the work deliberately left out of it.Phase 1 (#229) covers positional
Array<Option<String>>rows and parameters on SQLite (sqlite::memory:/sqlite:///path), withDB.queryandDB.executereturningResult. It is intentionally minimal: every cell is anOption<String>, rows are addressed positionally, and SQLite is the only backend.Phase 2 — named columns / typed rows
Rowabstraction, or aMap-keyed result).Int,Float64,Bool) instead of stringly-typedOption<String>everywhere, with an explicit, checked conversion story that preserves DESIGN principle 2 (no implicit behaviour).Phase 3 — connection & backend surface
VERA_DB_URL(PostgreSQL, MySQL) through the host driver.BEGIN/COMMIT/ROLLBACK) as first-class operations.Related
handle[DB]— user-defined handlers for mocking/replay — is tracked with the other host effects in Inference effect: user-defined handlers (handle[Inference]) #372.