Skip to content
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

[SPARK-30535][SQL] Migrate ALTER TABLE commands to the new framework #27243

Closed
wants to merge 9 commits into from

Conversation

imback82
Copy link
Contributor

@imback82 imback82 commented Jan 16, 2020

What changes were proposed in this pull request?

Use the new framework to resolve the ALTER TABLE commands.

This PR also refactors ALTER TABLE logical plans such that they extend a base class AlterTable. Each plan now implements def changes: Seq[TableChange] for any table change operations.

Additionally, UnresolvedV2Relation and its usage is completely removed.

Why are the changes needed?

This is a part of effort to make the relation lookup behavior consistent: SPARK-29900.

Does this PR introduce any user-facing change?

No

How was this patch tested?

Updated existing tests

@imback82
Copy link
Contributor Author

cc @cloud-fan

}
AlterTable(
r,
typeChange.toSeq ++ nullabilityChange ++ commentChange ++ positionChange)
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Should this logic of populating Seq[TableChange] reside this this file? Can't this go directly into AlterTableAlterColumn and have a trait for ALTER TABLE commands which exposes (def changes: Seq[TableChage])?

Copy link
Contributor

@cloud-fan cloud-fan Jan 17, 2020

Choose a reason for hiding this comment

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

yea sounds good! I think we can even make the logical plan AlterTable a base class for these ALTER TABLE commands, to make the workflow simpler: "different AlterTable logical plans -> AlterTableExec" instead of "different AlterTable logical plans -> AlterTable -> AlterTableExec"

@SparkQA
Copy link

SparkQA commented Jan 17, 2020

