-
Notifications
You must be signed in to change notification settings - Fork 28.1k
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-10176][SQL] Show partially analyzed plans when checkAnswer fails to analyze #8389
Conversation
Conflicts: sql/hive/src/test/scala/org/apache/spark/sql/hive/MultiDatabaseSuite.scala
Test build #41441 has finished for PR 8389 at commit
|
Conflicts: sql/hive/src/test/scala/org/apache/spark/sql/hive/ParquetHiveCompatibilitySuite.scala
Test build #41477 has finished for PR 8389 at commit
|
Conflicts: sql/core/src/test/scala/org/apache/spark/sql/execution/datasources/parquet/ParquetCompatibilityTest.scala sql/core/src/test/scala/org/apache/spark/sql/execution/datasources/parquet/ParquetIOSuite.scala sql/hive/src/test/scala/org/apache/spark/sql/hive/QueryPartitionSuite.scala sql/hive/src/test/scala/org/apache/spark/sql/sources/hadoopFsRelationSuites.scala
Test build #41562 has finished for PR 8389 at commit
|
Conflicts: sql/core/src/test/scala/org/apache/spark/sql/execution/datasources/parquet/ParquetCompatibilityTest.scala
Test build #41787 has finished for PR 8389 at commit
|
@andrewor14 this is ready to review |
@@ -17,11 +17,12 @@ | |||
|
|||
package org.apache.spark.sql.hive | |||
|
|||
import org.apache.spark.sql.hive.test.TestHiveSingleton |
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.
nit import order, should move down
Hi @marmbrus @cloud-fan all my comments are minor and this is mergeable as is, but I have two high level comments: (1) I think we should always put (2) Could we make |
Deferring to #8584 |
…ils to analyze This PR takes over #8389. This PR improves `checkAnswer` to print the partially analyzed plan in addition to the user friendly error message, in order to aid debugging failing tests. In doing so, I ran into a conflict with the various ways that we bring a SQLContext into the tests. Depending on the trait we refer to the current context as `sqlContext`, `_sqlContext`, `ctx` or `hiveContext` with access modifiers `public`, `protected` and `private` depending on the defining class. I propose we refactor as follows: 1. All tests should only refer to a `protected sqlContext` when testing general features, and `protected hiveContext` when it is a method that only exists on a `HiveContext`. 2. All tests should only import `testImplicits._` (i.e., don't import `TestHive.implicits._`) Author: Wenchen Fan <cloud0fan@outlook.com> Closes #8584 from cloud-fan/cleanupTests.
…ils to analyze This PR takes over apache/spark#8389. This PR improves `checkAnswer` to print the partially analyzed plan in addition to the user friendly error message, in order to aid debugging failing tests. In doing so, I ran into a conflict with the various ways that we bring a SQLContext into the tests. Depending on the trait we refer to the current context as `sqlContext`, `_sqlContext`, `ctx` or `hiveContext` with access modifiers `public`, `protected` and `private` depending on the defining class. I propose we refactor as follows: 1. All tests should only refer to a `protected sqlContext` when testing general features, and `protected hiveContext` when it is a method that only exists on a `HiveContext`. 2. All tests should only import `testImplicits._` (i.e., don't import `TestHive.implicits._`) Author: Wenchen Fan <cloud0fan@outlook.com> Closes #8584 from cloud-fan/cleanupTests.
This PR improves
checkAnswer
to print the partially analyzed plan in addition to the user friendly error message, in order to aid debugging failing tests.In doing so, I ran into a conflict with the various ways that we bring a SQLContext into the tests. Depending on the trait we refer to the current context as
sqlContext
,_sqlContext
,ctx
orhiveContext
with access modifierspublic
,protected
andprivate
depending on the defining class.I propose we refactor as follows:
protected sqlContext
when testing general features, andprotected hiveContext
when it is a method that only exists on aHiveContext
.testImplicits._
(i.e., don'timport TestHive.implicits._
)I made a pretty good crack at implementing the above, though there may be other outstanding locations. I suggest we address these in a follow up due to the likely hood of conflicts.