max / goingson

db: move off sqlx-sqlite to rusqlite, and the traits go sync with it The SQL library standard settled on 2026-08-07 asks for rusqlite under SQLite, and the measurement that decided it applies here in full: 292 runtime sqlx::query call sites, zero query! macros, no .sqlx offline dir. GoingsOn was paying an async runtime, a pool and a version ceiling for the one sqlx feature it never used, while already running a second rusqlite driver against the same file through SyncKit's SyncStore. The 18 repository traits go SYNC rather than staying async over a synchronous embedded database. Nothing wanted the async: each trait had exactly one implementor and AppState erases them to Arc<dyn ..> with no generic bound and no mock, so 231 #[async_trait] async fn became plain fn and the blocking moved to the callers. got dropped its tokio runtime outright. search_repo's tokio::join! over five sqlx futures became five sequential calls on one connection, because against a single SQLite file it bought interleaving rather than parallelism. The _sqlx_migrations ledger is kept VERBATIM: same table name, same columns, sha384 over raw file bytes. This was the one failure mode that could brick installs -- rename it and an upgraded install believes it has applied nothing and re-runs all 64 migrations against populated tables. migrate.rs is the runner, build.rs embeds the files parsing filenames the way sqlx::migrate! did, and migration_checksum_tests now computes the hash off disk itself instead of reading sqlx's Migrator, so the manifest and the runner agree by evidence rather than by construction. Verified against a copy of the live goingson.db: 64 applied, zero pending, data intact. r2d2 with a hand-written ManageConnection, deliberately not r2d2_sqlite, which requires rusqlite 0.40 -- the exact pin this migration exists to unblock. A :memory: pool gets a uniquely-named shared cache plus a keeper connection, since a shared-cache memory database dies when its last connection closes and r2d2 reaps idle ones. One connection at a time is now a stated rule (repository/mod.rs). Five pooled connections and a blocking checkout mean a method holding one while calling self.get_by_id, which takes another, deadlocks under load rather than merely slowing down; 20 write-then-read sites release theirs first. sqlx had the same hazard implicitly. Not done, and not a correctness problem today: Tauri commands call the sync repositories inline on the async runtime rather than through spawn_blocking. Fine for a local SQLite file, wrong the day a command gets slow. The backup export, the one path that already blocked for seconds, was on the blocking pool before and stays there. Balanced Breakfast is still on sqlx-sqlite and is now the only thing gating the tree-wide move to rusqlite 0.40.