4ec780c87a
Being able to derive partition map from partition definitions and current state of the world (transactions), segmented by timelines, is useful because it lets us not worry about keeping materialized partition maps up-to-date - since there's no need for materialized partition maps at that point. This comes in very handy when we start moving chunks of transactions off of our mainline. Alternative to this work would look like materializing partition maps per timeline, growing support for incremental "backwards update" of the materialized maps, etc. Our core partitions are defined in 'known_parts' table during bootstrap, and what used to be 'parts' table is a generated view that operates over transactions to figure out partition index. 'parts' is defined for the main timeline. Querying parts for other timelines or for particular timeline+tx combinations will look similar. |
||
|---|---|---|
| .. | ||
| src | ||
| tests | ||
| Cargo.toml | ||
| README.md | ||
This sub-crate implements the SQLite database layer: installing, managing, and migrating forward the SQL schema underlying the datom store.