[SPARK-20680][SQL] Spark-sql do not support for creating table with void column datatype #28833

LantaoJin · 2020-06-15T08:49:49Z

What changes were proposed in this pull request?

This is the new PR which to address the close one #17953

support "void" primitive data type in the AstBuilder, point it to NullType
forbid creating tables with VOID/NULL column type

Why are the changes needed?

Spark is incompatible with hive void type. When Hive table schema contains void type, DESC table will throw an exception in Spark.

hive> create table bad as select 1 x, null z from dual;
hive> describe bad;
OK
x int
z void

In Spark2.0.x, the behaviour to read this view is normal:

spark-sql> describe bad;
x int NULL
z void NULL
Time taken: 4.431 seconds, Fetched 2 row(s)

But in lastest Spark version, it failed with SparkException: Cannot recognize hive type string: void

spark-sql> describe bad;
17/05/09 03:12:08 ERROR thriftserver.SparkSQLDriver: Failed in [describe bad]
org.apache.spark.SparkException: Cannot recognize hive type string: void
Caused by: org.apache.spark.sql.catalyst.parser.ParseException:
DataType void() is not supported.(line 1, pos 0)
== SQL ==
void
^^^
... 61 more
org.apache.spark.SparkException: Cannot recognize hive type string: void

Hive CTAS statements throws error when select clause has NULL/VOID type column since HIVE-11217
In Spark, creating table with a VOID/NULL column should throw readable exception message, include

create data source table (using parquet, json, ...)
create hive table (with or without stored as)
CTAS

Does this PR introduce any user-facing change?

No

How was this patch tested?

Add unit tests

…of view

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

HyukjinKwon · 2020-06-15T11:26:42Z

cc @maropu, @cloud-fan, @dongjoon-hyun, @hvanhovell, @gatorsmile FYI

sql/catalyst/src/main/scala/org/apache/spark/sql/types/NullType.scala

SparkQA · 2020-06-15T12:08:54Z

Test build #124046 has finished for PR 28833 at commit 3b8ddec.

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

maropu · 2020-06-15T16:29:37Z

sql/hive/src/test/scala/org/apache/spark/sql/hive/execution/HiveDDLSuite.scala

+          spark.sharedState.externalCatalog.unwrapped.asInstanceOf[HiveExternalCatalog].client
+        client.runSqlHive("CREATE TABLE t (t1 int)")
+        client.runSqlHive("INSERT INTO t VALUES (3)")
+        client.runSqlHive("CREATE VIEW tabNullType AS SELECT NULL AS col FROM t")


We need the t table for this test? We cannot write CREATE VIEW tabNullType AS SELECT NULL AS col?

Yes. table t is needed, otherwise InvalidTableException: Table not found _dummy_table exception throws.

SparkQA · 2020-06-15T17:46:13Z

Test build #124056 has finished for PR 28833 at commit cf0db98.

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

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

maropu · 2020-06-16T00:35:14Z

Btw, could you brush up the PR description for better commit logs? what's the proposal of this PR, what's a behaivor change before/after this PR, brabrabra... I feel the curren one looks a bit ambiougous...

HyukjinKwon · 2020-06-16T01:25:05Z

Let's also follow the new GitHub PR template - https://github.com/apache/spark/blob/master/.github/PULL_REQUEST_TEMPLATE

SparkQA · 2020-06-16T05:16:51Z

Test build #124080 has finished for PR 28833 at commit 479901d.

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

maropu · 2020-06-16T05:18:41Z

retest this please

SparkQA · 2020-06-16T07:05:01Z

Test build #124098 has finished for PR 28833 at commit 479901d.

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

maropu · 2020-06-16T10:31:48Z

retest this please

cloud-fan · 2020-06-16T11:49:00Z

To confirm: In Hive, people can't create tables with the void type (including void type inside struct/array/map). The only way is CTAS. Is this true?

And how about Spark?

SparkQA · 2020-06-16T16:15:51Z

Test build #124121 has finished for PR 28833 at commit 479901d.

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

wangyum

How about adding another HiveNullType, like HiveStringType?

spark/sql/catalyst/src/main/scala/org/apache/spark/sql/types/HiveStringType.scala

