[SPARK-18555][SQL]DataFrameNaFunctions.fill miss up original values in long integers #15994

windpiger · 2016-11-23T13:45:50Z

What changes were proposed in this pull request?

DataSet.na.fill(0) used on a DataSet which has a long value column, it will change the original long value.

The reason is that the type of the function fill's param is Double, and the numeric columns are always cast to double(fillCol[Double](f, value)) .

  def fill(value: Double, cols: Seq[String]): DataFrame = {
    val columnEquals = df.sparkSession.sessionState.analyzer.resolver
    val projections = df.schema.fields.map { f =>
      // Only fill if the column is part of the cols list.
      if (f.dataType.isInstanceOf[NumericType] && cols.exists(col => columnEquals(f.name, col))) {
        fillCol[Double](f, value)
      } else {
        df.col(f.name)
      }
    }
    df.select(projections : _*)
  }

For example:

scala> val df = Seq[(Long, Long)]((1, 2), (-1, -2), (9123146099426677101L, 9123146560113991650L)).toDF("a", "b")
df: org.apache.spark.sql.DataFrame = [a: bigint, b: bigint]

scala> df.show
+-------------------+-------------------+
|                  a|                  b|
+-------------------+-------------------+
|                  1|                  2|
|                 -1|                 -2|
|9123146099426677101|9123146560113991650|
+-------------------+-------------------+

scala> df.na.fill(0).show
+-------------------+-------------------+
|                  a|                  b|
+-------------------+-------------------+
|                  1|                  2|
|                 -1|                 -2|
|9123146099426676736|9123146560113991680|
+-------------------+-------------------+

the original values changed [which is not we expected result]:

 9123146099426677101 -> 9123146099426676736
 9123146560113991650 -> 9123146560113991680

How was this patch tested?

unit test added.

SparkQA · 2016-11-23T14:05:47Z

Test build #69076 has finished for PR 15994 at commit 1ecc21e.

This patch fails MiMa tests.
This patch merges cleanly.
This patch adds no public classes.

srowen · 2016-11-23T14:21:20Z

sql/core/src/main/scala/org/apache/spark/sql/DataFrameNaFunctions.scala

You won't be able to remove public API methods like this. Why is this necessary if the idea is to handle Long differently?

I thought fill[T](value: T) can handle the String Type, then I remove it.....

Doesn't it change the binary signature of the API? That is the problem.

SparkQA · 2016-11-24T04:19:03Z

Test build #69101 has finished for PR 15994 at commit 6cb667e.

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

windpiger · 2016-11-24T05:00:29Z

@srowen I exclude the fill function from mima, is it ok?

SparkQA · 2016-11-24T05:09:10Z

Test build #69106 has finished for PR 15994 at commit 7c23f6f.

This patch fails Scala style tests.
This patch merges cleanly.
This patch adds no public classes.

SparkQA · 2016-11-24T07:03:06Z

Test build #69107 has finished for PR 15994 at commit dbf23a1.

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

windpiger · 2016-11-24T07:08:47Z

cc @cloud-fan

srowen · 2016-11-24T08:00:36Z

project/MimaExcludes.scala

No, as I say, you definitely can't just remove public API methods.

But although it is removed, the fill[T](value T) can handle this. It is backward compatibility. should we must keep the fill(value String) and fill(value Double) function?

The thing is they are not backward compatible at bytecode level, so applications will break if they are not rebuilt.

ok, thanks,I will try another way~

cloud-fan · 2016-11-27T05:51:31Z

sql/core/src/main/scala/org/apache/spark/sql/DataFrameNaFunctions.scala

instead of introducing fill[T], which breaks backward compatibility, can we just add a new version for long type? i.e. def fill(value: Long)

add a long type function is ok. I thought the string/long/double logic is the same ,so I want to merge them by a template function.

this is ok~
windpiger@360eafe

I think we can have a private def fill[T], but the public API can't be changed.

ok, thanks a lot ! I have put it as a private. @cloud-fan

SparkQA · 2016-11-28T04:19:56Z

