pub struct Db { /* private fields */ }Expand description
Cheaply-clonable SQLite handle. Clones share the underlying Mutex, so
a single physical connection backs every clone – the same guarantee
crate::store::SqliteMailStore::db’s own doc comment relies on for
letting a daemon share one connection between an “engine” store handle
and a “reader” store handle.
Implementations§
Source§impl Db
impl Db
Sourcepub fn open(cfg: &DbConfig) -> Result<Self, DbError>
pub fn open(cfg: &DbConfig) -> Result<Self, DbError>
Opens the database and applies WAL (file-backed only) + foreign_keys
pragmas. Does NOT run migrations – call
Db::run_migrations_blocking separately, same two-step boot the
daemon (src/main.rs) always did.
pub fn label(&self) -> &str
Sourcepub fn run_migrations_blocking(
&self,
runner: MigrationRunner,
) -> Result<(), DbError>
pub fn run_migrations_blocking( &self, runner: MigrationRunner, ) -> Result<(), DbError>
Synchronous migration runner – for fn main(), before a tokio
runtime exists at all (see src/main.rs’s own module doc comment
on why that ordering is deliberate). Panics if this handle’s lock
is already held, which would mean a caller reached this from
inside an already-running async task – use write_blocking
there instead, same discipline as every other mutating call this
crate makes.
Sourcepub fn read_blocking<F, T>(&self, f: F) -> Result<T>
pub fn read_blocking<F, T>(&self, f: F) -> Result<T>
Blocking read: waits on the mutex. Callers already inside a tokio
task must run this through spawn_blocking – see this crate’s own
module doc comment (lib.rs) for why calling it directly from an
async task panics.
Sourcepub fn write_blocking<F, T>(&self, f: F) -> Result<T>
pub fn write_blocking<F, T>(&self, f: F) -> Result<T>
Blocking write: waits on the mutex. Same discipline as
Db::read_blocking.