1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
//! The property family's storage: the `:index` subtrees a `property`,
//! unique, node-type or `reference` index writes, the computation that
//! produces them, and a structural consistency check over the pair.
//!
//! `docs/analysis/index-property-storage.md` specifies all of it. The
//! module divides the way the specification does:
//!
//! * [`key_encoding`] — the exact derivation from a property's values to the
//! child names a `:index` subtree is keyed by;
//! * [`type_predicate`] — `declaringNodeTypes` resolved against
//! `/jcr:system/jcr:nodeTypes`;
//! * [`mirror`] — `:index/<key>/<path elements…>` with `match = true`, which
//! is also how the reference index stores under `:references` and
//! `:weakreferences`;
//! * [`unique`] — `:index/<key>` with an `entry` array of absolute paths;
//! * [`consistency`] — the two-halved check, with a budget for each half.
//!
//! **Which strategy applies to a definition follows from the definition, not
//! from what is on disk.** Oak decides it with one strict `BOOLEAN` read of
//! `unique`, in the editor, the lookup and the query planner alike, so a
//! `unique` stored as the `STRING` `"true"` is a *mirror* index to Oak. Every
//! reader here goes through the same field for the same reason: a reader that
//! guessed from the shape it found would disagree with Oak exactly on the
//! stores where the disagreement matters.
pub use ;
pub use keys_for_property;
pub use ;
pub use TypePredicate;
pub use ;