The REST catalog spec defines POST /v1/{prefix}/transactions/commit, which applies changes to multiple tables in one atomic operation, and CommitTableRequest in this crate already notes that identifier "must be present for CommitTransactionRequest" — but there is currently no way to drive that endpoint from iceberg-rust.
Proposal:
Transaction::prepare_commit() — run a transaction's actions and return the resulting TableCommit without sending it to a catalog (the per-table building block).RestCatalog::commit_transaction(Vec<TableCommit>) — submit the group as one CommitTransactionRequest; the catalog applies all of the changes or none of them.
Kept on RestCatalog rather than the Catalog trait because multi-table atomicity is a catalog capability rather than a universal guarantee; whether the trait should expose a capability for it seems like a good follow-up discussion.
Use case: a CDC producer (Postgres → Iceberg) that commits row deltas to many tables plus a changelog table per cadence, and needs the group to land atomically so downstream readers never observe a half-applied cut. Validated against Lakekeeper, which implements the endpoint.
I have a working implementation with unit tests and will open a PR.
The REST catalog spec defines
POST /v1/{prefix}/transactions/commit, which applies changes to multiple tables in one atomic operation, andCommitTableRequestin this crate already notes thatidentifier"must be present for CommitTransactionRequest" — but there is currently no way to drive that endpoint from iceberg-rust.Proposal:
Transaction::prepare_commit()— run a transaction's actions and return the resultingTableCommitwithout sending it to a catalog (the per-table building block).RestCatalog::commit_transaction(Vec<TableCommit>)— submit the group as oneCommitTransactionRequest; the catalog applies all of the changes or none of them.Kept on
RestCatalograther than theCatalogtrait because multi-table atomicity is a catalog capability rather than a universal guarantee; whether the trait should expose a capability for it seems like a good follow-up discussion.Use case: a CDC producer (Postgres → Iceberg) that commits row deltas to many tables plus a changelog table per cadence, and needs the group to land atomically so downstream readers never observe a half-applied cut. Validated against Lakekeeper, which implements the endpoint.
I have a working implementation with unit tests and will open a PR.