[SPARK-33142][SPARK-33647][SQL] Store SQL text for SQL temp view #30567

linhongliu-db · 2020-12-02T09:52:52Z

What changes were proposed in this pull request?

Currently, in spark, the temp view is saved as its analyzed logical plan, while the permanent view
is kept in HMS with its origin SQL text. As a result, permanent and temporary views have
different behaviors in some cases. In this PR we store the SQL text for temporary view in order
to unify the behavior between permanent and temporary views.

Why are the changes needed?

to unify the behavior between permanent and temporary views

Does this PR introduce any user-facing change?

Yes, with this PR, the temporary view will be re-analyzed when it's referred. So if the
underlying datasource changed, the view will also be updated.

How was this patch tested?

existing and newly added test cases

SparkQA · 2020-12-02T11:34:04Z

Test build #132038 has finished for PR 30567 at commit 09419a6.

This patch fails Spark unit tests.
This patch merges cleanly.
This patch adds the following public classes (experimental):
case class TemporaryViewRelation(tableMeta: CatalogTable) extends LeafNode

linhongliu-db · 2020-12-02T14:05:53Z

cc @cloud-fan @leanken

cloud-fan · 2020-12-02T14:15:26Z

sql/catalyst/src/main/scala/org/apache/spark/sql/catalyst/analysis/Analyzer.scala

+        lookupTempView(ident, isStreaming).map(ResolveRelations.resolveViews).getOrElse(u)
      case i @ InsertIntoStatement(UnresolvedRelation(ident, _, false), _, _, _, _, _) =>
        lookupTempView(ident)
+          .map(ResolveRelations.resolveViews)


nit: do this in lookupTempView?

cloud-fan · 2020-12-02T14:18:52Z

sql/catalyst/src/main/scala/org/apache/spark/sql/catalyst/catalog/interface.scala


