issue_comments

Table actions

3 rows where issue = 322741659 sorted by updated_at descending

✎ View and edit SQL

This data as json, CSV (advanced)

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

user 2

author_association 2

issue 1

  • Add new metadata key persistent_urls which removes the hash from all database urls · 3 ✖
id html_url issue_url node_id user created_at updated_at ▲ author_association body reactions issue performed_via_github_app
390577711 https://github.com/simonw/datasette/pull/258#issuecomment-390577711 https://api.github.com/repos/simonw/datasette/issues/258 MDEyOklzc3VlQ29tbWVudDM5MDU3NzcxMQ== philroche 247131 2018-05-21T07:38:15Z 2018-05-21T07:38:15Z NONE

Excellent, I was not aware of the auto redirect to the new hash. My bad

This solves my use case.

I do agree that your suggested --no-url-hash approach is much neater. I will investigate 

{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
 Add new metadata key persistent_urls which removes the hash from all database urls 322741659  
389536870 https://github.com/simonw/datasette/pull/258#issuecomment-389536870 https://api.github.com/repos/simonw/datasette/issues/258 MDEyOklzc3VlQ29tbWVudDM4OTUzNjg3MA== simonw 9599 2018-05-16T14:22:31Z 2018-05-16T14:22:31Z OWNER

The principle benefit provided by the hash URLs is that Datasette can set a far-future cache expiry header on every response. This is particularly useful for JavaScript API work as it makes fantastic use of the browser's cache. It also means that if you are serving your API from behind a caching proxy like Cloudflare you get a fantastic cache hit rate.

An option to serve without persistent hashes would also need to turn off the cache headers.

Maybe the option should support both? If you hit a page with the hash in the URL you still get the cache headers, but hits to the URL without the hash serve uncashed content directly.

 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
 Add new metadata key persistent_urls which removes the hash from all database urls 322741659  
389386142 https://github.com/simonw/datasette/pull/258#issuecomment-389386142 https://api.github.com/repos/simonw/datasette/issues/258 MDEyOklzc3VlQ29tbWVudDM4OTM4NjE0Mg== simonw 9599 2018-05-16T03:51:13Z 2018-05-16T03:51:13Z OWNER

The URL does persist across deployments already, in that you can use the URL without the hash and it will redirect to the current location. Here's an example of that: https://san-francisco.datasettes.com/sf-trees/Street_Tree_List.json

This also works if you attempt to hit the incorrect hash, e.g. if you have deployed a new version of the database with an updated hash. The old hash will redirect, e.g. https://san-francisco.datasettes.com/sf-trees-c4b972c/Street_Tree_List.json

If you serve Datasette from a HTTP/2 proxy (I've been using Cloudflare for this) you won't even have to pay the cost of the redirect - Datasette sends a Link: <URL>; rel=preload header with those redirects, which causes Cloudflare to push out the redirected source as part of that HTTP/2 request. You can fire up the Chrome DevTools to watch this happen.

https://github.com/simonw/datasette/blob/2b79f2bdeb1efa86e0756e741292d625f91cb93d/datasette/views/base.py#L91

All of that said... I'm not at all opposed to this feature. For consistency with other Datasette options (e.g. --cors) I'd prefer to do this as an optional argument to the datasette serve command - something like this:

datasette serve mydb.db --no-url-hash

{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
 Add new metadata key persistent_urls which removes the hash from all database urls 322741659  

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