issue_comments
6 rows where issue = 743371103
This data as json, CSV (advanced)
Suggested facets: user, author_association, 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 |
---|---|---|---|---|---|---|---|---|---|---|---|
735444858 | https://github.com/simonw/datasette/issues/1099#issuecomment-735444858 | https://api.github.com/repos/simonw/datasette/issues/1099 | MDEyOklzc3VlQ29tbWVudDczNTQ0NDg1OA== | simonw 9599 | 2020-11-29T19:51:58Z | 2020-11-29T19:51:58Z | OWNER | My fix in deb0be4ae56f191f121239b29e83dd53b62d6305 for #1098 was to have Datasette deliberately pretend that compound foreign keys don't exist: https://github.com/simonw/datasette/blob/deb0be4ae56f191f121239b29e83dd53b62d6305/datasette/utils/__init__.py#L470-L495 This workaround will need to be rethought to implement real support for them. | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Support linking to compound foreign keys 743371103 | |
749771231 | https://github.com/simonw/datasette/issues/1099#issuecomment-749771231 | https://api.github.com/repos/simonw/datasette/issues/1099 | MDEyOklzc3VlQ29tbWVudDc0OTc3MTIzMQ== | simonw 9599 | 2020-12-22T20:54:25Z | 2020-12-22T20:54:25Z | OWNER | https://latest.datasette.io/_internal/foreign_keys (use https://latest.datasette.io/login-as-root first) is now a compound foreign key table: ```sql CREATE TABLE foreign_keys ( "database_name" TEXT, "table_name" TEXT, "id" INTEGER, "seq" INTEGER, "table" TEXT, "from" TEXT, "to" TEXT, "on_update" TEXT, "on_delete" TEXT, "match" TEXT, PRIMARY KEY (database_name, table_name, id, seq), FOREIGN KEY (database_name) REFERENCES databases(database_name), FOREIGN KEY (database_name, table_name) REFERENCES tables(database_name, table_name) ); ``` Currently the `database_name` column becomes a link (because it's a single foreign key) but the `table_name` one remains a non-link: <img width="1079" alt="_internal__foreign_keys__24_rows" src="https://user-images.githubusercontent.com/9599/102932110-87ba3080-4454-11eb-9ad5-b70a65129588.png"> My original idea for compound foreign keys was to turn both of those columns into links, but that doesn't fit here because `database_name` is already part of a different foreign key. | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Support linking to compound foreign keys 743371103 | |
749845797 | https://github.com/simonw/datasette/issues/1099#issuecomment-749845797 | https://api.github.com/repos/simonw/datasette/issues/1099 | MDEyOklzc3VlQ29tbWVudDc0OTg0NTc5Nw== | simonw 9599 | 2020-12-23T00:13:29Z | 2020-12-23T00:14:25Z | OWNER | Also need to solve displaying these links in the opposite direction: https://latest.datasette.io/_internal/tables/fixtures,facet_cities <img width="617" alt="_internal__tables" src="https://user-images.githubusercontent.com/9599/102944742-84cd3900-4470-11eb-95a0-bfaf00b17e82.png"> That page should link to lists of records in columns, foreign_keys and indexes - like this example: https://latest.datasette.io/fixtures/roadside_attractions/1 <img width="712" alt="fixtures__roadside_attractions" src="https://user-images.githubusercontent.com/9599/102944816-c1009980-4470-11eb-9dbd-50d0ba4fd137.png"> | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Support linking to compound foreign keys 743371103 | |
1402563930 | https://github.com/simonw/datasette/issues/1099#issuecomment-1402563930 | https://api.github.com/repos/simonw/datasette/issues/1099 | IC_kwDOBm6k_c5TmW1a | fgregg 536941 | 2023-01-24T20:11:11Z | 2023-01-24T20:11:11Z | CONTRIBUTOR | hi @simonw, this bug bit me today. the UX for linking from a table to the foreign key seems tough! the design in the other direction seems a lot easier, for a given primary key detail page, add links back to the tables that refer to the row. would you be open to a PR that solved the second problem but not the first? | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Support linking to compound foreign keys 743371103 | |
1402898291 | https://github.com/simonw/datasette/issues/1099#issuecomment-1402898291 | https://api.github.com/repos/simonw/datasette/issues/1099 | IC_kwDOBm6k_c5Tnodz | fgregg 536941 | 2023-01-25T00:55:06Z | 2023-01-25T00:55:06Z | CONTRIBUTOR | I went ahead and spiked something together, in #2003 | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Support linking to compound foreign keys 743371103 | |
1402900354 | https://github.com/simonw/datasette/issues/1099#issuecomment-1402900354 | https://api.github.com/repos/simonw/datasette/issues/1099 | IC_kwDOBm6k_c5Tno-C | fgregg 536941 | 2023-01-25T00:58:26Z | 2023-01-25T00:58:26Z | CONTRIBUTOR | > My original idea for compound foreign keys was to turn both of those columns into links, but that doesn't fit here because `database_name` is already part of a different foreign key. it's pretty hard to know what the right thing to do is if a field is part of multiple foreign keys. but, if that's not the case, what about making each of the columns a link. seems like an improvement over the status quo. | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Support linking to compound foreign keys 743371103 |
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]);