1.0a6

• New plugin hook: actors_from_ids(datasette, actor_ids) and an internal method to accompany it, await .actors_from_ids(actor_ids). This mechanism is intended to be used by plugins that may need to display the actor who was responsible for something managed by that plugin: they can now resolve the recorded IDs of actors into the full actor objects. (#2181)
• DATASETTE_LOAD_PLUGINS environment variable for controlling which plugins are loaded by Datasette. (#2164)
• Datasette now checks if the user has permission to view a table linked to by a foreign key before turning that foreign key into a clickable link. (#2178)
• The execute-sql permission now implies that the actor can also view the database and instance. (#2169)
• Documentation describing a pattern for building plugins that themselves define further hooks for other plugins. (#1765)
• Datasette is now tested against the Python 3.12 preview. (#2175)

1.0a5

• When restrictions are applied to API tokens, those restrictions now behave slightly differently: applying the view-table restriction will imply the ability to view-database for the database containing that table, and both view-table and view-database will imply view-instance. Previously you needed to create a token with restrictions that explicitly listed view-instance and view-database and view-table in order to view a table without getting a permission denied error. (#2102)
• New datasette.yaml (or .json) configuration file, which can be specified using datasette -c path-to-file. The goal here to consolidate settings, plugin configuration, permissions, canned queries, and other Datasette configuration into a single single file, separate from metadata.yaml. The legacy settings.json config file used for Configuration directory mode has been removed, and datasette.yaml has a "settings" section where the same settings key/value pairs can be included. In the next future alpha release, more configuration such as plugins/permissions/canned queries will be moved to the datasette.yaml file. See #2093 for more details. Thanks, Alex Garcia.
• The -s/--setting option can now take dotted paths to nested settings. These will then be used to set or over-ride the same options as are present in the new configuration file. (#2156)
• New --actor '{"id": "json-goes-here"}' option for use with datasette --get to treat the simulated request as being made by a specific actor, see datasette --get. (#2153)
• The Datasette _internal database has had some changes. It no longer shows up in the datasette.databases list by default, and is now instead available to plugins using the datasette.get_internal_database(). Plugins are invited to use this as a private database to store configuration and settings and secrets that should not be made visible through the default Datasette interface. Users can pass the new --internal internal.db option to persist that internal database to disk. Thanks, Alex Garcia. (#2157).

1.0a4

This alpha fixes a security issue with the /-/api API explorer. On authenticated Datasette instances (instances protected using plugins such as datasette-auth-passwords) the API explorer interface could reveal the names of databases and tables within the protected instance. The data stored in those tables was not revealed.

For more information and workarounds, read the security advisory. The issue has been present in every previous alpha version of Datasette 1.0: versions 1.0a0, 1.0a1, 1.0a2 and 1.0a3.

Also in this alpha:

• The new datasette plugins --requirements option outputs a list of currently installed plugins in Python requirements.txt format, useful for duplicating that installation elsewhere. (#2133)
• Writable canned queries can now define a on_success_message_sql field in their configuration, containing a SQL query that should be executed upon successful completion of the write operation in order to generate a message to be shown to the user. (#2138)
• The automatically generated border color for a database is now shown in more places around the application. (#2119)
• Every instance of example shell script code in the documentation should now include a working copy button, free from additional syntax. (#2140)

1.0a3

This alpha release previews the updated design for Datasette's default JSON API. (#782)

The new default JSON representation for both table pages (/dbname/table.json) and arbitrary SQL queries (/dbname.json?sql=...) is now shaped like this:

{
  "ok": true,
  "rows": [
    {
      "id": 3,
      "name": "Detroit"
    },
    {
      "id": 2,
      "name": "Los Angeles"
    },
    {
      "id": 4,
      "name": "Memnonia"
    },
    {
      "id": 1,
      "name": "San Francisco"
    }
  ],
  "truncated": false
}

Tables will include an additional "next" key for pagination, which can be passed to ?_next= to fetch the next page of results.

The various ?_shape= options continue to work as before - see Different shapes for details.

A new ?_extra= mechanism is available for tables, but has not yet been stabilized or documented. Details on that are available in #262.

Smaller changes

• Datasette documentation now shows YAML examples for Metadata by default, with a tab interface for switching to JSON. (#1153)
• register_output_renderer(datasette) plugins now have access to error and truncated arguments, allowing them to display error messages and take into account truncated results. (#2130)
• render_cell() plugin hook now also supports an optional request argument. (#2007)
• New Justfile to support development workflows for Datasette using Just.
• datasette.render_template() can now accepts a datasette.views.Context subclass as an alternative to a dictionary. (#2127)
• datasette install -e path option for editable installations, useful while developing plugins. (#2106)
• When started with the --cors option Datasette now serves an Access-Control-Max-Age: 3600 header, ensuring CORS OPTIONS requests are repeated no more than once an hour. (#2079)
• Fixed a bug where the _internal database could display None instead of null for in-memory databases. (#1970)

0.64.3

• Added pip and setuptools as explicit dependencies. This fixes a bug where Datasette could not be installed using Rye. (#2065)

0.64.2

• Fixed a bug with datasette publish cloudrun where deploys all used the same Docker image tag. This was mostly inconsequential as the service is deployed as soon as the image has been pushed to the registry, but could result in the incorrect image being deployed if two different deploys for two separate services ran at exactly the same time. #2036

0.64.1

• Documentation now links to a current source of information for installing Python 3. (#1987)
• Incorrectly calling the Datasette constructor using Datasette("path/to/data.db") instead of Datasette(["path/to/data.db"]) now returns a useful error message. (#1985)

0.64

• Datasette now strongly recommends against allowing arbitrary SQL queries if you are using SpatiaLite. SpatiaLite includes SQL functions that could cause the Datasette server to crash. See SpatiaLite for more details.
• New default_allow_sql setting, providing an easier way to disable all arbitrary SQL execution by end users: datasette --setting default_allow_sql off. See also Controlling the ability to execute arbitrary SQL. (#1409)
• Building a location to time zone API with SpatiaLite is a new Datasette tutorial showing how to safely use SpatiaLite to create a location to time zone API.
• New documentation about how to debug problems loading SQLite extensions. The error message shown when an extension cannot be loaded has also been improved. (#1979)
• Fixed an accessibility issue: the <select> elements in the table filter form now show an outline when they are currently focused. (#1771)

0.63.3

• Fixed a bug where datasette --root, when running in Docker, would only output the URL to sign in as root when the server shut down, not when it started up. (#1958)
• You no longer need to ensure await datasette.invoke_startup() has been called in order for Datasette to start correctly serving requests - this is now handled automatically the first time the server receives a request. This fixes a bug experienced when Datasette is served directly by an ASGI application server such as Uvicorn or Gunicorn. It also fixes a bug with the datasette-gunicorn plugin. (#1955)

1.0a2

The third Datasette 1.0 alpha release adds upsert support to the JSON API, plus the ability to specify finely grained permissions when creating an API token.

See Datasette 1.0a2: Upserts and finely grained permissions for an extended, annotated version of these release notes.

• New /db/table/-/upsert API, documented here. upsert is an update-or-insert: existing rows will have specified keys updated, but if no row matches the incoming primary key a brand new row will be inserted instead. (#1878)
• New register_permissions(datasette) plugin hook. Plugins can now register named permissions, which will then be listed in various interfaces that show available permissions. (#1940)
• The /db/-/create API for creating a table now accepts "ignore": true and "replace": true options when called with the "rows" property that creates a new table based on an example set of rows. This means the API can be called multiple times with different rows, setting rules for what should happen if a primary key collides with an existing row. (#1927)
• Arbitrary permissions can now be configured at the instance, database and resource (table, SQL view or canned query) level in Datasette's Metadata JSON and YAML files. The new "permissions" key can be used to specify which actors should have which permissions. See Other permissions in metadata for details. (#1636)
• The /-/create-token page can now be used to create API tokens which are restricted to just a subset of actions, including against specific databases or resources. See API Tokens for details. (#1947)
• Likewise, the datasette create-token CLI command can now create tokens with a subset of permissions. (#1855)
• New datasette.create_token() API method <datasette_create_token>` for programmatically creating signed API tokens. (#1951)
• /db/-/create API now requires actor to have insert-row permission in order to use the "row" or "rows" properties. (#1937)