issue_comments

Table actions

3 rows where author_association = "OWNER", issue = 671763164 and user = 9599 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

  • simonw · 3 ✖

issue 1

  • Refactor TableView class so things like datasette-graphql can reuse the logic · 3 ✖

author_association 1

  • OWNER · 3 ✖
id html_url issue_url node_id user created_at updated_at ▲ author_association body reactions issue performed_via_github_app
675751136 https://github.com/simonw/datasette/issues/915#issuecomment-675751136 https://api.github.com/repos/simonw/datasette/issues/915 MDEyOklzc3VlQ29tbWVudDY3NTc1MTEzNg== simonw 9599 2020-08-18T22:28:36Z 2020-08-18T22:28:36Z OWNER

I'm closing this in favour of an internal requests mechanism in #943.

 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
 Refactor TableView class so things like datasette-graphql can reuse the logic 671763164  
675746544 https://github.com/simonw/datasette/issues/915#issuecomment-675746544 https://api.github.com/repos/simonw/datasette/issues/915 MDEyOklzc3VlQ29tbWVudDY3NTc0NjU0NA== simonw 9599 2020-08-18T22:14:41Z 2020-08-18T22:14:41Z OWNER

I'm actually pretty happy with how datasette-graphql works now - maybe the trick here is to redesign the JSON format in #782 such that it can be used as a documented interface by things like datasette-graphql and then ensure Datasette has a documented mechanism for dispatching internal requests.

I just did a horrible hack here that simulates an internal request, so supporting them as a feature would definitely make sense: https://github.com/natbat/tidepools_near_me/commit/ec102c6da5a5d86f17628740d90b6365b671b5e1

 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
 Refactor TableView class so things like datasette-graphql can reuse the logic 671763164  
671073223 https://github.com/simonw/datasette/issues/915#issuecomment-671073223 https://api.github.com/repos/simonw/datasette/issues/915 MDEyOklzc3VlQ29tbWVudDY3MTA3MzIyMw== simonw 9599 2020-08-09T16:35:20Z 2020-08-09T16:36:10Z OWNER

datasette-graphql uses the logic from TableView right now. It wasn't too unpleasant, but I do worry about the two of them being coupled together in this way.

https://github.com/simonw/datasette-graphql/blob/cc65ec294b0bf8e26213fc68bb5487066de9caab/datasette_graphql/utils.py#L412-L417

```python request = Request.fake(path_with_query_string)

    view = TableView(DatasetteSpecialConfig(datasette))
    data, _, _ = await view.data(
        request, database=database_name, hash=None, table=table_name, _next=after
    )

```

 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
 Refactor TableView class so things like datasette-graphql can reuse the logic 671763164  

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,
   [issue] INTEGER REFERENCES [issues]([id])
, [performed_via_github_app] TEXT);
CREATE INDEX [idx_issue_comments_issue]
                ON [issue_comments] ([issue]);
CREATE INDEX [idx_issue_comments_user]
                ON [issue_comments] ([user]);