issues

Spotted a problem while working on this: if you grant a token access to view table for a specific table but don't also grant view database and view instance permissions, that token is useless.

This was a deliberate design decision in Datasette - it's documented on https://docs.datasette.io/en/1.0a2/authentication.html#access-permissions-in-metadata

If a user cannot access a specific database, they will not be able to access tables, views or queries within that database. If a user cannot access the instance they will not be able to access any of the databases, tables, views or queries.

I'm now second-guessing if this was a good decision.

Originally posted by @simonw in https://github.com/simonw/datasette-auth-tokens/issues/7#issuecomment-1636031702

For every command/API method there should be a link to the equivalent in the other form factor.

Maybe also link to the API and CLI reference pages too.

Label detection doesn't work if the primary key is called pk rather than id, so this page doesn't work: https://latest.datasette.io/fixtures/roadside_attraction_characteristics

Code is here:

https://github.com/simonw/datasette/blob/cccea85be6aaaeadb31f3b588ec7f732628815f5/datasette/app.py#L644-L653

Spin off from #251. The ability to execute Python functions to convert and split columns should be part of the library too, not just the CLI.

e.g. I should be able to do this:

datasette App/data.db Other_App/data.db

This currently errors because you can't have two databases taking the /data URL path.

Instead, how about in this particular case assigning the second database /data-1?

Refs #943

It can go here in the documentation: https://datasette.readthedocs.io/en/stable/metadata.html#setting-which-columns-can-be-used-for-sorting

Also need to fix this sentence which is no longer true:

By default, database views in Datasette do not support sorting

Right now it's triggering any time a mutable database changes.

This feature really doesn't warrant continuing to exist. For reference: #150 and #44

Don't forget to remove it from the docs: https://github.com/simonw/datasette/blob/172da009d890aa029cff7138b4dcfd4f60948525/docs/json_api.rst#L322-L324

Currently if there's a null in a foreign key we get "None" displayed in the inflated view:

It would be useful if Datasette could be configured to allow CORS requests from one or more origins, as opposed to only allowing either none or "*".

This is slightly tricky because the Access-Control-Allow-Origin: https://foo.example header is only allowed to return one value per request - and according to https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS "The Access-Control-Allow-Origin header should contain the value that was sent in the request's Origin header."

This means the application code needs to have a whitelist of allowed hosts and code that dynamically changes the outgoing Access-Control-Allow-Origin header based on the Origin header from the incoming request.

E.g. if a field contains "Tags,With,Commas" be able to facet them in the same way as _facet_array= lets you facet ["Tags", "With", "Commas"]

Right now a super-long CREATE TABLE statement causes the table page to be even wider than the table itself:

Adding white-space: pre-wrap to that <pre> element is an easy fix:

After #272 we can finally add this hook. It will allow plugins to wrap their own ASGI middleware around Datasette. Potential use-cases include:

• adding authentication
• custom CORS headers (see #454)
• maybe gzip support?
• possibly defining entirely new routes, though that may be better handled by a separate hook

https://datasette.readthedocs.io/en/stable/full_text_search.html already has a section about csvs-to-sqlite, sqlite-utils is even more relevant.

Most of the code here was fleshed out in comments on #272 (Port Datasette to ASGI) - this pull request will track the final pieces:

• [x] Update test harness to more correctly simulate the raw_path issue
• [x] Use raw_path so table names containing / can work correctly
• [x] Bug: JSON not served with correct content-type
• [x] Get ?_trace=1 working again
• [x] Replacement for @app.listener("before_server_start")
• [x] Bug: /fixtures/table%2Fwith%2Fslashes.csv?_format=json downloads as CSV
• [x] Replace Sanic request and response objects with my own classes, so I can remove Sanic dependency
• [x] Final code tidy-up before merging to master

Datasette doesn't take much advantage of Sanic, and I'm increasingly having to work around parts of it because of idiosyncrasies that are specific to Datasette - caring about the exact order of querystring arguments for example.

Since Datasette is GET-only our needs from a web framework are actually pretty slim.

This becomes more important as I expand the plugins #14 framework. Am I sure I want the plugin ecosystem to depend on a Sanic if I might move away from it in the future?

If Datasette wasn't all about async/await I would use WSGI, but today it makes more sense to use ASGI. I'd like to be confident that switching to ASGI would still give me the excellent performance that Sanic provides.

https://github.com/django/asgiref/blob/master/specs/asgi.rst

As requested in https://github.com/simonw/datasette/issues/185#issuecomment-376614973

I've previously avoided this for performance reasons: sort-by-column on a column without an index is likely to perform badly for hundreds of thousands of rows.

That's not a good enough reason to avoid the feature entirely though. A few options:

• Allow sort-by-column by default, give users the option to disable it for specific tables/columns
• Disallow sort-by-column by default, give users option (probably in metadata.json) to enable it for specific tables/columns
• Automatically detect if a column either has an index on it OR a table has less than X rows in it

We already have the mechanism in place to cut off SQL queries that take more than X seconds, so if someone DOES try to sort by a column that's too expensive it won't actually hurt anything - but it would be nice to not show people a "sort" option which is guaranteed to throw a timeout error.

The vast majority of datasette usage that I've seen so far is on smaller datasets where the performance penalties of sort-by-column are extremely unlikely to show up.

Still left to do:

• [x] UI that shows which sort order is currently being applied (in HTML and in JSON)
• [x] UI for applying a sort order (with rel=nofollow to avoid Google crawling it)
• [x] Sort column names should be escaped correctly in generated SQL
• [x] Validation that the selected sort order is a valid column
• [x] Throw error if user attempts to apply _sort AND _sort_desc at the same time
• [x] Ability to disable sorting (or sort only for specific columns) in metadata.json
• [x] Fix "201 rows where sorted by sortable_with_nulls " bug

Probably using YAML because then we get support for multiline strings:

bats:
  db: bats.sqlite3
  name: "Bat sightings"
  queries:
    specific_row: |
      select * from Bats
      where a = 1;