[fix](iceberg) Reject invalid name mapping instead of reading NULL - #68004
Merged
Gabriel39 merged 1 commit intoSep 17, 2026
Merged
Conversation
…pache#68004) ### What problem does this PR solve? Problem Summary: A table property `schema.name-mapping.default` that is present but malformed was silently degraded by the Iceberg connector: `IcebergSchemaUtils.extractNameMapping` caught the parse failure and rebuilt a "current schema" mapping, which is authoritative. Data files without Iceberg field ids could then only be resolved by their current column names, so after a column rename the old physical column is unmatched and V2 semantics materializes NULL for it - the query succeeds but historical values are lost. Once a name was reused, the fallback could even bind the wrong physical column. Iceberg readers do not behave that way: Spark's `BaseReader` parses `schema.name-mapping.default` while constructing the reader and fails the query for a malformed value (`IllegalArgumentException` / `UncheckedIOException`), regardless of whether the data files carry field ids. This PR removes the current-schema fallback and reports the metadata fault instead: the connector now throws a `DorisConnectorException` naming the table, the property, the root cause and the remediation. Metadata (system) table scans are unaffected because the schema-evolution carrier is only built for base-table scans. ### Behavior changes Before this change: - A malformed `schema.name-mapping.default` was rewritten into current-schema aliases, so ID-less files were read by current column name (renamed columns returned NULL). - No user visible error was raised; only a warning was logged. After this change: - A malformed `schema.name-mapping.default` fails the query with an explicit metadata error. ### Check List (For Author) - Test - [x] Unit Test - Behavior changed: - [x] Yes. - Does this need documentation? - [x] No.
Contributor
|
Thank you for your contribution to Apache Doris. Please clearly describe your PR:
|
hubgeter
force-pushed
the
fix/iceberg-invalid-name-mapping-master
branch
from
September 15, 2026 07:07
f2d22f3 to
d10b548
Compare
Contributor
Author
|
run buildall |
Contributor
Author
|
/review |
Merged
15 tasks
Contributor
There was a problem hiding this comment.
Request changes: I found two P1 correctness issues in the name-mapping contract; details are inline.
Review checkpoints
- Goal and tests: non-empty malformed mappings now fail through the common base-table preflight with a useful connector error, but the persistable empty-string boundary still bypasses that failure. The valid-empty utility test proves the transported dictionary, not the required mixed-version backend fence.
- Compatibility and parallel paths: ordinary, equality-delete, time-travel, and Top-N base scans share the preflight. Iceberg metadata tables do not expose the base mapping, so system-table isolation remains intact. The unresolved compatibility issue is the new-FE/old-BE disagreement for projected authoritative no-fallback mappings.
- Error handling and observability: once invoked,
DorisConnectorExceptionpropagates across the plugin classloader boundary and includes the table, property, root cause, and remediation. The dependency/package path is established. - Scope and other risks: the change is localized. I found no new concurrency, lifecycle, configuration, persistence, transaction/data-write, storage-format, or material performance issue.
- Release note: the PR marks
Behavior changed: Yes, but### Release noteisNone. Please replace it with a concise user-facing note explaining that malformedschema.name-mapping.defaultvalues now fail queries and how operators should remediate them. - Evidence: this was a static review only; no builds or tests were run under the review contract. At submission time, CheckStyle and the lightweight checks pass, while COMPILE, FE UT, and performance are still pending. Three bounded review rounds converged without a new finding in the final round. No additional user review focus was supplied.
hubgeter
marked this pull request as draft
September 15, 2026 10:17
Contributor
FE Regression Coverage ReportIncrement line coverage |
hubgeter
marked this pull request as ready for review
September 16, 2026 09:56
924060929
approved these changes
Sep 16, 2026
Contributor
TPC-H: Total hot run time: 16948 ms |
Contributor
TPC-DS: Total hot run time: 82857 ms |
Contributor
ClickBench: Total hot run time: 14.88 s |
yiguolei
pushed a commit
that referenced
this pull request
Sep 20, 2026
…ding NULL (#68004) (#68003) ### What problem does this PR solve? Problem Summary: bp #68004 When the Iceberg table property `schema.name-mapping.default` is present but malformed, the FE caught the parse failure and rebuilt a "current schema" name mapping, which is authoritative. Data files that do not carry Iceberg field ids could then only be resolved by their current column names. After a column rename the old physical column is unmatched, V2 semantics materializes NULL for it, and the query succeeds with historical values lost. If the old name was later reused by another column, the fallback could even bind the wrong physical column. Iceberg itself does not degrade like this: Spark's `BaseReader` parses `schema.name-mapping.default` while constructing the reader and fails the query for a malformed value (`IllegalArgumentException` / `UncheckedIOException`), regardless of whether the data files carry field ids. This PR removes the current-schema fallback and reports the metadata fault instead. `IcebergUtils.getNameMapping` now throws a `UserException` that names the table, the property, the root cause and the remediation, so the failure is visible instead of silently returning NULL. Metadata (system) table scans are excluded, because they never resolve physical data columns by name. ### Release note None ### Check List (For Author) - Test - [ ] Regression test - [x] Unit Test - [ ] Manual test (add detailed scripts or steps below) - [ ] No need to test or manual test. Explain why: - [ ] This is a refactor/code format and no logic has been changed. - [ ] Previous test can cover this change. - [ ] No code files have been changed. - [ ] Other reason - Behavior changed: - [x] Yes. - Does this need documentation? - [ ] No. - [ ] Yes. ### Check List (For Reviewer who merge this PR) - [ ] Confirm the release note - [ ] Confirm test cases - [ ] Confirm document - [ ] Add branch pick label
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What problem does this PR solve?
Issue Number: N/A
Problem Summary:
When the Iceberg table property
schema.name-mapping.defaultis present but malformed,IcebergSchemaUtils.extractNameMappingcaught the parse failure and rebuilt a "current schema" name mapping, which is authoritative. Data files that do not carry Iceberg field ids could then only be resolved by their current column names. After a column rename the old physical column is unmatched, V2 semantics materializes NULL for it, and the query succeeds with historical values lost. If the old name was later reused by another column, the fallback could even bind the wrong physical column.Iceberg itself does not degrade like this: Spark's
BaseReaderparsesschema.name-mapping.defaultwhile constructing the reader and fails the query for a malformed value (IllegalArgumentException/UncheckedIOException), regardless of whether the data files carry field ids.This PR removes the current-schema fallback and reports the metadata fault instead. The connector now throws a
DorisConnectorExceptionthat names the table, the property, the root cause and the remediation, so the failure is visible instead of silently returning NULL. Metadata (system) table scans are unaffected, because the schema-evolution carrier is only built for base-table scans.Release note
None
Check List (For Author)
Test
Behavior changed:
Does this need documentation?
Check List (For Reviewer who merge this PR)