New docs on expressions and constants #1008

knz · 2017-01-17T16:05:27Z

Fixes #992.

This change is

cockroach-teamcity · 2017-01-17T21:51:31Z

http://cockroach-docs-review.s3-website-us-east-1.amazonaws.com/fe1b2e99645d1324ce682d04ae816f4a6cc62f4e/

jseldess

Whoa! Amazing work, @knz! Thank you so much for taking this on.

I'm reviewing in two batches. Here are suggestions/questions on the changes to the existing data type pages. Next, I'll review the new pages.

jseldess · 2017-01-19T14:53:37Z

bytes.md

- String literal: `'a1b2c3'`
-
-You can also use these in combination, for example, `b'\141\061\x62\x32\c3'`.
+When it is not ambiguous, a string literal can also be automatically


I find this statement ambiguous ;). @arjunravinarayan also wasn't quite certain about the intention. Can you be more explicit about when a string is not ambiguous? What that means exactly? Perhaps an example?

I reworded to clarify.

jseldess · 2017-01-19T15:11:09Z

data-types.md

+- `<value>::<data type>`, or its equivalent longer form `CAST(<value> AS <data type>)`, which converts an arbitrary expression of one built-in type to another (this is also known as type coercion or "casting"). For example:
+  `NOW()::DECIMAL`, `VARIANCE(a+2)::INT`.
+
+  **Note that in many cases it is advisable to use an


Nice tip! 2 suggestions:

Instead of bolding the whole thing, let's format it as an actual tip. Here's how (plus some suggested copy edits):

