meerkat_sqlite/lib.rs
1//! Shared SQLite mechanics for Meerkat stores.
2//!
3//! This crate is the single home for the connection policy, schema-evolution,
4//! and maintenance-fence machinery that was previously copy-pasted across the
5//! store crates (six independently authored PRAGMA setups with divergent busy
6//! timeouts, `CREATE TABLE IF NOT EXISTS` everywhere, and no version ledger).
7//! See `docs/plans/storage-unification-plan.md` (Phase 3) in the workspace
8//! root for the design rationale.
9//!
10//! What lives here:
11//!
12//! - [`profile`]: DDL-free connection opening under named policy profiles
13//! ([`ConnectionProfile::Primary`], [`ConnectionProfile::ReadOnly`],
14//! [`ConnectionProfile::Maintenance`]). Opening a connection never runs
15//! schema DDL; stores apply their [`ledger`] domain after opening. The
16//! optional [`OpenOptions::schema_preflight`] refuses a future file before
17//! any mutating pragma, and [`WriteContact`] types each profile's honest
18//! no-write guarantee (WAL reads may need sidecar files).
19//! - [`ledger`]: the per-file migration ledger (`meerkat_schema(domain,
20//! version)`) with the pinned concurrent-open transaction protocol and the
21//! typed [`SqliteStoreError::SchemaFromTheFuture`] refusal. Ledger state
22//! that is malformed (wrong shape, duplicate rows, non-positive versions)
23//! is refused typed, never healed.
24//! - [`json_column`]: the TEXT-or-BLOB tolerant JSON column codec.
25//! - [`fence`]: the per-operation maintenance-fence guards. Store operations
26//! take a shared guard; offline migration takes the exclusive side and
27//! waits for in-flight operations to drain. Stores built on this crate hold
28//! no bespoke opener, which is what makes them fence-aware for free.
29//! - [`error`]: the crate error type plus the storage-level error
30//! classification (transient / corrupt) that store crates layer their
31//! staleness semantics on top of. Adoption contract: store crates route
32//! every raw rusqlite error through [`classify_sqlite_error`] instead of
33//! re-matching SQLite error codes locally.
34//!
35//! # Retryability
36//!
37//! Error classification alone does not authorize a retry: a transient failure
38//! can land after a write committed but before success became observable, and
39//! blind retry duplicates non-idempotent effects. Automatic retry is only
40//! sound for idempotent or CAS-keyed operations; an indeterminate
41//! non-idempotent write requires outcome reconciliation (read back, then
42//! decide) before any retry. Bounded waiting for lock contention is the
43//! connection busy handler's job, not a caller retry loop.
44
45pub mod error;
46pub mod fence;
47pub mod json_column;
48pub mod ledger;
49pub mod profile;
50
51pub use error::{SqliteErrorClass, SqliteStoreError, classify_sqlite_error, is_busy_or_locked};
52pub use fence::{ExclusiveFence, OperationGuard, fence_lock_path};
53pub use json_column::JsonColumnBytes;
54pub use ledger::{
55 LedgerReport, Migration, SchemaDomain, apply_domain_migrations, domain_version,
56 refuse_future_schema,
57};
58pub use profile::{
59 ConnectionProfile, OpenOptions, SHARED_BUSY_TIMEOUT, WriteContact, begin_immediate, open,
60 open_with,
61};