Lines 65 to 81 in 4f274a4

    
           /** 
        
            * Hive char type. Similar to other HiveStringType's, these datatypes should only used for 
        
            * parsing, and should NOT be used anywhere else. Any instance of these data types should be 
        
            * replaced by a [[StringType]] before analysis. 
        
            */ 
        
           case class CharType(length: Int) extends HiveStringType { 
        
             override def simpleString: String = s"char($length)" 
        
           } 
        
           /** 
        
            * Hive varchar type. Similar to other HiveStringType's, these datatypes should only used for 
        
            * parsing, and should NOT be used anywhere else. Any instance of these data types should be 
        
            * replaced by a [[StringType]] before analysis. 
        
            */ 
        
           case class VarcharType(length: Int) extends HiveStringType { 
        
             override def simpleString: String = s"varchar($length)" 
        
           }

Could we add another test case?

create table t1 stored as parquet as select null as null_col;

CTAS statements throws error when select clause has NULL/VOID type column since HIVE-11217

cloud-fan · 2020-06-23T04:32:00Z

@wangyum that said, only legacy Hive tables can have VOID column type?

It's also good to list the current Spark behaviors. I think it makes sense to forbid creating tables with VOID column type, maybe we can do that with an analyzer rule.

LantaoJin · 2020-06-23T07:16:43Z

Emmm, thanks @wangyum . I think we should keep the same behavior with Hive2.x. Throw more readable exceptions for below SQLs.

create table t as select 1 x, null z from dual;
create table t as select null as null_col
create table t (v void);

@cloud-fan

cloud-fan · 2020-06-23T11:28:07Z

Does hive support inner void like struct<v: void>, array<void>, etc.?

LantaoJin · 2020-06-24T00:41:27Z

Success in Hive 2.3.7:

create table t (col1 struct<name:STRING, id: BIGINT>);
create table t (col1 array<STRING>);

Fail with NoViableAltException in Hive 2.3.7:

create table t (col1 struct<name:VOID, id: BIGINT>);
create table t (col1 array<VOID>);

cloud-fan · 2020-06-24T04:48:39Z

Can we have another PR to forbid creating tables with void type, via an analyzer rule?

dongjoon-hyun · 2020-07-08T01:57:19Z

Merged to master. Thank you for your patience, @LantaoJin .
(The last commit is only about HiveDDLSuite. I tested it locally.)

SparkQA · 2020-07-08T02:23:47Z

Test build #125270 has finished for PR 28833 at commit 9ad57d1.

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

LantaoJin · 2020-07-08T03:41:59Z

Thank you for all kindly review.

HyukjinKwon · 2020-07-08T04:34:35Z

Re: #28833 (comment)

Sorry I read the comments just now. So the decision here is we allow to parse void as NullType but doesn't allow it in some commands like CREATE TABLEs.

How about other cases when we directly use DDL-formatted string as its type? These simple type strings can be used in many places such as from_csv (schema as DDL formatted string), from_json (schema as DDL formatted string), createDataFrame (Python), etc. However, StructType.simpleString cannot still be parsed as the valid types.

HyukjinKwon · 2020-07-08T04:37:59Z

If we're going to treat void as Hive legacy, let's don't support it at all and make the direction to deprecate and remove NullType away.

If we'll still care and have NullType, let's make it a proper type in Spark.

If we're not sure, let's don't change simpleString to something else for now.

dongjoon-hyun · 2020-07-08T05:17:20Z

First of all, it's not a good idea to add NullType into a new Spark datatype officially. Not only the exposure causes more complexity, but also what can we do in Spark SQL world (https://spark.apache.org/docs/latest/sql-ref-datatypes.html) if that is an official type?

If we'll still care and have NullType, let's make it a proper type in Spark.

Previously, this was supported until Apache Spark 2.0.0. After that, Apache Spark didn't support void. This PR also tried to forbid VOID. AstBuilder provides a way for graceful warning. Currently, we are very careful even in the error message, we didn't mention void type. We called it unknown type. I believe this PR is one way to implement your idea, too. Of course, we can add more messages, too.

