Snapshots

A snapshot pins a point-in-time view of the whole database, and reads select it through ustore_snapshot_view, so a read can name a transaction or a snapshot but never both:

ustore_snapshot_t snapshot = NULL;
ustore_snapshot_init(&(ustore_snapshot_init_t){
    .snapshot = &snapshot,
    .database = database,
    .outcome = &outcome,
});

ustore_blobs_read(&(ustore_blobs_read_t){
    .database = database, .outcome = &outcome, .view = ustore_snapshot_view(snapshot), /* ... */});

ustore_snapshot_free(snapshot);

ustore_snapshot_init can export its read_stamp, the stamp the snapshot reads at, which LevelDB, keeping its sequence numbers private, reports as zero. A snapshot lives no longer than the process that took it, and holds its database open until freed, as a transaction does, so ustore_database_free closes the database only once the last of them is freed. ustore_snapshot_save writes one out as a new database of the same engine, holding exactly the collections and names the snapshot records, which that engine’s open then serves, so a save is how a view outlives the process. RocksDB and LevelDB create its path, the ram engine writes its image into the directory path names, and NVMe takes path as the manifest of the new database. Persistent snapshots, recorded in a system collection under UUIDv7 identifiers and kept across restarts until dropped, are planned.