seawinde opened a new pull request, #66613:
URL: https://github.com/apache/doris/pull/66613
### What problem does this PR solve?
Issue Number: N/A
Related PR: #43539, #62492, #63268
Problem Summary:
When an INNER JOIN query is matched against a LEFT OUTER JOIN materialized
view, the rewrite must prove that the nullable side is null-rejected. The MV
rule shuttles the nullable-side output Slots through the view plan lineage to
normalize Project and Alias outputs before selecting an `IS NOT NULL`
compensation Slot.
**Root cause:**
`AbstractMaterializedViewRule.getShuttledRequireNoNullableViewSlots()`
assumed that `ExpressionUtils.shuttleExpressionWithLineage()` always returns
`Slot` values and unconditionally used `Slot.class::cast`. The API returns
general `Expression` values. Expression JOIN keys such as CAST equality can
introduce helper projections whose lineage expands to `Cast`, causing a
`ClassCastException` during MV rewrite. The unsafe assumption was introduced
by #43539. PR #62492 added INNER JoinEdge null-reject inference, and #63268
materialized that evidence as compensation, making this path more readily
reachable.
**Change summary:**
| File | Change |
|------|--------|
| `AbstractMaterializedViewRule.java` | Keep only actual `Slot` lineage
values before converting the stream. |
| `MvExplorationSuiteTest.java` | Cover CAST equality JOIN compensation and
verify that it falls back without throwing. |
**Current limitation:** This is a conservative crash fix, not transparent
rewrite support for CAST or arbitrary derived expressions. If no usable Slot
remains after lineage expansion, the existing proof checks return invalid and
the MV rewrite safely falls back to base tables. The CAST JOIN case covered
by
the test therefore still does not use the MV. Using an expression's input
Slots
as compensation evidence is not generally sound because functions and casts
can change nullability semantics; supporting such expressions requires an
explicit nullability-preserving proof.
### Release note
Fixed an internal `ClassCastException` during materialized view rewrite for
expression-based join keys. Unsupported derived-expression lineage now falls
back safely.
### 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] No. Unsupported expression lineage still falls back; this change
removes the internal exception.
- [ ] Yes.
- Does this need documentation?
- [x] No.
- [ ] Yes.
### Check List (For Reviewer who merge this PR)
- [ ] Confirm the release note
- [ ] Confirm test cases
- [ ] Confirm document
- [ ] Add branch pick label
--
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]
