[SPARK-21580][SQL]Integers in aggregation expressions are wrongly taken as group-by ordinal by 10110346 · Pull Request #18779 · apache/spark

10110346 · 2017-07-31T04:10:38Z

What changes were proposed in this pull request?

create temporary view data as select * from values
(1, 1),
(1, 2),
(2, 1),
(2, 2),
(3, 1),
(3, 2)
as data(a, b);

select 3, 4, sum(b) from data group by 1, 2;
select 3 as c, 4 as d, sum(b) from data group by c, d;
When running these two cases, the following exception occurred:
Error in query: GROUP BY position 4 is not in select list (valid range is [1, 3]); line 1 pos 10

The cause of this failure:
If an aggregateExpression is integer, after replaced with this aggregateExpression, the
groupExpression still considered as an ordinal.

The solution:
This bug is due to re-entrance of an analyzed plan. We can solve it by using resolveOperators in SubstituteUnresolvedOrdinals.

How was this patch tested?

Added unit test case

viirya · 2017-07-31T04:49:09Z

A specified title for this might be better. Such as "Integers in aggregation expressions are wrongly taken as group-by ordinal".

viirya · 2017-07-31T05:03:59Z

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

We can use pattern matching here like:

ng match { case a: Alias => if (!isIntLiteral(a.child)) filterGroups :+= ng case _ => filterGroups :+= ng }

viirya · 2017-07-31T05:05:55Z

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

Please also fix the indent of code here. Like:

newGroups.foreach { ng => ng match { ... } }

viirya · 2017-07-31T05:06:29Z

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

Please leave a comment explaining why we need to filter the group-by exprs.

viirya · 2017-07-31T05:23:59Z

BTW, we should modify the PR description too. Please briefly describe the problem, what the fix is. Thanks.

10110346 · 2017-07-31T05:57:24Z

Thanks,i will update @viirya

SparkQA · 2017-07-31T06:46:42Z

Test build #80067 has finished for PR 18779 at commit 5319670.

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

maropu · 2017-07-31T08:01:29Z

I checked the root cause of this and SubstituteUnresolvedOrdinals wrongly wraps again int literals with UnresolvedOrdinal.

