glimr_sqlite/sqlite

SQLite Adapter

The SQLite counterpart to glimr_postgres/postgres.gleam. Same idea — a clean public entry point that hides config parsing and pool construction behind simple start calls. SQLite is particularly appealing for smaller apps and local development since there’s no separate server to manage, but it still goes through the same Pool abstraction so switching to Postgres later doesn’t require changing application code.

Values

session_store

</>

pub fn session_store(pool: db.DbPool) -> store.SessionStore

For apps already using SQLite, storing sessions in the same database keeps things simple — no Redis or extra infrastructure. Pass the result to session.setup() in your bootstrap and sessions live right alongside your application data.

start

</>

pub fn start(name: String) -> db.DbPool

The one-liner every app’s main module calls at boot. Loads database.toml, finds the named connection, and starts a pool — no config parsing or driver types to deal with. The assert crash is intentional: a broken database path at startup is unrecoverable, and crashing immediately gives a clear stack trace instead of propagating errors through every downstream function that tries to use the pool.

start_cache

</>

pub fn start_cache(
  db_pool: db.DbPool,
  name: String,
) -> cache.CachePool

SQLite is already a single file — using the same file for caching means zero extra infrastructure. This wires your existing database pool into the framework’s cache system using a regular SQL table, same CachePool API as the Redis and file backends.