Expand description
Index — where stable IDs and (later) the materialized graph live.
An index fuses two natures (DESIGN §5): the authoritative id↔path registry — not rebuildable from the documents — and (to come) the derived resolution cache and adjacency index, which are. Keeping it behind a trait is deliberate: a sidecar file, an in-memory map, or a sync-backed store are all valid homes.
Only the query half is here — IdIndex, the lookups link resolution
needs. Everything that changes a registration (IndexStore, the
Rebase seam, the in-memory and registry-document stores) is
prov-store’s index module, for the same reason the write half of
fs is: a read-only consumer must not merely decline to write,
it must have nothing to write with.
§Tombstones — IDs are forever
DESIGN’s open question #1 (“does the registry ever need to survive without
its documents?”) is answered yes, minimally: deleting a document leaves
a tombstone — the ID stops resolving but is never forgotten, so it can
never be reminted to mean something else. A dangling prov: reference
then stays diagnosable (validation can say “that document was deleted”)
instead of becoming a silent re-resolution hazard. is_known is the
question that tells the two apart.
Structs§
- NoIndex
- No index — identity-off workspaces. Registers nothing, resolves nothing.
Enums§
- Collision
- A registration that would displace one the index already holds.
Traits§
- IdIndex
- The query half of an ID index: the three lookups link resolution needs, and no way to change what is stored.