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/915#issuecomment-675751136 | https://api.github.com/repos/simonw/datasette/issues/915 | 675751136 | MDEyOklzc3VlQ29tbWVudDY3NTc1MTEzNg== | 9599 | 2020-08-18T22:28:36Z | 2020-08-18T22:28:36Z | OWNER | I'm closing this in favour of an internal requests mechanism in #943. | { "total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0 } |
671763164 | |
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 | |
https://github.com/simonw/datasette/issues/915#issuecomment-675746544 | https://api.github.com/repos/simonw/datasette/issues/915 | 675746544 | MDEyOklzc3VlQ29tbWVudDY3NTc0NjU0NA== | 9599 | 2020-08-18T22:14:41Z | 2020-08-18T22:14:41Z | OWNER | I'm actually pretty happy with how `datasette-graphql` works now - maybe the trick here is to redesign the JSON format in #782 such that it can be used as a documented interface by things like `datasette-graphql` and then ensure Datasette has a documented mechanism for dispatching internal requests. I just did a horrible hack here that simulates an internal request, so supporting them as a feature would definitely make sense: https://github.com/natbat/tidepools_near_me/commit/ec102c6da5a5d86f17628740d90b6365b671b5e1 | { "total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0 } |
671763164 | |
https://github.com/simonw/datasette/issues/268#issuecomment-675725464 | https://api.github.com/repos/simonw/datasette/issues/268 | 675725464 | MDEyOklzc3VlQ29tbWVudDY3NTcyNTQ2NA== | 9599 | 2020-08-18T21:18:07Z | 2020-08-18T21:18:35Z | OWNER | I want this on the table page - but that means that the table page will need to run a slightly more complex query since it needs access to a `rank` column to sort by - which it gets from running a join. BUT... that join needs to be constructed in a way that keeps existing filters, `?_where=` clauses etc intact. Here's a prototype using SQLite CTEs: https://register-of-members-interests.datasettes.com/regmem?sql=with+original+as+%28select+rowid%2C+*+from+items%29%0D%0Aselect%0D%0A++original.*%2C%0D%0A++items_fts.rank+as+items_fts_rank%0D%0Afrom%0D%0A++original+join+items_fts+on+original.rowid+%3D+items_fts.rowid%0D%0Awhere%0D%0A++items_fts+match+escape_fts%28%3Asearch%29%0D%0Aorder+by+items_fts_rank+desc+limit+10&search=hotel ```sql with original as ( select rowid, * from items ) select original.*, items_fts.rank as items_fts_rank from original join items_fts on original.rowid = items_fts.rowid where items_fts match escape_fts(:search) order by items_fts_rank desc limit 10 ``` | { "total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0 } |
323718842 | |
https://github.com/simonw/datasette/issues/942#issuecomment-675720040 | https://api.github.com/repos/simonw/datasette/issues/942 | 675720040 | MDEyOklzc3VlQ29tbWVudDY3NTcyMDA0MA== | 9599 | 2020-08-18T21:05:24Z | 2020-08-18T21:05:24Z | OWNER | Is `columns` the right key for this in the table metadata block? I might want to use that for initial values for `?_col=` in #615. Alternative names: - `column_descriptions` - `column_info` | { "total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0 } |
681334912 | |
https://github.com/simonw/datasette/issues/942#issuecomment-675718593 | https://api.github.com/repos/simonw/datasette/issues/942 | 675718593 | MDEyOklzc3VlQ29tbWVudDY3NTcxODU5Mw== | 9599 | 2020-08-18T21:02:11Z | 2020-08-18T21:02:24Z | OWNER | Easiest solution: if you provide column metadata it gets displayed above the table, something like on https://fivethirtyeight.datasettes.com/fivethirtyeight/antiquities-act%2Factions_under_antiquities_act <img width="500" alt="fivethirtyeight__antiquities-act_actions_under_antiquities_act__344_rows" src="https://user-images.githubusercontent.com/9599/90565187-57d3e700-e15b-11ea-89c8-0270e3040a50.png"> HTML `title=` tooltips are also added to the table headers, which won't be visible on touch devices but that's OK because the information is visible on the page already. | { "total_count": 1, "+1": 1, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0 } |
681334912 | |
https://github.com/simonw/datasette/issues/942#issuecomment-675715472 | https://api.github.com/repos/simonw/datasette/issues/942 | 675715472 | MDEyOklzc3VlQ29tbWVudDY3NTcxNTQ3Mg== | 9599 | 2020-08-18T20:55:02Z | 2020-08-18T20:55:02Z | OWNER | Could display these as tooltips on icons something like this (from the experimental `datasette-inspect-columns` plugin): <img width="500" alt="fixtures__facetable__15_rows_and_NOAA_tides_second_attempt_-_Jupyter_Notebook" src="https://user-images.githubusercontent.com/9599/90564416-37eff380-e15a-11ea-95e5-b556e9039a2a.png"> This would need to take accessibility into account, and would need a different display for the mobile web layout. Need to consider how it will interact with the column menu suggested in #690. | { "total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0 } |
681334912 | |
https://github.com/simonw/datasette/issues/873#issuecomment-675610275 | https://api.github.com/repos/simonw/datasette/issues/873 | 675610275 | MDEyOklzc3VlQ29tbWVudDY3NTYxMDI3NQ== | 9599 | 2020-08-18T17:24:05Z | 2020-08-18T17:26:10Z | OWNER | Maybe I can do this with ASGI after all. Here's the output of `/-/asgi-scope` with `datasette-debug-asgi` installed: ``` {'asgi': {'spec_version': '2.1', 'version': '3.0'}, 'client': ('127.0.0.1', 62035), 'headers': [(b'host', b'127.0.0.1:62029'), (b'user-agent', b'Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:79.0) Gecko' b'/20100101 Firefox/79.0'), (b'accept', b'text/html,application/xhtml+xml,application/xml;q=0.9,image/' b'webp,*/*;q=0.8'), (b'accept-language', b'en-US,en;q=0.5'), (b'accept-encoding', b'gzip, deflate'), (b'dnt', b'1'), (b'connection', b'keep-alive'), (b'upgrade-insecure-requests', b'1'), (b'cache-control', b'max-age=0')], 'http_version': '1.1', 'method': 'GET', 'path': '/-/asgi-scope', 'query_string': b'', 'raw_path': b'/-/asgi-scope', 'root_path': '', 'scheme': 'http', 'server': ('127.0.0.1', 62029), 'type': 'http'} ``` That `'server': ('127.0.0.1', 62029)` bit has the correct port. Question is, can I access that programmatically on server startup? | { "total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0 } |
647095487 | |
https://github.com/simonw/datasette/issues/873#issuecomment-675609109 | https://api.github.com/repos/simonw/datasette/issues/873 | 675609109 | MDEyOklzc3VlQ29tbWVudDY3NTYwOTEwOQ== | 9599 | 2020-08-18T17:21:51Z | 2020-08-18T17:21:51Z | OWNER | Asked about this on the encode gitter here: https://gitter.im/encode/community?at=5f3c0dcaa8c17801765940c0 | { "total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0 } |
647095487 | |
https://github.com/simonw/datasette/issues/940#issuecomment-675538586 | https://api.github.com/repos/simonw/datasette/issues/940 | 675538586 | MDEyOklzc3VlQ29tbWVudDY3NTUzODU4Ng== | 9599 | 2020-08-18T15:11:36Z | 2020-08-18T15:11:36Z | OWNER | I tested this new publish pattern (running the tests in parallel before the deploy step) on `github-to-sqlite` - skipping the Docker step - and it worked: https://github.com/dogsheep/github-to-sqlite/actions/runs/213809864 | { "total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0 } |
679808124 | |
https://github.com/simonw/datasette/issues/940#issuecomment-675253373 | https://api.github.com/repos/simonw/datasette/issues/940 | 675253373 | MDEyOklzc3VlQ29tbWVudDY3NTI1MzM3Mw== | 9599 | 2020-08-18T05:10:17Z | 2020-08-18T05:10:17Z | OWNER | I'll close this after the next release successfully goes out. | { "total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0 } |
679808124 | |
https://github.com/simonw/datasette/issues/940#issuecomment-675251613 | https://api.github.com/repos/simonw/datasette/issues/940 | 675251613 | MDEyOklzc3VlQ29tbWVudDY3NTI1MTYxMw== | 9599 | 2020-08-18T05:05:15Z | 2020-08-18T05:05:15Z | OWNER | I think this is ready. I'll only know for sure the first time I push a release through it though! | { "total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0 } |
679808124 | |
https://github.com/simonw/datasette/issues/940#issuecomment-674590583 | https://api.github.com/repos/simonw/datasette/issues/940 | 674590583 | MDEyOklzc3VlQ29tbWVudDY3NDU5MDU4Mw== | 9599 | 2020-08-16T23:15:51Z | 2020-08-18T05:04:43Z | OWNER | This example of jobs depending on each other and sharing data via artifacts looks relevant: https://docs.github.com/en/actions/configuring-and-managing-workflows/persisting-workflow-data-using-artifacts#passing-data-between-jobs-in-a-workflow | { "total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0 } |
679808124 | |
https://github.com/simonw/datasette/issues/940#issuecomment-675250280 | https://api.github.com/repos/simonw/datasette/issues/940 | 675250280 | MDEyOklzc3VlQ29tbWVudDY3NTI1MDI4MA== | 9599 | 2020-08-18T05:01:34Z | 2020-08-18T05:01:42Z | OWNER | I think `${GITHUB_REF#refs/tags/}` is the equivalent of `$TRAVIS_TAG`. | { "total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0 } |
679808124 |