issue_comments

Table actions

6 rows where author_association = "OWNER", issue = 729096595 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 · 6 ✖

issue 1

  • Better display of binary data on arbitrary query results page · 6 ✖

author_association 1

  • OWNER · 6 ✖
id html_url issue_url node_id user created_at updated_at ▲ author_association body reactions issue performed_via_github_app
719053669 https://github.com/simonw/datasette/issues/1051#issuecomment-719053669 https://api.github.com/repos/simonw/datasette/issues/1051 MDEyOklzc3VlQ29tbWVudDcxOTA1MzY2OQ== simonw 9599 2020-10-29T22:12:16Z 2020-10-29T22:12:16Z OWNER 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
 Better display of binary data on arbitrary query results page 729096595  
718980659 https://github.com/simonw/datasette/issues/1051#issuecomment-718980659 https://api.github.com/repos/simonw/datasette/issues/1051 MDEyOklzc3VlQ29tbWVudDcxODk4MDY1OQ== simonw 9599 2020-10-29T19:45:42Z 2020-10-29T19:45:42Z OWNER

OK, alternative idea. The .blob output renderer from #1050 gets to see multiple rows at once.

For an arbitrary SQL query, how about if I link to this?

/db.blob?sql=...&_blob_column=data&_blob_hash=bc4c24181ed3ce666

Then the output renderer loops through all of the data results that are available to it and, if one of them hashes to that value, serves up that data?

If no matches are found it can show an error message telling you that the link has expired (presumably because the underlying database has changed since the link was generated).

I think this might be the best solution to the problem.

 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
 Better display of binary data on arbitrary query results page 729096595  
716681602 https://github.com/simonw/datasette/issues/1051#issuecomment-716681602 https://api.github.com/repos/simonw/datasette/issues/1051 MDEyOklzc3VlQ29tbWVudDcxNjY4MTYwMg== simonw 9599 2020-10-26T16:51:58Z 2020-10-26T16:51:58Z OWNER

I still need to improve the current binary display on the query page though, where it outputs a Python b'...' literal.

 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
 Better display of binary data on arbitrary query results page 729096595  
716681167 https://github.com/simonw/datasette/issues/1051#issuecomment-716681167 https://api.github.com/repos/simonw/datasette/issues/1051 MDEyOklzc3VlQ29tbWVudDcxNjY4MTE2Nw== simonw 9599 2020-10-26T16:51:15Z 2020-10-26T16:51:15Z OWNER

Crazy idea: generate a signed URL containing a base64 of the gzip of the binary content (to try and reduce size).

No: this will blow through URL limits in various hosting providers and possibly even browsers. It could be made to work a little bit more reliably with some extra JavaScript that turns it into a download on the browser-side, but that would be hideously complicated.

Also the signed bit doesn't prevent people from generating SQL queries that generate nasty binary blobs for download.

I'm beginning to think that restricting this feature to just table view, not query view, is a better idea. Query view can still get at the binary using JSON and base64.

 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
 Better display of binary data on arbitrary query results page 729096595  
716204271 https://github.com/simonw/datasette/issues/1051#issuecomment-716204271 https://api.github.com/repos/simonw/datasette/issues/1051 MDEyOklzc3VlQ29tbWVudDcxNjIwNDI3MQ== simonw 9599 2020-10-25T20:08:04Z 2020-10-25T20:08:04Z OWNER

This is bad though, because if I want to provide binary data in CSV as requested in #1034 I need some way of providing that data.

Which suggests to me that the base64 option is the only one that can make sense for arbitrary SQL queries represented as CSV. Download links won't work.

 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
 Better display of binary data on arbitrary query results page 729096595  
716204090 https://github.com/simonw/datasette/issues/1051#issuecomment-716204090 https://api.github.com/repos/simonw/datasette/issues/1051 MDEyOklzc3VlQ29tbWVudDcxNjIwNDA5MA== simonw 9599 2020-10-25T20:06:42Z 2020-10-25T20:06:42Z OWNER

Providing a binary download link here is actually extremely difficult.

The problem is that the SQL query itself represents data that can change from one moment to the next. It's no good showing a "Binary: 55 bytes" message that links to that same SQL query but with a .blob extension and arguments to select the particular result, because the data may change in a way that causes that query to return a different row - at which point the download link will give you the wrong data, not the 55 bytes you asked for.

So providing a download link risks being misleading.

 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
 Better display of binary data on arbitrary query results page 729096595  

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]);