pub struct PreparedCommand {
pub commit_index: u64,
pub writes: BTreeSet<Vec<u8>>,
pub reads: DependencySet,
pub sequenced: bool,
}Expand description
Prepared metadata for one admitted command. The publisher keeps this alongside expanded operations so an admission overlay can validate read/write conflicts without re-expanding the command.
Fields§
§commit_index: u64Reserved commit index, preserving command-log order.
writes: BTreeSet<Vec<u8>>Canonical keys written by the expanded operation set.
reads: DependencySetKeys/ranges read while preparing the command.
sequenced: boolExpanded under writer admission against the sequencer overlay, so its reads already observed every lower-index commit (published or pending). Such a command can share a publish group with the commits it read from: the group applies in commit-index order.
Implementations§
Source§impl PreparedCommand
impl PreparedCommand
Sourcepub fn from_ops(commit_index: u64, ops: &[Op]) -> Self
pub fn from_ops(commit_index: u64, ops: &[Op]) -> Self
Build prepared metadata from an expanded operation set.
Sourcepub fn conflicts_with(&self, other: &Self) -> bool
pub fn conflicts_with(&self, other: &Self) -> bool
Whether this command’s reads overlap writes from other, or vice
versa. The check is symmetric and suitable for optimistic admission.
The write-write check (large-transaction support, Part F) uses
writes being a BTreeSet directly — other.writes.contains(key)
is O(log n), not the nested linear scan this used to be. Filtering
only self’s side is still exactly equivalent to filtering both:
is_coordination_write is a pure function of the key’s own bytes, so
if key already passed the filter, an identical byte sequence in
other.writes has the same classification — there is no case where
filtering the other side too would change the answer.
Read sets are probed against the ordered write set — one range query per recorded read — rather than testing every written key against a linear list of read ranges. The old form was O(writes × reads) per pair and, applied pairwise inside every publish group, starved bulk ingest for minutes (cloud-capacity F4 follow-up).