1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
//! SQLite storage adapters for codlet (RFC-011).
//!
//! `SqliteStore` wraps a [`sqlx::SqlitePool`] and implements all three
//! core store traits plus the admin extension:
//!
//! - [`codlet_core::store::code::CodeStore`] — code issue, lookup, claim, revoke
//! - [`codlet_core::store::session::SessionStore`] — session issue, validate, revoke
//! - [`codlet_core::store::token::FormTokenStore`] — form-token issue, consume, replay
//! - [`codlet_core::admin::CodeAdminStore`] — metadata listing and lookup (RFC-030)
//!
//! ## Backend options
//!
//! SQLx supports three SQLite connection strings:
//!
//! ```text
//! "sqlite::memory:" — ephemeral, in-process only (tests / local dev)
//! "sqlite:path/to/codlet.db" — persistent file on disk (single-server production)
//! "sqlite::memory:?cache=shared&uri=true" — named shared memory (advanced)
//! ```
//!
//! For production use a file-backed database and set WAL mode (applied
//! automatically by [`run_migrations`]).
//!
//! ## Atomicity guarantee
//!
//! Every one-time transition (code claim, form-token consume) uses a single
//! `UPDATE … WHERE … AND <guard condition>` followed by an affected-row count
//! check. SQLite's serialised write mode ensures these are atomic under
//! concurrent access from multiple threads within the same process. For
//! multi-process deployments, WAL mode and an appropriate busy-timeout are
//! recommended.
//!
//! ## Conformance
//!
//! All stores pass the full `codlet-conformance` suite, including the
//! concurrent-claim race test (RFC-022, RFC-023).
pub use run_migrations;
/// A handle wrapping a [`sqlx::SqlitePool`] that implements all three
/// codlet store traits.
///
/// Clone is cheap (the pool is reference-counted internally).