Struct RelationSet

Source

pub struct RelationSet { /* private fields */ }

Expand description

The configured set of relations for a workspace, and which one is spanning.

The spanning relation is the single-parent containment tree that gives the workspace its self-describing discovery spine. All other relations may be many-to-many overlays.

Implementations§

Source §

impl RelationSet

Source

pub fn new() -> Self

An empty relation set.

Source

pub fn with(self, relation: Relation) -> Self

Add a relation (builder-style).

Source

pub fn spanning(self, name: impl Into<String>) -> Self

Mark the named relation as the spanning (canonical tree) relation.

Source

pub fn registry(self, name: impl Into<String>) -> Self

Mark the named relation as the registry pointer: the root document links its ID registry through this relation, which is what makes the registry reachable — workspace-critical state discovered by following links from the root, like everything else, rather than hidden in an app-private sidecar folder.

Source

pub fn config(self, name: impl Into<String>) -> Self

Mark the named relation as the config pointer: the root document links its workspace-config document through this relation — the same reachability move as the registry (§6), so workspace policy (link_format, defaults, …) is a self-describing node discovered by following links from the root, never an app-private sidecar. The config document is optional and lazily created; its absence means all defaults.

Source

pub fn recycle(self, name: impl Into<String>) -> Self

Mark the named relation as the recycle-bin pointer: the root document links its recycle-bin index through this relation — the same reachability move as the registry and config (§6). A deleted document is not destroyed but moved into the bin, and the bin’s index (a self-describing member, discovered by following this link from the root) records where it came from so it can be restored. Making the bin reachable is what keeps it honest: check validates it like any other member, and nothing about a deletion is hidden in an app-private folder.

Source

pub fn history(self, name: impl Into<String>) -> Self

Mark the named relation as the history pointer: the root document links its history-store index through this relation — the same reachability move as the registry, config and recycle bin (§6). The store holds one immutable event document per capture plus a content-addressed blob store, so a bad sync merge can be rolled back file by file. Making it reachable is what lets check validate it like any other member, and what keeps prov’s own safety net out of an app-private folder.

Source

pub fn about(self, name: impl Into<String>) -> Self

Mark the named relation as the about pointer: the root document links its generated about.md through this relation — structurally the same one-way move as the registry, config, recycle bin and history (§6), but a distinct target kind (spec §4, generated prose), because the file is entirely prose in the workspace’s content format rather than a whole-file record store.

The pointer exists so prov can find the page to regenerate and validate it, and so the file is reachable rather than loose in the tree. It is deliberately not the human reader’s way in: a person opening the directory finds about.md by its name, needing no pointer, no parser and no convention beyond being able to read a text file. That is the whole point of the artifact, and why the default filename is load-bearing.

Source

pub fn diaryx() -> Self

The diaryx vocabulary: contents/part_of containment (spanning), links/link_of arbitrary cross-references, registry (the root’s pointer to its ID registry document), config (the root’s pointer to its workspace-config document), recycle_bin (the root’s pointer to its recycle-bin index), history (the root’s pointer to its history store), and about (the root’s pointer to its generated about.md).

Source

pub fn relations(&self) -> &[Relation]

The configured relations.

Source

pub fn style_for(&self, name: &str) -> Option<ReferenceStyle>

The per-relation reference style override for name, if that relation is configured and carries one. None means “inherit the workspace default” — the caller falls back to its own default style.

Source

pub fn with_styles(self, styles: &BTreeMap<String, ReferenceStyle>) -> Self

Overlay per-relation reference styles by name (builder-style) — the config-driven form of Relation::style. Each configured relation whose name appears in styles adopts that style; relations absent from the map keep whatever style they already carry (usually none → the workspace default). Names in styles with no matching relation are ignored. This is how a workspace’s vocabulary picks up the relations block of its config document (see prov’s WorkspaceConfig::resolved_relation_styles).

prov’s WorkspaceConfig::resolved_relation_styles: prov’s WorkspaceConfig::resolved_relation_styles

Source

pub fn spanning_relation(&self) -> Option<&str>

The name of the spanning relation, if one is configured.

Source

pub fn registry_relation(&self) -> Option<&str>

The name of the registry-pointer relation, if one is configured.

Source

pub fn config_relation(&self) -> Option<&str>

The name of the config-pointer relation, if one is configured.

Source

pub fn recycle_relation(&self) -> Option<&str>

The name of the recycle-bin-pointer relation, if one is configured.

Source

pub fn history_relation(&self) -> Option<&str>

The name of the history-pointer relation, if one is configured.

Source

pub fn about_relation(&self) -> Option<&str>

The name of the about-pointer relation, if one is configured.

Source

pub fn edges(&self, meta: &Value) -> Vec<Edge>

Extract every link declared by a document’s metadata, tagged by relation.

Source

pub fn children(&self, meta: &Value) -> Vec<String>

The raw targets of the spanning relation — i.e. this node’s children in the canonical tree. Empty if no spanning relation is configured or the field is absent.