Test build #69213 has finished for PR 15994 at commit 7117447.

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

SparkQA · 2016-11-28T04:23:24Z

Test build #69214 has finished for PR 15994 at commit 508aaa0.

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

cloud-fan · 2016-11-28T05:52:04Z

sql/core/src/main/scala/org/apache/spark/sql/DataFrameNaFunctions.scala

nit: fill1(value, cols) should work, scala has type inference.

cloud-fan · 2016-11-28T05:52:46Z

sql/core/src/main/scala/org/apache/spark/sql/DataFrameNaFunctions.scala

we don't need (Scala-specific) and the since tag for private methods.

cloud-fan · 2016-11-28T05:57:14Z

sql/core/src/main/scala/org/apache/spark/sql/DataFrameNaFunctions.scala

nit: we can combine the check here:

val targetType = value match { case _: Long => LongType case _: Double => DoubleType case _: String => StringType case _ => throw ... }

cloud-fan · 2016-11-28T06:02:04Z

sql/core/src/main/scala/org/apache/spark/sql/DataFrameNaFunctions.scala

a clearer version:

val typeMatches = (targetType, f.dataType) match { case (LongType, dt) => dt.isInstanceOf[IntergralType] case (DoubleType, dt) => dt.isInstanceOf[FractionType] case (StringType, dt) => if dt == StringType } if (typeMatches && cols.exists(col => columnEquals(f.name, col))) { fillCol... } else ...

Thanks!
I have modified except one:
If T is a double type , this should be apply to all Numeric columns(include LongType/IntegerType), or just apply to FractionType?
The fill(value Double) apply to all Numeric columns, and I think fill(value Long) also keep the logic.

SparkQA · 2016-11-28T07:12:37Z

Test build #69229 has started for PR 15994 at commit 2043283.

cloud-fan · 2016-11-28T08:46:26Z

sql/core/src/main/scala/org/apache/spark/sql/DataFrameNaFunctions.scala

nit: put it in one line? i.e. def fill... = fill1...

cloud-fan · 2016-11-28T08:47:45Z

sql/core/src/main/scala/org/apache/spark/sql/DataFrameNaFunctions.scala

why the T can be Integer and Float?

remove them is ok

cloud-fan · 2016-11-28T08:49:12Z

sql/core/src/main/scala/org/apache/spark/sql/DataFrameNaFunctions.scala

why we match jd.Double here intead of scala Double?

HyukjinKwon · 2016-11-28T08:53:51Z

sql/core/src/main/scala/org/apache/spark/sql/DataFrameNaFunctions.scala

