issue_comments
6 rows where "created_at" is on date 2018-05-21 sorted by updated_at descending
This data as json, CSV (advanced)
Suggested facets: issue_url, updated_at (date)
issue 4
reactions 1 ✖
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
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]);
user 4