issue_comments
15 rows where "updated_at" is on date 2020-09-12 sorted by created_at
This data as json, CSV (advanced)
Suggested facets: author_association, reactions, created_at (date)
id | html_url | issue_url | node_id | user | created_at ▼ | updated_at | author_association | body | reactions | issue | performed_via_github_app |
---|---|---|---|---|---|---|---|---|---|---|---|
389702480 | https://github.com/simonw/datasette/issues/262#issuecomment-389702480 | https://api.github.com/repos/simonw/datasette/issues/262 | MDEyOklzc3VlQ29tbWVudDM4OTcwMjQ4MA== | simonw 9599 | 2018-05-17T00:00:39Z | 2020-09-12T18:19:30Z | OWNER | Idea: `?_extra=sqllog` could output a lot of every individual SQL statement that was executed in order to generate the page - useful for seeing how foreign key expansion and faceting actually works. | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Add ?_extra= mechanism for requesting extra properties in JSON 323658641 | |
691379980 | https://github.com/simonw/datasette/issues/963#issuecomment-691379980 | https://api.github.com/repos/simonw/datasette/issues/963 | MDEyOklzc3VlQ29tbWVudDY5MTM3OTk4MA== | simonw 9599 | 2020-09-12T01:50:56Z | 2020-09-12T01:50:56Z | OWNER | Good bug - looks like a problem with the hidden form fields. | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Currently selected array facets are not correctly persisted through hidden form fields 699947574 | |
691501132 | https://github.com/dogsheep/twitter-to-sqlite/issues/50#issuecomment-691501132 | https://api.github.com/repos/dogsheep/twitter-to-sqlite/issues/50 | MDEyOklzc3VlQ29tbWVudDY5MTUwMTEzMg== | bcongdon 706257 | 2020-09-12T14:48:10Z | 2020-09-12T14:48:10Z | NONE | This seems to be an issue even with larger values of `--stop_after`: ``` $ twitter-to-sqlite favorites twitter.db --stop_after=2000 Importing favorites [####################################] 198 $ ``` | {"total_count": 1, "+1": 1, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | favorites --stop_after=N stops after min(N, 200) 698791218 | |
691526416 | https://github.com/simonw/datasette/issues/782#issuecomment-691526416 | https://api.github.com/repos/simonw/datasette/issues/782 | MDEyOklzc3VlQ29tbWVudDY5MTUyNjQxNg== | simonw 9599 | 2020-09-12T18:16:36Z | 2020-09-12T18:16:36Z | OWNER | I'm going to hack together a preview of this in a branch and deploy it somewhere so people can see what I've got planned. Much easier to evaluate a working prototype than static examples. | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Redesign default .json format 627794879 | |
691526489 | https://github.com/simonw/datasette/issues/782#issuecomment-691526489 | https://api.github.com/repos/simonw/datasette/issues/782 | MDEyOklzc3VlQ29tbWVudDY5MTUyNjQ4OQ== | simonw 9599 | 2020-09-12T18:17:16Z | 2020-09-12T18:17:16Z | OWNER | (I think I may have been over-thinking the details of this is for a couple of years now.) | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Redesign default .json format 627794879 | |
691526635 | https://github.com/simonw/datasette/issues/680#issuecomment-691526635 | https://api.github.com/repos/simonw/datasette/issues/680 | MDEyOklzc3VlQ29tbWVudDY5MTUyNjYzNQ== | simonw 9599 | 2020-09-12T18:18:50Z | 2020-09-12T18:18:50Z | OWNER | I'm happy with the not-quite-automated way I'm doing this, so I'm going to close this issue. That's documented here https://docs.datasette.io/en/0.48/contributing.html#release-process - I use https://euangoddard.github.io/clipboard2markdown/ to create the GitHub releases markdown version. | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Release automation: automate the bit that posts the GitHub release 569275763 | |
691526719 | https://github.com/simonw/datasette/issues/262#issuecomment-691526719 | https://api.github.com/repos/simonw/datasette/issues/262 | MDEyOklzc3VlQ29tbWVudDY5MTUyNjcxOQ== | simonw 9599 | 2020-09-12T18:19:50Z | 2020-09-12T18:19:50Z | OWNER | > Idea: `?_extra=sqllog` could output a lot of every individual SQL statement that was executed in order to generate the page - useful for seeing how foreign key expansion and faceting actually works. I built a version of that a while ago as the `?_trace=1` argument. | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Add ?_extra= mechanism for requesting extra properties in JSON 323658641 | |
691526762 | https://github.com/simonw/datasette/issues/782#issuecomment-691526762 | https://api.github.com/repos/simonw/datasette/issues/782 | MDEyOklzc3VlQ29tbWVudDY5MTUyNjc2Mg== | simonw 9599 | 2020-09-12T18:20:19Z | 2020-09-12T18:20:19Z | OWNER | I'd like to revisit the idea of using `?_extra=x` to opt-in to extra blocks of JSON, from #262 | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Redesign default .json format 627794879 | |
691526878 | https://github.com/simonw/datasette/issues/782#issuecomment-691526878 | https://api.github.com/repos/simonw/datasette/issues/782 | MDEyOklzc3VlQ29tbWVudDY5MTUyNjg3OA== | simonw 9599 | 2020-09-12T18:21:41Z | 2020-09-12T18:22:20Z | OWNER | Would it be so bad if the default format had a `"rows"` key containing the array of rows? Maybe it wouldn't. The reason I always use `?_shape=array` is because I want an array of objects, rather than an array of arrays that I have to match up again with their columns. A default format that's an object rather than array also gives something for the `?_extra=` parameter to add its extras to. | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Redesign default .json format 627794879 | |
691526975 | https://github.com/simonw/datasette/issues/262#issuecomment-691526975 | https://api.github.com/repos/simonw/datasette/issues/262 | MDEyOklzc3VlQ29tbWVudDY5MTUyNjk3NQ== | simonw 9599 | 2020-09-12T18:22:44Z | 2020-09-12T18:22:44Z | OWNER | Are there any interesting use-cases for a plugin hook that allows plugins to define their own `?_extra=` blocks? | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Add ?_extra= mechanism for requesting extra properties in JSON 323658641 | |
691554088 | https://github.com/simonw/datasette/issues/782#issuecomment-691554088 | https://api.github.com/repos/simonw/datasette/issues/782 | MDEyOklzc3VlQ29tbWVudDY5MTU1NDA4OA== | simonw 9599 | 2020-09-12T21:39:03Z | 2020-09-12T21:39:03Z | OWNER | Plan: release a new release of Datasette (probably 0.49) with the new JSON API design, but provide a plugin called something like `datasette-api-0-48` which runs as ASGI wrapping middleware and internally rewrites incoming requests to e.g. `/db/table.json` to behave if they have the `?_extra=` params on them necessary to produce the 0.48 version of the JSON. Anyone who has built applications against 0.48 can install that plugin. | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Redesign default .json format 627794879 | |
691557429 | https://github.com/simonw/datasette/issues/880#issuecomment-691557429 | https://api.github.com/repos/simonw/datasette/issues/880 | MDEyOklzc3VlQ29tbWVudDY5MTU1NzQyOQ== | simonw 9599 | 2020-09-12T21:59:39Z | 2020-09-12T21:59:39Z | OWNER | What should happen when something does a POST to an extension that was registered by a plugin, e.g. `POST /db/table.atom` ? | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | POST to /db/canned-query that returns JSON should be supported (for API clients) 648637666 | |
691557675 | https://github.com/simonw/datasette/issues/880#issuecomment-691557675 | https://api.github.com/repos/simonw/datasette/issues/880 | MDEyOklzc3VlQ29tbWVudDY5MTU1NzY3NQ== | simonw 9599 | 2020-09-12T22:01:02Z | 2020-09-12T22:01:11Z | OWNER | Maybe POST to `.json` doesn't actually make sense. I could instead support `POST /db/queryname` with an optional mechanism for requesting that the response to that POST be in a JSON format. Could be a `Accept: application/json` header with an option of including `"_accept": "json"` as a POST parameter instead. | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | POST to /db/canned-query that returns JSON should be supported (for API clients) 648637666 | |
691558387 | https://github.com/simonw/datasette/issues/880#issuecomment-691558387 | https://api.github.com/repos/simonw/datasette/issues/880 | MDEyOklzc3VlQ29tbWVudDY5MTU1ODM4Nw== | simonw 9599 | 2020-09-12T22:04:48Z | 2020-09-12T22:04:48Z | OWNER | Is it safe to skip CSRF checks if the incoming request has `Accept: application/json` on it? I'm not sure that matters since `asgi-csrf` already won't reject requests that either have no cookies or are using a `Authorization: Bearer ...` header. | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | POST to /db/canned-query that returns JSON should be supported (for API clients) 648637666 | |
691566247 | https://github.com/simonw/datasette/issues/519#issuecomment-691566247 | https://api.github.com/repos/simonw/datasette/issues/519 | MDEyOklzc3VlQ29tbWVudDY5MTU2NjI0Nw== | simonw 9599 | 2020-09-12T22:48:53Z | 2020-09-12T22:48:53Z | OWNER | I think I've figured out what to do about stability of the HTML and the default templates with respect to semantic versioning. I'm going to announce that the JSON API - including the variables made available to templates - should be considered stable according to semver. I will only break backwards compatibility at that level in a major version release. The template HTML (and default CSS) will not be considered a stable interface. They won't change on bug fix releases but they may change (albeit described in the release notes) on minor version bumps. Since the template inputs are stable, you can run your own copy of the previous version's templates if something breaks. This means users (and plugin authors) who make changes to the default Datasette UI will have to test their changes against every minor release. I think that's OK. If you write plugins that don't affect the Datasette HTML UI you will be able to expect stability across minor version releases. | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Decide what goes into Datasette 1.0 459590021 |
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 ✖