Could I ask change [[DataFrame]] to `DataFrame`? It seems the DataFrame is unrecognisable via unidoc/genjavadoc (see #16013) which ends up with documentation build failure with Java 8.

change them in #16013 is better?

nvm, I will let you know if that one is merged first. If this one is merged first, I will rebase and fix them together.

@HyukjinKwon yeah the bad news is that I'm sure the javadoc generation is going to re-break periodically. we can try to catch it with reviews and your work at least gets it to a working state. But we'll clean it up again before releases regularly.

@windpiger I don't think this was quite resolved -- you need to back-tick DataFrame unfortunately to get it to work with javadoc 8.

SparkQA · 2016-11-28T10:35:48Z

Test build #69231 has finished for PR 15994 at commit 662acfb.

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

SparkQA · 2016-11-28T11:30:19Z

Test build #69236 has finished for PR 15994 at commit d1ba27f.

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

SparkQA · 2016-11-28T11:32:21Z

Test build #69237 has finished for PR 15994 at commit d7dc343.

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

SparkQA · 2016-11-28T11:36:27Z

Test build #69238 has finished for PR 15994 at commit 36bff41.

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

srowen · 2016-11-28T12:34:29Z

sql/core/src/main/scala/org/apache/spark/sql/DataFrameNaFunctions.scala

"fill1" isn't a good name. "fillInternal" maybe?

there is a fill0 function in the class, is there some code name rules which I can refer to

Yeah, that's a poor choice. I'd even suggest renaming it, while you rename this new method too.

what about change fill1 to fillValue ,and change private def fill0(values: Seq[(String, Any)]) to private def fillMap(values: Seq[(String, Any)]) ?

srowen · 2016-11-28T12:39:54Z

sql/core/src/main/scala/org/apache/spark/sql/DataFrameNaFunctions.scala

I think this may be in 2.2.0 in the end

SparkQA · 2016-11-28T16:48:16Z

Test build #69249 has finished for PR 15994 at commit 9f28b83.

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

SparkQA · 2016-12-01T04:33:09Z

Test build #69442 has finished for PR 15994 at commit 4c9f3a0.

This patch passes all tests.
This patch does not merge cleanly.
This patch adds no public classes.

HyukjinKwon · 2016-12-01T04:43:12Z

Hi @windpiger it seems there are conflicts here. Would you try to rebase this please?

…n long integers exclude mima na.fill methodtype modify the comment fix a style fix a style add long type na.fill and add a template func fill[T] remove na.fill from mimaexclude fix style optim and simpliy some code remove boolean type logic remove integer/float type fix style fix a java document modify 2.1.0 to 2.2.0 rename fill0 and fill1 in DataFrameNaFunctions

SparkQA · 2016-12-01T14:26:14Z

Test build #69471 has finished for PR 15994 at commit 7e799fc.

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

srowen · 2016-12-02T12:38:35Z

sql/core/src/main/scala/org/apache/spark/sql/DataFrameNaFunctions.scala

@windpiger I don't think this was quite resolved -- you need to back-tick DataFrame unfortunately to get it to work with javadoc 8.

SparkQA · 2016-12-05T03:29:06Z

Test build #69653 has finished for PR 15994 at commit 431038f.

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

windpiger · 2016-12-05T11:48:05Z

@srowen fixed it.

srowen

That looks reasonable to me though I'd prefer to have @rxin give a final OK

rxin · 2016-12-06T02:39:29Z

Thanks - merging in master.

rxin · 2016-12-06T02:40:30Z

@windpiger you should use a proper email on your github commit next time. It is currently shown as:

Enter primary author in the format of "name <email>" [root <root@iZbp1gsnrlfzjxh82cz80vZ.(none)>]:

windpiger · 2016-12-06T07:30:02Z

ok ,thanks!

…in long integers ## What changes were proposed in this pull request? DataSet.na.fill(0) used on a DataSet which has a long value column, it will change the original long value. The reason is that the type of the function fill's param is Double, and the numeric columns are always cast to double(`fillCol[Double](f, value)`) . ``` def fill(value: Double, cols: Seq[String]): DataFrame = { val columnEquals = df.sparkSession.sessionState.analyzer.resolver val projections = df.schema.fields.map { f => // Only fill if the column is part of the cols list. if (f.dataType.isInstanceOf[NumericType] && cols.exists(col => columnEquals(f.name, col))) { fillCol[Double](f, value) } else { df.col(f.name) } } df.select(projections : _*) } ``` For example: ``` scala> val df = Seq[(Long, Long)]((1, 2), (-1, -2), (9123146099426677101L, 9123146560113991650L)).toDF("a", "b") df: org.apache.spark.sql.DataFrame = [a: bigint, b: bigint] scala> df.show +-------------------+-------------------+ | a| b| +-------------------+-------------------+ | 1| 2| | -1| -2| |9123146099426677101|9123146560113991650| +-------------------+-------------------+ scala> df.na.fill(0).show +-------------------+-------------------+ | a| b| +-------------------+-------------------+ | 1| 2| | -1| -2| |9123146099426676736|9123146560113991680| +-------------------+-------------------+ ``` the original values changed [which is not we expected result]: ``` 9123146099426677101 -> 9123146099426676736 9123146560113991650 -> 9123146560113991680 ``` ## How was this patch tested? unit test added. Author: root <root@iZbp1gsnrlfzjxh82cz80vZ.(none)> Closes apache#15994 from windpiger/nafillMissupOriginalValue.

…in long integers ## What changes were proposed in this pull request? DataSet.na.fill(0) used on a DataSet which has a long value column, it will change the original long value. The reason is that the type of the function fill's param is Double, and the numeric columns are always cast to double(`fillCol[Double](f, value)`) . ``` def fill(value: Double, cols: Seq[String]): DataFrame = { val columnEquals = df.sparkSession.sessionState.analyzer.resolver val projections = df.schema.fields.map { f => // Only fill if the column is part of the cols list. if (f.dataType.isInstanceOf[NumericType] && cols.exists(col => columnEquals(f.name, col))) { fillCol[Double](f, value) } else { df.col(f.name) } } df.select(projections : _*) } ``` For example: ``` scala> val df = Seq[(Long, Long)]((1, 2), (-1, -2), (9123146099426677101L, 9123146560113991650L)).toDF("a", "b") df: org.apache.spark.sql.DataFrame = [a: bigint, b: bigint] scala> df.show +-------------------+-------------------+ | a| b| +-------------------+-------------------+ | 1| 2| | -1| -2| |9123146099426677101|9123146560113991650| +-------------------+-------------------+ scala> df.na.fill(0).show +-------------------+-------------------+ | a| b| +-------------------+-------------------+ | 1| 2| | -1| -2| |9123146099426676736|9123146560113991680| +-------------------+-------------------+ ``` the original values changed [which is not we expected result]: ``` 9123146099426677101 -> 9123146099426676736 9123146560113991650 -> 9123146560113991680 ``` ## How was this patch tested? unit test added. Author: root <rootiZbp1gsnrlfzjxh82cz80vZ.(none)> Closes apache#15994 from windpiger/nafillMissupOriginalValue. ## What changes were proposed in this pull request? (Please fill in changes proposed in this fix) ## How was this patch tested? (Please explain how this patch was tested. E.g. unit tests, integration tests, manual tests) (If this patch involves UI changes, please attach a screenshot; otherwise, remove this) Please review http://spark.apache.org/contributing.html before opening a pull request. Author: root <root@iZbp1gsnrlfzjxh82cz80vZ.(none)> Closes apache#202 from davies/backport_na.

…teger when the default value is in double ## What changes were proposed in this pull request? This bug was partially addressed in SPARK-18555 #15994, but the root cause isn't completely solved. This bug is pretty critical since it changes the member id in Long in our application if the member id can not be represented by Double losslessly when the member id is very big. Here is an example how this happens, with ``` Seq[(java.lang.Long, java.lang.Double)]((null, 3.14), (9123146099426677101L, null), (9123146560113991650L, 1.6), (null, null)).toDF("a", "b").na.fill(0.2), ``` the logical plan will be ``` == Analyzed Logical Plan == a: bigint, b: double Project [cast(coalesce(cast(a#232L as double), cast(0.2 as double)) as bigint) AS a#240L, cast(coalesce(nanvl(b#233, cast(null as double)), 0.2) as double) AS b#241] +- Project [_1#229L AS a#232L, _2#230 AS b#233] +- LocalRelation [_1#229L, _2#230] ``` Note that even the value is not null, Spark will cast the Long into Double first. Then if it's not null, Spark will cast it back to Long which results in losing precision. The behavior should be that the original value should not be changed if it's not null, but Spark will change the value which is wrong. With the PR, the logical plan will be ``` == Analyzed Logical Plan == a: bigint, b: double Project [coalesce(a#232L, cast(0.2 as bigint)) AS a#240L, coalesce(nanvl(b#233, cast(null as double)), cast(0.2 as double)) AS b#241] +- Project [_1#229L AS a#232L, _2#230 AS b#233] +- LocalRelation [_1#229L, _2#230] ``` which behaves correctly without changing the original Long values and also avoids extra cost of unnecessary casting. ## How was this patch tested? unit test added. +cc srowen rxin cloud-fan gatorsmile Thanks. Author: DB Tsai <[email protected]> Closes #17577 from dbtsai/fixnafill.

…in long integers ## What changes were proposed in this pull request? DataSet.na.fill(0) used on a DataSet which has a long value column, it will change the original long value. The reason is that the type of the function fill's param is Double, and the numeric columns are always cast to double(`fillCol[Double](f, value)`) . ``` def fill(value: Double, cols: Seq[String]): DataFrame = { val columnEquals = df.sparkSession.sessionState.analyzer.resolver val projections = df.schema.fields.map { f => // Only fill if the column is part of the cols list. if (f.dataType.isInstanceOf[NumericType] && cols.exists(col => columnEquals(f.name, col))) { fillCol[Double](f, value) } else { df.col(f.name) } } df.select(projections : _*) } ``` For example: ``` scala> val df = Seq[(Long, Long)]((1, 2), (-1, -2), (9123146099426677101L, 9123146560113991650L)).toDF("a", "b") df: org.apache.spark.sql.DataFrame = [a: bigint, b: bigint] scala> df.show +-------------------+-------------------+ | a| b| +-------------------+-------------------+ | 1| 2| | -1| -2| |9123146099426677101|9123146560113991650| +-------------------+-------------------+ scala> df.na.fill(0).show +-------------------+-------------------+ | a| b| +-------------------+-------------------+ | 1| 2| | -1| -2| |9123146099426676736|9123146560113991680| +-------------------+-------------------+ ``` the original values changed [which is not we expected result]: ``` 9123146099426677101 -> 9123146099426676736 9123146560113991650 -> 9123146560113991680 ``` ## How was this patch tested? unit test added. Author: root <root@iZbp1gsnrlfzjxh82cz80vZ.(none)> Closes #15994 from windpiger/nafillMissupOriginalValue. (cherry picked from commit 508de38) Signed-off-by: DB Tsai <[email protected]>

…teger when the default value is in double ## What changes were proposed in this pull request? This bug was partially addressed in SPARK-18555 #15994, but the root cause isn't completely solved. This bug is pretty critical since it changes the member id in Long in our application if the member id can not be represented by Double losslessly when the member id is very big. Here is an example how this happens, with ``` Seq[(java.lang.Long, java.lang.Double)]((null, 3.14), (9123146099426677101L, null), (9123146560113991650L, 1.6), (null, null)).toDF("a", "b").na.fill(0.2), ``` the logical plan will be ``` == Analyzed Logical Plan == a: bigint, b: double Project [cast(coalesce(cast(a#232L as double), cast(0.2 as double)) as bigint) AS a#240L, cast(coalesce(nanvl(b#233, cast(null as double)), 0.2) as double) AS b#241] +- Project [_1#229L AS a#232L, _2#230 AS b#233] +- LocalRelation [_1#229L, _2#230] ``` Note that even the value is not null, Spark will cast the Long into Double first. Then if it's not null, Spark will cast it back to Long which results in losing precision. The behavior should be that the original value should not be changed if it's not null, but Spark will change the value which is wrong. With the PR, the logical plan will be ``` == Analyzed Logical Plan == a: bigint, b: double Project [coalesce(a#232L, cast(0.2 as bigint)) AS a#240L, coalesce(nanvl(b#233, cast(null as double)), cast(0.2 as double)) AS b#241] +- Project [_1#229L AS a#232L, _2#230 AS b#233] +- LocalRelation [_1#229L, _2#230] ``` which behaves correctly without changing the original Long values and also avoids extra cost of unnecessary casting. ## How was this patch tested? unit test added. +cc srowen rxin cloud-fan gatorsmile Thanks. Author: DB Tsai <[email protected]> Closes #17577 from dbtsai/fixnafill. (cherry picked from commit 1a0bc41) Signed-off-by: DB Tsai <[email protected]>

…teger when the default value is in double ## What changes were proposed in this pull request? This bug was partially addressed in SPARK-18555 apache#15994, but the root cause isn't completely solved. This bug is pretty critical since it changes the member id in Long in our application if the member id can not be represented by Double losslessly when the member id is very big. Here is an example how this happens, with ``` Seq[(java.lang.Long, java.lang.Double)]((null, 3.14), (9123146099426677101L, null), (9123146560113991650L, 1.6), (null, null)).toDF("a", "b").na.fill(0.2), ``` the logical plan will be ``` == Analyzed Logical Plan == a: bigint, b: double Project [cast(coalesce(cast(a#232L as double), cast(0.2 as double)) as bigint) AS a#240L, cast(coalesce(nanvl(b#233, cast(null as double)), 0.2) as double) AS b#241] +- Project [_1#229L AS a#232L, _2#230 AS b#233] +- LocalRelation [_1#229L, _2#230] ``` Note that even the value is not null, Spark will cast the Long into Double first. Then if it's not null, Spark will cast it back to Long which results in losing precision. The behavior should be that the original value should not be changed if it's not null, but Spark will change the value which is wrong. With the PR, the logical plan will be ``` == Analyzed Logical Plan == a: bigint, b: double Project [coalesce(a#232L, cast(0.2 as bigint)) AS a#240L, coalesce(nanvl(b#233, cast(null as double)), cast(0.2 as double)) AS b#241] +- Project [_1#229L AS a#232L, _2#230 AS b#233] +- LocalRelation [_1#229L, _2#230] ``` which behaves correctly without changing the original Long values and also avoids extra cost of unnecessary casting. ## How was this patch tested? unit test added. +cc srowen rxin cloud-fan gatorsmile Thanks. Author: DB Tsai <[email protected]> Closes apache#17577 from dbtsai/fixnafill.

srowen reviewed Nov 23, 2016

View reviewed changes

windpiger changed the title ~~[SPARK-18555][SQL]DataFrameNaFunctions.fill miss up original values in long integers~~ [SPARK-18555][SQL][WIP]DataFrameNaFunctions.fill miss up original values in long integers Nov 24, 2016

srowen reviewed Nov 24, 2016

View reviewed changes

windpiger changed the title ~~[SPARK-18555][SQL][WIP]DataFrameNaFunctions.fill miss up original values in long integers~~ [SPARK-18555][SQL]DataFrameNaFunctions.fill miss up original values in long integers Nov 25, 2016

cloud-fan reviewed Nov 27, 2016

View reviewed changes

cloud-fan reviewed Nov 28, 2016

View reviewed changes

HyukjinKwon reviewed Nov 28, 2016

View reviewed changes

srowen requested changes Nov 28, 2016

View reviewed changes

windpiger force-pushed the nafillMissupOriginalValue branch from 4c9f3a0 to 7e799fc Compare December 1, 2016 12:10

srowen requested changes Dec 2, 2016

View reviewed changes

javadoc 8 fix

431038f

srowen approved these changes Dec 6, 2016

View reviewed changes

asfgit closed this in 508de38 Dec 6, 2016

dbtsai mentioned this pull request Apr 9, 2017

[SPARK-20270][SQL] na.fill should not change the values in long or integer when the default value is in double #17577

Closed

[SPARK-18555][SQL]DataFrameNaFunctions.fill miss up original values in long integers #15994

[SPARK-18555][SQL]DataFrameNaFunctions.fill miss up original values in long integers #15994

Uh oh!

Conversation

windpiger commented Nov 23, 2016 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

What changes were proposed in this pull request?

How was this patch tested?

Uh oh!

SparkQA commented Nov 23, 2016

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!

SparkQA commented Nov 24, 2016

Uh oh!

windpiger commented Nov 24, 2016

Uh oh!

SparkQA commented Nov 24, 2016

Uh oh!

SparkQA commented Nov 24, 2016

Uh oh!

windpiger commented Nov 24, 2016

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!

Choose a reason for hiding this comment

Uh oh!

SparkQA commented Nov 28, 2016

Uh oh!

SparkQA commented Nov 28, 2016

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!

cloud-fan Nov 28, 2016 • 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!

Choose a reason for hiding this comment

Uh oh!

SparkQA commented Nov 28, 2016

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!

Choose a reason for hiding this comment

windpiger commented Nov 23, 2016 •

edited

Loading

cloud-fan Nov 28, 2016 •

edited

Loading