jonnify·bcs /bcs/elixir-core/property-stores/key-order-is-time-order

B2.2.2 · dive 2 of 3 · module B2.2

Key order is time order.

Snowflakes are minted in time order and base62 preserves it, so the ordered_set is sorted by time for free. Latest-N, windows, and cursors are range operations on the key.

The key is time-sorted; latest-N is the tail; a window is a range between synthetic cursors. Select a part.
ts(41)node(10) seq(12)base62 keeps orderordered_set = time-sorted latest(n)last key, then walk back min_for(from)the rangemin_for(until)a window is a range on the key — no clock column
readout · Select a part. Mint-ordered snowflakes plus order-preserving base62 make the keyspace chronological; latest-N is the tail; a time window is a range built from min_for cursors.
§1

The idea

echo_data · timeline.ex, property_store.ex

Snowflakes are minted in time order, and base62 preserves that order byte for byte, so the ordered_set’s key order is chronological order — for free, with no clock column and no sort. EchoData.Timeline turns this into its whole API: latest-N, cursor pagination, and time-window counts are all range operations on the key.

Three reads fall out of one property. Latest-N walks back from the table’s last key; a window is an :ets.select over a half-open range of ids; and a time bound needs no stored id at all, because EchoData.Snowflake.min_for mints a synthetic cursor for any instant — everything since two o’clock becomes a key comparison. The branded id even doubles as the public pagination token: opaque-looking, URL-safe, and exact to resume from.

Codemojex reads its history this way. A room’s recent guesses are latest-N off the keyspace; a leaderboard over the last hour is a window between two synthetic cursors; a feed resumes from the last id the client saw. None of it stores a timestamp, because the id is the timestamp, and the keyspace is already sorted.

§4

The doors

the sibling courses
§2

References

sources · related

Sources

Related