Crate prov_store 

prov-store

The write surface over a prov workspace: the half of each storage port that changes something.

What this crate is for

prov_graph is the read core — it declares ReadStorage and IdIndex, and every traversal in it is generic over exactly those two. This crate declares their other halves — Storage and IndexStore — plus the metadata editor that rewrites a document’s frontmatter in place.

The two live in separate crates so that the read core’s guarantee is structural rather than editorial. A consumer that must not modify a workspace — a language server, a static renderer, a browser viewer — depends on prov-graph alone and cannot write, because the vocabulary for writing is not in its dependency graph at all. Not a feature flag it might have left on, not a convention review has to police: the functions do not exist.

The shape of it

• fs — Storage, the write half of the filesystem port, and the durability vocabulary a backend answers with (Capabilities, Durability, SyncGuarantee). Also InMemoryFs, a writable in-process backend for tests and sandboxes.
• edit — format-preserving, comment-preserving edits to a document’s embedded metadata, whatever carries it.
• index — IndexStore, the Rebase seam a pending change set answers through, and the two concrete registries (InMemoryIndex and the registry-document-backed FileIndex).

The crash-atomic staging that drives these — the change set and its write-ahead journal — is fs-transaction, a layer down: it knows nothing about documents, so it is a dependency of this crate rather than a consumer of it. fs re-exports its port.

Re-exports

pub use edit::MetaEditor;

pub use index::FileIndex;

pub use index::InMemoryIndex;

pub use index::IndexStore;

pub use index::Rebase;

Modules

edit

Format-preserving edits to a document’s metadata, whatever carries it.

fs

The write half of prov’s filesystem port.

index

The write half of the ID index.

Structs

Capabilities

The durability guarantees a Storage backend can make — declared by the backend through Storage::capabilities, honored by the crash-safety machinery in ChangeSet.

InMemoryFs

An in-memory, clone-shared Storage backend.

Enums

Durability

What a caller needs from one Storage::sync call — the weakest guarantee that is still correct at that point, so that a backend able to serve it cheaply is free to.

SyncGuarantee

How strong a backend’s Storage::sync actually is — the standing answer to a Durability request, declared once in Capabilities rather than discovered per call.

Traits

Storage

An async filesystem backend a transaction can drive — ReadStorage plus everything that changes bytes on disk.