Skip to content

Conversation

@scwf
Copy link
Contributor

@scwf scwf commented Dec 16, 2014

Remove Command and use RunnableCommand instead.

@SparkQA
Copy link

SparkQA commented Dec 16, 2014

Test build #24500 has started for PR 3712 at commit 125f542.

  • This patch merges cleanly.

@SparkQA
Copy link

SparkQA commented Dec 16, 2014

Test build #24500 has finished for PR 3712 at commit 125f542.

  • This patch fails Spark unit tests.
  • This patch merges cleanly.
  • This patch adds the following public classes (experimental):
    • case class SetCommand(kv: Option[(String, Option[String])], _output: Seq[Attribute])(
    • case class UncacheTableCommand(tableName: String) extends RunnableCommand
    • case class DescribeCommand(child: SparkPlan, _output: Seq[Attribute])(
    • case class AnalyzeTable(tableName: String)(hiveContext: HiveContext) extends RunnableCommand
    • case class DropTable(
    • case class AddJar(path: String)(hiveContext: HiveContext) extends RunnableCommand
    • case class AddFile(path: String)(hiveContext: HiveContext) extends RunnableCommand

@AmplabJenkins
Copy link

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/24500/
Test FAILed.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can't we get rid of strategy entirely and just have this single line added to BasicOperators. That was kind of my goal with this refactoring.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I will try, maybe we can add a rule to translate logical.XXXCommand to RunnableCommand in analyzer.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don think it needs to be in the Analyzer. I think just this single line in the BasicOperators Strategy should be sufficient.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But for set command, catalyst first parse it as logical.SetCommand, when to make it as execution.SetCommand (RunnableCommand)?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can not avoid this step to translate logical.XXXCommand to RunnableCommand, so keep CommandStrategy here.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay, I see the problem now. These commands still live inside of catalyst and thus cannot be RunnableCommands. I would argue that that should be changed. My whole goal here was to eliminate boilerplate from the planner and this still seems to have a bunch of it. That said, this could be done in a follow up PR.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes, i think we can parse command in sql/core instead of parsing in catalyst in the follow up PR

@SparkQA
Copy link

SparkQA commented Dec 17, 2014

Test build #24544 has started for PR 3712 at commit 1d4d018.

  • This patch merges cleanly.

@SparkQA
Copy link

SparkQA commented Dec 17, 2014

Test build #24544 has finished for PR 3712 at commit 1d4d018.

  • This patch fails Scala style tests.
  • This patch merges cleanly.
  • This patch adds no public classes.

@AmplabJenkins
Copy link

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/24544/
Test FAILed.

@SparkQA
Copy link

SparkQA commented Dec 17, 2014

Test build #24546 has started for PR 3712 at commit 3925492.

  • This patch merges cleanly.

@SparkQA
Copy link

SparkQA commented Dec 17, 2014

Test build #24547 has started for PR 3712 at commit 4033bed.

  • This patch merges cleanly.

@SparkQA
Copy link

SparkQA commented Dec 17, 2014

Test build #24546 has finished for PR 3712 at commit 3925492.

  • This patch passes all tests.
  • This patch merges cleanly.
  • This patch adds no public classes.

@AmplabJenkins
Copy link

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/24546/
Test PASSed.

@SparkQA
Copy link

SparkQA commented Dec 17, 2014

Test build #24547 has finished for PR 3712 at commit 4033bed.

  • This patch passes all tests.
  • This patch merges cleanly.
  • This patch adds no public classes.

@AmplabJenkins
Copy link

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/24547/
Test PASSed.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Its a little odd to have a var named sc that is not a SparkContext, also I think we should try and eliminate this since we get the SQLContext in the run method. Can we just move metastoreRelation into the run method?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we just move this to the place in the unit tests where we need it?

@marmbrus
Copy link
Contributor

Okay, I think this is getting pretty close. Thanks for working on this!

@SparkQA
Copy link

SparkQA commented Dec 18, 2014

Test build #24567 has started for PR 3712 at commit 0e03be8.

  • This patch merges cleanly.

@SparkQA
Copy link

SparkQA commented Dec 18, 2014

Test build #24567 has finished for PR 3712 at commit 0e03be8.

  • This patch fails Spark unit tests.
  • This patch merges cleanly.
  • This patch adds no public classes.

@AmplabJenkins
Copy link

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/24567/
Test FAILed.

@SparkQA
Copy link

SparkQA commented Dec 18, 2014

Test build #24584 has started for PR 3712 at commit 51a82f2.

  • This patch merges cleanly.

@SparkQA
Copy link

SparkQA commented Dec 18, 2014

Test build #24584 has finished for PR 3712 at commit 51a82f2.

  • This patch passes all tests.
  • This patch merges cleanly.
  • This patch adds no public classes.

@AmplabJenkins
Copy link

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/24584/
Test PASSed.

@scwf
Copy link
Contributor Author

scwf commented Dec 19, 2014

Updated. @marmbrus is this ok to go ?

@marmbrus
Copy link
Contributor

Thanks! Merged to master.

@asfgit asfgit closed this in c3d91da Dec 19, 2014
@scwf scwf deleted the cmd branch December 20, 2014 13:42
asfgit pushed a commit that referenced this pull request Jan 10, 2015
Follow up for #3712.
This PR finally remove ```CommandStrategy``` and make all commands follow ```RunnableCommand``` so they can go with ```case r: RunnableCommand => ExecutedCommand(r) :: Nil```.

One exception is the ```DescribeCommand``` of hive, which is a special case and need to distinguish hive table and temporary table, so still keep ```HiveCommandStrategy``` here.

Author: scwf <wangfei1@huawei.com>

Closes #3948 from scwf/followup-SPARK-4861 and squashes the following commits:

6b48e64 [scwf] minor style fix
2c62e9d [scwf] fix for hive module
5a7a819 [scwf] Refactory command in spark sql
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants