-
Notifications
You must be signed in to change notification settings - Fork 28.1k
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
[SQL] SPARK-6981: Factor out SparkPlanner and QueryExecution from SQLContext #6356
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. |
} | ||
|
||
|
||
class SparkPlanner(val sqlContext: SQLContext) extends org.apache.spark.sql.execution.SparkStrategies { |
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.
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
|
Project(projectList, filterCondition.map(Filter(_, scan)).getOrElse(scan)) | ||
} | ||
} | ||
} |
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.
i think u need to add a new line here to not fail scalastyle
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.
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 |
} | ||
} | ||
} | ||
@deprecated("use org.apache.spark.sql.SparkPlanner", "1.5.0") |
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.
1.6.0
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! |
@@ -114,7 +114,7 @@ private[sql] object DataFrame { | |||
@Experimental | |||
class DataFrame private[sql]( | |||
@transient val sqlContext: SQLContext, | |||
@DeveloperApi @transient val queryExecution: SQLContext#QueryExecution) extends Serializable { | |||
@DeveloperApi @transient val queryExecution: QueryExecution) extends Serializable { |
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.
@marmbrus This changes the signature of queryExecution
. Is there anyway that we can preserve the binary compatibility?
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.
Should we preserve binary compatibility for developer API? At least MIMA doesn't complain about it...
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.
QueryExecution extends SQLContext#QueryExecution so binary compatibility should be preserved
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.
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