Repository navigation
[KYUUBI #7206][LINEAGE] Collect input tables from filter subqueries - #7792
Open
wayne-x-wang wants to merge 1 commit into
Open
wayne-x-wang wants to merge 1 commit into
wayne-x-wang wants to merge 1 commit into
Conversation
|
Hello @wayne-x-wang, |
This branch has not been deployed
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.
Why are the changes needed?
Tables used only by filter subqueries are missing from input lineage. For example:
Before this change, the analyzed plan contains
tb2underFilter.condition, but lineage lists onlytb1. Ordinarychildrentraversal does not visit the subquery plan.Visit
SubqueryExpression.planin filters and collect its input tables without merging its column mappings. Output columns keep their existing sources. The existingspark.kyuubi.plugin.lineage.legacy.collectInputTablesByColumn=truemode retains its previous input-table semantics. No new configuration or dependency is introduced.This follows the traversal approach discussed in #7207 while avoiding the additional configuration questioned in review. Five existing input-table expectations are corrected; their column mappings are unchanged.
Fixes #7206.
How was this patch tested?
The correlated
EXISTSregression failed in two independent JVM runs on the unmodified master implementation (Spark 3.5.8):Its output-table and three column-source assertions passed before the input-table assertion failed. With the regression added, the pre-fix lineage suite had 75 passing tests and the same failure in both catalog suites.
Added 36 compatibility cases: nine scenarios × two legacy settings × two catalog suites. These cover
EXISTS,NOT EXISTS,IN,NOT IN, scalar subqueries,HAVING, nested subqueries, composite conditions and a filter without subqueries. They check input/output tables and column mappings, and restore the previous configuration infinally. Tests use Spark's parser/analyzer and the existing in-memory V2 catalogs, matching the listener's analyzed-plan input.After the fix, all 113 lineage tests passed on each matrix entry:
Both runs also passed Spotless and Scalastyle. Commands below omit only the local Maven mirror settings path:
dev/reformatandgit diff --checkpassed. The final source hashes match the files used in both successful test runs.Was this patch assisted by generative AI tooling?
Assisted-by: Codex (GPT-6)