If we're going to treat void as Hive legacy, let's don't support it at all and make the direction to deprecate and remove NullType away.

In any way, since this is a legitimate suggestion from @HyukjinKwon , cc @gatorsmile , too.

cloud-fan · 2020-07-08T05:22:29Z

NullType is a stable public class, I don't think we can drop it.

The intention is to only allow parsing NullType for the type string of legacy hive tables. But @HyukjinKwon is right that it also affects places like from_csv. Let's revert this part and think of a better solution.

We don't document NullType in SQL reference. I think it's better to hide NullType from end-users. It's usually type-coercioned to other official types, and this PR forbids NullType if it leaks to the end (top columns). df.show is still OK to have NullType though. I agree that NullType.simpleString update can be put in a separate PR and discussed separately.

dongjoon-hyun · 2020-07-08T05:28:51Z

Could you make a follow-up(full revert or partial revert) as what you suggest, @HyukjinKwon ?

HyukjinKwon · 2020-07-08T05:40:14Z

Thanks guys, sure. I will make a followup.

…own' to 'null' ### What changes were proposed in this pull request? This PR proposes to partially reverts the simple string in `NullType` at #28833: `NullType.simpleString` back from `unknown` to `null`. ### Why are the changes needed? - Technically speaking, it's orthogonal with the issue itself, SPARK-20680. - It needs some more discussion, see #28833 (comment) ### Does this PR introduce _any_ user-facing change? It reverts back the user-facing changes at #28833. The simple string of `NullType` is back to `null`. ### How was this patch tested? I just logically reverted. Jenkins should test it out. Closes #29041 from HyukjinKwon/SPARK-20680. Authored-by: HyukjinKwon <gurwls223@apache.org> Signed-off-by: Dongjoon Hyun <dongjoon@apache.org>

ulysses-you · 2020-07-13T04:50:57Z

What about view ?
After this pr we have no readable exception, and also not support to create view with NullType.

When execute create view v1 as select null as col, the exception is

org.apache.spark.SparkException: Cannot recognize hive type string: null, column: col
  at org.apache.spark.sql.hive.client.HiveClientImpl$.getSparkSQLDataType(HiveClientImpl.scala:999)
  at org.apache.spark.sql.hive.client.HiveClientImpl$.$anonfun$verifyColumnDataType$1(HiveClientImpl.scala:1021)
  at scala.collection.Iterator.foreach(Iterator.scala:941)
  at scala.collection.Iterator.foreach$(Iterator.scala:941)
  at scala.collection.AbstractIterator.foreach(Iterator.scala:1429)
  at scala.collection.IterableLike.foreach(IterableLike.scala:74)
  at scala.collection.IterableLike.foreach$(IterableLike.scala:73)
  at org.apache.spark.sql.types.StructType.foreach(StructType.scala:102)
  at org.apache.spark.sql.hive.client.HiveClientImpl$.org$apache$spark$sql$hive$client$HiveClientImpl$$verifyColumnDataType(HiveClientImpl.scala:1021)
  at org.apache.spark.sql.hive.client.HiveClientImpl.$anonfun$createTable$1(HiveClientImpl.scala:547)

cloud-fan · 2020-07-13T05:35:53Z

@ulysses-you does it work before this PR?

ulysses-you · 2020-07-13T06:22:13Z

@cloud-fan doesn't work. We should choose a plan that forbid or support.

dongjoon-hyun · 2020-07-13T06:25:29Z

Hi, @ulysses-you . We already choose the plan. This is a step to forbid that gracefully.
For create view v1 as select null as col, we can add an AnalysisException if you want.
Could you file a JIRA for that?

ulysses-you · 2020-07-16T00:06:54Z

@dongjoon-hyun @cloud-fan Sorry for this, but I need to reconfirm that do we decide to forbid both of in-memory and hive ?

Currently, we support create view v as select null with in-memory, but failed with hive.

dongjoon-hyun · 2020-07-16T00:35:07Z

I guess we can forbid that too consistently as a continuation of this approach.
BTW, until now, it's beyond of the scope because this PR was designed to prevent Hive void type.
Since Apache Spark doesn't talk to Apache Hive Metastore in case of in-memory catalog, other PMC member may has a different opinion.

