issue_comments
6 rows where issue = 520667773
This data as json, CSV (advanced)
Suggested facets: created_at (date), updated_at (date)
id ▼ | html_url | issue_url | node_id | user | created_at | updated_at | author_association | body | reactions | issue | performed_via_github_app |
---|---|---|---|---|---|---|---|---|---|---|---|
552241725 | https://github.com/simonw/datasette/issues/620#issuecomment-552241725 | https://api.github.com/repos/simonw/datasette/issues/620 | MDEyOklzc3VlQ29tbWVudDU1MjI0MTcyNQ== | simonw 9599 | 2019-11-10T22:27:32Z | 2019-11-10T22:27:32Z | OWNER | Added bonus: this would mean faceting results could be enhanced with a "more" link that points to a custom paginated SQL query - but that query could maintain the ability to expand the labels on foreign keys. | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Mechanism for indicating foreign key relationships in the table and query page URLs 520667773 | |
552251831 | https://github.com/simonw/datasette/issues/620#issuecomment-552251831 | https://api.github.com/repos/simonw/datasette/issues/620 | MDEyOklzc3VlQ29tbWVudDU1MjI1MTgzMQ== | simonw 9599 | 2019-11-11T00:25:58Z | 2019-11-11T00:25:58Z | OWNER | There are three pieces of information that need to be described here: the column, the other table and the other table column. We already have a piece of API design that is similar to this: the `_through=` parameter, which looks like this: `?_through={"table":"m2m_characteristics","column":"characteristic_id","value":"1"}` I'm rethinking this syntax in #621 though to support a non-JSON variant that looks more like this: `?_through.roadside_attraction_characteristics.characteristic_id=1` | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Mechanism for indicating foreign key relationships in the table and query page URLs 520667773 | |
552252074 | https://github.com/simonw/datasette/issues/620#issuecomment-552252074 | https://api.github.com/repos/simonw/datasette/issues/620 | MDEyOklzc3VlQ29tbWVudDU1MjI1MjA3NA== | simonw 9599 | 2019-11-11T00:28:28Z | 2019-11-11T00:30:53Z | OWNER | So for foreign key definitions it could look like this: `/db/table?_fk.article_id=articles.id` Or for columns and table names that themselves contain dots it could be: `/db/table?_fk.article_id={"table":"articles","column":"id"}` The value (before the =) is unambiguous -it's `?fk.XXX` where XXX could be a column name that includes periods without breaking anything. Added bonus: if you're referencing another table's single primary key you can omit the `.id` entirely (since it can be automatically detected) - so you could do `?_fk.article_id=articles`. | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Mechanism for indicating foreign key relationships in the table and query page URLs 520667773 | |
552252199 | https://github.com/simonw/datasette/issues/620#issuecomment-552252199 | https://api.github.com/repos/simonw/datasette/issues/620 | MDEyOklzc3VlQ29tbWVudDU1MjI1MjE5OQ== | simonw 9599 | 2019-11-11T00:29:36Z | 2019-11-11T00:29:36Z | OWNER | This new `?_fk.column_name=` syntax makes me wonder if the various filters should be `?colname.contains=x` rather than `?colname__contains=x` - but that's a conversation for another time. | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Mechanism for indicating foreign key relationships in the table and query page URLs 520667773 | |
554869243 | https://github.com/simonw/datasette/issues/620#issuecomment-554869243 | https://api.github.com/repos/simonw/datasette/issues/620 | MDEyOklzc3VlQ29tbWVudDU1NDg2OTI0Mw== | simonw 9599 | 2019-11-18T06:16:17Z | 2019-11-18T06:16:51Z | OWNER | I think I should move the `ds.expand_foreign_keys()` method somewhere else: https://github.com/simonw/datasette/blob/c2779e5af0d056ef1637f9f0e191dca421259a5e/datasette/app.py#L355-L390 Moving it to `Database` makes sense to me. The question we then ask it is: "Given this column containing these values, give me back a dictionary mapping each column and value to a label - `(column, value) -> label`" Passing in the foreign keys we have calculated as an argument makes sense. | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Mechanism for indicating foreign key relationships in the table and query page URLs 520667773 | |
813167335 | https://github.com/simonw/datasette/issues/620#issuecomment-813167335 | https://api.github.com/repos/simonw/datasette/issues/620 | MDEyOklzc3VlQ29tbWVudDgxMzE2NzMzNQ== | simonw 9599 | 2021-04-05T03:57:22Z | 2021-04-05T03:57:22Z | OWNER | This may be obsoleted by #1293 - it looks like I may be able to auto-detect these foreign keys for arbitrary queries after all. | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Mechanism for indicating foreign key relationships in the table and query page URLs 520667773 |
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]);