Module plan

Module plan 

Source
Expand description

The view, as a dataflow plan rather than as one expression.

docs/05-tier-lowering.md §5.3:

a thousand connected users of todos.map(filter_by(session.user)) must compile to one shared dataflow whose final per-session operators (filter, project, diff) run per subscriber

and docs/03-type-and-effect-system.md §3.8:

remaining updates by ±1 per event, never by recount.

crate::split produces a Core function of the accumulator — full recompute per event, which Phase 1 called “semantically final, later made incremental”. crate::incremental answers which vertices a plan could maintain. This module is the plan itself: the same view, decomposed into operators that a delta can flow through, with crate::engine as the thing that flows them.

§What an operator is

Two kinds, and the distinction is the whole design:

Everything the decomposition cannot see through becomes one pointwise operator over the plan nodes it reads: a match, an if, a call through a value, a primitive with no delta rule. The fallback is the reason the engine can be correct for programs it cannot accelerate, and Node::because records which construct forced it so beck explain incremental can say so.

§Where the keys come from

An arrangement is a BTreeMap from an ordering key to a value, and the key is what makes the output’s order a consequence of the plan rather than of a sort at the end. Iteration order reaches the rendered page and the replay digest (crate::pmap), so an incremental view that produced the right entries in a different order would be a correctness bug, not a cosmetic one.

operatorkey
map_values(m)the map’s key — so the arrangement is already in the order map_values yields
map_list, filter_listthe input’s key, unchanged: neither moves an element
sort_by(xs, k)k(x) followed by the input’s key — a stable sort, expressed as an order
concat_lists([a, b])the input’s position, followed by that input’s key
flatten, flat_mapthe input’s key, followed by the position inside that element’s list
jointhe left input’s key — a lookup answers one left row, so nothing of the right’s is needed to separate two
arrange_by(xs, k)k(x) followed by the input’s key — sort_by’s arrangement, probed by prefix instead of iterated
group_bythe group’s key alone — one entry per group, so the collection’s order never reaches it
semi_join, anti_jointhe input’s key, unchanged: the index decides which rows survive, never where they sit

§What this is not

It is not a query plan. §4.2 keeps the Query sub-language symbolic and nothing compiles one; this compiles the signal graph, which is a different thing that happens to share the word. beck explain query prints this, and crate::fuse rewrites it.

Structs§

Fun
A function an operator applies per element, closed over the plan nodes it reads.
Node
Plan
The view as a dataflow.

Enums§

Agg
Which aggregate a Op::GroupBy maintains.
Matching
What one probe of a join’s right side returns.
Op
What one operator does.
Presence
Which side of an index’s answer a Op::Restrict keeps.
Relate
Whether the decomposition may read a loop as a join.

Constants§

OPERATORS
Every operator the engine implements, by name.

Functions§

cost_report
beck explain cost — what one event costs this view.
query_report
beck explain query — the view as a dataflow plan, operator by operator.
query_report_of
The same report over a plan whose root is not a page.

Type Aliases§

OpId