cloud-fan · 2020-07-16T06:15:43Z

I don't think it's a good idea to diverge the behavior between in-memory and hive catalogs.

ulysses-you · 2020-07-18T10:49:07Z

I have created a SPARK-32356/#29152 to forbid this.

zsxwing · 2021-04-13T17:50:23Z

sql/core/src/main/scala/org/apache/spark/sql/catalyst/analysis/ResolveSessionCatalog.scala

    // session catalog and the table provider is not v2.
    case c @ CreateTableStatement(
         SessionCatalogAndTable(catalog, tbl), _, _, _, _, _, _, _, _, _) =>
+      assertNoNullTypeInSchema(c.tableSchema)


It would be great if we could add a legacy flag for such behavior change in future. This changes the behavior for both v1 and v2 Catalogs in order to fix a compatibility issue with Hive Metastore. But Hive Metastore is not the only Catalog Spark supports since we have opened the Catalog APIs in DSv2.

I don't know any database that supports creating tables with null/void type column, so this change is not for hive compatibility but for reasonable SQL semantic.

I agree this is a breaking change that should be at least put in the migration guide. A legacy config can also be added but I can't find a reasonable use case for a null type column.

I don't know any database that supports creating tables with null/void type column, so this change is not for hive compatibility but for reasonable SQL semantic.

I agree this is a breaking change that should be at least put in the migration guide. A legacy config can also be added but I can't find a reasonable use case for a null type column.

I think the main reason why you would want to support it is when people are using tables / views / temp tables to structure existing workloads. We support NullType type in CTEs, but in the case where people want to reuse the same CTE in multiple queries (i.e., multi-output workloads), they have no choice but to use views or temporary tables. (With DataFrames they'd still be able to reuse the same dataframe for multiple outputs, but in SQL that doesn't work.)

One typical use case where you use CTEs to structure your code is if you have multiple sources with different structures that you then UNION ALL together into a single dataset. It is not uncommon for each of the sources to have certain columns that don't apply, and then you write explicit NULLs there. It would be pretty annoying if you had to write explicit casts of those NULLs to the right type in all of those cases.

@bart-samwel this makes sense, shall we also support CREATE TABLE t(c VOID)? Your case seems like CTAS only.

@bart-samwel this makes sense, shall we also support CREATE TABLE t(c VOID)? Your case seems like CTAS only.

I think the CREATE TABLE case with explicit types is not very useful, but it could be useful if there were tools that get a table's schema and then try to recreate it, e.g. for mocking purposes. Probably best to be orthogonal here.

@LantaoJin do you have time to fix it? I think we can simply remove the null type check and add a few tests with both in-memory and hive catalog.

### What changes were proposed in this pull request? Previously we blocked creating tables with the null column to follow the hive behavior in PR #28833 In this PR, I propose the restore the previous behavior to support the null column in a table. ### Why are the changes needed? For a complex query, it's possible to generate a column with null type. If this happens to the input query of CTAS, the query will fail due to Spark doesn't allow creating a table with null type. From the user's perspective, it’s hard to figure out why the null type column is produced in the complicated query and how to fix it. So removing this constraint is more friendly to users. ### Does this PR introduce _any_ user-facing change? Yes, this reverts the previous behavior change in #28833, for example, below command will success after this PR ```sql CREATE TABLE t (col_1 void, col_2 int) ``` ### How was this patch tested? newly added and existing test cases Closes #33488 from linhongliu-db/SPARK-36241-support-void-column. Authored-by: Linhong Liu <linhong.liu@databricks.com> Signed-off-by: Wenchen Fan <wenchen@databricks.com>