Test build #116873 has finished for PR 27243 at commit ac12efc.

  • This patch fails Spark unit tests.
  • This patch merges cleanly.
  • This patch adds the following public classes (experimental):
  • case class AlterTableAddColumns(
  • case class AlterTableAlterColumn(
  • case class AlterTableRenameColumn(
  • case class AlterTableDropColumns(
  • case class AlterTableSetProperties(
  • case class AlterTableUnsetProperties(
  • case class AlterTableSetLocation(

cloud-fan pushed a commit that referenced this pull request Jan 17, 2020
### What changes were proposed in this pull request?

Use the new framework to resolve the SHOW TBLPROPERTIES command. This PR along with #27243 should update all the existing V2 commands with `UnresolvedV2Relation`.

### Why are the changes needed?

This is a part of effort to make the relation lookup behavior consistent: [SPARK-2990](https://issues.apache.org/jira/browse/SPARK-29900).

### Does this PR introduce any user-facing change?

Yes `SHOW TBLPROPERTIES temp_view` now fails with `AnalysisException` will be thrown with a message `temp_view is a temp view not table`. Previously, it was returning empty row.

### How was this patch tested?

Existing tests

Closes #26921 from imback82/consistnet_v2command.

Authored-by: Terry Kim <yuminkim@gmail.com>
Signed-off-by: Wenchen Fan <wenchen@databricks.com>
@SparkQA
Copy link

SparkQA commented Jan 19, 2020

Test build #117017 has finished for PR 27243 at commit 81d692b.

  • This patch fails Spark unit tests.
  • This patch merges cleanly.
  • This patch adds the following public classes (experimental):
  • case class UnresolvedTableWithViewExists(view: ResolvedView) extends LeafNode
  • case class ResolvedView(identifier: Identifier, isTempView: Boolean) extends LeafNode
  • abstract class AlterTable extends Command

@SparkQA
Copy link

SparkQA commented Jan 20, 2020

Test build #117025 has finished for PR 27243 at commit 7a3f87f.

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


case alter: AlterTable =>
alter.table match {
case u @ UnresolvedTableWithViewExists(view) if !view.isTempView =>
Copy link
Contributor

Choose a reason for hiding this comment

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

what's the error message for temp view?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The current/existing tests expect [t] is a temp view not a table.

Copy link
Contributor

Choose a reason for hiding this comment

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

shall we use the same error message as permanent views?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

OK. I will do this as a follow-up. Thanks @cloud-fan for the review!

@@ -420,63 +425,71 @@ trait CheckAnalysis extends PredicateHelper {
}

case alter: AlterTable if alter.childrenResolved =>
Copy link
Contributor

Choose a reason for hiding this comment

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

nit: case alter: AlterTable if alter.childrenResolved && alter.table.isInstanceOf[ResolvedTable]

Then we don't need to change the indentation below and save a lot of code diff.

Copy link
Contributor

Choose a reason for hiding this comment

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

BTW we can't hit v1 table here right? We should have converted alter table command to v1 if the table is v1, before we reach here.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Thanks, changed as suggested.

That's correct. If a table is V1Table, the alter table are converted to v1 in ResolveSessionCatalog.

@cloud-fan
Copy link
Contributor

LGTM except a few minor comments

@cloud-fan
Copy link
Contributor

LGTM. We can address #27243 (comment) in followup as it's only about error message.

@SparkQA
Copy link

SparkQA commented Jan 20, 2020

Test build #117080 has finished for PR 27243 at commit 25ae584.

  • This patch fails due to an unknown error code, -9.
  • This patch merges cleanly.
  • This patch adds no public classes.

@SparkQA
Copy link

SparkQA commented Jan 20, 2020

Test build #117090 has finished for PR 27243 at commit bb21f16.

  • This patch fails due to an unknown error code, -9.
  • This patch merges cleanly.
  • This patch adds no public classes.

@cloud-fan
Copy link
Contributor

retest this please

@SparkQA
Copy link

SparkQA commented Jan 20, 2020

Test build #117105 has finished for PR 27243 at commit bb21f16.

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

@cloud-fan cloud-fan closed this in b5cb9ab Jan 20, 2020
@cloud-fan
Copy link
Contributor

thanks, merging to master!

@brkyvz
Copy link
Contributor

brkyvz commented Jan 22, 2020

Sorry, but couldn't we have done this change after 3.0? Was there a bug around views with Alter Table to require us to the new resolution framework (for which we didn't have a proper discussion around the design of something so critical)? This seems too risky of a PR for several reasons:

  1. It makes the resolution of the table that's going to be altered a child. We had avoided this on purpose as having an arbitrary rule change the child of AlterTable seemed risky. This change alone is a big -1 for me for this change.
  2. While the code may look cleaner, I think this approach makes certain things harder, e.g. differentiating between the Hive based Alter table CHANGE COLUMN and ALTER COLUMN syntax. Resolving and normalizing columns for ALTER COLUMN also becomes a bit harder, as we now have to check every single AlterTable command instead of just a single ALTER TABLE ALTER COLUMN statement

@gatorsmile
Copy link
Member

+1 Let us revert it now.

gatorsmile pushed a commit that referenced this pull request Jan 23, 2020
… framework

### What changes were proposed in this pull request?

This reverts commit b5cb9ab.

### Why are the changes needed?

The merged commit (#27243) was too risky for several reasons:
 1. It doesn't fix a bug
 2. It makes the resolution of the table that's going to be altered a child. We had avoided this on purpose as having an arbitrary rule change the child of AlterTable seemed risky. This change alone is a big -1 for me for this change.
 3. While the code may look cleaner, I think this approach makes certain things harder, e.g. differentiating between the Hive based Alter table CHANGE COLUMN and ALTER COLUMN syntax. Resolving and normalizing columns for ALTER COLUMN also becomes a bit harder, as we now have to check every single AlterTable command instead of just a single ALTER TABLE ALTER COLUMN statement

### Does this PR introduce any user-facing change?

No

### How was this patch tested?

Existing unit tests

This closes #27315

Closes #27327 from brkyvz/revAlter.

Authored-by: Burak Yavuz <brkyvz@gmail.com>
Signed-off-by: Xiao Li <gatorsmile@gmail.com>
@@ -2194,7 +2194,7 @@ class DataSourceV2SQLSuite
withTempView("v") {
sql("create global temp view v as select 1")
val e = intercept[AnalysisException](sql("COMMENT ON TABLE global_temp.v IS NULL"))
Copy link
Member

Choose a reason for hiding this comment

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

What happened if we apply this command to DSV1 tables? How many DDLs/DMLs are applied only to DSV2 tables?

Copy link
Contributor

Choose a reason for hiding this comment

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

I think all commands support v1 table: they either have a v1 command, or the v2 command works out of the box thanks to v2 session catalog. We need to add test though.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
6 participants