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/2153#issuecomment-1691779180 | https://api.github.com/repos/simonw/datasette/issues/2153 | 1691779180 | IC_kwDOBm6k_c5k1oBs | 9599 | 2023-08-24T14:21:03Z | 2023-08-24T14:21:03Z | OWNER | `datasette serve` currently only has a `--get` - for this to be really useful it needs to grow `--post` and maybe other verbs too. Which is a good argument for moving this functionality to `datasette client get ...` instead. | { "total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0 } |
1865232341 | |
https://github.com/simonw/datasette/issues/2153#issuecomment-1691763427 | https://api.github.com/repos/simonw/datasette/issues/2153 | 1691763427 | IC_kwDOBm6k_c5k1kLj | 9599 | 2023-08-24T14:12:43Z | 2023-08-24T14:12:43Z | OWNER | Annoying that `datasette client ...` makes a great name both for a plugin that executes simulated queries against a local database (thanks to its similarity to the existing `datasette.client` Python API) but is also the ideal name for a command for running commands as a client of an external Datasette instance! | { "total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0 } |
1865232341 | |
https://github.com/simonw/datasette/issues/2153#issuecomment-1691761685 | https://api.github.com/repos/simonw/datasette/issues/2153 | 1691761685 | IC_kwDOBm6k_c5k1jwV | 9599 | 2023-08-24T14:11:41Z | 2023-08-24T14:11:41Z | OWNER | Another option: implement this as a plugin, providing a new command like `datasette get ...` Or implement `datasette client get ...` as core commands or a plugin - except that clashes with the `datasette client` command that https://github.com/simonw/dclient adds (which is a tool for hitting remote Datasette instances, not running simulated queries through a local one). | { "total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0 } |
1865232341 | |
https://github.com/simonw/datasette/issues/2153#issuecomment-1691753489 | https://api.github.com/repos/simonw/datasette/issues/2153 | 1691753489 | IC_kwDOBm6k_c5k1hwR | 9599 | 2023-08-24T14:07:25Z | 2023-08-24T14:09:16Z | OWNER | Building that `"_r"` array is the main reason this would be useful, but it's also fiddly to get right. `datasette create-token` has a design for that already: https://docs.datasette.io/en/1.0a4/authentication.html#datasette-create-token ``` datasette create-token root \ --secret mysecret \ --all view-instance \ --all view-table \ --database docs view-query \ --resource docs documents insert-row \ --resource docs documents update-row ``` Adding imitations of those options (excluding `--secret`, not needed here) to `datasette serve` would add a LOT of extra options, but it would also make it really convenient to attempt a request with a specific set of restrictions. Not sure if that would be worth the extra `--help` output or not. I feel like the names would have to have a common prefix though. Maybe something like this: ```bash datasette serve data.db --get `/data/mytable.json' \ --actor-id root \ --r-all view-instance \ --r-database data view-query \ --r-resource data documents update-row ``` Other options could be the longer `--restrict-all/--restrict-database/--restrict-resource`. | { "total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0 } |
1865232341 |