pub struct Minter {
clock_id: u64,
last: Mutex<u64>,
}Expand description
Mints TIDs that sort in the order they were minted.
A TID as atproto specifies it: microseconds since the Unix epoch in the
low 53 bits above a 10-bit clock identifier, with the top bit clear,
rendered in BASE32_SORTABLE. Two properties matter. It is timestamped,
so a TID says when it was minted without a second field beside it; and it
is sortable as a string, so newest-first is a reverse iteration of an
ordered map rather than a sort.
One minter serves a store’s record keys and its commit revisions together. They are separate sequences to a reader and the same sequence here, which costs nothing — a revision is not required to be dense — and buys the one property both need: that nothing this store hands out ever repeats or sorts backwards, whatever the clock does.
Fields§
§clock_id: u64§last: Mutex<u64>Implementations§
Source§impl Minter
impl Minter
Sourcepub fn new() -> Self
pub fn new() -> Self
A minter with a fixed clock identifier.
The clock id is derived from the process start rather than randomly, because this store is per-process and never merges with another: its only job is to keep two processes writing the same logical repository from colliding, which cannot happen to an in-memory store anyway.
Sourcepub fn next(&self) -> String
pub fn next(&self) -> String
The next TID, strictly greater than every one this minter has returned.
The clock is only read, never trusted for ordering. Two writes inside one microsecond, or a clock that steps backwards, would otherwise produce a key that sorts before an earlier record and silently reorder a listing.
Sourcepub fn observe(&self, minted: &str)
pub fn observe(&self, minted: &str)
Notes a TID somebody else minted, so this minter never repeats it.
A restart replays keys a previous process wrote, and the clock is the
only thing that would otherwise keep the new process past them. That
is enough while the clock moves forward and is exactly the assumption
Minter::next already refuses to make, so replay states it here
instead: a key that sorted after everything when it was written must
still sort after everything when the log is read back.