[SPARK-27209][SQL] Split parsing of SELECT and INSERT into two top-level rules in the grammar file. #24150

dilipbiswal · 2019-03-20T05:14:08Z

What changes were proposed in this pull request?

Currently in the grammar file the rule query is responsible to parse both select and insert statements. As a result, we need to have more semantic checks in the code to guard against in-valid insert constructs in a query. Couple of examples are in the visitCreateView and visitAlterView functions. One other issue is that, we don't catch the invalid insert constructs in all the places until checkAnalysis (the errors we raise can be confusing as well). Here are couple of examples :

select * from (insert into bar values (2));

Error in query: unresolved operator 'Project [*];
'Project [*]
+- SubqueryAlias `__auto_generated_subquery_name`
   +- InsertIntoHiveTable `default`.`bar`, org.apache.hadoop.hive.serde2.lazy.LazySimpleSerDe, false, false, [c1]
      +- Project [cast(col1#18 as int) AS c1#20]
         +- LocalRelation [col1#18]

select * from foo where c1 in (insert into bar values (2))

Error in query: cannot resolve '(default.foo.`c1` IN (listquery()))' due to data type mismatch: 
The number of columns in the left hand side of an IN subquery does not match the
number of columns in the output of subquery.
#columns in left hand side: 1.
#columns in right hand side: 0.

Left side columns:
[default.foo.`c1`].
Right side columns:
[].;;
'Project [*]
+- 'Filter c1#6 IN (list#5 [])
   :  +- InsertIntoHiveTable `default`.`bar`, org.apache.hadoop.hive.serde2.lazy.LazySimpleSerDe, false, false, [c1]
   :     +- Project [cast(col1#7 as int) AS c1#9]
   :        +- LocalRelation [col1#7]
   +- SubqueryAlias `default`.`foo`
      +- HiveTableRelation `default`.`foo`, org.apache.hadoop.hive.serde2.lazy.LazySimpleSerDe, [c1#6]

For both the cases above, we should reject the syntax at parser level.

In this PR, we create two top-level parser rules to parse SELECT and INSERT respectively.
I will create a small PR to allow CTEs in DESCRIBE QUERY after this PR is in.

How was this patch tested?

Added tests to PlanParserSuite and removed the semantic check tests from SparkSqlParserSuites.

dilipbiswal · 2019-03-20T05:15:04Z

cc @cloud-fan @maropu @dongjoon-hyun

SparkQA · 2019-03-20T07:05:02Z

Test build #103708 has finished for PR 24150 at commit edb7440.

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

dilipbiswal · 2019-03-20T07:09:32Z

retest this please

cloud-fan · 2019-03-20T11:00:52Z

sql/catalyst/src/main/antlr4/org/apache/spark/sql/catalyst/parser/SqlBase.g4

-    : insertInto? queryTerm queryOrganization                                              #singleInsertQuery
-    | fromClause multiInsertQueryBody+                                                     #multiInsertQuery
+    : queryTerm queryOrganization                                               #noWithQuery
+    | fromClause querySpecification queryOrganization                           #queryWithFrom


where does this come from?

@cloud-fan This is required to parse statement of the form code

Why isn't it covered by insertStatement? We have (ctes)? fromClause multiInsertQueryBody+ there

@cloud-fan Actually this is sort of tricky.. I initially didn't have this rule thinking insertStatement should take care of this. But it didn't .

FROM (FROM TEST SELECT TRANSFORM(KEY, VALUE) USING 'CAT' AS (`THING1` INT, THING2 STRING)) T SELECT THING1 + 1

In this case, we have nested from clause. and the inner from is handled by rule aliasedQuery. If we see the definition, it calls queryNoWith and we resolve the nested FROM along with querySpecification(the transform query) by using queryNoWith:queryWithFrom rule.

cloud-fan · 2019-03-20T11:03:36Z

sql/catalyst/src/test/scala/org/apache/spark/sql/catalyst/parser/PlanParserSuite.scala

+    val sql1 =
+      """
+        |CREATE VIEW testView AS FROM jt
+        |INSERT INTO tbl1 SELECT * WHERE jt.id < 5 " +


INSERT INTO tbl1 SELECT * WHERE jt.id < 5 " + INSERT INTO tbl2 SELECT * WHERE jt.id > 4

what are we testing for it?

@cloud-fan oops.. will fix.

SparkQA · 2019-03-20T11:19:17Z

Test build #103713 has finished for PR 24150 at commit edb7440.

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

SparkQA · 2019-03-20T11:29:47Z

Test build #103715 has finished for PR 24150 at commit edb7440.

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

cloud-fan · 2019-03-20T13:06:59Z

sql/catalyst/src/main/antlr4/org/apache/spark/sql/catalyst/parser/SqlBase.g4

@@ -354,9 +355,14 @@ resource
    : identifier STRING
    ;

+insertStatement
+    : (ctes)? insertInto queryTerm queryOrganization                                       #singleInsertQuery
+    | (ctes)? fromClause multiInsertQueryBody+                                             #multiInsertQuery


shall we change the multiInsertQueryBody and make the insertInto non-optional?

@cloud-fan did you mean make insertInto non-optional in multiInsertQueryBody ? If so, i did try it and we need it to be optional to parse statement referenced in test
Also , we we can have a mixture of insert and selects in the multiInsertQueryBody. Thats why we have it under a "multi insert" rule where insert is optional. Not sure, but i think multiStatementBody may be a better name for the rule.

why do we still need https://github.com/apache/spark/pull/24150/files#diff-8c1cb2af4aa1109e08481dae79052cc3R365 ?

@cloud-fan If you don't mind, could you please paste the block or line here ? When i click on that link, it shows me pretty much all the changes so i am not sure which one i should focus on.

@dilipbiswal . He means line 365. And, that's the same question with the below comment, https://github.com/apache/spark/pull/24150/files#r267283726.

| fromClause querySpecification queryOrganization #queryWithFrom

Line 365 is required for FROM ... SELECT ... statement.

@dongjoon-hyun Thanks for helping out. When i clicked.. it took me to AstBuilder ... so i was confused.

@cloud-fan So we need the rule to parse statement i mentioned earlier.

from (from test select transform(....) using .. as ...) T select ...

It is parsed sort of recursively in the queryNoWith rule .. calling queryNoWith from relationPrimary:aliasedQuery rule.

fromClause multiInsertQueryBody+ -> fromClause (insertInto? querySpecification queryOrganization)+ -> fromClause (querySpecification queryOrganization)+

and in queryNoWith, we have fromClause querySpecification queryOrganization. Seems we should change it to fromClause (querySpecification queryOrganization)+

@cloud-fan Currently after this change, fromClause and multiple querySpecification queryOrganization will be handled by 2nd alternative of the insertStatement. I know that this may look confusing. In this pass, i wanted to handle single queries in one rule which is query. This would help us catch quite a few errors i.e when a user could plugin an insert in any part of the query. The rest is currently handled by insertStatement which includes multi insert, multi select etc. Please let me know what you think.

@cloud-fan instead of name insertStatement, should we change to insertOrMultiQueries to clear the confusion ?

dongjoon-hyun · 2019-03-20T19:51:44Z

sql/catalyst/src/main/antlr4/org/apache/spark/sql/catalyst/parser/SqlBase.g4

 queryNoWith
-    : insertInto? queryTerm queryOrganization                                              #singleInsertQuery
-    | fromClause multiInsertQueryBody+                                                     #multiInsertQuery
+    : queryTerm queryOrganization                                               #noWithQuery


Actually, queryNoWith has these two patterns. And both don't have With. Can we revise this name #noWithQuery more narrowly?

@dongjoon-hyun would you have any suggestion ? I was thinking selectQuery but this matches select, table query, inline table etc. So a little confused :-)

dongjoon-hyun · 2019-03-20T19:59:07Z

sql/catalyst/src/test/scala/org/apache/spark/sql/catalyst/parser/PlanParserSuite.scala

@@ -754,4 +754,29 @@ class PlanParserSuite extends AnalysisTest {
      assertEqual(query2, Distinct(a.union(b)).except(c.intersect(d, isAll = true), isAll = true))
    }
  }
+
+  test("create/alter view as insert into table") {
+    intercept[ParseException](parsePlan("CREATE VIEW testView AS INSERT INTO jt VALUES(1, 1)"))


~~Ur, is this a behavior change? Previously, this seems to be AnalysisException with Operation not allowed: CREATE VIEW ... AS INSERT INTO.~~ My bad. It was the same ParseException.

BTW, let's check the exception message always.

@dongjoon-hyun For parser exceptions, we would have list of expected tokens which may change in future to make this a little fragile (we may need to update the error message frequently) ? Thats why i didn't check the exact message text here.
if you want it checked, would it be better to put it in SQlQueryTestSuite (perhaps easy to regenerate the output file) ? Let me know what you think.

Oh, that means a subtle behavior change. There is no more kind message like Operation not allowed: ?

@dongjoon-hyun Let me paste a sample error from the describe query test.

DESCRIBE FROM desc_temp1 a insert into desc_temp1 select * insert into desc_temp2 select * -- !query 13 schema struct<> -- !query 13 output org.apache.spark.sql.catalyst.parser.ParseException mismatched input 'insert' expecting {<EOF>, '(', ',', 'ANTI', 'CLUSTER', 'CROSS', 'DISTRIBUTE', 'EXCEPT', 'FULL', 'GROUP', 'HAVING', 'INNER', 'INTERSECT', 'JOIN', 'LATERAL', 'LEFT', 'LIMIT', 'NATURAL', 'ORDER', 'PIVOT', 'RIGHT', 'SELECT', 'SEMI', 'MINUS', 'SORT', 'UNION', 'WHERE', 'WINDOW'}(line 3, pos 5)

I am thinking, this is coming from antlr itself as it knows the expected grammar ?

@dongjoon-hyun I will do a contains and look for "mismatched input" like we do in test "select hint syntax". hopefully its ok.

dongjoon-hyun · 2019-03-20T20:01:11Z

sql/catalyst/src/test/scala/org/apache/spark/sql/catalyst/parser/PlanParserSuite.scala

+        |INSERT INTO tbl2 SELECT * WHERE jt.id > 4
+      """.stripMargin
+    intercept[ParseException](parsePlan(sql1))
+    intercept[ParseException](parsePlan("ALTER VIEW testView AS INSERT INTO jt VALUES(1, 1)"))


sql/catalyst/src/test/scala/org/apache/spark/sql/catalyst/parser/PlanParserSuite.scala

SparkQA · 2019-03-20T20:42:20Z

Test build #103726 has finished for PR 24150 at commit 5033981.

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

SparkQA · 2019-03-21T02:31:03Z

Test build #103742 has finished for PR 24150 at commit e651e14.

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

viirya · 2019-03-21T16:03:38Z

sql/catalyst/src/main/antlr4/org/apache/spark/sql/catalyst/parser/SqlBase.g4

-    : insertInto? queryTerm queryOrganization                                              #singleInsertQuery
-    | fromClause multiInsertQueryBody+                                                     #multiInsertQuery
+    : queryTerm queryOrganization                                               #noWithQuery
+    | fromClause querySpecification queryOrganization                           #queryWithFrom


Previously there can be multiple multiInsertQueryBody. Looks like there will be an Union for the inserts. Because the insertInto is optional, I think it can a fromClause and multiple querySpecification queryOrganization. But looks like the new rule doesn't allow it?

@viirya Currently after this change, fromClause and multiple querySpecification queryOrganization will be handled by 2nd alternative of the insertStatement rule ?

viirya · 2019-03-21T16:04:24Z

sql/catalyst/src/main/scala/org/apache/spark/sql/catalyst/parser/AstBuilder.scala

+  override def visitQueryWithFrom(ctx: QueryWithFromContext): LogicalPlan = withOrigin(ctx) {
+    val from = visitFromClause(ctx.fromClause)
+    validate(ctx.querySpecification.fromClause == null,
+      "Script transformation queries cannot have a FROM clause in their" +


Am I missing anything, is this related to script transformation?

@viirya First of all you are absolutely right. I could use your suggestion here. So what this is guarding against is of query of following form :

FROM foo select c1 from foo

So this has nothing to do with script transformation :-). I don't know what to call this kind of query as ? Should we say "Individual select statement can not have FROM cause as its already specified in the outer query block" ?

Individual select statement can not have FROM cause as its already specified in the outer query block SGTM

@cloud-fan Thank you. will change.

Thank you @viirya

viirya · 2019-03-21T16:11:15Z

sql/catalyst/src/main/antlr4/org/apache/spark/sql/catalyst/parser/SqlBase.g4

@@ -354,9 +355,14 @@ resource
    : identifier STRING
    ;

+insertStatement
+    : (ctes)? insertInto queryTerm queryOrganization                                       #singleInsertQuery
+    | (ctes)? fromClause multiInsertQueryBody+                                             #multiInsertQuery


I also think why we keep insertInto as optional in multiInsertQueryBody after this change, if we want to split select and insert to individual rule.

We cannot write it like this?

insertStatement : ... | (ctes)? fromClause insertInto someName (insertInto? someName) #multiInsertQuery ; someName : querySpecification queryOrganization ;

maropu · 2019-03-22T00:23:03Z

sql/catalyst/src/main/antlr4/org/apache/spark/sql/catalyst/parser/SqlBase.g4

@@ -354,9 +355,14 @@ resource
    : identifier STRING
    ;

+insertStatement
+    : (ctes)? insertInto queryTerm queryOrganization                                       #singleInsertQuery


Can you move (ctes)? to the line 80 like | (ctes)? insertStatement ?

@maropu then i may have to implement/override another visit method to apply the cte to an insert statement, okay ?

the duplicate patten?

queryToDesc : queryTerm queryOrganization ;

@maropu Thats right. After this PR is in, i will have a follow-up to allow CTEs for DESCRIBE QUERY (currently it is a limitation) and that would remove this pattern all together (i hope :-) ).

dilipbiswal · 2019-03-22T15:31:46Z

@cloud-fan @viirya
Update
Basically i was trying to understand and answer the question both of you have raised which is
why make insertInto optional if we are splitting insert and select ?

The only test that fails after making insertInto mandatory in multiInsertQueryBody is PlanParserSuite:"test("multi select query")". Currently we allow multi insert and multi select queries like following :

FROM T1
INSERT INTO T2 SELECT WHERE <condition>
INSERT INTO T3 SELECT WHERE <another_condition>

AND

FROM T1
SELECT C1 WHERE <condition>
SELECT C1 WHERE <another_condition>

Given only the planParseSuite is affected, my thinking is , this multi select support is NOT really something we were designing to support. What we wanted to support is a insert into.. select from. Currently we plan the multi-select queries by simply unioning each branch. My question is , is this something we should continue to support ? Since there are better ways to support union queries, i am wondering why would users ever want to use this way ? WDYT ?

cloud-fan · 2019-03-22T16:55:04Z

I don't think the multi-select is valid syntax, what is the expected result? And what we get if we run a multi-select in real? Do we get an exception?

dilipbiswal · 2019-03-22T17:02:52Z

@cloud-fan It works :-) .. here is the output snippet :

spark-sql> select * from foo;
1
2
Time taken: 0.112 seconds, Fetched 2 row(s)
spark-sql> from foo
         > select c1 where c1 = 1
         > select c1 where c1 = 2;
1
2
Time taken: 0.218 seconds, Fetched 2 row(s)

It basically turns into :

  select c1 from foo where c1 = 1
  union all
  select c1 from foo where c1 = 2

What i don't know is if it is designed to work or its simply a side effect of supporting multi insert.

dilipbiswal · 2019-03-22T17:08:43Z

@cloud-fan and the error if we specify the from clause on a multi select query to add to the confusion :-)

spark-sql> from foo
         > select c1 from foo where c1 = 1
         > select c1 from foo where c1 = 2;
Error in query: 
Multi-Insert queries cannot have a FROM clause in their individual SELECT statements(line 2, pos 0)

== SQL ==
from foo
select c1 from foo where c1 = 1
^^^
select c1 from foo where c1 = 2

Please note the reference to "insert" .. even though there is no insert in the query.

cloud-fan · 2019-03-22T17:13:36Z

damn, then this is something we can't break, even if it's not designed this way.

Can we create a special parser rule for it? Also add a comment to say that we support it for history reasons.

dilipbiswal · 2019-03-22T17:15:39Z

@cloud-fan Sure. will do.

…ules in the grammar file.

viirya · 2019-03-23T03:10:23Z

damn, then this is something we can't break, even if it's not designed this way.
Can we create a special parser rule for it? Also add a comment to say that we support it for history reasons.

I knew for compatibility we usually don't break such thing. But for a major version like 3.0, can't we break it?

SparkQA · 2019-03-23T22:04:48Z

Test build #103846 has finished for PR 24150 at commit ea05263.

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

dilipbiswal · 2019-03-26T00:08:37Z

@cloud-fan Please let me know if this looks ok now. Thank you.

cloud-fan · 2019-03-26T00:43:22Z

thanks, merging to master!

dilipbiswal · 2019-03-26T00:48:46Z

Thank you very much @cloud-fan @viirya @maropu @dongjoon-hyun

…vel rules in the grammar file. Currently in the grammar file the rule `query` is responsible to parse both select and insert statements. As a result, we need to have more semantic checks in the code to guard against in-valid insert constructs in a query. Couple of examples are in the `visitCreateView` and `visitAlterView` functions. One other issue is that, we don't catch the `invalid insert constructs` in all the places until checkAnalysis (the errors we raise can be confusing as well). Here are couple of examples : ```SQL select * from (insert into bar values (2)); ``` ``` Error in query: unresolved operator 'Project [*]; 'Project [*] +- SubqueryAlias `__auto_generated_subquery_name` +- InsertIntoHiveTable `default`.`bar`, org.apache.hadoop.hive.serde2.lazy.LazySimpleSerDe, false, false, [c1] +- Project [cast(col1#18 as int) AS c1#20] +- LocalRelation [col1#18] ``` ```SQL select * from foo where c1 in (insert into bar values (2)) ``` ``` Error in query: cannot resolve '(default.foo.`c1` IN (listquery()))' due to data type mismatch: The number of columns in the left hand side of an IN subquery does not match the number of columns in the output of subquery. Left side columns: [default.foo.`c1`]. Right side columns: [].;; 'Project [*] +- 'Filter c1#6 IN (list#5 []) : +- InsertIntoHiveTable `default`.`bar`, org.apache.hadoop.hive.serde2.lazy.LazySimpleSerDe, false, false, [c1] : +- Project [cast(col1#7 as int) AS c1#9] : +- LocalRelation [col1#7] +- SubqueryAlias `default`.`foo` +- HiveTableRelation `default`.`foo`, org.apache.hadoop.hive.serde2.lazy.LazySimpleSerDe, [c1#6] ``` For both the cases above, we should reject the syntax at parser level. In this PR, we create two top-level parser rules to parse `SELECT` and `INSERT` respectively. I will create a small PR to allow CTEs in DESCRIBE QUERY after this PR is in. Added tests to PlanParserSuite and removed the semantic check tests from SparkSqlParserSuites. Closes apache#24150 from dilipbiswal/split-query-insert. Authored-by: Dilip Biswal <dbiswal@us.ibm.com> Signed-off-by: Wenchen Fan <wenchen@databricks.com>

chrisknoll · 2020-01-26T02:04:58Z

Apologies on crashing the party on this closed PR, but my question relates directly to the parsing of INSERT statements:

Related to the ANSI SQL specification for insert syntax, could the parsing and underlying engine support the syntax of:
INSERT INTO <table> (<column list>) select <columns list) from <otherTable>

I think I read somewhere that there's some underlying technical detail where the columns inserted into SPARK tables must have the selected columns match the order of the table definition. But, if this is the case, isn't' there a place in the parser-layer and execution-layer where the parser can translate something like:

insert into someTable (col1,col2)
select someCol1, someCol2 from otherTable

Where someTable has 3 columns (col3,col2,col1) (note the order here), the query is rewritten and sent to the engine as:

insert into someTable
select null, someCol2, someCol1 from otherTable

Note, the reordering and adding of the null column was done based on some table metadata on someTable so it knew which columns from the INSERT() map over to the columns from the select.

Is this possible? The lack of specifying column values is preventing our project from SPARK being a supported platform.

cloud-fan · 2020-01-30T11:35:15Z

This is unrelated to this PR but is a reasonable feature request. One missing part is the default column value, we should support it as well instead of always using null as the default value. It is still valuable to support this SQL syntax so that we can reorder the columns during insertion. Feel free to open a JIRA ticket/PR!

maropu · 2020-02-05T06:29:43Z

I remember we already have the tickets for the related topics, e.g., https://issues.apache.org/jira/browse/SPARK-21548 (#18756) and https://issues.apache.org/jira/browse/SPARK-20845 (#22532). Could you check them first? If there is a difference between your suggestion and these tickets, please file a jira!

chrisknoll · 2020-02-05T12:29:23Z

You are correct, apologies I didn't know about the jira issue tracking that was separate from github. You are correct that those issues do cover what I'm talking about here.

The closest PR was this one: #22532 but has been closed to inactivity. So, sadface on that.

cloud-fan reviewed Mar 20, 2019

View reviewed changes

dongjoon-hyun reviewed Mar 20, 2019

View reviewed changes

sql/catalyst/src/test/scala/org/apache/spark/sql/catalyst/parser/PlanParserSuite.scala Outdated Show resolved Hide resolved

dongjoon-hyun reviewed Mar 20, 2019

View reviewed changes

sql/catalyst/src/test/scala/org/apache/spark/sql/catalyst/parser/PlanParserSuite.scala Outdated Show resolved Hide resolved

viirya reviewed Mar 21, 2019

View reviewed changes

maropu reviewed Mar 22, 2019

View reviewed changes

dilipbiswal added 4 commits March 22, 2019 17:47

[SPARK-27209] Split parsing of SELECT and INSERT into two top-level r…

0e61c95

…ules in the grammar file.

Code review

fa07a73

Code review

18afacd

separate rule for multi inserts

f7aaebd

dilipbiswal force-pushed the split-query-insert branch from e25f2d0 to f7aaebd Compare March 23, 2019 00:51

Code review

ea05263

cloud-fan closed this in 9cc925c Mar 26, 2019

cloud-fan mentioned this pull request Apr 11, 2019

[SPARK-27444][SQL] multi-select can be used in subquery #24348

Closed

[SPARK-27209][SQL] Split parsing of SELECT and INSERT into two top-level rules in the grammar file. #24150

[SPARK-27209][SQL] Split parsing of SELECT and INSERT into two top-level rules in the grammar file. #24150

Conversation

dilipbiswal commented Mar 20, 2019 • edited

What changes were proposed in this pull request?

How was this patch tested?

dilipbiswal commented Mar 20, 2019 • edited

SparkQA commented Mar 20, 2019

dilipbiswal commented Mar 20, 2019

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

dilipbiswal Mar 21, 2019 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

SparkQA commented Mar 20, 2019

SparkQA commented Mar 20, 2019

cloud-fan Mar 20, 2019 • edited

Choose a reason for hiding this comment

dilipbiswal Mar 20, 2019 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

dilipbiswal Mar 21, 2019 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

dongjoon-hyun Mar 20, 2019 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

dongjoon-hyun Mar 20, 2019 • edited

Choose a reason for hiding this comment

dilipbiswal Mar 20, 2019 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

SparkQA commented Mar 20, 2019

SparkQA commented Mar 21, 2019

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

dilipbiswal Mar 21, 2019 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

dilipbiswal Mar 22, 2019 • edited

Choose a reason for hiding this comment

dilipbiswal commented Mar 22, 2019 • edited

cloud-fan commented Mar 22, 2019

dilipbiswal commented Mar 22, 2019

dilipbiswal commented Mar 22, 2019

cloud-fan commented Mar 22, 2019

dilipbiswal commented Mar 22, 2019

viirya commented Mar 23, 2019

SparkQA commented Mar 23, 2019

dilipbiswal commented Mar 26, 2019

cloud-fan commented Mar 26, 2019

dilipbiswal commented Mar 26, 2019

chrisknoll commented Jan 26, 2020

cloud-fan commented Jan 30, 2020

maropu commented Feb 5, 2020

chrisknoll commented Feb 5, 2020 • edited

dilipbiswal commented Mar 20, 2019 •

edited

dilipbiswal commented Mar 20, 2019 •

edited

dilipbiswal Mar 21, 2019 •

edited

cloud-fan Mar 20, 2019 •

edited

dilipbiswal Mar 20, 2019 •

edited

dilipbiswal Mar 21, 2019 •

edited

dongjoon-hyun Mar 20, 2019 •

edited

dongjoon-hyun Mar 20, 2019 •

edited

dilipbiswal Mar 20, 2019 •

edited

dilipbiswal Mar 21, 2019 •

edited

dilipbiswal Mar 22, 2019 •

edited

dilipbiswal commented Mar 22, 2019 •

edited

chrisknoll commented Feb 5, 2020 •

edited