Expand description
Every public entry point that mutates catalog or storage state runs inside a transaction obtained from
reifydb-transaction. Reading or writing a backend directly defeats MVCC, policy enforcement and CDC
capture, all of which assume the engine is the single mediator of those concerns.
Modules§
- bulk_
insert - Fast path for inserting many rows at once: validates the batch up front and writes through the storage commit path instead of the per-row VM dispatch loop. Validation here must match what the per-row INSERT path applies; any divergence lets one path accept rows the other rejects and silently produces inconsistent state.
- engine
- environment
- error
- partition
- policy
- Read policy is injected into the plan before execution; this module covers the cases injection cannot reach, where the engine has to actively gate the operation. Anything that mutates state or transitions a session goes through these enforce calls, and a “trusted” path that skips them runs no policy at all.
- remote
- run_
tests - Engine-side runner for CREATE TEST / RUN TESTS. Tests execute inside the same transaction as the admin command that launched them, so their side effects live and die with that outer transaction.
- session
- subscription
- transaction
- Wraps the typed catalog and storage operations the VM performs inside a transaction, so dispatch handlers call them by name instead of each wiring up the encoded-key plumbing itself.
- vm
- Virtual machine that executes the instruction stream emitted by the planner and owns the per-request lifecycle. The dispatch table here is the single place that decides what an opcode does; planner output never reaches storage without being interpreted through it.
- watermark