issue_comments

Table actions

4 rows where issue = 1781530343 and user = 15178711 sorted by updated_at descending

✎ View and edit SQL

This data as json, CSV (advanced)

Suggested facets: reactions, created_at (date), updated_at (date)

user 1

  • asg017 · 4 ✖

issue 1

  • Proposal: Combine settings, metadata, static, etc. into a single `datasette.yaml` File · 4 ✖

author_association 1

id html_url issue_url node_id user created_at updated_at ▲ author_association body reactions issue performed_via_github_app
1688532012 https://github.com/simonw/datasette/issues/2093#issuecomment-1688532012 https://api.github.com/repos/simonw/datasette/issues/2093 IC_kwDOBm6k_c5kpPQs asg017 15178711 2023-08-22T16:21:40Z 2023-08-22T16:21:40Z CONTRIBUTOR

OK Here's the gameplan for this, which is closely tied to #2143 :

  • We will add a new datasette.json/datasette.yaml configuration file to datasette, which combines settings/plugin config/permissions/canned queries into a new file format
  • Metadata will NOT be a part of this file
  • TOML support is not planned, but maybe we can create a separate issue for support TOML with JSON/YAML
  • The settings.json file will be deprecated, and the --config arg will be brought back.
  • Command line arguments can still be used to overwrite values (ex --setting will overwrite settings in datasette.yaml

The format of datasette.json will follow what Simon listed here: https://github.com/simonw/datasette/issues/2143#issuecomment-1684484426

Here's the current implementation plan:

  1. Add a new --config flag and port over "settings" into a new datasette.json config file, remove settings.json
  2. Add top-level plugin config support to datasette.json
  3. Figure out database/table structure of config datasette.json
  4. Port over database/table level plugin config support datasette.json
  5. Port over permissions/auth settings to datasette.json
  6. Deprecate non-metadata values in metadata.json
 
{
    "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.yaml` 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.yaml` 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.yaml` 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.yaml` File 1781530343  

Advanced export

JSON shape: default, array, newline-delimited, object

CSV options: 

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]);