+/**
+ * A wrapper to store the temporary view info, will be kept in `SessionCatalog`
+ * and will be transformed to `View` in `getTempView`


in getTempView, there are more places, maybe just say will be transformed to View during analysis

cloud-fan · 2020-12-02T14:19:27Z

sql/catalyst/src/main/scala/org/apache/spark/sql/internal/SQLConf.scala

+  val STORE_ANALYZED_PLAN_FOR_VIEW =
+    buildConf("spark.sql.legacy.storeAnalyzedPlanForView")
+      .internal()
+      .doc("When true, analyzed plan instead of sql text will be stored when creating " +


cloud-fan · 2020-12-02T14:21:18Z

sql/core/src/main/scala/org/apache/spark/sql/execution/command/views.scala

+      catalog.createTempView(name.table, tableDefinition, overrideIfExists = replace)
    } else if (viewType == GlobalTempView) {
+      val db = sparkSession.sessionState.conf.getConf(StaticSQLConf.GLOBAL_TEMP_DATABASE)
+      val globalTempView = TableIdentifier(name.table, Option(db))


the name is weird. how about viewIdent

cloud-fan · 2020-12-02T14:22:13Z

sql/core/src/main/scala/org/apache/spark/sql/execution/command/views.scala

+      viewName: TableIdentifier,
+      session: SparkSession,
+      analyzedPlan: LogicalPlan,
+      aliasedSchema: StructType): CatalogTable = {


viewSchema

cloud-fan · 2020-12-02T14:24:05Z

sql/core/src/main/scala/org/apache/spark/sql/execution/command/views.scala

+      val properties = generateViewProperties(
+        Map.empty, session, analyzedPlan, analyzedPlan.schema.fieldNames)
+
+      TemporaryViewRelation(CatalogTable(


can we call prepareTemporaryView?

we can if we move prepareTemporaryView to ViewHelper, but it's a little bit weird to keep prepareTemporaryView and prepareTable in 2 different class/object

I think it's OK, ViewHelper should contain view related utils.

sql/core/src/test/scala/org/apache/spark/sql/execution/SQLViewSuite.scala

SparkQA · 2020-12-02T14:57:28Z

Test build #132052 has finished for PR 30567 at commit ba54f31.

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

SparkQA · 2020-12-02T15:11:45Z

Test build #132055 has finished for PR 30567 at commit a0ab11d.

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

cloud-fan · 2020-12-02T15:54:12Z

sql/catalyst/src/main/scala/org/apache/spark/sql/catalyst/catalog/SessionCatalog.scala

    }
  }

+  def parseTempViewPlan(plan: LogicalPlan): LogicalPlan = {


nit: getTempViewPlan

cloud-fan · 2020-12-02T16:01:01Z

sql/core/src/test/scala/org/apache/spark/sql/execution/SQLViewTestSuite.scala

+  test("change SQLConf should not change view behavior - caseSensitiveAnalysis") {
+    withTable("t") {
+      Seq(2, 3, 1).toDF("c1").write.format("parquet").saveAsTable("t")
+      testView("v1", Seq("c1"), "SELECT C1 FROM t") {


This test is a bit hard to read. How about

def createView(viewName: String, columnNames: Seq[String], sqlText: String): String ... var viewName = "" def check(...) = { checkAnswer(sql(s"SELECT * FROM viewName"), ...) } withSQLConf(conf) { viewName = createView(...) check() } withSQLConf(flippedConf) { check() }

sql/core/src/main/scala/org/apache/spark/sql/execution/command/views.scala

cloud-fan · 2020-12-02T16:36:07Z

sql/catalyst/src/main/scala/org/apache/spark/sql/catalyst/catalog/SessionCatalog.scala

+  def parseTempViewPlan(plan: LogicalPlan): LogicalPlan = {
+    plan match {
+      case viewInfo: TemporaryViewRelation =>
+        val metadata = viewInfo.tableMeta


to remove duplicated code, we can have a function that turns CatalogTable to View, and takes a isTemp flag.

SparkQA · 2020-12-03T05:02:08Z

Kubernetes integration test starting
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/36685/

SparkQA · 2020-12-03T05:30:18Z

Kubernetes integration test status failure
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/36685/

SparkQA · 2020-12-03T05:58:49Z

Test build #132086 has finished for PR 30567 at commit f049fa1.

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

SparkQA · 2020-12-03T08:56:58Z

Test build #132096 has finished for PR 30567 at commit 979daa6.

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

SparkQA · 2020-12-03T09:07:13Z

Kubernetes integration test starting
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/36706/

SparkQA · 2020-12-03T09:20:43Z

Test build #132106 has finished for PR 30567 at commit e19e7e3.

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

SparkQA · 2020-12-03T09:36:13Z

Kubernetes integration test status failure
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/36706/

SparkQA · 2020-12-04T03:38:39Z

Kubernetes integration test status failure
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/36774/

SparkQA · 2020-12-04T04:08:50Z

Kubernetes integration test starting
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/36779/

SparkQA · 2020-12-04T04:39:01Z

Kubernetes integration test status failure
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/36779/

linhongliu-db · 2020-12-04T05:21:40Z

The failed tests are all flaky thrift server cases, should not be caused by this PR.
https://github.com/apache/spark/pull/30567/checks?check_run_id=1496528107

cloud-fan · 2020-12-04T06:20:50Z

sql/catalyst/src/main/scala/org/apache/spark/sql/catalyst/catalog/SessionCatalog.scala

-          tableType = CatalogTableType.VIEW,
-          storage = CatalogStorageFormat.empty,
-          schema = plan.output.toStructType)
+      val a = globalTempViewManager.get(table)


we can remove this line

cloud-fan · 2020-12-04T06:23:36Z

...alyst/src/main/scala/org/apache/spark/sql/catalyst/plans/logical/basicLogicalOperators.scala

    sqlConf
  }
+
+  def fromCatalogTable(


This can be put in SessionCatalog

SparkQA · 2020-12-04T06:37:33Z

Test build #132173 has finished for PR 30567 at commit bc038c5.

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

cloud-fan · 2020-12-04T06:44:14Z

sql/catalyst/src/main/scala/org/apache/spark/sql/catalyst/catalog/SessionCatalog.scala

    }
  }

+  def getTempViewPlan(plan: LogicalPlan): LogicalPlan = {


this can be private.

cloud-fan · 2020-12-04T06:48:46Z

thanks, merging to master! please address these minor comments in a followup.

SparkQA · 2020-12-04T07:09:13Z

Test build #132178 has finished for PR 30567 at commit db9f0ba.

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

### What changes were proposed in this pull request? Addressed comments in PR #30567, including: 1. add test case for SPARK-33647 and SPARK-33142 2. add migration guide 3. add `getRawTempView` and `getRawGlobalTempView` to return the raw view info (i.e. TemporaryViewRelation) 4. other minor code clean ### Why are the changes needed? Code clean and more test cases ### Does this PR introduce _any_ user-facing change? No ### How was this patch tested? Existing and newly added test cases Closes #30666 from linhongliu-db/SPARK-33142-followup. Lead-authored-by: Linhong Liu <[email protected]> Co-authored-by: Linhong Liu <[email protected]> Signed-off-by: Wenchen Fan <[email protected]>

### What changes were proposed in this pull request? Addressed comments in PR #30567, including: 1. add test case for SPARK-33647 and SPARK-33142 2. add migration guide 3. add `getRawTempView` and `getRawGlobalTempView` to return the raw view info (i.e. TemporaryViewRelation) 4. other minor code clean ### Why are the changes needed? Code clean and more test cases ### Does this PR introduce _any_ user-facing change? No ### How was this patch tested? Existing and newly added test cases Closes #30666 from linhongliu-db/SPARK-33142-followup. Lead-authored-by: Linhong Liu <[email protected]> Co-authored-by: Linhong Liu <[email protected]> Signed-off-by: Wenchen Fan <[email protected]> (cherry picked from commit b7c8210) Signed-off-by: Wenchen Fan <[email protected]>

…E TABLE .. AS SELECT" ### What changes were proposed in this pull request? This passes original SQL text to `CacheTableAsSelect` command in DSv1 and v2 so that it will be stored instead of the analyzed logical plan, similar to `CREATE VIEW` command. In addition, this changes the behavior of dropping temporary view to also invalidate dependent caches in a cascade, when the config `SQLConf.STORE_ANALYZED_PLAN_FOR_VIEW` is false (which is the default value). ### Why are the changes needed? Currently, after creating a temporary view with `CACHE TABLE ... AS SELECT` command, the view can still be queried even after the source table is dropped or replaced (in v2). This can cause correctness issue. For instance, in the following: ```sql > CREATE TABLE t ...; > CACHE TABLE v AS SELECT * FROM t; > DROP TABLE t; > SELECT * FROM v; ``` The last select query still returns the old (and stale) result instead of fail. Note that the cache is already invalidated as part of dropping table `t`, but the temporary view `v` still exist. On the other hand, the following: ```sql > CREATE TABLE t ...; > CREATE TEMPORARY VIEW v AS SELECT * FROM t; > CACHE TABLE v; > DROP TABLE t; > SELECT * FROM v; ``` will throw "Table or view not found" error in the last select query. This is related to #30567 which aligns the behavior of temporary view and global view by storing the original SQL text for temporary view, as opposed to the analyzed logical plan. However, the PR only handles `CreateView` case but not the `CacheTableAsSelect` case. This also changes uncache logic and use cascade invalidation for temporary views created above. This is to align its behavior to how a permanent view is handled as of today, and also to avoid potential issues where a dependent view becomes invalid while its data is still kept in cache. ### Does this PR introduce _any_ user-facing change? Yes, now when `SQLConf.STORE_ANALYZED_PLAN_FOR_VIEW` is set to false (the default value), whenever a table/permanent view/temp view that a cached view depends on is dropped, the cached view itself will become invalid during analysis, i.e., user will get "Table or view not found" error. In addition, when the dependent is a temp view in the previous case, the cache itself will also be invalidated. ### How was this patch tested? Modified/Enhanced some existing tests. Closes #31107 from sunchao/SPARK-34052. Lead-authored-by: Chao Sun <[email protected]> Co-authored-by: Chao Sun <[email protected]> Signed-off-by: Wenchen Fan <[email protected]>

…E TABLE .. AS SELECT" This passes original SQL text to `CacheTableAsSelect` command in DSv1 and v2 so that it will be stored instead of the analyzed logical plan, similar to `CREATE VIEW` command. In addition, this changes the behavior of dropping temporary view to also invalidate dependent caches in a cascade, when the config `SQLConf.STORE_ANALYZED_PLAN_FOR_VIEW` is false (which is the default value). Currently, after creating a temporary view with `CACHE TABLE ... AS SELECT` command, the view can still be queried even after the source table is dropped or replaced (in v2). This can cause correctness issue. For instance, in the following: ```sql > CREATE TABLE t ...; > CACHE TABLE v AS SELECT * FROM t; > DROP TABLE t; > SELECT * FROM v; ``` The last select query still returns the old (and stale) result instead of fail. Note that the cache is already invalidated as part of dropping table `t`, but the temporary view `v` still exist. On the other hand, the following: ```sql > CREATE TABLE t ...; > CREATE TEMPORARY VIEW v AS SELECT * FROM t; > CACHE TABLE v; > DROP TABLE t; > SELECT * FROM v; ``` will throw "Table or view not found" error in the last select query. This is related to apache#30567 which aligns the behavior of temporary view and global view by storing the original SQL text for temporary view, as opposed to the analyzed logical plan. However, the PR only handles `CreateView` case but not the `CacheTableAsSelect` case. This also changes uncache logic and use cascade invalidation for temporary views created above. This is to align its behavior to how a permanent view is handled as of today, and also to avoid potential issues where a dependent view becomes invalid while its data is still kept in cache. Yes, now when `SQLConf.STORE_ANALYZED_PLAN_FOR_VIEW` is set to false (the default value), whenever a table/permanent view/temp view that a cached view depends on is dropped, the cached view itself will become invalid during analysis, i.e., user will get "Table or view not found" error. In addition, when the dependent is a temp view in the previous case, the cache itself will also be invalidated. Modified/Enhanced some existing tests. Closes apache#31107 from sunchao/SPARK-34052. Lead-authored-by: Chao Sun <[email protected]> Co-authored-by: Chao Sun <[email protected]> Signed-off-by: Wenchen Fan <[email protected]>

…"CACHE TABLE .. AS SELECT ..." This is a backport of #31107 to branch-3.1. ### What changes were proposed in this pull request? This passes original SQL text to `CacheTableCommand` command in DSv1 so that it will be stored instead of the analyzed logical plan, similar to `CREATE VIEW` command. In addition, this changes the behavior of dropping temporary view to also invalidate dependent caches in a cascade, when the config `SQLConf.STORE_ANALYZED_PLAN_FOR_VIEW` is false (which is the default value). ### Why are the changes needed? Currently, after creating a temporary view with `CACHE TABLE ... AS SELECT` command, the view can still be queried even after the source table is dropped or replaced (in v2). This can cause correctness issue. For instance, in the following: ```sql > CREATE TABLE t ...; > CACHE TABLE v AS SELECT * FROM t; > DROP TABLE t; > SELECT * FROM v; ``` The last select query still returns the old (and stale) result instead of fail. Note that the cache is already invalidated as part of dropping table `t`, but the temporary view `v` still exist. On the other hand, the following: ```sql > CREATE TABLE t ...; > CREATE TEMPORARY VIEW v AS SELECT * FROM t; > CACHE TABLE v; > DROP TABLE t; > SELECT * FROM v; ``` will throw "Table or view not found" error in the last select query. This is related to #30567 which aligns the behavior of temporary view and global view by storing the original SQL text for temporary view, as opposed to the analyzed logical plan. However, the PR only handles `CreateView` case but not the `CacheTableAsSelect` case. This also changes uncache logic and use cascade invalidation for temporary views created above. This is to align its behavior to how a permanent view is handled as of today, and also to avoid potential issues where a dependent view becomes invalid while its data is still kept in cache. ### Does this PR introduce _any_ user-facing change? Yes, now when `SQLConf.STORE_ANALYZED_PLAN_FOR_VIEW` is set to false (the default value), whenever a table/permanent view/temp view that a cached view depends on is dropped, the cached view itself will become invalid during analysis, i.e., user will get "Table or view not found" error. In addition, when the dependent is a temp view in the previous case, the cache itself will also be invalidated. ### How was this patch tested? Added new test cases. Also modified and enhanced some existing related tests. Closes #31300 from sunchao/SPARK-34052-branch-3.1. Authored-by: Chao Sun <[email protected]> Signed-off-by: HyukjinKwon <[email protected]>

…E TABLE .. AS SELECT" ### What changes were proposed in this pull request? This passes original SQL text to `CacheTableAsSelect` command in DSv1 and v2 so that it will be stored instead of the analyzed logical plan, similar to `CREATE VIEW` command. In addition, this changes the behavior of dropping temporary view to also invalidate dependent caches in a cascade, when the config `SQLConf.STORE_ANALYZED_PLAN_FOR_VIEW` is false (which is the default value). ### Why are the changes needed? Currently, after creating a temporary view with `CACHE TABLE ... AS SELECT` command, the view can still be queried even after the source table is dropped or replaced (in v2). This can cause correctness issue. For instance, in the following: ```sql > CREATE TABLE t ...; > CACHE TABLE v AS SELECT * FROM t; > DROP TABLE t; > SELECT * FROM v; ``` The last select query still returns the old (and stale) result instead of fail. Note that the cache is already invalidated as part of dropping table `t`, but the temporary view `v` still exist. On the other hand, the following: ```sql > CREATE TABLE t ...; > CREATE TEMPORARY VIEW v AS SELECT * FROM t; > CACHE TABLE v; > DROP TABLE t; > SELECT * FROM v; ``` will throw "Table or view not found" error in the last select query. This is related to apache#30567 which aligns the behavior of temporary view and global view by storing the original SQL text for temporary view, as opposed to the analyzed logical plan. However, the PR only handles `CreateView` case but not the `CacheTableAsSelect` case. This also changes uncache logic and use cascade invalidation for temporary views created above. This is to align its behavior to how a permanent view is handled as of today, and also to avoid potential issues where a dependent view becomes invalid while its data is still kept in cache. ### Does this PR introduce _any_ user-facing change? Yes, now when `SQLConf.STORE_ANALYZED_PLAN_FOR_VIEW` is set to false (the default value), whenever a table/permanent view/temp view that a cached view depends on is dropped, the cached view itself will become invalid during analysis, i.e., user will get "Table or view not found" error. In addition, when the dependent is a temp view in the previous case, the cache itself will also be invalidated. ### How was this patch tested? Modified/Enhanced some existing tests. Closes apache#31107 from sunchao/SPARK-34052. Lead-authored-by: Chao Sun <[email protected]> Co-authored-by: Chao Sun <[email protected]> Signed-off-by: Wenchen Fan <[email protected]>

…h CTEs ### What changes were proposed in this pull request? This PR: - Fixes a bug that prevents analysis of: ``` CREATE TEMPORARY VIEW temp_view AS WITH cte AS (SELECT temp_func(0)) SELECT * FROM cte; SELECT * FROM temp_view ``` by throwing: ``` Undefined function: 'temp_func'. This function is neither a registered temporary function nor a permanent function registered in the database 'default'. ``` - and doesn't report analysis error when it should: ``` CREATE TEMPORARY VIEW temp_view AS SELECT 0; CREATE VIEW view_on_temp_view AS WITH cte AS (SELECT * FROM temp_view) SELECT * FROM cte ``` by properly collecting temporary objects from VIEW definitions with CTEs. - Minor refactor to make the affected code more readable. ### Why are the changes needed? To fix a bug introduced with #30567 ### Does this PR introduce _any_ user-facing change? Yes, the query works again. ### How was this patch tested? Added new UT + existing ones. Closes #31550 from peter-toth/SPARK-34421-temp-functions-in-views-with-cte. Authored-by: Peter Toth <[email protected]> Signed-off-by: Wenchen Fan <[email protected]> (cherry picked from commit 27abb6a) Signed-off-by: Wenchen Fan <[email protected]>

…h CTEs ### What changes were proposed in this pull request? This PR: - Fixes a bug that prevents analysis of: ``` CREATE TEMPORARY VIEW temp_view AS WITH cte AS (SELECT temp_func(0)) SELECT * FROM cte; SELECT * FROM temp_view ``` by throwing: ``` Undefined function: 'temp_func'. This function is neither a registered temporary function nor a permanent function registered in the database 'default'. ``` - and doesn't report analysis error when it should: ``` CREATE TEMPORARY VIEW temp_view AS SELECT 0; CREATE VIEW view_on_temp_view AS WITH cte AS (SELECT * FROM temp_view) SELECT * FROM cte ``` by properly collecting temporary objects from VIEW definitions with CTEs. - Minor refactor to make the affected code more readable. ### Why are the changes needed? To fix a bug introduced with #30567 ### Does this PR introduce _any_ user-facing change? Yes, the query works again. ### How was this patch tested? Added new UT + existing ones. Closes #31550 from peter-toth/SPARK-34421-temp-functions-in-views-with-cte. Authored-by: Peter Toth <[email protected]> Signed-off-by: Wenchen Fan <[email protected]>

…s with CTEs This PR: - Fixes a bug that prevents analysis of: ``` CREATE TEMPORARY VIEW temp_view AS WITH cte AS (SELECT temp_func(0)) SELECT * FROM cte; SELECT * FROM temp_view ``` by throwing: ``` Undefined function: 'temp_func'. This function is neither a registered temporary function nor a permanent function registered in the database 'default'. ``` - and doesn't report analysis error when it should: ``` CREATE TEMPORARY VIEW temp_view AS SELECT 0; CREATE VIEW view_on_temp_view AS WITH cte AS (SELECT * FROM temp_view) SELECT * FROM cte ``` by properly collecting temporary objects from VIEW definitions with CTEs. - Minor refactor to make the affected code more readable. To fix a bug introduced with apache#30567 Yes, the query works again. Added new UT + existing ones. Closes apache#31550 from peter-toth/SPARK-34421-temp-functions-in-views-with-cte. Authored-by: Peter Toth <[email protected]> Signed-off-by: Wenchen Fan <[email protected]>

store sql text for temp view

09419a6

github-actions bot added the SQL label Dec 2, 2020

linhongliu-db added 2 commits December 2, 2020 21:49

test cases and bug fix

9e65f73

fix test

ba54f31

cloud-fan reviewed Dec 2, 2020

View reviewed changes

sql/core/src/test/scala/org/apache/spark/sql/execution/SQLViewSuite.scala Show resolved Hide resolved

fix test

a0ab11d

cloud-fan reviewed Dec 2, 2020

View reviewed changes

sql/core/src/main/scala/org/apache/spark/sql/execution/command/views.scala Show resolved Hide resolved

cloud-fan reviewed Dec 2, 2020

View reviewed changes

address comment

f049fa1

linhongliu-db added 2 commits December 3, 2020 14:01

fix test

979daa6

fix test

e19e7e3

cloud-fan reviewed Dec 4, 2020

View reviewed changes

linhongliu-db changed the title ~~[SPARK-33142][SQL] Store SQL text for SQL temp view~~ [SPARK-33142][SPARK-33647][SQL] Store SQL text for SQL temp view Dec 4, 2020

cloud-fan reviewed Dec 4, 2020

View reviewed changes

cloud-fan approved these changes Dec 4, 2020

View reviewed changes

cloud-fan closed this in e02324f Dec 4, 2020

linhongliu-db mentioned this pull request Dec 8, 2020

[SPARK-33142][SPARK-33647][SQL][FOLLOW-UP] Add docs and test cases #30666

Closed

This was referenced Jan 10, 2021

[SPARK-34052][SQL] store SQL text for a temp view created using "CACHE TABLE .. AS SELECT" #31107

Closed

[SPARK-34076][SQL] SQLContext.dropTempTable fails if cache is non-empty #31136

Closed

sunchao mentioned this pull request Jan 22, 2021

[SPARK-34052][SQL][3.1] store SQL text for a temp view created using "CACHE TABLE .. AS SELECT ..." #31300

Closed

imback82 mentioned this pull request Jan 23, 2021

[SPARK-34152][SQL] Make CreateViewStatement.child to be LogicalPlan's children so that it's resolved in analyze phase #31273

Closed

peter-toth mentioned this pull request Feb 11, 2021

[SPARK-34421][SQL] Resolve temporary functions and views in views with CTEs #31550

Closed

[SPARK-33142][SPARK-33647][SQL] Store SQL text for SQL temp view #30567

[SPARK-33142][SPARK-33647][SQL] Store SQL text for SQL temp view #30567

Uh oh!

Conversation

linhongliu-db commented Dec 2, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

What changes were proposed in this pull request?

Why are the changes needed?

Does this PR introduce any user-facing change?

How was this patch tested?

Uh oh!

SparkQA commented Dec 2, 2020

Uh oh!

linhongliu-db commented Dec 2, 2020

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

SparkQA commented Dec 2, 2020

Uh oh!

SparkQA commented Dec 2, 2020

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

SparkQA commented Dec 3, 2020

Uh oh!

SparkQA commented Dec 3, 2020

Uh oh!

SparkQA commented Dec 3, 2020

Uh oh!

SparkQA commented Dec 3, 2020

Uh oh!

SparkQA commented Dec 3, 2020

Uh oh!

SparkQA commented Dec 3, 2020

Uh oh!

SparkQA commented Dec 3, 2020

Uh oh!

SparkQA commented Dec 4, 2020

Uh oh!

SparkQA commented Dec 4, 2020

Uh oh!

SparkQA commented Dec 4, 2020

Uh oh!

linhongliu-db commented Dec 4, 2020

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

SparkQA commented Dec 4, 2020

Uh oh!

Choose a reason for hiding this comment

Uh oh!

cloud-fan commented Dec 4, 2020

Uh oh!

SparkQA commented Dec 4, 2020

Uh oh!

Reviewers

Assignees

Labels

linhongliu-db commented Dec 2, 2020 •

edited

Loading