### What changes were proposed in this pull request? Previously we blocked creating tables with the null column to follow the hive behavior in PR #28833 In this PR, I propose the restore the previous behavior to support the null column in a table. ### Why are the changes needed? For a complex query, it's possible to generate a column with null type. If this happens to the input query of CTAS, the query will fail due to Spark doesn't allow creating a table with null type. From the user's perspective, it’s hard to figure out why the null type column is produced in the complicated query and how to fix it. So removing this constraint is more friendly to users. ### Does this PR introduce _any_ user-facing change? Yes, this reverts the previous behavior change in #28833, for example, below command will success after this PR ```sql CREATE TABLE t (col_1 void, col_2 int) ``` ### How was this patch tested? newly added and existing test cases Closes #33488 from linhongliu-db/SPARK-36241-support-void-column. Authored-by: Linhong Liu <linhong.liu@databricks.com> Signed-off-by: Wenchen Fan <wenchen@databricks.com> (cherry picked from commit 8e7e14d) Signed-off-by: Wenchen Fan <wenchen@databricks.com>

### What changes were proposed in this pull request? Change the `NullType.simpleString` to "void" to set "void" as the formal type name of `NullType` ### Why are the changes needed? This PR is intended to address the type name discussion in PR #28833. Here are the reasons: 1. The type name of NullType is displayed everywhere, e.g. schema string, error message, document. Hence it's not possible to hide it from users, we have to choose a proper name 2. The "void" is widely used as the type name of "NULL", e.g. Hive, pgSQL 3. Changing to "void" can enable the round trip of `toDDL`/`fromDDL` for NullType. (i.e. make `from_json(col, schema.toDDL)`) work ### Does this PR introduce _any_ user-facing change? Yes, the type name of "NULL" is changed from "null" to "void". for example: ``` scala> sql("select null as a, 1 as b").schema.catalogString res5: String = struct<a:void,b:int> ``` ### How was this patch tested? existing test cases Closes #33437 from linhongliu-db/SPARK-36224-void-type-name. Authored-by: Linhong Liu <linhong.liu@databricks.com> Signed-off-by: Wenchen Fan <wenchen@databricks.com>

### What changes were proposed in this pull request? Change the `NullType.simpleString` to "void" to set "void" as the formal type name of `NullType` ### Why are the changes needed? This PR is intended to address the type name discussion in PR #28833. Here are the reasons: 1. The type name of NullType is displayed everywhere, e.g. schema string, error message, document. Hence it's not possible to hide it from users, we have to choose a proper name 2. The "void" is widely used as the type name of "NULL", e.g. Hive, pgSQL 3. Changing to "void" can enable the round trip of `toDDL`/`fromDDL` for NullType. (i.e. make `from_json(col, schema.toDDL)`) work ### Does this PR introduce _any_ user-facing change? Yes, the type name of "NULL" is changed from "null" to "void". for example: ``` scala> sql("select null as a, 1 as b").schema.catalogString res5: String = struct<a:void,b:int> ``` ### How was this patch tested? existing test cases Closes #33437 from linhongliu-db/SPARK-36224-void-type-name. Authored-by: Linhong Liu <linhong.liu@databricks.com> Signed-off-by: Wenchen Fan <wenchen@databricks.com> (cherry picked from commit 2f70077) Signed-off-by: Wenchen Fan <wenchen@databricks.com>

LantaoJin added 3 commits June 3, 2017 19:04

[SPARK-20680][SQL] Spark-sql do not support for void column datatype …

fda353f

…of view

[SPARK-20680][SQL] re-generate golden files

1e86674

Merge remote-tracking branch 'upstream/master' into SPARK-20680

3b8ddec

probot-autolabeler bot added the SQL label Jun 15, 2020

LantaoJin mentioned this pull request Jun 15, 2020

[SPARK-20680][SQL] Spark-sql do not support for void column datatype … #17953

Closed

ulysses-you reviewed Jun 15, 2020

View reviewed changes

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

HyukjinKwon reviewed Jun 15, 2020

View reviewed changes

sql/catalyst/src/main/scala/org/apache/spark/sql/types/NullType.scala Outdated Show resolved Hide resolved

address comment

cf0db98

probot-autolabeler bot added the PYTHON label Jun 15, 2020

maropu reviewed Jun 15, 2020

View reviewed changes

fix ut

479901d

maropu reviewed Jun 16, 2020

View reviewed changes

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

LantaoJin changed the title ~~[SPARK-20680][SQL] Spark-sql do not support for void column datatype~~ [SPARK-20680][SQL] Make null type in Spark sql to be compatible with Hive void datatype Jun 16, 2020

wangyum reviewed Jun 23, 2020

