mbutrovich commented on code in PR #2307:
URL: https://github.com/apache/iceberg-rust/pull/2307#discussion_r3022632038
##########
crates/iceberg/src/arrow/reader.rs:
##########
@@ -1111,14 +1111,24 @@ fn build_field_id_map(parquet_schema:
&SchemaDescriptor) -> Result<Option<HashMa
}
/// Build a fallback field ID map for Parquet files without embedded field IDs.
-/// Position-based (1, 2, 3, ...) for compatibility with iceberg-java
migrations.
+///
+/// Must use top-level field positions (not leaf column positions) to stay
consistent
+/// with `add_fallback_field_ids_to_arrow_schema`, which assigns ordinal IDs to
+/// top-level Arrow fields. Using leaf positions instead would produce wrong
indices
+/// when nested types (struct/list/map) expand into multiple leaf columns.
+///
+/// Matches iceberg-java's ParquetSchemaUtil.addFallbackIds().
fn build_fallback_field_id_map(parquet_schema: &SchemaDescriptor) ->
HashMap<i32, usize> {
Review Comment:
Updated to iterate `root_schema().get_fields()` directly, mirroring Java's
`fileSchema.getFields()` loop. For primitives we map ordinal -> leaf index; for
groups we advance the leaf counter using `get_column_root_idx` to skip past
their leaves.
We can't do an exact 1:1 with Java because Java's `addFallbackIds` just
stamps IDs onto the Parquet `MessageType` and lets the Parquet reader handle
column resolution later. Here we need to produce a `field_id ->
leaf_column_index` map eagerly since arrow-rs needs leaf indices for
projection. So the structure mirrors Java but the output is what our reader
pipeline consumes.
--
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]
