Trait DbBatch 

pub trait DbBatch: Send {
    // Required methods
    fn dialect(&self) -> SqlDialect;
    fn add_statement(&mut self, sql: &str, params: &[DbValue]) -> StmtId;
    fn commit<'async_trait>(
        self: Box<Self>,
    ) -> Pin<Box<dyn Future<Output = Result<Vec<DbStatementResult>, DbError>> + Send + 'async_trait>>
       where Self: 'async_trait;
}

An atomic, all-or-nothing unit of writes.

Statements are collected with add_statement and then run together by commit inside a single transaction. Either every statement commits or none does; on any error the whole batch rolls back.

There is deliberately no read method on a batch. A queued statement may not depend on the result of an earlier one in the same batch — all reads must happen on Db before the batch is assembled. This keeps a batch expressible as a flat, declarative statement list.

That declarative shape is the portable lowest common denominator across SQLite backends. Any backend where compute is network-distant from the database can’t safely expose an interactive BEGIN/COMMIT: a client could open a write transaction and then crash or stall, stranding SQLite’s single write slot. So the whole category of HTTP-fronted edge SQLite exposes only a batch/pipeline primitive that opens and closes the transaction database-side in one round trip — Cloudflare D1’s batch(), Turso/libSQL’s remote client (its stateless HTTP requests share no transaction context), and Bunny (also libSQL-over-HTTP). The same flat list also maps cleanly onto backends that do offer a real interactive transaction because compute is colocated with the data — rusqlite BEGIN/COMMIT, Durable Object transactionSync. One batch abstraction therefore runs identically everywhere.

Required Methods

fn dialect(&self) -> SqlDialect

The SQL dialect this batch speaks. Available here because callers build statements while holding only the batch.

fn add_statement(&mut self, sql: &str, params: &[DbValue]) -> StmtId

Queue a write statement and return its StmtId. Infallible: this only buffers sql and params; any SQL error surfaces at commit.

fn commit<'async_trait>( self: Box<Self>, ) -> Pin<Box<dyn Future<Output = Result<Vec<DbStatementResult>, DbError>> + Send + 'async_trait>>

where Self: 'async_trait,

Commit all queued statements atomically, consuming the batch. Returns one DbStatementResult per queued statement, in add order (so a StmtId indexes straight into it). On any failure the transaction is rolled back and nothing is persisted.

Dyn Compatibility

This trait is dyn compatible.

In older versions of Rust, dyn compatibility was called "object safety".

Implementors