pub enum Update {
Hydrated {
tx_id: TxId,
changes: Vec<ChangeEvent>,
},
Changed {
tx_id: TxId,
changes: Vec<ChangeEvent>,
},
PartitionHydrated {
tx_id: TxId,
binding: Binding,
changes: Vec<ChangeEvent>,
},
}Expand description
A query baseline or incremental changes. A Hydrated contains the full result
as Add events and replaces any previous baseline. Changed contains deltas to
apply in order. Delivery depends on the runtime:
Dbcalls subscribers withChangedafter the SQL commit.Clustercan emit several provisionalChangedslices for one transaction, before commit. Stage them until the hosting worker’sClusterEvent::Progressed.
Hydrated can fire AGAIN after a delta-overflow shed (design 306 D4): a
transaction whose folded rows outgrow the derivation memory budget still
commits, but it cannot be derived incrementally — the engine rebuilds and every
query re-hydrates from the committed state. A re-delivered Hydrated REPLACES the
subscriber’s entire view state (drop what you hold, apply the Adds); it is the
single-thread Db’s analogue of the cluster’s Faulted → re-register →
re-hydrate cycle, folded into the existing subscription.
Variants§
Hydrated
Changed
PartitionHydrated
One partition of a parameterized query family hydrated (design 310 §5.2 / impl
plan D8): the initial Add set for binding, tagged with the committed watermark
it reflects — emitted once per bound partition (at family registration, and again
for every later bind) in place of the singleton’s Hydrated. A family’s later
Changed events carry every partition’s deltas together; the consumer demuxes
them by the root row’s partition key (the drain does this for the daemon).