pub struct Section {
pub kind: [u8; 8],
pub id: u64,
pub generation: u64,
pub extents: u32,
pub extent_page: u64,
pub extent_bytes: u32,
pub hash: u64,
pub flags: u32,
pub header_bytes: u32,
}Expand description
One entry in a table’s section table.
The payload is not here. This is the entry that says where the payload is, what it is, and whether it is still current, and it is all a reader needs to decide whether to read the payload at all.
Fields§
§kind: [u8; 8]Which kind of structure this is: one of KEY_MAP, FORWARD_LINK, ADJACENCY, or
something a later build wrote that this one carries through untouched.
id: u64Which structure of that kind. For a key map this identifies the column, for a forward link
the relationship. The format does not interpret it; rudb-graph assigns it.
generation: u64The table generation this section was built against.
A section whose stamp does not match the table’s is stale, and section 3.1 says stale means ignored rather than repaired. So this field is the whole of the maintenance story: there is no repair path in this crate because a mismatch here removes the section from consideration and the query runs the way it ran before the section existed.
extents: u32How many extents the payload is split into.
extent_page: u64Where the extent table starts.
extent_bytes: u32How many bytes the extent table takes.
hash: u64Checksum over the extent table, so a torn one is found before it is believed.
flags: u32Kind-specific flags. For a key map this carries which of the three forms was chosen, which is why a reader never has to guess a form.
header_bytes: u32Bytes of kind-specific header at the front of the first extent, or, when there are no
extents, what the structure would have cost. See Self::refused.
Implementations§
Source§impl Section
impl Section
Sourcepub fn known(&self) -> bool
pub fn known(&self) -> bool
Whether this build understands this section’s kind.
The five it knows are the three the graph document’s section 3.2 names and the two the statistics document’s sections 3.3 and 3.4 name. Everything else is a section a later build wrote, and the answer is to leave it alone: the entry is carried through a rewrite so that opening a file with an old build and closing it does not silently discard work, and the payload is never read.
Sourcepub fn among(&self, kinds: &[&[u8; 8]]) -> bool
pub fn among(&self, kinds: &[&[u8; 8]]) -> bool
Whether this section’s kind is one of these, which is how a budget finds what it owns.
Sourcepub fn current(&self, generation: u64) -> bool
pub fn current(&self, generation: u64) -> bool
Whether this section was built against this table generation.
Sourcepub fn usable(&self, generation: u64) -> bool
pub fn usable(&self, generation: u64) -> bool
Whether this section is one this build should read: a kind it knows, at the current generation.
Sourcepub fn refused(&self) -> Option<u64>
pub fn refused(&self) -> Option<u64>
What this structure would have cost, when the entry is a record of one that did not fit.
Section 3.7 asks for a relationship that did not fit the budget to be recorded with its size
rather than forgotten, so that raising graph_budget is a decision somebody can make from a
number. An entry with no extents is that record, and the number is in Self::header_bytes,
which has nothing else to mean when there is no first extent to have a header at the front
of. Self::flags keeps the meaning it has for a built section of the same kind, so a
record says which form the structure would have taken as well as what it would have cost.
None for a section that is in the file, which is the ordinary case and is the one where
the size is the payload’s own length.
A size past four gigabytes saturates, because the field is a u32. The largest structure
this project expects to refuse is a packed forward link over an SF100 lineitem, which is
about 2.1 GB, so the saturation is a bound rather than a rounding, and a saturated record
still says far more than the budget correctly.