issue_comments: 389386142

This data as json

html_url issue_url id node_id user created_at updated_at author_association body reactions issue performed_via_github_app
https://github.com/simonw/datasette/pull/258#issuecomment-389386142 https://api.github.com/repos/simonw/datasette/issues/258 389386142 MDEyOklzc3VlQ29tbWVudDM4OTM4NjE0Mg== 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
}
 322741659