Repository navigation
branch-4.2: [fix](fe) Preserve Hudi scan state when assigning table aliases - #69387
Conversation
### What problem does this PR solve? Issue Number: N/A Problem Summary: Queries that assign an alias to a Hudi table fail during physical plan translation. The alias elimination rule calls withTableAlias, but LogicalHudiScan inherits the LogicalFileScan implementation, which replaces the Hudi scan with a generic file scan and drops its incremental read state. Override the alias copy in LogicalHudiScan and preserve the alias through all subsequent copies, retaining the dedicated Hudi implementation path and relation-scoped scan state. ### Release note Fix query planning failures when Hudi tables are referenced with table aliases. ### Check List (For Author) - Test: Unit Test - LogicalHudiScanTest, LogicalFileScanTest and PruneFileScanPartitionTest; verify the new tests fail on the original implementation and pass after the fix. FE Checkstyle. - Behavior changed: Yes, aliased Hudi scans retain their scan type and read state instead of failing plan translation. - Does this need documentation: No
|
run buildall |
|
/review |
|
Thank you for your contribution to Apache Doris. Please clearly describe your PR:
|
There was a problem hiding this comment.
No new substantiated correctness issue was found in the two changed files at da062d868a7b97dfc3e228ac69534f858126958f. The alias override preserves the specialized Hudi scan and its pinned read state through logical copies, allowing the existing Hudi implementation and translator to run.
The inspected production flow is:
SubQueryAlias(t1, LogicalHudiScan[id#i; snapshot V, incremental I])
-> Project(t1.id#i, LogicalHudiScan[id#i; alias=t1, V, I])
-> Project(t1.id#i, PhysicalHudiScan[id#i; V, I])
-> HudiScanNode(V, I)
This is a source-derived reduced plan. The old inherited alias copy returned LogicalFileScan, which reached the generic translator's explicit HUDI rejection. The new copy reuses LogicalProperties, preserving output ExprIds even when output is initially uncached, and retains partition selection, captured schema, relation snapshot and incremental state.
Required checkpoint conclusions:
| Checkpoint | Conclusion |
|---|---|
| Goal and proving tests | The override fixes subtype erasure. Two new JUnit 5 tests exercise alias removal, physical Hudi selection and all seven existing logical copy APIs. |
| Scope and clarity | Focused constructor delegation, one override and alias forwarding; no unrelated production changes. |
| Concurrency and locks | No new threads, shared mutable state, lock acquisitions, heavy locked operations or lock-order changes. |
| Lifecycle and static initialization | No new resource ownership, cleanup obligation, reference cycle or static initializer. Existing read-state objects are shared through copies. |
| Configuration | No configuration changes; dynamic-update checks do not apply. |
| Compatibility | Existing public/protected constructors remain available with the prior empty-alias default. No persisted or wire-format change. |
| Thrift/protobuf compatibility | No definitions changed; cross-release field/enum comparison does not apply. |
| Parallel paths | Every reconstructing parent copy API is overridden. Pruning and deep-copy dispatch preserve Hudi, and both normal and aggregate implementation routes choose PhysicalHudiScan. |
| Special conditions | No new branching. Existing incremental, partition and error conditions remain unchanged. The alias copy follows the parent's group-expression reset/property-reuse contract. |
| Test coverage | Tests cover the changed rule boundary and state forwarding. They use cached output and mocked metadata; uncached output and downstream translation were inspected in source. Real COW/MOR reads and end-to-end Hudi SQL remain unexecuted. |
| Test results | No expected-results files changed. Assertions match the copy contracts. No build or test was run during this static review; author-reported passing tests were not independently executed. |
| Observability | Existing wrong-scan-type errors and Hudi diagnostics remain sufficient for this state-preservation fix; no new operational path requires metrics. |
| Transactions, persistence and failover | No commit, publish, journal or replay changes. Pinned external read-state forwarding remains intact. |
| Writes, atomicity and crash handling | Read-planning-only changes; no write, delete-bitmap, version-publication or crash-cleanup protocol changes. |
| FE/BE variables | No new transmitted field. Existing scan parameters, snapshots and incremental state reach HudiScanNode unchanged. Alias-qualified slots are already represented by the project. |
| Performance and memory | Existing copy structure is retained with an additional String reference; no extra metadata lookup, timeline IO, large allocation, loop or synchronization. |
| Other issues | Deep copies, slot qualifiers/ExprIds, policy-generated predicates, inherited mutators, memo identity and physical alias presentation were checked without a substantiated introduced regression. |
There were no existing inline comments or additional user focus points. The initial subtype/read-state risk and all examined candidates were dismissed with source evidence; no accepted finding, unresolved source question or uncovered changed file remains.
The review converged in round 1: the complete reviewer and the separate risk reviewer both returned NO_NEW_VALUABLE_FINDINGS on the unchanged empty inline set, followed by the main reviewer's independent verification and final sweep. Validation was static only, as required; runtime integration behavior remains unexecuted.
Review converged after 1 round(s).
FE UT Coverage ReportIncrement line coverage |
FE Regression Coverage ReportIncrement line coverage |
|
PR approved by anyone and no changes requested. |
|
PR approved by at least one committer and no changes requested. |
What problem does this PR solve?
Regression introduced by #68213 (
branch-4.2 [feat](nereids) add table alias for catalog relation, commitee3f10d42156). That PR added a call toLogicalCatalogRelation.withTableAlias()inLogicalSubQueryAliasToLogicalProject.LogicalHudiScandid not override the new method, so it inherited the implementation that constructs aLogicalFileScan, losing its Hudi-specific scan type and incremental read state.Queries that assign an alias to a Hudi table fail during physical plan translation. The alias elimination rule calls
withTableAlias, butLogicalHudiScaninherits the implementation that creates a genericLogicalFileScan, dropping the dedicated Hudi scan type and incremental read state.Override
withTableAliasinLogicalHudiScanand retain the alias through all subsequent copies. This preserves the Hudi implementation path, partition selection, and relation-scoped read state.This fix targets branch-4.2 directly because master removed the dedicated Hudi scan classes in #64304. Branch-4.1 does not contain the alias propagation change and is unaffected by this bug.
Release note
Fix query planning failures when Hudi tables are referenced with table aliases.
Check List (For Author)
LogicalFileScaninstead ofLogicalHudiScan; after the fix, all 12 tests inLogicalHudiScanTest,LogicalFileScanTest, andPruneFileScanPartitionTestpass using JDK 17 andrun-fe-ut.sh. FE Checkstyle passes with zero violations. The external Hudi end-to-end regression suite was not run locally.