-
Notifications
You must be signed in to change notification settings - Fork 29k
[SPARK-33685][SQL] Migrate DROP VIEW command to use UnresolvedView to resolve the identifier #30636
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
Conversation
|
Kubernetes integration test starting |
|
Test build #132317 has finished for PR 30636 at commit
|
|
retest this please |
|
Kubernetes integration test status failure |
|
Kubernetes integration test starting |
|
Kubernetes integration test status success |
|
Test build #132324 has finished for PR 30636 at commit
|
|
Kubernetes integration test starting |
|
Kubernetes integration test status failure |
|
Kubernetes integration test starting |
|
Test build #132330 has finished for PR 30636 at commit
|
|
Kubernetes integration test status failure |
|
Test build #132340 has finished for PR 30636 at commit
|
|
cc @cloud-fan |
|
retest this please |
| } | ||
| assert( | ||
| e.getMessage.contains("Cannot drop a table with DROP VIEW. Please use DROP TABLE instead")) | ||
| e.getMessage.contains("dbx.tab1 is a table. 'DROP VIEW' expects a view.")) |
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.
@cloud-fan do you think the message is regressing in terms of usefulness? One thing we can do is to introduce hint: Option[String] to UnresolvedView such that we can make the message as dbx.tab1 is a table. 'DROP VIEW' expects a view. Please use DROP TABLE instead.. WDYT?
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.
SGTM. Do we need to do the same for table commands?
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.
Yes. I will go thru commands that are using UnresolvedTable and add hints if necessary as a follow up PR.
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.
And I will revisit #30475 (comment) for UnresolvedTableOrView.
|
Kubernetes integration test starting |
|
Kubernetes integration test status success |
| .getOrElse(u) | ||
|
|
||
| case u @ UnresolvedView(NonSessionCatalogAndIdentifier(catalog, ident), cmd) => | ||
| u.failAnalysis( |
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.
this seems like something that we should put in CheckAnalysis
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.
Moved to CheckAnalysis.
| NoopDropTable(u.multipartIdentifier) | ||
| NoopCommand(u.multipartIdentifier) | ||
| case DropView(u: UnresolvedView, ifExists) if ifExists => | ||
| NoopCommand(u.multipartIdentifier) |
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.
shall we add cmdName: String to NoopCommand?
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.
Thanks, added.
|
Test build #132378 has finished for PR 30636 at commit
|
|
Kubernetes integration test starting |
|
Test build #132397 has finished for PR 30636 at commit
|
|
Kubernetes integration test status failure |
|
Kubernetes integration test starting |
|
Kubernetes integration test status success |
| "because view support in v2 catalog has not been implemented yet. " + | ||
| s"$cmd expects a view.") | ||
|
|
||
| case u: UnresolvedView => |
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.
do we have a clear rule about when hint should be used in error message?
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 rule I am thinking is if an expected "type" of relation is not found. For example, UnresolvedTable is resolved to ResolvedView or UnresolvedView is resolved to ResolvedTable.
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.
then probably we should make the name clearer: relationTypeMismatchHint
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.
That sounds good, thanks!
|
Test build #132409 has finished for PR 30636 at commit
|
cloud-fan
left a comment
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.
LGTM except one comment
|
Test build #132415 has finished for PR 30636 at commit
|
|
This is definitely not related to SparkR. I'm merging it to master, thanks! |
…ble for a better error message ### What changes were proposed in this pull request? This PR proposes to add `relationTypeMismatchHint` to `UnresolvedTable` so that if a relation is resolved to a view when a table is expected, a hint message can be included as a part of the analysis exception message. Note that the same feature is already introduced to `UnresolvedView` in #30636. This mostly affects `ALTER TABLE` commands where the analysis exception message will now contain `Please use ALTER VIEW as instead`. ### Why are the changes needed? To give a better error message. (The hint used to exist but got removed for commands that migrated to the new resolution framework) ### Does this PR introduce _any_ user-facing change? Yes, now `ALTER TABLE` commands include a hint to use `ALTER VIEW` instead. ``` sql("ALTER TABLE v SET SERDE 'whatever'") ``` Before: ``` "v is a view. 'ALTER TABLE ... SET [SERDE|SERDEPROPERTIES]' expects a table. ``` After this PR: ``` "v is a view. 'ALTER TABLE ... SET [SERDE|SERDEPROPERTIES]' expects a table. Please use ALTER VIEW instead. ``` ### How was this patch tested? Updated existing test cases to include the hint. Closes #31424 from imback82/better_error. Authored-by: Terry Kim <[email protected]> Signed-off-by: Wenchen Fan <[email protected]>
…ble for a better error message ### What changes were proposed in this pull request? This PR proposes to add `relationTypeMismatchHint` to `UnresolvedTable` so that if a relation is resolved to a view when a table is expected, a hint message can be included as a part of the analysis exception message. Note that the same feature is already introduced to `UnresolvedView` in apache#30636. This mostly affects `ALTER TABLE` commands where the analysis exception message will now contain `Please use ALTER VIEW as instead`. ### Why are the changes needed? To give a better error message. (The hint used to exist but got removed for commands that migrated to the new resolution framework) ### Does this PR introduce _any_ user-facing change? Yes, now `ALTER TABLE` commands include a hint to use `ALTER VIEW` instead. ``` sql("ALTER TABLE v SET SERDE 'whatever'") ``` Before: ``` "v is a view. 'ALTER TABLE ... SET [SERDE|SERDEPROPERTIES]' expects a table. ``` After this PR: ``` "v is a view. 'ALTER TABLE ... SET [SERDE|SERDEPROPERTIES]' expects a table. Please use ALTER VIEW instead. ``` ### How was this patch tested? Updated existing test cases to include the hint. Closes apache#31424 from imback82/better_error. Authored-by: Terry Kim <[email protected]> Signed-off-by: Wenchen Fan <[email protected]>
What changes were proposed in this pull request?
This PR introduces
UnresolvedViewin the resolution framework to resolve the identifier.This PR then migrates
DROP VIEWto useUnresolvedViewto resolve the table/view identifier. This allows consistent resolution rules (temp view first, etc.) to be applied for both v1/v2 commands. More info about the consistent resolution rule proposal can be found in JIRA or proposal doc.Why are the changes needed?
To use
UnresolvedViewfor view resolution. Note that there is no resolution behavior change with this PR.Does this PR introduce any user-facing change?
No.
How was this patch tested?
Updated existing tests.