anoopj commented on code in PR #3230: URL: https://github.com/apache/iceberg-rust/pull/3230#discussion_r4039581522
########## crates/iceberg/src/writer/base_writer/position_delete_input.rs: ########## @@ -0,0 +1,378 @@ +// Licensed to the Apache Software Foundation (ASF) under one +// or more contributor license agreements. See the NOTICE file +// distributed with this work for additional information +// regarding copyright ownership. The ASF licenses this file +// to you under the Apache License, Version 2.0 (the +// "License"); you may not use this file except in compliance +// with the License. You may obtain a copy of the License at +// +// http://www.apache.org/licenses/LICENSE-2.0 +// +// Unless required by applicable law or agreed to in writing, +// software distributed under the License is distributed on an +// "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY +// KIND, either express or implied. See the License for the +// specific language governing permissions and limitations +// under the License. + +//! This module provides [`PositionDeleteInputBuilder`], a small helper that assembles a +//! spec-conforming position delete [`RecordBatch`] from `(path, pos)` rows. +//! +//! A [`PositionDeleteFileWriter`](super::position_delete_writer::PositionDeleteFileWriter) +//! accepts batches shaped as exactly the two required position delete columns: `file_path` +//! (`Utf8`, field id [`crate::metadata_columns::RESERVED_FIELD_ID_DELETE_FILE_PATH`]) and +//! `pos` (`Int64`, field id [`crate::metadata_columns::RESERVED_FIELD_ID_DELETE_FILE_POS`]), +//! both required. Hand-wiring that Arrow schema is error-prone, so this builder reuses the +//! writer's own Arrow projection of +//! [`position_delete_schema`](super::position_delete_writer::position_delete_schema), keeping +//! a single source of truth, and produces a batch the writer's validation accepts. +//! +//! The builder does not sort or deduplicate rows; position delete files must be sorted by +//! `file_path` then `pos`, so callers are responsible for pushing rows in that order for +//! direct-to-writer use (see +//! [`PositionDeleteFileWriter::write`](crate::writer::IcebergWriter::write), which +//! [`PositionDeleteFileWriter`](super::position_delete_writer::PositionDeleteFileWriter) +//! implements). +//! A future sorting writer will consume unsorted input and lift this requirement. +//! +//! All rows are materialized into two heap [`Vec`]s before the [`RecordBatch`] is built, so +//! for very large inputs prefer constructing one builder per write batch rather than +//! accumulating everything in a single builder. +//! +//! Only the two required columns are produced. The spec's optional third `row` column +//! (field id `i32::MAX - 103`), which inlines the deleted row's data, is not supported yet; +//! see [`PositionDeleteFileWriter`](super::position_delete_writer::PositionDeleteFileWriter). +//! +//! Position delete files are a v2 construct. v3 tables use deletion vectors and forbid adding +//! new position delete files, so a format-version gate must be applied at the +//! transaction/commit layer before routing v3 writes here; this builder and the underlying +//! [`PositionDeleteFileWriter`](super::position_delete_writer::PositionDeleteFileWriter) have +//! no such gate by design. + +use std::sync::Arc; + +use arrow_array::{ArrayRef, Int64Array, RecordBatch, StringArray}; + +use crate::{Error, ErrorKind, Result}; + +/// Builds a spec-conforming position delete [`RecordBatch`] from `(file_path, pos)` rows. +/// +/// The output has exactly the two required position delete columns and passes the +/// per-batch validation of +/// [`PositionDeleteFileWriter`](super::position_delete_writer::PositionDeleteFileWriter), +/// so it can be handed straight to that writer. An empty builder still produces a valid +/// 0-row batch with the correct schema. +/// +/// # Example +/// +/// ``` +/// use iceberg::writer::base_writer::position_delete_input::PositionDeleteInputBuilder; +/// +/// let mut input = PositionDeleteInputBuilder::new(); +/// input +/// .push("s3://bucket/data/f0.parquet", 1) +/// .push("s3://bucket/data/f0.parquet", 4); +/// let batch = input.build().unwrap(); +/// assert_eq!(batch.num_rows(), 2); +/// assert_eq!(batch.num_columns(), 2); +/// ``` +#[derive(Debug, Default, Clone)] +pub struct PositionDeleteInputBuilder { Review Comment: Yes, sorting is a requirement, but the PR keeps out of scope. `PositionDeleteInputBuilder` class is just a thin, per-batch assembler. The caller or a future sorting writer owns ordering, and that's where a `BTreeMap<String, RoaringTreemap>` (64-bit, since pos is i64) probably belongs. I think a radix tree is a neat idea, but the payoff might not be very large since a single write touches only a handful of distinct data files. In v4 relative paths drop the common prefix anyway. -- 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]