{{site.data.alerts.callout_success}} In many cases, it is recommended to use a [type annotation](sql-expressions.html#explicitly-typed-expression) instead of a coercion to create a value of an arbitrary type. {{site.data.alerts.end}}

Should we add a bit of explanation about why type annotation is better in most cases?

I have added the callout thing and a more clearly worded recommendation.

jseldess · 2017-01-19T15:14:44Z

date.md

+The string format for dates is `YYYY-MM-DD`. For example: `DATE '2016-12-23'`.	 

-Note that in some contexts, dates may be displayed with hours, minutes, seconds, and timezone set to 0.
+When it is unambiguous, a simple unannotated string literal can also


Same as my comment on bytes.md. I don't understand what we're trying to say here. Can you please be more explicit, rephrase, perhaps include an example, if necessary?

jseldess · 2017-01-19T15:25:23Z

float.md


 ## Format

 When inserting into a `FLOAT` column, format the value as a numeric literal, e.g., `1.2345` or `1`.


Let's change the section title to Syntax and replace the first sentence with:

Values of type `FLOAT` must be expressed as [numeric literals](sql-constants.html#numeric-literals).

jseldess · 2017-01-19T15:26:25Z

float.md

+For more details about `FLOAT` numeric formats,
+see the section on [SQL constants](sql-constants.html).
+
+The special IEEE754 values for positive infinity, negative infinity


Let's change interpreted literal to a link:

[interpreted literal](sql-constants.html#interpreted-literals)

jseldess · 2017-01-19T15:42:52Z

int.md

-### Hexadecimal-Encoded Numeric Literal
-
-When inserting a hexadecimal-encoded numeric literal into a `INT` column, format the value as hexadecimal digits preceded by `0x`. For example, `0xcafe1111` corresponds to the numeric literal `3405648145`.
+See the section on [numeric literals](sql-constants.html#numeric-literals) for more details.


As above, let's change the section title to Syntax and replace this sentence with:

Values of type `INT` must be expressed as [numeric literals](sql-constants.html#numeric-literals).

jseldess · 2017-01-19T15:44:45Z

serial.md

 ---

-The `SERIAL` [data type](data-types.html) defaults to a unique 64-bit signed integer. The default value is the combination of the insert timestamp and the ID of the node executing the insert. This combination is guaranteed to be globally unique. Also, because value generation does not require talking to other nodes, it is much faster than sequentially auto-incrementing a value, which requires distributed coordination.
+The `SERIAL` [data type](data-types.html) is a column data type which


Thanks for strengthening this! While you're here, can you rename the Format section to Syntax?

jseldess · 2017-01-19T15:47:17Z

string.md

 ## Formats

-A `STRING` column accepts Unicode string literals, hexadecimal string literals, and escape strings. 
+A `STRING` constant can be expressed using a variety of formats,


Let's retitle this section Syntax and, for consistency, rephrase the content a bit:

Values of type `STRING` can be expressed in a variety of formats. See [string literals](sql-constants.html#string-literals) for more details.

jseldess · 2017-01-19T15:48:19Z

string.md

-For example, the `e'x61\141\u0061'` escape string represents the hexadecimal byte, octal byte, and 16-bit hexadecimal Unicode character values equivalent to the `'aaa'` string literal. 
-
-Note that any character not in the table above is taken literally in an escape string. Also, when continuing an escape string across lines, write `e` or `E` only before the first opening quote.
+When printing out a `STRING` value in the SQL shell, the shell uses the simple


Let's make SQL shell a link:

[SQL shell](use-the-built-in-sql-client.html)

jseldess · 2017-01-19T15:56:24Z

timestamp.md

+[coerced to](sql-expressions.html#explicit-type-coercions) type
+`TIMESTAMP`/`TIMESTAMPTZ`.
+
+`TIMESTAMP` constants can be expressed using the


You removed this type of guidance from other type pages - I assume because the details are available in your value expressions doc? Should we do the same here, or is there a risk that they won't find the correct details via link?

DATE/INTERVAL/TIMESTAMP constants are not lexical elements and thus not distinguishable as separate constant categories in the page "SQL constants". However I agree that a mutual xref was missing; I added it.

sploiselle · 2017-01-19T16:16:30Z

Review status: 0 of 14 files reviewed at latest revision, 17 unresolved discussions, some commit checks failed.

bytes.md, line 20 at r1 (raw file):

## Formats

To express a byte array constant, see the section on

Quick note before I do a more thorough review: for this and all other data types, I would like to see at least one example of formatting left on the page. The idea being that I can jump to the page and get the information I'm most likely to need, and then find a link to deeper reference material only if I need it.

Comments from Reviewable

jseldess · 2017-01-19T16:22:28Z

bytes.md, line 20 at r1 (raw file):

Previously, sploiselle (Sean Loiselle) wrote…

Quick note before I do a more thorough review: for this and all other data types, I would like to see at least one example of formatting left on the page. The idea being that I can jump to the page and get the information I'm most likely to need, and then find a link to deeper reference material only if I need it.

@knz, although I didn't say as much in my review, I agree with Sean that simple examples on page are a huge plus for getting users quick answers. I'd say a simple example per expression type mentioned, here and other data type pages.

Comments from Reviewable

knz · 2017-01-19T16:42:06Z

Quick note before I do a more thorough review: for this and all other data types, I would like to see at least one example of formatting left on the page. The idea being that I can jump to the page and get the information I'm most likely to need, and then find a link to deeper reference material only if I need it. @knz <https://github.com/knz>, although I didn't say as much in my review, I agree with Sean that simple examples on page are a huge plus for getting users quick answers. I'd say a simple example per expression type mentioned, here and other data type pages.

I agree with both of you on this. I'll have a look before Monday. Cheers

jseldess

Again, amazing work, @knz. Thanks very much for writing this up!

I have lots of little comments and suggestions, some content-driven, some format-driven. I'm happy to take such revisions on in a follow-up PR, if you prefer. Just let me know.

Also, we should think about how to represent these pages in the sidenav. Not sure what the best approach is here. Might want to create a new section under Develop for these pages as well as, for example, the keywords and identifiers page?

jseldess · 2017-01-19T19:29:26Z

sql-expressions.md

+[table expressions](table-expressions.html) which produce results
+structured as a table.
+
+A value expression can be:


I don't think it's necessary to provide this list, given that the auto-generated toc provides the same exact list. Instead, I'd suggest we:

Replace the single intro sentence ("Value expressions allow...") with the first two paragraphs of the Introduction section.

And then delete the entire Introduction section.

After the two intro paragraphs, and before the toc, we could have a sentence like: The following sections provide details on possible types of value expressions.

jseldess · 2017-01-19T19:30:22Z

sql-expressions.md

+
+## Introduction
+
+Most SQL statements can contain *value expressions* that compute new


Add a comma after SELECT ceil(price) FROM items.

jseldess · 2017-01-19T19:30:38Z

sql-expressions.md

+items` the expression `ceil(price)` computes the rounded-up value of
+the values from the `price` column.
+
+Value expressions produce values suitable to store in a single table


Add a comma after the table expressions link.

jseldess · 2017-01-19T19:32:31Z

sql-expressions.md

+Constant expressions represent a simple value that doesn't change.
+They are described further in section [SQL Constants](sql-constants.html).
+
+## Column references


For this and all other section headings, let's use title case, i.e., Column References instead of Column references.

jseldess · 2017-01-19T19:32:58Z

sql-expressions.md

+
+## Column references
+
+An expression can refer to columns in the current query in two ways:


Would be clearer as: An expression in a query can refer to columns in two ways:

jseldess · 2017-01-19T21:28:29Z

sql-constants.md

+  [+-]9999.[9999][e[+-]999]
+  [+-][9999].9999[e[+-]999]
+  [+-]9999e[+-]999
+


Remove extra line.

jseldess · 2017-01-19T21:29:12Z

sql-constants.md

+```
+
+The actual data type of a numeric constant depends both on the context
+where it is used, its literal format and its numeric value.


Use comma before and its numeric value.

jseldess · 2017-01-19T21:30:16Z

sql-constants.md

+
+## Byte array literals
+
+A byte array literal uses the same syntax as string literals containing character escapes,


Make [string literals](#string-literals) a link.

jseldess · 2017-01-19T21:30:52Z

sql-constants.md

+
+The two differences between byte array literals and string literals with character escapes are:
+
+- byte array literals always have data type `BYTES`, whereas the data


Capitalize first letter of each bullet item, and end each with a period.

wait what? The paragraph starts with "The two differences ..." above and ends with the last bullet point.

jseldess · 2017-01-19T21:31:44Z

sql-constants.md

+
+CockroachDB recognizes the following SQL named constants:
+
+- `TRUE` and `FALSE`, the two possible values of data type `BOOL`;


Change ; to .

cockroach-teamcity · 2017-01-23T00:09:59Z

http://cockroach-docs-review.s3-website-us-east-1.amazonaws.com/43efba793828ada65cdeb5e49ac8be24c7be3af7/

cockroach-teamcity · 2017-01-23T00:57:29Z

http://cockroach-docs-review.s3-website-us-east-1.amazonaws.com/8e57b91fa43f99401722a50b1d39d05aefd33fc6/

cockroach-teamcity · 2017-01-23T01:36:49Z

http://cockroach-docs-review.s3-website-us-east-1.amazonaws.com/a6276885a813e628e8931abcccacb517f12f91e4/

cockroach-teamcity · 2017-01-23T02:28:56Z

http://cockroach-docs-review.s3-website-us-east-1.amazonaws.com/6640c43f9571bcb43fd8c6dcfa785f2e5ec780d6/

knz · 2017-01-23T02:38:14Z

I have reworked the sidebar significantly. PTAL

cockroach-teamcity · 2017-01-23T02:39:21Z

http://cockroach-docs-review.s3-website-us-east-1.amazonaws.com/4a5a77415472fad5e61ffba435c0b4fb74fac9e9/

cockroach-teamcity · 2017-01-23T02:48:20Z

http://cockroach-docs-review.s3-website-us-east-1.amazonaws.com/b8b97d1dd02fbcefdc52dc54626348eac116d4d7/

cockroach-teamcity · 2017-01-23T02:55:13Z

http://cockroach-docs-review.s3-website-us-east-1.amazonaws.com/e5e040d55c94e333bd4d21866a4b4a6241f2cae5/

jseldess · 2017-01-23T16:14:54Z

sql-constants.md, line 85 at r1 (raw file):

Previously, knz (kena) wrote…

Done.

Parentheses are still there ...?

Comments from Reviewable

jseldess · 2017-01-23T16:17:36Z

sql-constants.md, line 174 at r1 (raw file):

Previously, knz (kena) wrote…

wait what? The paragraph starts with "The two differences ..." above and ends with the last bullet point.

Yes, you're right. I should have also asked you to rework the intro to the list to be a complete sentence, something like:

The two differences between byte array literals and string literals with character escapes are as follows:

Comments from Reviewable

jseldess · 2017-01-23T16:20:21Z

sql-expressions.md, line 60 at r1 (raw file):

Previously, knz (kena) wrote…

done

Whoa! Thank you.

Comments from Reviewable

jseldess · 2017-01-23T16:23:08Z

sql-expressions.md, line 69 at r1 (raw file):

Previously, knz (kena) wrote…

I do not like the idea of combining these things anytime soon. There is much more information to share in docs about operators than what fits in our auto-generator, and extending the auto-generator so that it produces output nearly as useful as a simple hand-written chapter on the topic is a non-trivial task.

You're misunderstanding what I meant. I envision adding manually created content to the page with auto-generated content, not getting the auto-generator to produce this type of content. In any case, we can revisit later. This content is great here as well.

Comments from Reviewable

jseldess · 2017-01-23T16:27:23Z

sql-expressions.md, line 198 at r1 (raw file):

Previously, knz (kena) wrote…

The whole makes a single paragraph. I do not understand why the need to split it; the semicolons are breaking the reading already as appropriate.

Instead of using a list to form a complete sentence, we introduce a list with a complete sentence and then treat each bullet as an independent item.

Can each of these bullets stand on its own, or are they dependent on each other? If the former, please don't use semicolons.

Comments from Reviewable

jseldess · 2017-01-23T16:28:58Z

sql-expressions.md, line 264 at r1 (raw file):

Previously, knz (kena) wrote…

No, and that's another example of why #1009 matters.

OK, point take, and we'll revisit that. But if a column can't contain an array, then we should say "For example, if column a of the current row contains an array...", right?

Comments from Reviewable

jseldess · 2017-01-23T16:29:59Z

sql-expressions.md, line 365 at r1 (raw file):

Previously, knz (kena) wrote…

I don't know how to construe meaningful examples (and I still personally think that window functions are a poor feature that ought not to exist).

window functions and processing deserve as separate page anyway. Let's address Document window functions #710 separately.

OK, thanks.

Comments from Reviewable

jseldess · 2017-01-23T16:31:19Z

sql-expressions.md, line 419 at r1 (raw file):

Previously, knz (kena) wrote…

done

Looks like this didn't actually get done?

Comments from Reviewable

jseldess · 2017-01-23T16:32:27Z

sql-statements.md, line 2 at r2 (raw file):

---
title: SQL Statements

This is a huge improvement. Thank you, @knz!

Comments from Reviewable

jseldess · 2017-01-23T16:33:06Z

table-expressions.md, line 7 at r1 (raw file):

Previously, knz (kena) wrote…

I disagree that the intro is unnecessary. The mention that multiple table names after FROM is a cross join is not mentioned elsewhere (for now).

OK.

Comments from Reviewable

jseldess · 2017-01-23T16:34:53Z

table-expressions.md, line 156 at r1 (raw file):

Previously, knz (kena) wrote…

done

Sorry to have misdirected you here. Can you reformat the the callout to include only html formatting, not markdown?

{{site.data.alerts.callout_info}}
WITH ORDINALITY necessarily prevents some optimizations of the surrounding query. Use it sparingly if performance is a concern, and always check the output of EXPLAIN in case of doubt.
{{site.data.alerts.end}}

Comments from Reviewable

jseldess · 2017-01-23T16:40:56Z

Thanks for making so many tweaks, @knz. I've included/repeated a few more, but it's look very close now.

I would like to decouple this work from an overahaul of the sidenav, however. There are some strange user experience issues that need to be factored in when designing the sidenav (page url needs to match link url in sidenav in order for the correct section to expand and the sidnav item to get highlighted, for example). And we're already intending to rethink the docs architecture (mostly this section) next quarter, as well as move to another tool that will let us restructure our site hierarchy.

So for now, I'd suggest we go back to the old sidenav with the three new pages simply added to the Develop section.

Comments from Reviewable

jseldess · 2017-01-23T16:41:03Z

Reviewed 22 of 22 files at r2.
Review status: all files reviewed at latest revision, 17 unresolved discussions, some commit checks failed.

Comments from Reviewable

knz · 2017-01-23T20:11:25Z

I'm very confused by the sidenav syntax and I can't seem to get it to work now (although it worked yesterday!). Are you ok with adding this fix after merging this PR?

Review status: 1 of 16 files reviewed at latest revision, 18 unresolved discussions, some commit checks pending.

data-types.md, line 31 at r1 (raw file):

Previously, jseldess wrote…

Thanks, @knz. One more change: I lead you to use markdown formatting for the link inside. Turns out that causes rendering issues. So please format the link as html instead, here an in any other callouts you added:
<a href="sql-expressions.html#explicitly-typed-expressions">type annotation</a>

Done.

date.md, line 47 at r2 (raw file):

Previously, jseldess wrote…

spelling: explicitly

Done.

manual-deployment.md, line 12 at r2 (raw file):

Previously, jseldess wrote…

As mentioned above, I've had to revert the ability to use markdown inside callouts, so we need to revert this to html as well.

Done.

sql-constants.md, line 2 at r1 (raw file):

Previously, jseldess wrote…

Title case, please: Constant Values

Done.

sql-constants.md, line 30 at r1 (raw file):

Previously, jseldess wrote…

Let's change ; to . at the end of each bullet, please. And remove and from the end of the last bullet.

Done.

sql-constants.md, line 85 at r1 (raw file):

Previously, jseldess wrote…

Parentheses are still there ...?

I had forgotten to commit the change. Apologies.

sql-constants.md, line 174 at r1 (raw file):

Previously, jseldess wrote…

Yes, you're right. I should have also asked you to rework the intro to the list to be a complete sentence, something like:

The two differences between byte array literals and string literals with character escapes are as follows:

Done.

sql-expressions.md, line 69 at r1 (raw file):

Previously, jseldess wrote…

You're misunderstanding what I meant. I envision adding manually created content to the page with auto-generated content, not getting the auto-generator to produce this type of content. In any case, we can revisit later. This content is great here as well.

Ok I agree!

sql-expressions.md, line 198 at r1 (raw file):

Previously, jseldess wrote…

Instead of using a list to form a complete sentence, we introduce a list with a complete sentence and then treat each bullet as an independent item.

Can each of these bullets stand on its own, or are they dependent on each other? If the former, please don't use semicolons.

Done.

sql-expressions.md, line 264 at r1 (raw file):

Previously, jseldess wrote…

OK, point take, and we'll revisit that. But if a column can't contain an array, then we should say "For example, if column a of the current row contains an array...", right?

Ok now I see where you're coming from.
The fun thing is that a query can produce arrays in columns by means of SQL expression computations, and these arrays can be used further in the query; however the array values cannot be stored in the database.

We were writing past each other by overlapping the notion of "physical column in storage" and "virtual column of an intermediate result table in a query".

I reworked the explanation accordingly.

sql-expressions.md, line 419 at r1 (raw file):

Previously, jseldess wrote…

Looks like this didn't actually get done?

Again forgot to commit.

sql-statements.md, line 2 at r2 (raw file):

Previously, jseldess wrote…

This is a huge improvement. Thank you, @knz!

😸

table-expressions.md, line 156 at r1 (raw file):

Previously, jseldess wrote…

Sorry to have misdirected you here. Can you reformat the the callout to include only html formatting, not markdown?

{{site.data.alerts.callout_info}}
WITH ORDINALITY necessarily prevents some optimizations of the surrounding query. Use it sparingly if performance is a concern, and always check the output of EXPLAIN in case of doubt.
{{site.data.alerts.end}}

Done.

Comments from Reviewable

cockroach-teamcity · 2017-01-23T20:12:29Z

http://cockroach-docs-review.s3-website-us-east-1.amazonaws.com/3c6f92a0b73cf95df653eab200bb04fc4f4a6ea0/

cockroach-teamcity · 2017-01-23T20:23:44Z

http://cockroach-docs-review.s3-website-us-east-1.amazonaws.com/eeaddbc57a64f8cd050ef07f5f68219e93f084b2/

cockroach-teamcity · 2017-01-24T18:13:03Z

http://cockroach-docs-review.s3-website-us-east-1.amazonaws.com/3e989bf31aa085ad013b476de92a0827a7c718b9/

knz · 2017-01-24T18:14:23Z

Just extended this PR to integrate the changes from cockroachdb/cockroach#13094

cockroach-teamcity · 2017-01-24T18:24:53Z

http://cockroach-docs-review.s3-website-us-east-1.amazonaws.com/22b5eeeb3b8f4c9784487ce2960c4f95ea4bf106/

jseldess · 2017-01-24T18:37:00Z

Thanks again, @knz! I'll deal with the sidenav in a follow-up pr. Excited to get this content to users.

Reviewed 16 of 21 files at r3.
Review status: all files reviewed at latest revision, 1 unresolved discussion.

Comments from Reviewable

* Add note about non-root users * Update getting-started.md * Update getting-started.md * Update oasis/getting-started.md Co-authored-by: Simran <Simran-B@users.noreply.github.com> * Update getting-started.md Co-authored-by: ansoboleva <93702078+ansoboleva@users.noreply.github.com> Co-authored-by: Simran <Simran-B@users.noreply.github.com>

knz force-pushed the knz-updates branch 3 times, most recently from ba26800 to fe1b2e9 Compare January 17, 2017 21:50

knz changed the title ~~[WIP - do not merge] New docs on expressions and constants~~ New docs on expressions and constants Jan 17, 2017

knz assigned jseldess and sploiselle Jan 17, 2017

jseldess reviewed Jan 19, 2017

View reviewed changes

jseldess mentioned this pull request Jan 19, 2017

sql/parser: Introduce IndirectionExpr and support for array subscripting #877

Closed

jseldess reviewed Jan 19, 2017

View reviewed changes

knz force-pushed the knz-updates branch from fe1b2e9 to 43efba7 Compare January 23, 2017 00:08

knz force-pushed the knz-updates branch from 43efba7 to 8e57b91 Compare January 23, 2017 00:56

knz force-pushed the knz-updates branch from 8e57b91 to a627688 Compare January 23, 2017 01:35

knz force-pushed the knz-updates branch 3 times, most recently from ebca42c to 6640c43 Compare January 23, 2017 02:27

knz force-pushed the knz-updates branch from 6640c43 to 4a5a774 Compare January 23, 2017 02:37

knz force-pushed the knz-updates branch from 4a5a774 to b8b97d1 Compare January 23, 2017 02:47

knz force-pushed the knz-updates branch from b8b97d1 to e5e040d Compare January 23, 2017 02:54

knz mentioned this pull request Jan 23, 2017

Proposal for a new sidebar organisation for sql docs. #1021

Closed

knz force-pushed the knz-updates branch from a7c35c5 to 3c6f92a Compare January 23, 2017 20:11

knz force-pushed the knz-updates branch from 3c6f92a to eeaddbc Compare January 23, 2017 20:22

knz force-pushed the knz-updates branch from eeaddbc to 3e989bf Compare January 24, 2017 18:12

New docs on SQL constants and expressions.

22b5eee

knz force-pushed the knz-updates branch from 3e989bf to 22b5eee Compare January 24, 2017 18:23

jseldess merged commit ecbff69 into cockroachdb:gh-pages Jan 24, 2017

This was referenced Jan 24, 2017

sql: Categorize SQL Statements #260

Closed

Expressions in sidenav #1025

Merged


		## Format

		When inserting into a `FLOAT` column, format the value as a numeric literal, e.g., `1.2345` or `1`.


		## Introduction

		Most SQL statements can contain value expressions that compute new


		## Column references

		An expression can refer to columns in the current query in two ways:


		## Byte array literals

		A byte array literal uses the same syntax as string literals containing character escapes,


		The two differences between byte array literals and string literals with character escapes are:

		- byte array literals always have data type `BYTES`, whereas the data


		CockroachDB recognizes the following SQL named constants:

		- `TRUE` and `FALSE`, the two possible values of data type `BOOL`;

New docs on expressions and constants #1008

New docs on expressions and constants #1008

Uh oh!

Conversation

knz commented Jan 17, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

cockroach-teamcity commented Jan 17, 2017

Uh oh!

jseldess left a comment

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!

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!

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!

sploiselle commented Jan 19, 2017

Uh oh!

jseldess commented Jan 19, 2017

Uh oh!

knz commented Jan 19, 2017 via email

Uh oh!

jseldess left a comment

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!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

knz commented Jan 17, 2017 •

edited

Loading