hubgeter opened a new pull request, #68124: URL: https://github.com/apache/doris/pull/68124
### What problem does this PR solve? Problem Summary: After an Iceberg table's default partition spec evolves to unpartitioned, split planning gated the per-file partition metadata on the **current** spec (`table.spec().isPartitioned()`), so data files written under an older identity spec stopped carrying their partition values. `path_partition_keys` is the union of all specs, so BE does not read those columns from the data file either — an identity partition column whose value only exists in the file's partition metadata (e.g. a table migrated with `add_files`) was read as NULL, with both `enable_file_scanner_v2=true` and `false`. Gate on whether **any** spec of the table is partitioned instead. The values, spec id and partition data are already derived from the spec each data file was written with, which is what Iceberg's `PartitionUtil.constantsMap` does. The scanned-partition count keeps its previous meaning: a range only counts toward EXPLAIN `partition=N/M` / `sql_block_rule` `partition_num` when the current spec is partitioned, so this read fix does not change that display. Added FE unit tests for both evolution directions (partitioned -> unpartitioned, and unpartitioned -> partitioned, which must keep reporting its old spec id for the DML `$row_id` contract). ### Release note Fix Iceberg identity partition columns being read as NULL after the table's partition spec evolves to unpartitioned. -- 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]
