A procedure registered with a ProcedureRegistry. The TCK
harness builds one per And there exists a procedure ... step by
collating the signature and the gherkin data table: each data row
contributes one entry to rows where the leading cells are the
input-column values (matched against call arguments) and the
trailing cells are the output-column values (projected by
YIELD).
Lookup table for registered procedures, keyed by fully qualified
name (test.my.proc). The executor consults this at run time;
callers (TCK harness, server startup) build an instance and pass
it to crate::execute_with_reader_and_procs. An empty registry
is the default, meaning no procedures are known and any CALL
raises ProcedureNotFound.
Adapter that lets a &dyn StorageEngine act as a GraphReader.
Needed because trait objects of unrelated traits don’t coerce —
see the note on the blanket impl<T: StorageEngine> GraphReader for T.
Wraps a trait-object reference; no heap allocation. Works for both
reads and writes via the sibling crate::writer::StorageWriterAdapter.
Declared argument / output type for a procedure signature.
Mirrors the openCypher type names the TCK uses (STRING?,
INTEGER?, FLOAT?, NUMBER?, BOOLEAN?, ANY?). Nullability
is not tracked separately — every TCK type in practice is nullable
(?) and the match logic treats nulls uniformly.
Read-side counterpart to crate::GraphWriter. Gives the executor a
uniform view of the graph regardless of whether the data behind it lives
entirely in a local storage engine (single-node or full-replica Raft
mode) or is sharded across cluster peers (routing mode, where a
partitioned reader fans out point reads to owners and scatter-gathers
bulk scans).
Sink for mutating graph operations produced by the executor. Isolates
write-side concerns from read-side traversal so we can plug in either a
direct-to-storage writer (single-node mode) or a Raft-backed writer that
proposes each mutation through consensus (cluster mode).
Execute a plan using the given store for both reads and writes.
Equivalent to execute_with_reader with the store acting as both
and an empty parameter map.
Run plan with a pre-materialised set of rows substituted
for the (single) LogicalPlan::CallSubqueryInTransactions
node in the tree. Used by
MeshService::execute_call_in_transactions to fold its
already-batched-and-committed body output back into the
regular pipeline so wrapping clauses (Project / OrderBy /
Limit / Aggregate / Filter) can run untouched.
Like execute_with_reader but with an explicit procedure
registry in scope. Used by the TCK harness to mount mock
procedures declared by there exists a procedure ... steps,
and reserved for the server startup path once built-in
procedures land.
Run plan once for a caller-supplied “outer” row that’s
folded into the operator pipeline as a seed. Used by
CALL { ... } IN TRANSACTIONS to evaluate the body once per
input row (with the row’s bindings visible inside the body)
while letting the caller batch writes across multiple
invocations into a shared BufferingGraphWriter.
Execute a plan against a local RocksDbStorageEngine for reads,
sending mutations to a separate GraphWriter. Used by in-process
setups where reads are always cheap-local (single node or
full-replica Raft). No parameters.
Execute a plan with an arbitrary GraphReader for reads and a
parameter map for $param resolution. Routing mode uses a
partitioned reader that fans out reads across peers; the Bolt
listener supplies the driver-bound param map.
Per-query parameter bindings, e.g. $name → "Ada". Built once per
execute_with_reader call and threaded through every eval_expr
invocation so Expr::Parameter(name) resolves to a concrete value.
One data-table row. Columns are keyed by declared column name
so the registry can look up either the input side (for arg
matching) or the output side (for YIELD projection) without
recomputing offsets.