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