issue_comments
3 rows where author_association = "OWNER" and "updated_at" is on date 2019-10-02 sorted by html_url
This data as json, CSV (advanced)
Suggested facets: issue_url
id | html_url ▼ | issue_url | node_id | user | created_at | updated_at | author_association | body | reactions | issue | performed_via_github_app |
---|---|---|---|---|---|---|---|---|---|---|---|
537716955 | https://github.com/simonw/datasette/issues/283#issuecomment-537716955 | https://api.github.com/repos/simonw/datasette/issues/283 | MDEyOklzc3VlQ29tbWVudDUzNzcxNjk1NQ== | simonw 9599 | 2019-10-02T23:02:15Z | 2019-10-02T23:02:15Z | OWNER | I've been thinking pretty hard about this as part of #569. My big concerns are: * If I'm caching and reusing connections I need to worry about the different combinations - if I have four databases do I cache separate connections for the ("one", "two") AND ("two", "three") AND ("one", "three") and so on pairs? * How does the API and interface deal with instances where you have a database connected as the primary and you want to ATTACH another database and talk to that as well? I think the best way to do this is to say that cross-database joins will only be available against the `:memory:` database. Maybe with an optional mode you can run like `datasette --crossdb` which causes every database to be `ATTACHd` to that connection with an alias so you can start running queries. If this proves to be a problem when hundreds of files are attached to a Datasette Library instance (#417) then maybe cross database joins are handled (in that case) by the authenticated user selecting which ones to ?_attach= and detaching them at the end of the request. Also perhaps limit to joining across a maximum of 3 databases at once in this case. I can probably avoid the scariest negative consequences of cross-database joins by having them turned off by default for signed-out users. The datasette-on-my-laptop or authenticated Datasette Library cases can be opt-in and can be a little less locked down. | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Support cross-database joins 325958506 | |
537711455 | https://github.com/simonw/datasette/issues/569#issuecomment-537711455 | https://api.github.com/repos/simonw/datasette/issues/569 | MDEyOklzc3VlQ29tbWVudDUzNzcxMTQ1NQ== | simonw 9599 | 2019-10-02T22:41:12Z | 2019-10-02T22:41:12Z | OWNER | I'm going to refactor the `execute()` and `execute_against_connection_in_thread()` methods. They currently live on the `Datasette` class, but in this new world it would make more sense for them to live on the `Database`, `ConnectionGroup` or `Connection` classes. I think I'll put them on the `Database` class. | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | More advanced connection pooling 481885279 | |
537712384 | https://github.com/simonw/datasette/issues/569#issuecomment-537712384 | https://api.github.com/repos/simonw/datasette/issues/569 | MDEyOklzc3VlQ29tbWVudDUzNzcxMjM4NA== | simonw 9599 | 2019-10-02T22:44:36Z | 2019-10-02T22:44:36Z | OWNER | I'm going to simplify things a bunch by continuing to ignore the cross-database joining issue #283 - I'll post some notes there on my latest thinking. | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | More advanced connection pooling 481885279 |
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]);
updated_at (date) 1 ✖