-
Notifications
You must be signed in to change notification settings - Fork 29k
[SPARK-7067][SQL] fix bug when use complex nested fields in ORDER BY #5659
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
Can one of the admins verify this patch? |
|
ok to test |
|
Test build #30861 has started for PR 5659 at commit |
|
Test build #30861 has finished for PR 5659 at commit
|
|
Test PASSed. |
|
Can one of the admins verify this patch? |
|
ping @marmbrus |
|
Retest this please. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Two suggestions here:
- Can we share the code with the block below? and only add a try/catch around it?
- I think we can probably avoid the
changedoptimization. The rule executor and transform already do checks to avoid churn when the plan does not change. Either way, I think its better to keep rules simple even if there is a small performance penalty.
8c2e600 to
d75cef0
Compare
|
Retest this please. |
|
cc @marmbrus |
|
ping @marmbrus |
|
cc @marmbrus , is it OK to test? |
|
add to whitelist |
|
Merged build triggered. |
|
Merged build started. |
|
Test build #34909 has started for PR 5659 at commit |
|
Test build #34909 has finished for PR 5659 at commit
|
|
Merged build finished. Test FAILed. |
|
Merged build triggered. |
|
Merged build started. |
|
Test build #34910 has started for PR 5659 at commit |
|
Test build #34910 has finished for PR 5659 at commit
|
|
Merged build finished. Test PASSed. |
|
Merged build triggered. |
|
Merged build started. |
|
Test build #34984 has started for PR 5659 at commit |
|
Test build #34984 has finished for PR 5659 at commit
|
|
Merged build finished. Test FAILed. |
|
Merged build triggered. |
|
Merged build started. |
|
Test build #34989 has started for PR 5659 at commit |
|
Test build #34989 has finished for PR 5659 at commit
|
|
Merged build finished. Test FAILed. |
|
retest it please. |
|
test this please |
|
Merged build triggered. |
|
Merged build started. |
|
Test build #35056 has started for PR 5659 at commit |
|
Test build #35056 has finished for PR 5659 at commit
|
|
Merged build finished. Test PASSed. |
|
Thanks! Merging to master. |
This PR is a improvement for apache#5189. The resolution rule for ORDER BY is: first resolve based on what comes from the select clause and then fall back on its child only when this fails. There are 2 steps. First, try to resolve `Sort` in `ResolveReferences` based on select clause, and ignore exceptions. Second, try to resolve `Sort` in `ResolveSortReferences` and add missing projection. However, the way we resolve `SortOrder` is wrong. We just resolve `UnresolvedAttribute` and use the result to indicate if we can resolve `SortOrder`. But `UnresolvedAttribute` is only part of `GetField` chain(broken by `GetItem`), so we need to go through the whole chain to indicate if we can resolve `SortOrder`. With this change, we can also avoid re-throw GetField exception in `CheckAnalysis` which is little ugly. Author: Wenchen Fan <[email protected]> Closes apache#5659 from cloud-fan/order-by and squashes the following commits: cfa79f8 [Wenchen Fan] update test 3245d28 [Wenchen Fan] minor improve 465ee07 [Wenchen Fan] address comment 1fc41a2 [Wenchen Fan] fix SPARK-7067
This PR is a improvement for #5189.
The resolution rule for ORDER BY is: first resolve based on what comes from the select clause and then fall back on its child only when this fails.
There are 2 steps. First, try to resolve
SortinResolveReferencesbased on select clause, and ignore exceptions. Second, try to resolveSortinResolveSortReferencesand add missing projection.However, the way we resolve
SortOrderis wrong. We just resolveUnresolvedAttributeand use the result to indicate if we can resolveSortOrder. ButUnresolvedAttributeis only part ofGetFieldchain(broken byGetItem), so we need to go through the whole chain to indicate if we can resolveSortOrder.With this change, we can also avoid re-throw GetField exception in
CheckAnalysiswhich is little ugly.