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 codec;
23mod config;
24mod dir;
25mod errors;
26mod io;
27mod lock;
28mod lsn;
29mod record;
30mod recorder;
31mod replay;
32mod segment;
33#[cfg(test)]
34mod testing;
35mod wal;
36
37// ---- Operator-facing surface ----------------------------------------------
38//
39// Everything below is what callers (`lora-database`, the HTTP server,
40// admin paths, integration tests) need. Internal types — segment
41// framing constants, the segment reader/writer, record codec — stay
42// `pub(crate)`. Bumping that boundary later is opt-in and easy; the
43// reverse (un-publishing a previously-public type) breaks downstream
44// builds.
45
46pub use config::{SyncMode, WalConfig};
47pub use dir::SegmentId;
48pub use errors::WalError;
49pub use lsn::Lsn;
50pub use recorder::{
51 WalBufferedCommitError, WalCommitError, WalMirror, WalPoisonError, WalRecorder, WroteCommit,
52};
53pub use replay::{replay_dir, ReplayOutcome, TornTailInfo};
54pub use wal::Wal;