Module views 

Materialized property views — incremental per-node derived properties.

Storage choice

View values are stored as regular entries in the ColumnStore under their view_prop name, updated in place on each triggering event.

Why ColumnStore in-place:

• Zero query-layer changes: every read path (scan, filter, project, group) already reads from ColumnStore — view props appear automatically.
• ColumnStore::set / remove handle cleanup; remove_all clears a deleted node’s view values as part of the normal tombstone sweep.
• Rebuild-on-open recomputes values from persisted graph state (topo + props) without touching the snapshot format.
• No virtual-column overlay, no side-table, no special query path.

Trade-off: view props appear in node_info() alongside real props. That is intentional — “they’re column values” per the brief.

MIN/MAX retraction cost

Retracting an edge whose endpoint held the current MIN or MAX requires rescanning all remaining neighbors (O(degree)) because there is no sorted structure tracking the second-best value. This is documented as the v1 cost; no auxiliary structures are maintained.

Subscriptions interplay (v1)

View-value updates do not emit subscription events. Only user-write WAL records and rule fire/retract deltas generate DbEvents. View maintenance writes to ColumnStore directly and is invisible to the subscription layer. This preserves T1’s pending_deltas discipline: the debug_assert!(pending_delta_count == 0) at log_then_apply_with entry remains green through view-heavy workloads because view updates bypass the engine’s delta path entirely.

Structs

ViewDef

ViewStore

Enums

AggFn

ViewSource

Functions

compute_view_value

Compute the view value for a single node. Returns None when there are no qualifying neighbors for Avg/Min/Max (no sensible neutral value).