github
html_url | issue_url | id | node_id | user | created_at | updated_at | author_association | body | reactions | issue | performed_via_github_app |
---|---|---|---|---|---|---|---|---|---|---|---|
https://github.com/simonw/datasette/issues/2143#issuecomment-1685263948 | https://api.github.com/repos/simonw/datasette/issues/2143 | 1685263948 | IC_kwDOBm6k_c5kcxZM | 11784304 | 2023-08-20T11:50:10Z | 2023-08-20T11:50:10Z | NONE | This also makes it simple to separate out secrets. `datasette --config settings.yaml --config secrets.yaml --config db-docs.yaml --config db-fixtures.yaml` settings.yaml ``` settings: default_page_size: 10 max_returned_rows: 3000 sql_time_limit_ms": 8000 plugins: datasette-ripgrep: path: /usr/local/lib/python3.11/site-packages ``` secrets.yaml ``` plugins: datasette-auth-github: client_secret: SUCH_SECRET ``` db-docs.yaml ``` databases: docs: permissions: create-table: id: editor ``` db-fixtures.yaml ``` databases: fixtures: tables: no_primary_key: hidden: true queries: neighborhood_search: sql: |- select neighborhood, facet_cities.name, state from facetable join facet_cities on facetable.city_id = facet_cities.id where neighborhood like '%' || :text || '%' order by neighborhood; title: Search neighborhoods description_html: |- <p>This demonstrates <em>basic</em> LIKE search ``` | { "total_count": 1, "+1": 1, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0 } |
1855885427 | |
https://github.com/simonw/datasette/issues/2143#issuecomment-1685260624 | https://api.github.com/repos/simonw/datasette/issues/2143 | 1685260624 | IC_kwDOBm6k_c5kcwlQ | 11784304 | 2023-08-20T11:31:16Z | 2023-08-20T11:31:16Z | NONE | https://pypi.org/project/deep-chainmap/ | { "total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0 } |
1855885427 | |
https://github.com/simonw/datasette/issues/2143#issuecomment-1685260244 | https://api.github.com/repos/simonw/datasette/issues/2143 | 1685260244 | IC_kwDOBm6k_c5kcwfU | 11784304 | 2023-08-20T11:29:00Z | 2023-08-20T11:29:00Z | NONE | https://docs.python.org/3/library/collections.html#collections.ChainMap | { "total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0 } |
1855885427 | |
https://github.com/simonw/datasette/issues/2143#issuecomment-1685259985 | https://api.github.com/repos/simonw/datasette/issues/2143 | 1685259985 | IC_kwDOBm6k_c5kcwbR | 11784304 | 2023-08-20T11:27:21Z | 2023-08-20T11:27:21Z | NONE | To chime in from a poweruser perspective: I'm worried that this is an overengineering trap. Yes, the current solution is somewhat messy. But there are datasette-wide settings, there are database-scope settings, there are table-scope settings etc, but then there are database-scope metadata and table-scope metadata. Trying to cleanly separate "settings" from "configuration" is, I believe, an uphill fight. Even separating db/table-scope settings from pure descriptive metadata is not always easy. Like, do canned queries belong to database metadata or to settings? Do I need two separate files for this? One pragmatic solution I used in a project is stacking yaml configuration files. Basically, have an arbitrary number of yaml or json settings files that you load in a specified order. Every file adds to the corresponding settings in the earlier-loaded file (if it already existed). I implemented this myself but found later that there is an existing Python "cascading dict" type of thing, I forget what it's called. There is a bit of a challenge deciding whether there is "replacement" or "addition" (I think I pragmatically ran `update` on the second level of the dict but better solutions are certainly possible). This way, one allows separation of settings into different blocks, while not imposing a specific idea of what belongs where that might not apply equally to all cases. | { "total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0 } |
1855885427 |