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/943#issuecomment-675753114 | https://api.github.com/repos/simonw/datasette/issues/943 | 675753114 | MDEyOklzc3VlQ29tbWVudDY3NTc1MzExNA== | 9599 | 2020-08-18T22:34:55Z | 2020-08-18T22:34:55Z | OWNER | Maybe allow this: response = await datasette.get("/{database}/{table}.json", database=database, table=table) This could cause problems if users ever need to pass literal `{` in their paths. Maybe allow this too: response = await datasette.get("/{database}/{table}.json", interpolate=False) Not convinced this is useful - it's a bit unintuitive. | { "total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0 } |
681375466 | |
https://github.com/simonw/datasette/issues/943#issuecomment-675752436 | https://api.github.com/repos/simonw/datasette/issues/943 | 675752436 | MDEyOklzc3VlQ29tbWVudDY3NTc1MjQzNg== | 9599 | 2020-08-18T22:32:44Z | 2020-08-18T22:32:44Z | OWNER | One thing to consider here: Datasette's table and database name escaping rules can be a little bit convoluted. If a plugin wants to get back the first five rows of a table, it will need to construct a URL `/dbname/tablename?_size=5` - but it will need to know how to turn the database and table names into the correctly escaped `dbname` and `tablename` values. Here's how the `row.html` table handles that right now: https://github.com/simonw/datasette/blob/b21ed237ab940768574c834aa5a7130724bd3a2d/datasette/templates/row.html#L19-L23 It would be an improvement to have this logic abstracted out somewhere and documented so plugins can use it. | { "total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0 } |
681375466 | |
https://github.com/simonw/datasette/issues/943#issuecomment-675751719 | https://api.github.com/repos/simonw/datasette/issues/943 | 675751719 | MDEyOklzc3VlQ29tbWVudDY3NTc1MTcxOQ== | 9599 | 2020-08-18T22:30:27Z | 2020-08-18T22:30:27Z | OWNER | Right now calling `datasette.app()` instantiates an ASGI application - complete with a bunch of routes and wrappers - and returns that application object. Calling it twice instantiates another ASGI application. I think a single `Datasette` instance should only ever create a single ASGI app - so the `.app()` method should cache the ASGI app that it returns the first time and return the same application again on future calls. | { "total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0 } |
681375466 | |
https://github.com/simonw/datasette/issues/943#issuecomment-675750845 | https://api.github.com/repos/simonw/datasette/issues/943 | 675750845 | MDEyOklzc3VlQ29tbWVudDY3NTc1MDg0NQ== | 9599 | 2020-08-18T22:27:43Z | 2020-08-18T22:27:43Z | OWNER | What about authentication checks etc? Won't they run twice? I think that's OK too, in fact it's desirable: think of the case of `datasette-graphql` where a bunch of different TableView calls are being made as part of the same GraphQL queries. Having those calls take advantage of finely grained per-table authentication and permission checks seems like a good feature. | { "total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0 } |
681375466 | |
https://github.com/simonw/datasette/issues/943#issuecomment-675750382 | https://api.github.com/repos/simonw/datasette/issues/943 | 675750382 | MDEyOklzc3VlQ29tbWVudDY3NTc1MDM4Mg== | 9599 | 2020-08-18T22:26:15Z | 2020-08-18T22:26:15Z | OWNER | Should internal requests executed in this way be handled by plugins that used the `asgi_wrapper()` hook? Hard to be sure one way or the other. I'm worried about logging middleware triggering twice - but actually anyone doing serious logging of their Datasette instance is probably doing it in a different layer (uvicorn logs or nginx proxy or whatever) so they wouldn't be affected. There aren't any ASGI logging middlewares out there that I've seen. Also: if you run into a situation where your stuff is breaking because `datasette.get()` is calling ASGI middleware twice you can fix it by running your ASGI middleware outside of the `asgi_wrapper` plugin hook mechanism. So I think it DOES execute `asgi_wrapper()` middleware. | { "total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0 } |
681375466 | |
https://github.com/simonw/datasette/issues/943#issuecomment-675749319 | https://api.github.com/repos/simonw/datasette/issues/943 | 675749319 | MDEyOklzc3VlQ29tbWVudDY3NTc0OTMxOQ== | 9599 | 2020-08-18T22:23:01Z | 2020-08-18T22:23:01Z | OWNER | Actually no - `requests.get()` and `httpx.get()` prove that having a `.get()` method for an HTTP-related API isn't confusing to people at all. `datasette.get()` it is. (I'll probably add `datasette.post()` in the future too). | { "total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0 } |
681375466 | |
https://github.com/simonw/datasette/issues/943#issuecomment-675749076 | https://api.github.com/repos/simonw/datasette/issues/943 | 675749076 | MDEyOklzc3VlQ29tbWVudDY3NTc0OTA3Ng== | 9599 | 2020-08-18T22:22:21Z | 2020-08-18T22:22:21Z | OWNER | Alternative name possibilities: - `datasette.http_get(...)` - slightly misleading since it's not going over the HTTP protocol - `datasette.internal_get(...)` - the `internal_` might suggest its not an API for external use, which isn't true - it's for plugins - `datasette.get(...)` - clashes with `dict.get()` but I'm not at all sure that's a good reason not to use it | { "total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0 } |
681375466 | |
https://github.com/simonw/datasette/issues/943#issuecomment-675748573 | https://api.github.com/repos/simonw/datasette/issues/943 | 675748573 | MDEyOklzc3VlQ29tbWVudDY3NTc0ODU3Mw== | 9599 | 2020-08-18T22:20:52Z | 2020-08-18T22:20:52Z | OWNER | Should it default to treating things as if they had the `.json` extension? There are use-cases for the non-JSON method, such as https://github.com/natbat/tidepools_near_me/commit/ec102c6da5a5d86f17628740d90b6365b671b5e1 I think I'm OK with people having to add `.json` to their internal calls. Maybe they could use `format="json"`) as an optional parameter which would automatically handle the very weird edge-cases where you need to use `?_format=json` instead of `.json` (due to table names existing with a `.json` suffix). | { "total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0 } |
681375466 | |
https://github.com/simonw/datasette/issues/943#issuecomment-675747878 | https://api.github.com/repos/simonw/datasette/issues/943 | 675747878 | MDEyOklzc3VlQ29tbWVudDY3NTc0Nzg3OA== | 9599 | 2020-08-18T22:18:46Z | 2020-08-18T22:19:12Z | OWNER | Could be as simple as `response = await datasette.get("/path/blah")` - which could also be re-used by the implementation of the `datasette --get /` CLI option introduced in #927. Bit weird calling it `.get()` since that clashes with Python's dictionary `.get()` method. | { "total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0 } |
681375466 |