issue_comments

Table actions

6 rows where "updated_at" is on date 2018-05-21 sorted by updated_at descending

✎ View and edit SQL

This data as json, CSV (advanced)

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

author_association 3

id html_url issue_url node_id user created_at updated_at ▲ author_association body reactions issue performed_via_github_app
390804333 https://github.com/simonw/datasette/pull/277#issuecomment-390804333 https://api.github.com/repos/simonw/datasette/issues/277 MDEyOklzc3VlQ29tbWVudDM5MDgwNDMzMw== simonw 9599 2018-05-21T22:40:16Z 2018-05-21T22:43:50Z OWNER

We should merge this before refactoring the tests though, because that way we don't couple the new tests to the verification of this change.

 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
 Refactor inspect logic 324836533  
390795067 https://github.com/simonw/datasette/issues/276#issuecomment-390795067 https://api.github.com/repos/simonw/datasette/issues/276 MDEyOklzc3VlQ29tbWVudDM5MDc5NTA2Nw== russss 45057 2018-05-21T21:55:57Z 2018-05-21T21:55:57Z CONTRIBUTOR

Well, we do have the capability to detect spatialite so my intention certainly wasn't to require it.

I can see the advantage of having it as a plugin but it does touch a number of points in the code. I think I'm going to attack this by refactoring the necessary bits and seeing where that leads (which was my plan anyway).

I think my main concern is - if I add certain plugin hooks for this, is anything else ever going to use them? I'm not sure I have an answer to that question yet, either way.

 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
 Handle spatialite geometry columns better 324835838  
390707760 https://github.com/simonw/datasette/issues/276#issuecomment-390707760 https://api.github.com/repos/simonw/datasette/issues/276 MDEyOklzc3VlQ29tbWVudDM5MDcwNzc2MA== simonw 9599 2018-05-21T16:30:35Z 2018-05-21T16:30:35Z OWNER

This probably needs to be in a plugin simply because getting Spatialite compiled and installed is a bit of a pain.

It's a great opportunity to expand the plugin hooks in useful ways though.

 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
 Handle spatialite geometry columns better 324835838  
390707183 https://github.com/simonw/datasette/pull/277#issuecomment-390707183 https://api.github.com/repos/simonw/datasette/issues/277 MDEyOklzc3VlQ29tbWVudDM5MDcwNzE4Mw== simonw 9599 2018-05-21T16:28:39Z 2018-05-21T16:28:39Z OWNER

This is definitely a big improvement.

I'd like to refactor the unit tests that cover .inspect() too - currently they are a huge ugly blob at the top of test_api.py

 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
 Refactor inspect logic 324836533  
390689406 https://github.com/simonw/datasette/issues/247#issuecomment-390689406 https://api.github.com/repos/simonw/datasette/issues/247 MDEyOklzc3VlQ29tbWVudDM5MDY4OTQwNg== jsancho-gpl 11912854 2018-05-21T15:29:31Z 2018-05-21T15:29:31Z NONE

I've changed my mind about the way to support external connectors aside of SQLite and I'm working in a more simple style that respects the original Datasette, i.e. less refactoring. I present you a version of Datasette wich supports other database connectors and a Datasette connector for HDF5/PyTables files.

 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
 SQLite code decoupled from Datasette 319449852  
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  

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