Crate larust_db 

Larust’s own database admin dashboard (/xr-db, dashboard/ module) - a phpMyAdmin/Adminer-style tool built into the framework itself: browse and edit the app’s actual SQL database (whatever DB_CONNECTION is configured - SQLite/MySQL/Postgres via larust_orm::AnyPool; see sql/ for the schema-introspection/generic-row engine behind it), run raw SQL, all from a browser during development. This is the primary reason this crate exists.

Also an embedded, pure-Rust key-value store (this module - wraps redb, single-file, MVCC, zero C dependencies), reachable from the same dashboard’s secondary “Key-Value” section. Named db (not kv) for the xr new wizard/CLI/feature surface deliberately - a developer scanning feature names recognizes “db” instantly. Additive, not a second SQL backend: #[derive(Model)] generates literal SQL and requires sqlx::FromRow - a KV store has no columns to decode, so it structurally cannot plug into that macro, larust_repository’s relations, or QueryBuilder. Every real model (users, posts, …) lives in the SQL database, which the dashboard’s primary section browses directly - the KV store is only ever for app-local data that never needed relations in the first place (feature flags, small local caches, offline queues, embedded config); the same posture larust_cache already has for its own SQLite-backed store.

The KV store has no network port, no server process, ever. redb is an in-process embedded library, the same way rusqlite/ sqlx-sqlite are for SQLite - connect() just opens a plain file on disk (database/db.redb by default) directly inside the app’s own process. There is nothing to start, stop, or point a connection string’s host/port at. The dashboard itself is likewise just a route on the app’s own existing HTTP server, not a second listener - it shares whatever port APP_PORT already binds, for both its SQL and KV sections alike; only the SQL side additionally talks to whatever real database server the app itself is already configured to use.

Gated behind larust-support’s db feature - re-exported through larust_support::db, never depended on directly by a generated app - selectable via xr new’s wizard. See docs/ARCHITECTURE.md’s “Embedded key-value store” section for the full design, and dashboard/mod.rs’s own doc comment for the dashboard itself.

Modules

sql

The SQL admin engine - schema introspection, generic row/value codecs, and parameterized mutation, all built on larust_orm::AnyPool. HTTP concerns (routes, forms, HTML) live in crate::dashboard, which is this module’s only caller.

Structs

DbPlugin

The routes this crate needs, for larust_http::Router::plugin. Only /login is reachable without a valid dashboard session - everything else sits behind [require_db_login] via a nested .group("", ...), the same shape ROUTES_WEB_HEADER_WITH_AUTH’s own require_auth group already uses. axum matches /{base} and /{base}/ (and /login vs /login/) as distinct routes - both registered so a typed or bookmarked trailing slash doesn’t 404.

Functions

connect

Opens (creating if missing) the embedded store at path and stores it process-wide - same OnceLock singleton discipline as larust_orm::connect() ([crates/larust-orm/src/pool.rs]), for the same reason: an embedded engine’s own file lock means only one Database handle per process per file. Call once at startup, before any other function in this module.

forget

Removes key, if present. A no-op (not an error) if it isn’t.

get

Reads the value stored under key, if any, deserialized as T.

get_raw

Untyped read - what the CLI browser and dashboard use, since they don’t know any app’s Rust types at compile time. get is a thin serde_json::from_value wrapper around this.

keys

Every key currently stored, in no particular order. A dev/inspection tool (the CLI browser, the dashboard) - not meant for a hot request path in a store with a large key count.

parse_cli_value

Parses a CLI argument into a JSON value for put_raw - tries real JSON first (42 -> a number, "Alice" -> a string, true -> a bool), falling back to storing the raw text as a JSON string so xr db:put name Alice works without shell-quoting a JSON string.

put

Stores value (JSON-serialized) under key, overwriting any existing value.

put_raw

Untyped write - what the CLI browser and dashboard use. put is a thin serde_json::to_value wrapper around this.