lora_wal/lib.rs
1//! Write-ahead log for LoraDB.
2//!
3//! `lora-wal` is the additive durability layer that sits between
4//! [`lora_store::MutationEvent`] producers (the in-memory engine) and a
5//! durable byte stream on disk. It is deliberately separate from
6//! `lora-store`:
7//!
8//! - `lora-store` stays storage-only — backends do not learn about logs,
9//! segments, or fsync. The mutation surface they already expose
10//! (`MutationEvent` + `MutationRecorder`) is the only seam.
11//! - `lora-wal` owns segment files, framing, replay, and truncation.
12//! Consumers depending on the no-WAL story (wasm, embedded read-only)
13//! can avoid this crate entirely.
14//! - `lora-database` glues the two together: it installs a [`WalRecorder`]
15//! onto the store and brackets each query with `arm` / `commit` /
16//! `abort` markers so replay sees query-atomic units even though the
17//! recorder fires per primitive mutation.
18//!
19//! See `docs/decisions/0004-wal.md` for the full design and
20//! `docs/operations/wal.md` for operator-facing semantics.
21
22mod config;
23mod dir;
24mod error;
25mod lock;
26mod lsn;
27mod record;
28mod recorder_adapter;
29mod replay;
30mod segment;
31#[cfg(test)]
32mod testing;
33mod wal;
34
35// ---- Operator-facing surface ----------------------------------------------
36//
37// Everything below is what callers (`lora-database`, the HTTP server,
38// admin paths, integration tests) need. Internal types — segment
39// framing constants, the segment reader/writer, record codec — stay
40// `pub(crate)`. Bumping that boundary later is opt-in and easy; the
41// reverse (un-publishing a previously-public type) breaks downstream
42// builds.
43
44pub use config::{SyncMode, WalConfig};
45pub use dir::SegmentId;
46pub use error::WalError;
47pub use lsn::Lsn;
48pub use recorder_adapter::{WalMirror, WalRecorder, WroteCommit};
49pub use replay::{replay_dir, ReplayOutcome, TornTailInfo};
50pub use wal::Wal;