issue_comments

Table actions

3 rows where issue = 216611104 and user = 1217238 sorted by updated_at descending

✎ View and edit SQL

This data as json, CSV (advanced)

Suggested facets: created_at (date), updated_at (date)

user 1

  • shoyer · 3 ✖

issue 1

  • Shorter repr for attributes · 3 ✖

author_association 1

id html_url issue_url node_id user created_at updated_at ▲ author_association body reactions performed_via_github_app issue
291027510 https://github.com/pydata/xarray/pull/1322#issuecomment-291027510 https://api.github.com/repos/pydata/xarray/issues/1322 MDEyOklzc3VlQ29tbWVudDI5MTAyNzUxMA== shoyer 1217238 2017-04-03T00:50:28Z 2017-04-03T00:50:28Z MEMBER

Thanks for the contribution!

 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
   Shorter repr for attributes 216611104
291027495 https://github.com/pydata/xarray/pull/1322#issuecomment-291027495 https://api.github.com/repos/pydata/xarray/issues/1322 MDEyOklzc3VlQ29tbWVudDI5MTAyNzQ5NQ== shoyer 1217238 2017-04-03T00:50:17Z 2017-04-03T00:50:17Z MEMBER

@Zac-HD My guess is that non-string multi-line attributes are quite rare, so in truth it doesn't really matter what we pick (even though my preference leaned the other way from yours). If someone cares enough to complain we can revisit this, but until then I'm OK with your choice.

 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
   Shorter repr for attributes 216611104
289484312 https://github.com/pydata/xarray/pull/1322#issuecomment-289484312 https://api.github.com/repos/pydata/xarray/issues/1322 MDEyOklzc3VlQ29tbWVudDI4OTQ4NDMxMg== shoyer 1217238 2017-03-27T15:12:15Z 2017-03-27T15:12:15Z MEMBER

If the logic is "clever", time to ditch it. I've rebased to a clearer version which simply handles indentation and replaces tabs and newlines with their backslash representations.

"Clever" was possibly too strong of a word. I think both your original and new proposal are fine -- use your own best taste on which version is most readable.

It's more that we need unit tests for any functionality. Otherwise, things tend to brake inadvertently when someone else does code cleanup months or years later.

What properties of this would you want to test?

This could be super simple here, e.g., just a few assert statements verifying the text substitutions and truncation. Ideally we exercise every line of logic in your code.

 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
   Shorter repr for attributes 216611104

Advanced export

JSON shape: default, array, newline-delimited, object

CSV options: 

CREATE TABLE [issue_comments] (
   [html_url] TEXT,
   [issue_url] TEXT,
   [id] INTEGER PRIMARY KEY,
   [node_id] TEXT,
   [user] INTEGER REFERENCES [users]([id]),
   [created_at] TEXT,
   [updated_at] TEXT,
   [author_association] TEXT,
   [body] TEXT,
   [reactions] TEXT,
   [performed_via_github_app] TEXT,
   [issue] INTEGER REFERENCES [issues]([id])
);
CREATE INDEX [idx_issue_comments_issue]
    ON [issue_comments] ([issue]);
CREATE INDEX [idx_issue_comments_user]
    ON [issue_comments] ([user]);