Views
A view is derived state the engine maintains for you. You declare a pipeline over source data; ReifyDB builds a dataflow behind it and keeps the result materialized as the sources change. Reading a view is a lookup, never a recomputation. Two decisions define every view: when it is maintained (transactional or deferred) and where its rows live (table, ring buffer, or series).
Transactional views
A transactional view is maintained inside the writing transaction: when a commit returns, the view is already correct. create view and create transactional view are synonyms. Create the view before writing data, then run the snippets on this page in order:
Write to the source table - there is nothing to refresh and no second system to notify:
Rows enter and leave with FILTER
When a view's pipeline contains a filter, membership follows the predicate: a source row that matches appears in the view, and a row that stops matching disappears from it.
Deactivate Alice and she leaves the view - no application code deletes anything from it:
GATE: membership as an explicit signal
gate also controls membership with a boolean expression, but it models membership as explicit transitions: a row whose gate flips from false to true is recorded as entering the view, changes while true are updates, and a flip back to false is recorded as leaving. Use it when downstream consumers care about the transition itself, not just the current contents:
Bob's active flag is currently false. Flip it and he enters the gated view:
Deferred views
A deferred view is maintained asynchronously, driven by the change stream after each commit. Writes stay cheap; the view is eventually consistent and catches up moments later. Declare it with create deferred view:
By the time you read it, the deferred flow has processed the change log - here it counts all four orders written on this page, including those written before the view existed:
Choose transactional views for derived state that reads must never see stale - balances, inventory, anything an invariant depends on. Choose deferred views when a moment of lag is fine and write latency matters - dashboards, counters, feeds.
Backing storage: table, ring buffer, or series
By default a view materializes into table storage. Deferred views can instead materialize into a ring buffer - the derived rows themselves get "keep the last N" semantics:
Three rows flowed into a capacity-2 buffer; the oldest derived row was evicted:
A series-backed view records its output as a keyed, time-ordered history - derived data you can range-query like any other series:
Views compose
A view can source from another view, and a single write propagates through the whole chain within the same maintenance model:
Materialized sort order
A sort inside the view definition materializes the rows in that order, so readers get sorted results without sorting at query time: