Context
In credential_vault/mod.rs, blobs::put(conn, ...) is called while an active transaction is open on the same connection. This works correctly in SQLite (same connection object), but it's confusing to readers since blobs.rs functions currently take a &Connection directly rather than a type that makes the transactional context explicit.
Proposed Refactor
Refactor blobs.rs (and similar helper modules) to accept a generic parameter — e.g. something implementing a Deref<Target = rusqlite::Connection> or a rusqlite::ToSql-style abstraction — so the same functions can be called with either a bare Connection or an active Transaction without ambiguity.
This would make call-sites like:
let tx = conn.transaction()?;
blobs::put(&tx, ...)?; // clearly operating inside the transaction
tx.commit()?;
…unambiguous and self-documenting.
References
Flagged during review of #400. Not blocking that PR — tracking here for a follow-up refactor.
Context
In
credential_vault/mod.rs,blobs::put(conn, ...)is called while an active transaction is open on the same connection. This works correctly in SQLite (same connection object), but it's confusing to readers sinceblobs.rsfunctions currently take a&Connectiondirectly rather than a type that makes the transactional context explicit.Proposed Refactor
Refactor
blobs.rs(and similar helper modules) to accept a generic parameter — e.g. something implementing aDeref<Target = rusqlite::Connection>or arusqlite::ToSql-style abstraction — so the same functions can be called with either a bareConnectionor an activeTransactionwithout ambiguity.This would make call-sites like:
…unambiguous and self-documenting.
References
Flagged during review of #400. Not blocking that PR — tracking here for a follow-up refactor.