Uh oh!
There was an error while loading. Please reload this page.
[SPARK-7067][SQL] fix bug when use complex nested fields in ORDER BY - #5659
[SPARK-7067][SQL] fix bug when use complex nested fields in ORDER BY#5659cloud-fan wants to merge 4 commits into
Conversation
AmplabJenkins
commented
Apr 23, 2015
Can one of the admins verify this patch? |
marmbrus
commented
Apr 23, 2015
ok to test |
SparkQA
commented
Apr 23, 2015
Test build #30861 has started for PR 5659 at commit |
SparkQA
commented
Apr 23, 2015
Test build #30861 has finished for PR 5659 at commit
|
AmplabJenkins
commented
Apr 23, 2015
Test PASSed. |
AmplabJenkins
commented
Apr 27, 2015
Can one of the admins verify this patch? |
cloud-fan
commented
Apr 28, 2015
ping @marmbrus |
cloud-fan
commented
May 12, 2015
Retest this please. |
There was a problem hiding this comment.
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
d75cef0Comparecloud-fan
commented
Jun 3, 2015
Retest this please. |
cloud-fan
commented
Jun 3, 2015
cc @marmbrus |
cloud-fan
commented
Jun 12, 2015
ping @marmbrus |
cloud-fan
commented
Jun 15, 2015
cc @marmbrus , is it OK to test? |
marmbrus
commented
Jun 15, 2015
add to whitelist |
AmplabJenkins
commented
Jun 15, 2015
Merged build triggered. |
AmplabJenkins
commented
Jun 15, 2015
Merged build started. |
SparkQA
commented
Jun 15, 2015
Test build #34909 has started for PR 5659 at commit |
SparkQA
commented
Jun 15, 2015
Test build #34909 has finished for PR 5659 at commit
|
AmplabJenkins
commented
Jun 15, 2015
Merged build finished. Test FAILed. |
AmplabJenkins
commented
Jun 15, 2015
Merged build triggered. |
AmplabJenkins
commented
Jun 15, 2015
Merged build started. |
SparkQA
commented
Jun 15, 2015
Test build #34910 has started for PR 5659 at commit |
SparkQA
commented
Jun 15, 2015
Test build #34910 has finished for PR 5659 at commit
|
AmplabJenkins
commented
Jun 15, 2015
Merged build finished. Test PASSed. |
AmplabJenkins
commented
Jun 16, 2015
Merged build triggered. |
AmplabJenkins
commented
Jun 16, 2015
Merged build started. |
SparkQA
commented
Jun 16, 2015
Test build #34984 has started for PR 5659 at commit |
SparkQA
commented
Jun 16, 2015
Test build #34984 has finished for PR 5659 at commit
|
AmplabJenkins
commented
Jun 16, 2015
Merged build finished. Test FAILed. |
AmplabJenkins
commented
Jun 16, 2015
Merged build triggered. |
AmplabJenkins
commented
Jun 16, 2015
Merged build started. |
SparkQA
commented
Jun 16, 2015
Test build #34989 has started for PR 5659 at commit |
SparkQA
commented
Jun 16, 2015
Test build #34989 has finished for PR 5659 at commit
|
AmplabJenkins
commented
Jun 16, 2015
Merged build finished. Test FAILed. |
cloud-fan
commented
Jun 17, 2015
retest it please. |
marmbrus
commented
Jun 17, 2015
test this please |
AmplabJenkins
commented
Jun 17, 2015
Merged build triggered. |
AmplabJenkins
commented
Jun 17, 2015
Merged build started. |
SparkQA
commented
Jun 17, 2015
Test build #35056 has started for PR 5659 at commit |
SparkQA
commented
Jun 17, 2015
Test build #35056 has finished for PR 5659 at commit
|
AmplabJenkins
commented
Jun 17, 2015
Merged build finished. Test PASSed. |
marmbrus
commented
Jun 17, 2015
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 <cloud0fan@outlook.com> Closesapache#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.