[SQL] SPARK-6981: Factor out SparkPlanner and QueryExecution from SQLContext#6356
[SQL] SPARK-6981: Factor out SparkPlanner and QueryExecution from SQLContext#6356evacchi wants to merge 9 commits into
Conversation
* process in a lighter-weight, backwards-compatible way
|
I don't think we need to care about the binary compatibility for this case. Maybe just add the exclude rules to MimaExcludes file. |
There was a problem hiding this comment.
can we move this into the execution package?
|
In order to make a minimal change (To keep the |
|
@chenghao-intel to me both solutions are fine, see PR #6122; however, this solution would retain binary compatibility |
|
@evacchi mind bringing this up to date so we can merge it for 1.5? |
|
ok, will check today |
|
@rxin merge conflicts fixed; should pass tests as well |
|
Test build #1123 has finished for PR 6356 at commit
|
There was a problem hiding this comment.
i think u need to add a new line here to not fail scalastyle
There was a problem hiding this comment.
there might be more so u should check the output from jenkins
|
@rxin weird, didn't get those during local testing. BTW, they should pass now |
|
Jenkins, test this please. |
|
Test build #1146 has finished for PR 6356 at commit
|
|
@rxin I fixed today's merge conflicts; I would advise doing a merged build once again and then (if, of course, the patch is good enough) to go ahead and merge it ASAP. Since this is a refactoring it will obviously break every day until it will be merged ! :) |
|
Jenkins, test this please. |
|
test build has not started |
|
Test build #1194 has finished for PR 6356 at commit
|
|
tests should pass now |
|
@evacchi, sorry for letting this go stale again. Can we close this issue until you have time to bring it up to date? |
Conflicts: sql/core/src/main/scala/org/apache/spark/sql/DataFrame.scala sql/core/src/main/scala/org/apache/spark/sql/SQLContext.scala
|
@marmbrus I have brought this up to date. Might need fixes in order to merge cleanly, though |
|
ok to test |
|
Minor comments, otherwise LGTM |
|
Test build #42156 has finished for PR 6356 at commit
|
|
Hope this still merges cleanly, I'm writing this from my phone. Otherwise it'll have to wait till I'm back from holidays |
|
Test build #42246 has finished for PR 6356 at commit
|
|
Rerun tests? |
|
ok to test |
|
Test build #1746 has finished for PR 6356 at commit
|
|
Test build #42359 has finished for PR 6356 at commit
|
|
Thanks, merging to master! |
There was a problem hiding this comment.
@marmbrus This changes the signature of queryExecution. Is there anyway that we can preserve the binary compatibility?
There was a problem hiding this comment.
Should we preserve binary compatibility for developer API? At least MIMA doesn't complain about it...
There was a problem hiding this comment.
QueryExecution extends SQLContext#QueryExecution so binary compatibility should be preserved
There was a problem hiding this comment.
The signature of the function to retrieve it has changed though. I think that we should rename this parameter and add a method that constructs a new instance of the inner subclass to return with the name queryExecution. I think its worth rerunning the optimizer to not have to recompile all our perf tools.
Alternative to PR #6122; in this case the refactored out classes are replaced by inner classes with the same name for backwards binary compatibility