home / github

Menu
  • GraphQL API
  • Search all tables

issue_comments

Table actions
  • GraphQL API for issue_comments

3 rows where issue = 675342733 and user = 14808389 sorted by updated_at descending

✎ View and edit SQL

This data as json, CSV (advanced)

Suggested facets: updated_at (date)

user 1

  • keewis · 3 ✖

issue 1

  • constructing nested inline reprs · 3 ✖

author_association 1

  • MEMBER 3
id html_url issue_url node_id user created_at updated_at ▲ author_association body reactions performed_via_github_app issue
692084290 https://github.com/pydata/xarray/issues/4324#issuecomment-692084290 https://api.github.com/repos/pydata/xarray/issues/4324 MDEyOklzc3VlQ29tbWVudDY5MjA4NDI5MA== keewis 14808389 2020-09-14T14:19:50Z 2020-09-14T14:19:50Z MEMBER

see also dask/dask#6637

{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
  constructing nested inline reprs 675342733
677690442 https://github.com/pydata/xarray/issues/4324#issuecomment-677690442 https://api.github.com/repos/pydata/xarray/issues/4324 MDEyOklzc3VlQ29tbWVudDY3NzY5MDQ0Mg== keewis 14808389 2020-08-20T14:11:16Z 2020-08-20T14:11:16Z MEMBER

I brought this up at the meeting, and if I remember correctly, the recommendation was to take a step back and solve nested duck arrays in general (e.g. by writing a design doc – a NEP?). Correct me if I'm wrong, @shoyer, but I think the hope was that after that it would be easier to design nested reprs.

{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
  constructing nested inline reprs 675342733
675186695 https://github.com/pydata/xarray/issues/4324#issuecomment-675186695 https://api.github.com/repos/pydata/xarray/issues/4324 MDEyOklzc3VlQ29tbWVudDY3NTE4NjY5NQ== keewis 14808389 2020-08-18T00:49:10Z 2020-08-18T00:49:10Z MEMBER

I'll add a few ideas, too:

  • we could also add a format parameter to _repr_inline_ that if True requires the implementers to return a list of types (prepending type(self)) and a dictionary containing the metadata. xarray could then use those to construct the repr proposed in dask/dask#5329 (I guess that only works for the expanded view, though, because the collapsed view doesn't have that much horizontal space).

  • other than that, we could have the implementers delegate to the data's _repr_inline_ (falling back to the normal repr) and prepend their own metadata.

{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
  constructing nested inline reprs 675342733

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]);
Powered by Datasette · Queries took 155.284ms · About: xarray-datasette