acme_proxy/sqlite/
mod.rs

1//! Persistence: one module per table, over `sqlx` and SQLite.
2//!
3//! Queries are built with the runtime `sqlx::query` API rather than the
4//! compile-time macros, so `DATABASE_URL` is not needed to build the crate.
5//! Migrations are embedded and run at startup — see [`db`].
6//!
7//! Two invariants shape almost everything here:
8//!
9//! - **A profile is a data boundary.** `accounts` and `orders` carry a
10//!   `profile` column and `accounts` is keyed `UNIQUE(profile, pubkey)`, so one
11//!   client key at two endpoints is two unrelated accounts. Request-path
12//!   lookups always take the profile; the admin layer uses the deliberately
13//!   unscoped `find_any_*` variants.
14//! - **[`audit`] rows outlive their subjects.** That table has no foreign keys,
15//!   because a `CASCADE` would delete the evidence along with the account or
16//!   order it describes. It is INSERT-only: there is no setter and no `UPDATE`
17//!   against it anywhere in the crate.
18//!
19//! Methods return `Result<_, sqlx::Error>` and leave the mapping to a
20//! [`crate::error::Problem`] to their caller.
21
22pub mod account;
23pub mod admin_recovery_code;
24pub mod admin_session;
25pub mod admin_user;
26pub mod audit;
27pub mod authz;
28pub mod db;
29pub mod eab;
30pub mod job;
31pub mod nonce;
32pub mod order;
33pub mod status;
34pub mod upstream_order;
acme_proxy/sqlite/mod.rs

acme_proxy/sqlite/
mod.rs
