jatorre opened a new pull request, #3641: URL: https://github.com/apache/iceberg-rust/pull/3641
## Which issue does this PR close? - Part of #3639. ## What changes are included in this PR? - `ParquetWriter::parquet_files_to_data_files` becomes `pub` (it was `pub(crate)` and `#[allow(dead_code)]`), with a doc comment: data files from existing Parquet footers, for an add-files commit. Unpartitioned tables only, as before. - `Transaction::build_commit(self) -> Result<TableCommit>` applies the actions (a fast append writes its manifests and manifest list here) and returns the `TableCommit` instead of sending it, so a client with its own catalog (PyIceberg, through pyiceberg-core) can send it. No refresh and no retry: a conflict is the caller's, who rebuilds from a fresh table. The Python binding that uses both is a separate PR, stacked on this one. ## Are these changes tested? `test_build_commit_sends_through_another_catalog_client` (in `test_row_lineage`): a v3 fast append built with `build_commit` commits nothing by itself; sent through the memory catalog's `update_table`, it gives the same row lineage as `commit` (`first-row-id` 0, `next-row-id` 30) and one manifest. `cargo test -p iceberg --lib transaction::` passes (107), clippy `-D warnings` and rustfmt are clean. End to end: against a REST catalog, a DuckDB-created v3 table with a `geometry` column, two Parquet files registered this way; DuckDB 2.0 and PyIceberg 0.12 read 3,000 rows with consistent row ids, and a later DuckDB insert continued them. ## AI Disclosure Drafted with Claude Code (Claude Opus 5.5) at my direction; I ran the tests, clippy and rustfmt, and the end-to-end check described above. Points I would like reviewers to look at: - `build_commit` duplicates the action loop of `do_commit` rather than refactoring `do_commit` to use it; happy to change that. - Whether `build_commit` should refuse a transaction with no actions (`commit` returns the table unchanged; here an empty commit is returned). -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