View reviewed changes

test case adjustment

9ad57d1

dongjoon-hyun closed this in b5297c4 Jul 8, 2020

HyukjinKwon mentioned this pull request Jul 8, 2020

[SPARK-20680][SQL][FOLLOW-UP] Revert NullType.simpleString from 'unknown' to 'null' #29041

Closed

ulysses-you mentioned this pull request Jul 18, 2020

[SPARK-32356][SQL] Forbid create view with null type #29152

Closed

zsxwing reviewed Apr 13, 2021

View reviewed changes

This was referenced Jul 22, 2021

[SPARK-36224][SQL] Use Void as the type name of NullType #33437

Closed

[SPARK-36241][SQL] Support creating tables with null column #33488

Closed

wmoustafa mentioned this pull request Oct 5, 2021

Translation of NULL column from Hive to Trino linkedin/coral#148

Open

	/**
	* Hive char type. Similar to other HiveStringType's, these datatypes should only used for
	* parsing, and should NOT be used anywhere else. Any instance of these data types should be
	* replaced by a [[StringType]] before analysis.
	*/
	case class CharType(length: Int) extends HiveStringType {
	override def simpleString: String = s"char($length)"
	}

	/**
	* Hive varchar type. Similar to other HiveStringType's, these datatypes should only used for
	* parsing, and should NOT be used anywhere else. Any instance of these data types should be
	* replaced by a [[StringType]] before analysis.
	*/
	case class VarcharType(length: Int) extends HiveStringType {
	override def simpleString: String = s"varchar($length)"
	}

[SPARK-20680][SQL] Spark-sql do not support for creating table with void column datatype #28833

[SPARK-20680][SQL] Spark-sql do not support for creating table with void column datatype #28833

Uh oh!

Conversation

LantaoJin commented Jun 15, 2020 • edited by dongjoon-hyun 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!

Uh oh!

HyukjinKwon commented Jun 15, 2020

Uh oh!

Uh oh!

SparkQA commented Jun 15, 2020

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

SparkQA commented Jun 15, 2020

Uh oh!

Uh oh!

maropu commented Jun 16, 2020

Uh oh!

HyukjinKwon commented Jun 16, 2020

Uh oh!

SparkQA commented Jun 16, 2020

Uh oh!

maropu commented Jun 16, 2020

Uh oh!

SparkQA commented Jun 16, 2020

Uh oh!

maropu commented Jun 16, 2020

Uh oh!

cloud-fan commented Jun 16, 2020

Uh oh!

SparkQA commented Jun 16, 2020

Uh oh!

wangyum left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

cloud-fan commented Jun 23, 2020

Uh oh!

LantaoJin commented Jun 23, 2020

Uh oh!

cloud-fan commented Jun 23, 2020

Uh oh!

LantaoJin commented Jun 24, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

cloud-fan commented Jun 24, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

dongjoon-hyun commented Jul 8, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

SparkQA commented Jul 8, 2020

Uh oh!

LantaoJin commented Jul 8, 2020

Uh oh!

HyukjinKwon commented Jul 8, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

HyukjinKwon commented Jul 8, 2020

Uh oh!

dongjoon-hyun commented Jul 8, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

cloud-fan commented Jul 8, 2020

Uh oh!

dongjoon-hyun commented Jul 8, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

HyukjinKwon commented Jul 8, 2020

Uh oh!

ulysses-you commented Jul 13, 2020

Uh oh!

LantaoJin commented Jun 15, 2020 •

edited by dongjoon-hyun

Loading

wangyum left a comment •

edited

Loading

LantaoJin commented Jun 24, 2020 •

edited

Loading

cloud-fan commented Jun 24, 2020 •

edited

Loading

dongjoon-hyun commented Jul 8, 2020 •

edited

Loading

HyukjinKwon commented Jul 8, 2020 •

edited

Loading

dongjoon-hyun commented Jul 8, 2020 •

edited

Loading

dongjoon-hyun commented Jul 8, 2020 •

edited

Loading

dongjoon-hyun commented Jul 13, 2020 •

edited

Loading

dongjoon-hyun commented Jul 16, 2020 •

edited

Loading