issue_comments
7 rows where issue = 1781530343
This data as json, CSV (advanced)
Suggested facets: user, author_association, reactions, 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 |
|---|---|---|---|---|---|---|---|---|---|---|---|
| 1613887492 | https://github.com/simonw/datasette/issues/2093#issuecomment-1613887492 | https://api.github.com/repos/simonw/datasette/issues/2093 | IC_kwDOBm6k_c5gMfgE | simonw 9599 | 2023-06-29T22:40:25Z | 2023-06-29T22:40:25Z | OWNER | I'm strongly in favour of combining settings, configuration and plugin configuration. I'm not keen on mixing in metadata as well - that feels like a different concept to me, and I'm unhappy with how that's already had things like plugin settings leak into it. I'm not yet sold on TOML - I actually find it less intuitive than YAML, surprisingly. They all have their warts I guess. Datasette already has the ability to consume JSON or YAML for metadata - maybe it could grow TOML support too? That way users could have a `datasette.json` or `datasette.yaml` or `datasette.toml` file depending on their preference. In terms of metadata: since that's means to be driven by a plugin hook anyway, maybe one of the potential sources of metadata is a `metadata` nested object in that `datasette.*` configuration file. Or you can have it in a separate `metadata.json` or bundled into the SQLite database or some other plugin-driven mechanism. | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Proposal: Combine settings, metadata, static, etc. into a single `datasette.toml` File 1781530343 | |
| 1613889979 | https://github.com/simonw/datasette/issues/2093#issuecomment-1613889979 | https://api.github.com/repos/simonw/datasette/issues/2093 | IC_kwDOBm6k_c5gMgG7 | simonw 9599 | 2023-06-29T22:44:08Z | 2023-06-30T13:25:39Z | OWNER | I do like also being able to set options using command line options though - for things like SQL time limits I'd much rather be able to throw on `--setting sql_time_limit_ms 10000` than have to save a config file to disk. So I'd want to support both. Which maybe means also having a way to set plugin options with CLI options. `datasette publish` kind of has that ability already: ``` datasette publish heroku my_database.db \ --name my-heroku-app-demo \ --install=datasette-auth-github \ --plugin-secret datasette-auth-github client_id your_client_id \ --plugin-secret datasette-auth-github client_secret your_client_secret ``` | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Proposal: Combine settings, metadata, static, etc. into a single `datasette.toml` File 1781530343 | |
| 1613895188 | https://github.com/simonw/datasette/issues/2093#issuecomment-1613895188 | https://api.github.com/repos/simonw/datasette/issues/2093 | IC_kwDOBm6k_c5gMhYU | asg017 15178711 | 2023-06-29T22:51:53Z | 2023-06-29T22:51:53Z | CONTRIBUTOR | I agree with not liking `metadata.json` stuff in a `datasette.*` config file. Editing description of a table/column in a file like `datasette.*` seems odd to me. Though since plugin configuration currently lives in `metadata.json`, I think it should be removed from there and placed in `datasette.*`, at least for top-level config like `datasette-auth-github`'s config. Keeping `metadata.json` strictly for documentation/licensing/column units makes sense to me, but anything plugin related should be in some config file, like `datasette.*`. And ya, supporting both `datasette.*` and CLI flags makes a lot of sense to me. Any `--setting` flag should override anything in `datasette.*` for easier debugging, with possibly a warning message so people don't get confused. Same with `--port` and a port defined in `datasette.*` | {"total_count": 1, "+1": 1, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Proposal: Combine settings, metadata, static, etc. into a single `datasette.toml` File 1781530343 | |
| 1613896210 | https://github.com/simonw/datasette/issues/2093#issuecomment-1613896210 | https://api.github.com/repos/simonw/datasette/issues/2093 | IC_kwDOBm6k_c5gMhoS | asg017 15178711 | 2023-06-29T22:53:33Z | 2023-06-29T22:53:33Z | CONTRIBUTOR | Maybe we can have a separate issue for revamping `metadata.json`? A `datasette_metadata` table or the `sqlite-docs` extension seem like two reasonable additions that we can work through. Storing metadata inside a SQLite database makes sense, but I don't think storing `datasette.*` style config (ex ports, settings, etc.) inside a SQLite DB makes sense, since it's very environment-dependent | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Proposal: Combine settings, metadata, static, etc. into a single `datasette.toml` File 1781530343 | |
| 1614652001 | https://github.com/simonw/datasette/issues/2093#issuecomment-1614652001 | https://api.github.com/repos/simonw/datasette/issues/2093 | IC_kwDOBm6k_c5gPaJh | simonw 9599 | 2023-06-30T13:27:13Z | 2023-06-30T13:27:13Z | OWNER | I agree, settings in the DB doesn't make sense but metadata does. On the JSON v YAML v TOML issue I just spotted Caddy has a concept of config adapters which they use to resolve exactly that problem: https://caddyserver.com/docs/config-adapters | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Proposal: Combine settings, metadata, static, etc. into a single `datasette.toml` File 1781530343 | |
| 1616195496 | https://github.com/simonw/datasette/issues/2093#issuecomment-1616195496 | https://api.github.com/repos/simonw/datasette/issues/2093 | IC_kwDOBm6k_c5gVS-o | terinjokes 273509 | 2023-07-02T00:06:54Z | 2023-07-02T00:07:17Z | NONE | I'm not keen on requiring metadata to be within the database. I commonly have multiple DBs, from various sources, and having one config file to provide the metadata works out very well. I use Datasette with databases where I'm not the original source, needing to mutate them to add a metadata table or sqlite-docs makes me uncomfortable. | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Proposal: Combine settings, metadata, static, etc. into a single `datasette.toml` File 1781530343 | |
| 1616286848 | https://github.com/simonw/datasette/issues/2093#issuecomment-1616286848 | https://api.github.com/repos/simonw/datasette/issues/2093 | IC_kwDOBm6k_c5gVpSA | asg017 15178711 | 2023-07-02T02:17:46Z | 2023-07-02T02:17:46Z | CONTRIBUTOR | Storing metadata in the database won't be required. I imagine there'll be many different ways to store metadata, including any possible `datasette_metadata` or sqlite-docs, or the older metadata.json way. The next question will be how precedence should work - i'd imagine metadata.json > plugins > datasette_metadata > sqlite-docs | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Proposal: Combine settings, metadata, static, etc. into a single `datasette.toml` File 1781530343 |
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]);