pub struct SqliteOptions { /* private fields */ }Expand description
How a SqliteStore opens and uses its connections.
Builder style: SqliteOptions::new().busy_timeout(Duration::from_secs(5)).
Implementations§
Source§impl SqliteOptions
impl SqliteOptions
Sourcepub fn new() -> SqliteOptions
pub fn new() -> SqliteOptions
At most 8 idle connections kept; a writer waits at most 30 seconds for the
database’s write lock (and a reader for a lock held in exclusive mode); every commit
durable (synchronous = FULL).
Sourcepub fn max_size(self, n: usize) -> SqliteOptions
pub fn max_size(self, n: usize) -> SqliteOptions
The most idle connections kept open for reuse (at least 1). More may be open at once, one per concurrent call; SQLite connections are cheap, and readers do not wait for each other or for the writer (WAL).
Sourcepub fn busy_timeout(self, d: Duration) -> SqliteOptions
pub fn busy_timeout(self, d: Duration) -> SqliteOptions
How long a call waits for a lock another connection (of this process or another)
holds before failing with Error::Database (SQLITE_BUSY; reads through the
Resolver: None). Writers take the database’s one write lock for the duration
of a put_*, so this is the longest a writer waits behind the others.
Sourcepub fn durable(self, yes: bool) -> SqliteOptions
pub fn durable(self, yes: bool) -> SqliteOptions
Whether each commit is flushed to disk before it returns (synchronous = FULL, the
default), or only at checkpoints (synchronous = NORMAL: a power loss can lose the
latest commits, never consistency; much faster for bulk loads, like PostgreSQL’s
synchronous_commit = off). Either way an application crash loses nothing
committed.