17/07/31 16:54:50 TRACE HiveSessionStateBuilder$$anon$1:
=== Applying Rule org.apache.spark.sql.catalyst.analysis.SubstituteUnresolvedOrdinals ===
!GlobalLimit 21                                                                           'GlobalLimit 21
!+- LocalLimit 21                                                                         +- 'LocalLimit 21
!   +- Aggregate [3, 4], [3 AS 3#56, 4 AS 4#57, sum(cast(b#1 as bigint)) AS sum(b)#58L]      +- 'Aggregate [unresolvedordinal(3), unresolvedordinal(4)], [3 AS 3#56, 4 AS 4#57, sum(cast(b#1 as bigint)) AS sum(b)#58L]
       +- SubqueryAlias data                                                                    +- SubqueryAlias data
          +- Project [a#0, b#1]                                                                    +- Project [a#0, b#1]
             +- SubqueryAlias data                                                                    +- SubqueryAlias data
                +- LocalRelation [a#0, b#1]                                                              +- LocalRelation [a#0, b#1]

It seems the current fix is similar to RemoveLiteralFromGroupExpressions in the optimizer, so we better move this optimizer rule to here?

viirya · 2017-07-31T08:06:08Z

@maropu I am not sure if I understand your idea correctly. Those int literals in group-by is intended to be wrapped in UnresolvedOrdinal. So they can be replaced with aggregation expressions at the corresponding ordinal position later by ResolveOrdinalInOrderByAndGroupBy.

viirya · 2017-07-31T08:08:22Z

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

Please also comment on why this filtering is safe from changing grouping result. Thanks.

viirya · 2017-07-31T08:10:46Z

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

I think we may need to trim all possible Aliases, e.g., Alias(Alias(1, 'a'), 'b').

Have they been trimmed in aggregateExpressions?

This rule is before CleanupAliases.

maropu · 2017-07-31T08:38:18Z

@viirya sorry for my ambiguous explanation and I mean;

scala> sql("""select 3, 4, sum(b) from data group by 1, 2""").show
17/07/31 17:13:23 TRACE HiveSessionStateBuilder$$anon$1:

// 1. Replace literals in grouping exprs with unresolveordinal here
=== Applying Rule org.apache.spark.sql.catalyst.analysis.SubstituteUnresolvedOrdinals ===
!'Aggregate [1, 2], [unresolvedalias(3, None), unresolvedalias(4, None), unresolvedalias('sum('b), None)]   'Aggregate [unresolvedordinal(1), unresolvedordinal(2)], [unresolvedalias(3, None), unresolvedalias(4, None), unresolvedalias('sum('b), None)]
 +- 'UnresolvedRelation `data`                                                                              +- 'UnresolvedRelation `data`
...

17/07/31 17:13:23 TRACE HiveSessionStateBuilder$$anon$1:

// 2. And then, resolve unresolvedordinal by using agg expressions here (but, the resolved expressions are literals)
=== Applying Rule org.apache.spark.sql.catalyst.analysis.Analyzer$ResolveOrdinalInOrderByAndGroupBy ===
!'Aggregate [unresolvedordinal(1), unresolvedordinal(2)], [3 AS 3#4, 4 AS 4#5, sum(cast(b#1 as bigint)) AS sum(b)#6L]   Aggregate [3 AS 3#4, 4 AS 4#5], [3 AS 3#4, 4 AS 4#5, sum(cast(b#1 as bigint)) AS sum(b)#6L]
 +- SubqueryAlias data                                                                                                  +- SubqueryAlias data
    +- Project [a#0, b#1]                                                                                                  +- Project [a#0, b#1]
       +- SubqueryAlias data                                                                                                  +- SubqueryAlias data
          +- LocalRelation [a#0, b#1]                                                                                            +- LocalRelation [a#0, b#1]
...

17/07/31 17:13:23 TRACE HiveSessionStateBuilder$$anon$1:

// 3. the resolved expressions above are literals, so wrap them with unresolveordinal again here.
=== Applying Rule org.apache.spark.sql.catalyst.analysis.SubstituteUnresolvedOrdinals ===
!GlobalLimit 21                                                                        'GlobalLimit 21
!+- LocalLimit 21                                                                      +- 'LocalLimit 21
!   +- Aggregate [3, 4], [3 AS 3#4, 4 AS 4#5, sum(cast(b#1 as bigint)) AS sum(b)#6L]      +- 'Aggregate [unresolvedordinal(3), unresolvedordinal(4)], [3 AS 3#4, 4 AS 4#5, sum(cast(b#1 as bigint)) AS sum(b)#6L]
       +- SubqueryAlias data                                                                 +- SubqueryAlias data
          +- Project [a#0, b#1]                                                                 +- Project [a#0, b#1]
             +- SubqueryAlias data                                                                 +- SubqueryAlias data
                +- LocalRelation [a#0, b#1]                                                           +- LocalRelation [a#0, b#1]

// 4. Then, it fails here.
org.apache.spark.sql.AnalysisException: GROUP BY position 4 is not in select list (valid range is [1, 3]); line 1 pos 10
  at org.apache.spark.sql.catalyst.analysis.package$AnalysisErrorAt.failAnalysis(package.scala:42)
  at org.apache.spark.sql.catalyst.analysis.Analyzer$ResolveOrdinalInOrderByAndGroupBy$$anonfun$apply$11$$anonfun$43.apply(Analyzer.scala:1008)
  at org.apache.spark.sql.catalyst.analysis.Analyzer$ResolveOrdinalInOrderByAndGroupBy$$anonfun$apply$11$$anonfun$43.apply(Analyzer.scala:1004)
  at scala.collection.TraversableLike$$anonfun$map$1.apply(TraversableLike.scala:234)

I think replacing unresolvedordinals with literals in ResolveOrdinalInOrderByAndGroupBy cause this failure, so we need to avoid this (I know this pr fixes in that way). I feel this solution of this pr is similar to RemoveLiteralFromGroupExpressions in the optimizer, so I though we'd better to move this rule into the analyzer phase.

viirya · 2017-07-31T08:47:12Z

@maropu Thanks for clarifying it.

Although they looks similar, from semantics I'd treat them different rules. However, I don't have strong opinion on this.

Btw, RemoveLiteralFromGroupExpressions reminds me that we should not drop all literal grouping expressions here too.

viirya · 2017-07-31T08:48:58Z

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

Similar to RemoveLiteralFromGroupExpressions, we shouldn't drop all grouping expressions if they are all int literals after resolved from UnresolvedOrdinal.

It looks no problem here, although we drop all grouping expressions

Please see the comments at

spark/sql/catalyst/src/main/scala/org/apache/spark/sql/catalyst/optimizer/Optimizer.scala

Lines 1254 to 1257 in 75b168f

// All grouping expressions are literals. We should not drop them all, because this can

// change the return semantics when the input of the Aggregate is empty (SPARK-17114). We

// instead replace this by single, easy to hash/sort, literal expression.

a.copy(groupingExpressions = Seq(Literal(0, IntegerType)))

. We should not make the grouping expressions empty.

Actually, We have supported GlobalAggregates and group by null

When the aggregates that have an empty input, if we remove all grouping expressions, this triggers the ungrouped code path (which aways returns a single row). So the query semantics are changed.

You meant this is not an issue anymore?

If we reimplement this by using ResolvedOrdinal, we probably need not consider the empty issue here, I think.

@maropu yap, I think so. Because RemoveLiteralFromGroupExpressions takes care of this.

thanks, I'm not very familiar with this module , how to do it?

@10110346 Please see previous comment: #18779 (comment)

The basic idea is, instead of resolve UnresolvedOrdinal to actual aggregate expressions, we resolve it to ResolvedOrdinal.

Then in the beginning of optimization, we replace all ResolvedOrdinal to actual aggregate expressions.

What do you think?

maropu · 2017-07-31T08:53:10Z

yea, just suggestion.

viirya · 2017-07-31T08:53:12Z

@maropu As an alternative approach, we can avoid to resolve UnresolvedOrdinal to actual expressions in this rule.

Instead, we can create a ResolvedOrdinal and replace it with actual agg expression in an optimization rule.

By doing this, we can fix this issue (because we don't replace the int literal with UnresolvedOrdinal again). We also don't need to duplicate the logic of remove literals from grouping expressions.

@10110346 @maropu What do you think?

maropu · 2017-07-31T08:55:11Z

Aha, I feel better idea to add ResolvedOrdinal.

SparkQA · 2017-07-31T09:49:26Z

Test build #80070 has finished for PR 18779 at commit fae3190.

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

SparkQA · 2017-08-01T05:51:18Z

Test build #80105 has finished for PR 18779 at commit a5667c8.

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

10110346 · 2017-08-02T03:42:15Z

@viirya Only to group-by ordinal, i think this is a good idea.
but this will also result in inconsistent processing between order-by ordinal and group-by ordinal.
and i feel that it's more complicated than the current changes

viirya · 2017-08-02T04:21:30Z

@10110346 Can't we also do the same on order by ordinal?

10110346 · 2017-08-02T08:13:16Z

@viirya Maybe adding ResolvedOrdinal is not very well.
I have another problem:
select a, 4 AS k, count(b) from data group by k, 1;
This test case has the same exception:
Error in query: GROUP BY position 4 is not in select list (valid range is [1, 3]); line 1 pos 10

10110346 · 2017-08-02T08:15:50Z

I have updated this PR, please help to review it again. @viirya also cc @cloud-fan @gatorsmile

viirya · 2017-08-02T08:21:13Z

@10110346 Why?

In the query select a, 4 AS k, count(b) from data group by k, 1, 1 is resolved to ResolvedOrdinal(1) first. Then at the beginning of optimization, ResolvedOrdinal(1) is replaced by a.

Is there any problem?

10110346 · 2017-08-02T08:29:26Z

@viirya k is resolved to 4 in ResolveAggAliasInGroupBy,and then 4 is resolved to ResolvedOrdinal(4)

viirya · 2017-08-02T08:36:02Z

Actually I don't think SubstituteUnresolvedOrdinals rule should run with fixedPoint. It should be run with Once.

viirya · 2017-08-04T07:31:12Z

sql/core/src/test/scala/org/apache/spark/sql/DataFrameAggregateSuite.scala

Please also add order-by test too. Maybe add to DataFrameSuite.

viirya · 2017-08-04T09:30:28Z

sql/core/src/test/resources/sql-tests/inputs/group-by-ordinal.sql

Why do we need to have change like this?

viirya · 2017-08-04T09:30:45Z

sql/core/src/test/resources/sql-tests/inputs/order-by-ordinal.sql

Do we still need to keep this change?

it is not necessary, i will remove it.thanks

SparkQA · 2017-08-04T09:43:09Z

Test build #80237 has finished for PR 18779 at commit 791bc33.

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

viirya · 2017-08-04T09:49:37Z

sql/core/src/test/scala/org/apache/spark/sql/DataFrameSuite.scala

I've run this test. Even without transform -> resolveOperators, it still works. Can you check it again?

OK. I see. When we input query like df.select(lit(7), 'a, 'b).orderBy(lit(1), lit(2), lit(3)), the query plan looks like:

Sort [7#22 ASC NULLS FIRST, a#5 ASC NULLS FIRST, b#6 ASC NULLS FIRST], true +- Project [7 AS 7#22, a#5, b#6] +- Project [_1#2 AS a#5, _2#3 AS b#6] +- LocalRelation [_1#2, _2#3]

We have a Project below Sort. The ordinal 1 be replaced with the attribute 7#22. So we won't get an int literal 7 here. That is why it passes.

Can you have a test for ordinal order-by that show different behavior? If not, I think ordinal order-by should be safe from this bug. And we don't need to add this test.

Hmm, maybe we still can keep this test for the case that someone changes the Sort/Project relationship in the future.

viirya · 2017-08-04T10:40:05Z

sql/core/src/test/scala/org/apache/spark/sql/DataFrameAggregateSuite.scala

I've verified that the above tests will fail without this fix.

viirya · 2017-08-04T10:41:42Z

LGTM. cc @gatorsmile for final check.

viirya · 2017-08-04T10:44:43Z

@10110346 Thanks for working this! Sorry I've confused you in previous comments. Current changes looks good to me.

SparkQA · 2017-08-04T11:11:30Z

Test build #80244 has finished for PR 18779 at commit 2dc3610.

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

SparkQA · 2017-08-04T11:49:51Z

Test build #80246 has finished for PR 18779 at commit c1594c7.

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

viirya · 2017-08-04T12:35:22Z

retest this please.

SparkQA · 2017-08-04T15:17:50Z

Test build #80249 has finished for PR 18779 at commit c1594c7.

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

gatorsmile · 2017-08-04T16:35:48Z

sql/core/src/test/scala/org/apache/spark/sql/DataFrameAggregateSuite.scala

One more comment. You need to use withTempView

gatorsmile · 2017-08-04T16:36:24Z

sql/core/src/test/scala/org/apache/spark/sql/DataFrameAggregateSuite.scala

Nit: Please use upper cases for SQL keywords.

gatorsmile · 2017-08-04T16:36:31Z

sql/core/src/test/scala/org/apache/spark/sql/DataFrameAggregateSuite.scala

The same here.

gatorsmile · 2017-08-04T16:36:50Z

sql/core/src/test/scala/org/apache/spark/sql/DataFrameSuite.scala

The same here.

gatorsmile · 2017-08-04T16:37:54Z

LGTM except a few minor comments. The fix looks great now! Thanks everyone!

10110346 · 2017-08-05T02:53:15Z

I learned a lot from you, thanks all.

SparkQA · 2017-08-05T05:29:46Z

Test build #80277 has finished for PR 18779 at commit 2bf42b1.

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

gatorsmile · 2017-08-05T05:54:14Z

Really appreciate your patience and your work! This is how we work in Spark SQL. Thanks!

…ken as group-by ordinal ## What changes were proposed in this pull request? create temporary view data as select * from values (1, 1), (1, 2), (2, 1), (2, 2), (3, 1), (3, 2) as data(a, b); `select 3, 4, sum(b) from data group by 1, 2;` `select 3 as c, 4 as d, sum(b) from data group by c, d;` When running these two cases, the following exception occurred: `Error in query: GROUP BY position 4 is not in select list (valid range is [1, 3]); line 1 pos 10` The cause of this failure: If an aggregateExpression is integer, after replaced with this aggregateExpression, the groupExpression still considered as an ordinal. The solution: This bug is due to re-entrance of an analyzed plan. We can solve it by using `resolveOperators` in `SubstituteUnresolvedOrdinals`. ## How was this patch tested? Added unit test case Author: liuxian <liu.xian3@zte.com.cn> Closes #18779 from 10110346/groupby. (cherry picked from commit 894d5a4) Signed-off-by: gatorsmile <gatorsmile@gmail.com>

gatorsmile · 2017-08-05T05:56:17Z

Thanks! Merging to master/2.2

…ken as group-by ordinal ## What changes were proposed in this pull request? create temporary view data as select * from values (1, 1), (1, 2), (2, 1), (2, 2), (3, 1), (3, 2) as data(a, b); `select 3, 4, sum(b) from data group by 1, 2;` `select 3 as c, 4 as d, sum(b) from data group by c, d;` When running these two cases, the following exception occurred: `Error in query: GROUP BY position 4 is not in select list (valid range is [1, 3]); line 1 pos 10` The cause of this failure: If an aggregateExpression is integer, after replaced with this aggregateExpression, the groupExpression still considered as an ordinal. The solution: This bug is due to re-entrance of an analyzed plan. We can solve it by using `resolveOperators` in `SubstituteUnresolvedOrdinals`. ## How was this patch tested? Added unit test case Author: liuxian <liu.xian3@zte.com.cn> Closes apache#18779 from 10110346/groupby. (cherry picked from commit 894d5a4) Signed-off-by: gatorsmile <gatorsmile@gmail.com>

viirya reviewed Jul 31, 2017

View reviewed changes

10110346 changed the title ~~[SPARK-21580][SQL]There's a bug with Group by ordinal~~ [SPARK-21580][SQL]Integers in aggregation expressions are wrongly taken as group-by ordinal Jul 31, 2017

10110346 force-pushed the groupby branch from 5319670 to fae3190 Compare July 31, 2017 07:12

viirya reviewed Jul 31, 2017

View reviewed changes

10110346 force-pushed the groupby branch from fae3190 to a5667c8 Compare August 1, 2017 03:20

10110346 force-pushed the groupby branch from a5667c8 to 17bdf88 Compare August 2, 2017 08:10

viirya reviewed Aug 4, 2017

View reviewed changes

10110346 force-pushed the groupby branch from 791bc33 to 2dc3610 Compare August 4, 2017 09:02

viirya reviewed Aug 4, 2017

View reviewed changes

sql/core/src/test/resources/sql-tests/inputs/group-by-ordinal.sql Outdated

Copy link

Member

viirya Aug 4, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why do we need to have change like this?

viirya reviewed Aug 4, 2017

View reviewed changes

10110346 force-pushed the groupby branch from 2dc3610 to c1594c7 Compare August 4, 2017 09:47

viirya reviewed Aug 4, 2017

View reviewed changes

gatorsmile reviewed Aug 4, 2017

View reviewed changes

sql/core/src/test/scala/org/apache/spark/sql/DataFrameAggregateSuite.scala Outdated

Copy link

Member

gatorsmile Aug 4, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One more comment. You need to use withTempView

gatorsmile reviewed Aug 4, 2017

View reviewed changes

sql/core/src/test/scala/org/apache/spark/sql/DataFrameAggregateSuite.scala Outdated

Copy link

Member

gatorsmile Aug 4, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: Please use upper cases for SQL keywords.

gatorsmile reviewed Aug 4, 2017

View reviewed changes

sql/core/src/test/scala/org/apache/spark/sql/DataFrameAggregateSuite.scala Outdated

Copy link

Member

gatorsmile Aug 4, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The same here.

gatorsmile reviewed Aug 4, 2017

View reviewed changes

sql/core/src/test/scala/org/apache/spark/sql/DataFrameSuite.scala Outdated

Copy link

Member

gatorsmile Aug 4, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The same here.

group by ordinal

2bf42b1

10110346 force-pushed the groupby branch from c1594c7 to 2bf42b1 Compare August 5, 2017 02:50

asfgit closed this in 894d5a4 Aug 5, 2017

	// All grouping expressions are literals. We should not drop them all, because this can
	// change the return semantics when the input of the Aggregate is empty (SPARK-17114). We
	// instead replace this by single, easy to hash/sort, literal expression.
	a.copy(groupingExpressions = Seq(Literal(0, IntegerType)))

Conversation

10110346 commented Jul 31, 2017 • 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!

viirya commented Jul 31, 2017

Uh oh!

viirya Jul 31, 2017 • 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!

viirya Jul 31, 2017 • 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!

viirya commented Jul 31, 2017

Uh oh!

10110346 commented Jul 31, 2017

Uh oh!

SparkQA commented Jul 31, 2017

Uh oh!

maropu commented Jul 31, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

viirya commented Jul 31, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

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!

maropu commented Jul 31, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

viirya commented Jul 31, 2017

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!

maropu Aug 1, 2017 • 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!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

maropu commented Jul 31, 2017

Uh oh!

viirya commented Jul 31, 2017

Uh oh!

maropu commented Jul 31, 2017

Uh oh!

SparkQA commented Jul 31, 2017

Uh oh!

SparkQA commented Aug 1, 2017

Uh oh!

10110346 commented Aug 2, 2017

Uh oh!

viirya commented Aug 2, 2017

Uh oh!

10110346 commented Aug 2, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

10110346 commented Jul 31, 2017 •

edited

Loading

viirya Jul 31, 2017 •

edited

Loading

viirya Jul 31, 2017 •

edited

Loading

maropu commented Jul 31, 2017 •

edited

Loading

viirya commented Jul 31, 2017 •

edited

Loading

maropu commented Jul 31, 2017 •

edited

Loading

maropu Aug 1, 2017 •

edited

Loading

10110346 commented Aug 2, 2017 •

edited

Loading

10110346 commented Aug 2, 2017 •

edited

Loading