-
Notifications
You must be signed in to change notification settings - Fork 29k
[SPARK-32960][SQL] Provide better exception on temporary view against DataFrameWriterV2 #29830
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
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -153,6 +153,7 @@ final class DataFrameWriterV2[T] private[sql](table: String, ds: Dataset[T]) | |
| */ | ||
| @throws(classOf[NoSuchTableException]) | ||
| def append(): Unit = { | ||
| assertNoTempView("append") | ||
| val append = loadTable(catalog, identifier) match { | ||
| case Some(t) => | ||
| AppendData.byName( | ||
|
|
@@ -177,6 +178,7 @@ final class DataFrameWriterV2[T] private[sql](table: String, ds: Dataset[T]) | |
| */ | ||
| @throws(classOf[NoSuchTableException]) | ||
| def overwrite(condition: Column): Unit = { | ||
| assertNoTempView("overwrite") | ||
| val overwrite = loadTable(catalog, identifier) match { | ||
| case Some(t) => | ||
| OverwriteByExpression.byName( | ||
|
|
@@ -204,6 +206,7 @@ final class DataFrameWriterV2[T] private[sql](table: String, ds: Dataset[T]) | |
| */ | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Should we write it about
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. +1 for @HyukjinKwon 's suggestion.
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I thought about this, and decided to skip because AnalysisException is thrown for whatever cases even without this case. We couldn't explain all these things. I'll add it if we prefer to explain it at least for explicit case. |
||
| @throws(classOf[NoSuchTableException]) | ||
| def overwritePartitions(): Unit = { | ||
| assertNoTempView("overwritePartitions") | ||
| val dynamicOverwrite = loadTable(catalog, identifier) match { | ||
| case Some(t) => | ||
| OverwritePartitionsDynamic.byName( | ||
|
|
@@ -216,6 +219,12 @@ final class DataFrameWriterV2[T] private[sql](table: String, ds: Dataset[T]) | |
| runCommand("overwritePartitions")(dynamicOverwrite) | ||
| } | ||
|
|
||
| private def assertNoTempView(name: String): Unit = { | ||
| if (sparkSession.sessionState.catalog.isTempView(tableName)) { | ||
| throw new AnalysisException(s"Temporary view $table doesn't support $name") | ||
| } | ||
| } | ||
|
|
||
| /** | ||
| * Wrap an action to track the QueryExecution and time cost, then report to the user-registered | ||
| * callback functions. | ||
|
|
||
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'm thinking of a more aggressive refactor, which creates an unresolved logical plan here and leaves the table/temp view lookup to the analyzer.
For example, here we can just create
AppendData.byName(UnresolvedRelation(...)).By doing this, we can make the framework more clear: the API layer should just create logical plans, other works should be done by the analyzer and query planner.
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 agree the suggestion is promising, but I'm not sure I understand all spots I need to modify. I could try to find places where
InsertIntoStatement(UnresolvedRelation(...))is resolved, but AppendData and InsertIntoStatement are not 100% same. In addition, looks like it should be done for each operation.I'll take a look at this soon. If you can fix it easily (and you'd like to) please go ahead and I can learn from your 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.
done in #29970