You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit dc21748
Browse filesBrowse the repository at this point in the historyBrowse files
committed
[fix](fe) Resolve dropped Iceberg equality-delete keys after a schema ID is reused
### What problem does this PR solve?
Issue Number: None
Related PR: #66538, #69394
Problem Summary: When an Iceberg table drops a column so that its schema
becomes equal to an earlier one, Iceberg reuses the earlier schema ID
instead of adding a new schema, and the metadata schema list keeps that
schema at its original, earlier position. The equality-delete schema
carrier in the Iceberg connector located the scan schema in that list by
ID and searched only the schemas listed before it. A live equality delete
keyed on the dropped column therefore could not find the schema that still
defines the key, and every scan of the table failed with "Iceberg
equality-delete fields are absent from schema history". This happens in
steady state, not only during an upgrade.
Reproduce: create a table with column id, add column k, write data and an
equality delete keyed on k, drop k (the schema returns to the initial one
and reuses its ID), then query the table.
branch-4.1 (#66538) searches the scan snapshot's parent chain first, so the
definition recorded on that lineage wins, and falls back to the whole
metadata list, newest first, for schema-only changes and expired
ancestors. This change ports that order to IcebergScanPlanProvider. Each
lineage schema is indexed at most once and the walk stops as soon as every
key is resolved. It also ports the branch-4.1 tests for a reused schema ID
(with and without an expired parent) and for time travel past a later
rename. The existing test
equalityCarrierKeepsLatestDefinitionOfDroppedEqualityKey (#69394)
renamed and then dropped the key with no write in between. It now writes
a snapshot after each schema change, as the branch-4.1 test it was ported
from does, and still expects k2.
### Release note
Fix Iceberg queries that failed with "equality-delete fields are absent
from schema history" after a column used as an equality-delete key was
dropped and the table schema returned to an earlier one.
### Check List (For Author)
- Test: Unit Test
- fe-connector-iceberg: 4 new cases and 1 adjusted case in
IcebergScanPlanProviderTest; the two reused-ID cases fail without
the fix; the whole module passes
- Behavior changed: Yes. Such queries no longer fail. When a dropped key
has several historical definitions, the carrier now prefers the one
recorded on the scan snapshot's lineage, as branch-4.1 does.
- Does this need documentation: No
Co-authored-by: daidai <[email protected]>
Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>
Copy file name to clipboardExpand all lines: fe/fe-connector/fe-connector-iceberg/src/main/java/org/apache/doris/connector/iceberg/IcebergScanPlanProvider.java
+29-18Lines changed: 29 additions & 18 deletions
Original file line number
Diff line number
Diff line change
@@ -2108,7 +2108,7 @@ public Map<String, String> getScanNodeProperties(
2108
2108
// every branch so the default and current field type match BE's read.
Copy file name to clipboardExpand all lines: fe/fe-connector/fe-connector-iceberg/src/test/java/org/apache/doris/connector/iceberg/IcebergScanPlanProviderTest.java
+160-1Lines changed: 160 additions & 1 deletion
Original file line number
Diff line number
Diff line change
@@ -108,6 +108,7 @@
108
108
importjava.util.HashMap;
109
109
importjava.util.IdentityHashMap;
110
110
importjava.util.Iterator;
111
+
importjava.util.LinkedHashMap;
111
112
importjava.util.List;
112
113
importjava.util.Map;
113
114
importjava.util.NoSuchElementException;
@@ -1925,7 +1926,8 @@ null, new IcebergTableHandle("db1", "dropped_eq_key"),
0 commit comments