Allow materialized views to select a named source database #7

New issue

Open

opened 2026-09-02 17:27:30 +00:00 by nsaspy · 0 comments

nsaspy commented

2026-09-02 17:27:30 +00:00

Owner

Problem

Tek9 materialized views can be stored/read through the public view API, but apply-view-to-database and apply-view currently read only the primary database (+main-name+). database-view has no generic source-database field.

Hackmode issue lost-rob0t/hackmode#15 needs ingest/by-state over its durable outbox records, which live in the named Tek9 database outbox. Implementing that view today would require moving canonical data, duplicating it, or reaching around Tek9 internals. None are acceptable.

Desired generic behavior

Let a materialized view declare the Tek9 source database it maps over while preserving the current primary database as the default for backward compatibility.

API naming is not prescribed. A shape such as new-view ... :source-database-name "outbox" is sufficient if it remains storage-agnostic and the public view read API is unchanged.

Constraints

no Hackmode-specific view names or outbox semantics in Tek9;
keep view/<name> as the durable materialized representation unless Tek9 itself requires a generic change;
existing callers that omit the source database continue mapping the primary database;
rebuild and incremental application must use the same declared source;
no raw LMDB dependency should leak to consumers.

RED-first acceptance

define a named source database separate from the primary DB;
put fixtures only in that named source;
define a view selecting that source;
full rebuild materializes exactly those rows;
incremental update from that source yields the same rows;
rows remain readable through exported view-get / view-rows / map-view APIs;
primary-database view behavior remains unchanged;
an unknown source database fails explicitly rather than silently reading the primary DB.

Downstream

Unblocks the ingest/by-state portion of lost-rob0t/hackmode#15. Hackmode will continue to own the actual investigation-view semantics.

## Problem Tek9 materialized views can be stored/read through the public view API, but `apply-view-to-database` and `apply-view` currently read only the primary database (`+main-name+`). `database-view` has no generic source-database field. Hackmode issue lost-rob0t/hackmode#15 needs `ingest/by-state` over its durable outbox records, which live in the named Tek9 database `outbox`. Implementing that view today would require moving canonical data, duplicating it, or reaching around Tek9 internals. None are acceptable. ## Desired generic behavior Let a materialized view declare the Tek9 source database it maps over while preserving the current primary database as the default for backward compatibility. API naming is not prescribed. A shape such as `new-view ... :source-database-name "outbox"` is sufficient if it remains storage-agnostic and the public view read API is unchanged. ## Constraints - no Hackmode-specific view names or outbox semantics in Tek9; - keep `view/<name>` as the durable materialized representation unless Tek9 itself requires a generic change; - existing callers that omit the source database continue mapping the primary database; - rebuild and incremental application must use the same declared source; - no raw LMDB dependency should leak to consumers. ## RED-first acceptance - define a named source database separate from the primary DB; - put fixtures only in that named source; - define a view selecting that source; - full rebuild materializes exactly those rows; - incremental update from that source yields the same rows; - rows remain readable through exported `view-get` / `view-rows` / `map-view` APIs; - primary-database view behavior remains unchanged; - an unknown source database fails explicitly rather than silently reading the primary DB. ## Downstream Unblocks the `ingest/by-state` portion of lost-rob0t/hackmode#15. Hackmode will continue to own the actual investigation-view semantics.

nsaspy referenced this issue from a pull request that will close it,

2026-09-04 22:28:14 +00:00

Nix: expose Tek9 as a consumable ASDF package #15

nsaspy referenced this issue from a pull request that will close it,

2026-09-04 22:28:14 +00:00

Nix: expose Tek9 as a consumable ASDF package #16