{"rowid": 361, "title": "0.54.1 (2021-02-02)", "content": "Fixed a bug where  ?_search=  and  ?_sort=  parameters were incorrectly duplicated when the filter form on the table page was re-submitted. ( #1214 )", "sections_fts": 249, "rank": null}
{"rowid": 360, "title": "0.55 (2021-02-18)", "content": "Support for cross-database SQL queries and built-in support for serving via HTTPS. \n             \n                 \n                     The new  --crossdb  command-line option causes Datasette to attach up to ten database files to the same  /_memory  database connection. This enables cross-database SQL queries, including the ability to use joins and unions to combine data from tables that exist in different database files. See  Cross-database queries  for details. ( #283 ) \n                 \n                 \n                     --ssl-keyfile  and  --ssl-certfile  options can be used to specify a TLS certificate, allowing Datasette to serve traffic over  https://  without needing to run it behind a separate proxy. ( #1221 ) \n                 \n                 \n                     The  /:memory:  page has been renamed (and redirected) to  /_memory  for consistency with the new  /_internal  database introduced in Datasette 0.54. ( #1205 ) \n                 \n                 \n                     Added plugin testing documentation on  Using pdb for errors thrown inside Datasette . ( #1207 ) \n                 \n                 \n                     The  official Datasette Docker image  now uses Python 3.7.10, applying  the latest security fix  for that Python version. ( #1235 )", "sections_fts": 249, "rank": null}
{"rowid": 359, "title": "0.56 (2021-03-28)", "content": "Documentation improvements, bug fixes and support for SpatiaLite 5. \n             \n                 \n                     The SQL editor can now be resized by dragging a handle. ( #1236 ) \n                 \n                 \n                     Fixed a bug with JSON faceting and the  __arraycontains  filter caused by tables with spaces in their names. ( #1239 ) \n                 \n                 \n                     Upgraded  httpx  dependency. ( #1005 ) \n                 \n                 \n                     JSON faceting is now suggested even if a column contains blank strings. ( #1246 ) \n                 \n                 \n                     New  datasette.add_memory_database()  method. ( #1247 ) \n                 \n                 \n                     The  Response.asgi_send()  method is now documented. ( #1266 ) \n                 \n                 \n                     The official Datasette Docker image now bundles SpatiaLite version 5. ( #1278 ) \n                 \n                 \n                     Fixed a  no such table: pragma_database_list  bug when running Datasette against SQLite versions prior to SQLite 3.16.0. ( #1276 ) \n                 \n                 \n                     HTML lists displayed in table cells are now styled correctly. Thanks, Bob Whitelock. ( #1141 ,  #1252 ) \n                 \n                 \n                     Configuration directory mode now correctly serves immutable databases that are listed in  inspect-data.json . Thanks Campbell Allen and Frankie Robertson. ( #1031 ,  #1229 )", "sections_fts": 249, "rank": null}
{"rowid": 358, "title": "0.56.1 (2021-06-05)", "content": "This release fixes a  reflected cross-site scripting  security hole with the  ?_trace=1  feature. You should upgrade to this version, or to Datasette 0.57, as soon as possible. ( #1360 )", "sections_fts": 249, "rank": null}
{"rowid": 355, "title": "0.57 (2021-06-05)", "content": "This release fixes a  reflected cross-site scripting  security hole with the  ?_trace=1  feature. You should upgrade to this version, or to Datasette 0.56.1, as soon as possible. ( #1360 ) \n             \n             In addition to the security fix, this release includes  ?_col=  and  ?_nocol=  options for controlling which columns are displayed for a table,  ?_facet_size=  for increasing the number of facet results returned, re-display of your SQL query should an error occur and numerous bug fixes.", "sections_fts": 249, "rank": null}
{"rowid": 354, "title": "0.57.1 (2021-06-08)", "content": "Fixed visual display glitch with global navigation menu. ( #1367 ) \n                 \n                 \n                     No longer truncates the list of table columns displayed on the  /database  page. ( #1364 )", "sections_fts": 249, "rank": null}
{"rowid": 353, "title": "0.58 (2021-07-14)", "content": "New  datasette --uds /tmp/datasette.sock  option for binding Datasette to a Unix domain socket, see  proxy documentation  ( #1388 ) \n                 \n                 \n                     \"searchmode\": \"raw\"  table metadata option for defaulting a table to executing SQLite full-text search syntax without first escaping it, see  Advanced SQLite search queries . ( #1389 ) \n                 \n                 \n                     New plugin hook:  get_metadata(datasette, key, database, table) , for returning custom metadata for an instance, database or table. Thanks, Brandon Roberts! ( #1384 ) \n                 \n                 \n                     New plugin hook:  skip_csrf(datasette, scope) , for opting out of CSRF protection based on the incoming request. ( #1377 ) \n                 \n                 \n                     The  menu_links() ,  table_actions()  and  database_actions()  plugin hooks all gained a new optional  request  argument providing access to the current request. ( #1371 ) \n                 \n                 \n                     Major performance improvement for Datasette faceting. ( #1394 ) \n                 \n                 \n                     Improved documentation for  Running Datasette behind a proxy  to recommend using  ProxyPreservehost On  with Apache. ( #1387 ) \n                 \n                 \n                     POST  requests to endpoints that do not support that HTTP verb now return a 405 error. \n                 \n                 \n                     db.path  can now be provided as a  pathlib.Path  object, useful when writing unit tests for plugins. Thanks, Chris Amico. ( #1365 )", "sections_fts": 249, "rank": null}
{"rowid": 352, "title": "0.58.1 (2021-07-16)", "content": "Fix for an intermittent race condition caused by the  refresh_schemas()  internal function. ( #1231 )", "sections_fts": 249, "rank": null}
{"rowid": 351, "title": "0.59 (2021-10-14)", "content": "Columns can now have associated metadata descriptions in  metadata.json , see  Column descriptions . ( #942 ) \n                 \n                 \n                     New  register_commands()  plugin hook allows plugins to register additional Datasette CLI commands, e.g.  datasette mycommand file.db . ( #1449 ) \n                 \n                 \n                     Adding  ?_facet_size=max  to a table page now shows the number of unique values in each facet. ( #1423 ) \n                 \n                 \n                     Upgraded dependency  httpx 0.20  - the undocumented  allow_redirects=  parameter to  datasette.client  is now  follow_redirects= , and defaults to  False  where it previously defaulted to  True . ( #1488 ) \n                 \n                 \n                     The  --cors  option now causes Datasette to return the  Access-Control-Allow-Headers: Authorization  header, in addition to  Access-Control-Allow-Origin: * . ( #1467 ) \n                 \n                 \n                     Code that figures out which named parameters a SQL query takes in order to display form fields for them is no longer confused by strings that contain colon characters. ( #1421 ) \n                 \n                 \n                     Renamed  --help-config  option to  --help-settings . ( #1431 ) \n                 \n                 \n                     datasette.databases  property is now a documented API. ( #1443 ) \n                 \n                 \n                     The  base.html  template now wraps everything other than the  <footer>  in a  <div class=\"not-footer\">  element, to help with advanced CSS customization. ( #1446 ) \n                 \n                 \n                     The  render_cell()  plugin hook can now return an awaitable function. This means the hook can execute SQL queries. ( #1425 ) \n                 \n                 \n                     register_routes(datasette)  plugin hook now accepts an optional  datasette  argument. ( #1404 ) \n                 \n                 \n                     New  hide_sql  canned query option for defaulting to hiding the SQL query used by a canned query, see  Additional canned query options . ( #1422 ) \n                 \n                 \n                     New  --cpu  option for  datasette publish cloudrun . ( #1420 ) \n                 \n                 \n                     If  Rich  is installed in the same virtual environment as Datasette, it will be used to provide enhanced display of error tracebacks on the console. ( #1416 ) \n                 \n                 \n                     datasette.utils   parse_metadata(content)  function, used by the new  datasette-remote-metadata plugin , is now a documented API. ( #1405 ) \n                 \n                 \n                     Fixed bug where  ?_next=x&_sort=rowid  could throw an error. ( #1470 ) \n                 \n                 \n                     Column cog menu no longer shows the option to facet by a column that is already selected by the default facets in metadata. ( #1469 )", "sections_fts": 249, "rank": null}
{"rowid": 350, "title": "0.59.1 (2021-10-24)", "content": "Fix compatibility with Python 3.10. ( #1482 ) \n                 \n                 \n                     Documentation on how to use  Named parameters  with integer and floating point values. ( #1496 )", "sections_fts": 249, "rank": null}
{"rowid": 349, "title": "0.59.2 (2021-11-13)", "content": "Column names with a leading underscore now work correctly when used as a facet. ( #1506 ) \n                 \n                 \n                     Applying  ?_nocol=  to a column no longer removes that column from the filtering interface. ( #1503 ) \n                 \n                 \n                     Official Datasette Docker container now uses Debian Bullseye as the base image. ( #1497 ) \n                 \n                 \n                     Datasette is four years old today! Here's the  original release announcement  from 2017.", "sections_fts": 249, "rank": null}
{"rowid": 348, "title": "0.59.3 (2021-11-20)", "content": "Fixed numerous bugs when running Datasette  behind a proxy  with a prefix URL path using the  base_url  setting. A live demo of this mode is now available at  datasette-apache-proxy-demo.datasette.io/prefix/ . ( #1519 ,  #838 ) \n                 \n                 \n                     ?column__arraycontains=  and  ?column__arraynotcontains=  table parameters now also work against SQL views. ( #448 ) \n                 \n                 \n                     ?_facet_array=column  no longer returns incorrect counts if columns contain the same value more than once.", "sections_fts": 249, "rank": null}
{"rowid": 347, "title": "0.59.4 (2021-11-29)", "content": "Fixed bug where columns with a leading underscore could not be removed from the interactive filters list. ( #1527 ) \n                 \n                 \n                     Fixed bug where columns with a leading underscore were not correctly linked to by the \"Links from other tables\" interface on the row page. ( #1525 ) \n                 \n                 \n                     Upgraded dependencies  aiofiles ,  black  and  janus .", "sections_fts": 249, "rank": null}
{"rowid": 343, "title": "0.60 (2022-01-13)", "content": "", "sections_fts": 249, "rank": null}
{"rowid": 342, "title": "0.60.1 (2022-01-20)", "content": "Fixed a bug where installation on Python 3.6 stopped working due to a change to an underlying dependency. This release can now be installed on Python 3.6, but is the last release of Datasette that will support anything less than Python 3.7. ( #1609 )", "sections_fts": 249, "rank": null}
{"rowid": 341, "title": "0.60.2 (2022-02-07)", "content": "Fixed a bug where Datasette would open the same file twice with two different database names if you ran  datasette file.db file.db . ( #1632 )", "sections_fts": 249, "rank": null}
{"rowid": 340, "title": "0.61 (2022-03-23)", "content": "In preparation for Datasette 1.0, this release includes two potentially backwards-incompatible changes. Hashed URL mode has been moved to a separate plugin, and the way Datasette generates URLs to databases and tables with special characters in their name such as  /  and  .  has changed. \n             Datasette also now requires Python 3.7 or higher. \n             \n                 \n                     URLs within Datasette now use a different encoding scheme for tables or databases that include \"special\" characters outside of the range of  a-zA-Z0-9_- . This scheme is explained here:  Tilde encoding . ( #1657 ) \n                 \n                 \n                     Removed hashed URL mode from Datasette. The new  datasette-hashed-urls  plugin can be used to achieve the same result, see  datasette-hashed-urls  for details. ( #1661 ) \n                 \n                 \n                     Databases can now have a custom path within the Datasette instance that is independent of the database name, using the  db.route  property. ( #1668 ) \n                 \n                 \n                     Datasette is now covered by a  Code of Conduct . ( #1654 ) \n                 \n                 \n                     Python 3.6 is no longer supported. ( #1577 ) \n                 \n                 \n                     Tests now run against Python 3.11-dev. ( #1621 ) \n                 \n                 \n                     New  datasette.ensure_permissions(actor, permissions)  internal method for checking multiple permissions at once. ( #1675 ) \n                 \n                 \n                     New  datasette.check_visibility(actor, action, resource=None)  internal method for checking if a user can see a resource that would otherwise be invisible to unauthenticated users. ( #1678 ) \n                 \n                 \n                     Table and row HTML pages now include a  <link rel=\"alternate\" type=\"application/json+datasette\" href=\"...\">  element and return a  Link: URL; rel=\"alternate\"; type=\"application/json+datasette\"  HTTP header pointing to the JSON version of those pages. ( #1533 ) \n                 \n                 \n                     Access-Control-Expose-Headers: Link  is now added to the CORS headers, allowing remote JavaScript to access that header. \n                 \n                 \n                     Canned queries are now shown at the top of the database page, directly below the SQL editor. Previously they were shown at the bottom, below the list of tables. ( #1612 ) \n                 \n                 \n                     Datasette now has a default favicon. ( #1603 ) \n                 \n                 \n                     sqlite_stat  tables are now hidden by default. ( #1587 ) \n                 \n                 \n                     SpatiaLite tables  data_licenses ,  KNN  and  KNN2  are now hidden by default. ( #1601 ) \n                 \n                 \n                     SQL query tracing mechanism now works for queries executed in  asyncio  sub-tasks, such as those created by  asyncio.gather() . ( #1576 ) \n                 \n                 \n                     datasette.tracer  mechanism is now documented. \n                 \n                 \n                     Common Datasette symbols can now be imported directly from the top-level  datasette  package, see  Import shortcuts . Those symbols are  Response ,  Forbidden ,  NotFound ,  hookimpl ,  actor_matches_allow . ( #957 ) \n                 \n                 \n                     /-/versions  page now returns additional details for libraries used by SpatiaLite. ( #1607 ) \n                 \n                 \n                     Documentation now links to the  Datasette Tutorials . \n                 \n                 \n                     Datasette will now also look for SpatiaLite in  /opt/homebrew  - thanks, Dan Peterson. ( #1649 ) \n                 \n                 \n                     Fixed bug where  custom pages  did not work on Windows. Thanks, Robert Christie. ( #1545 ) \n                 \n                 \n                     Fixed error caused when a table had a column named  n . ( #1228 )", "sections_fts": 249, "rank": null}
{"rowid": 339, "title": "0.61.1 (2022-03-23)", "content": "Fixed a bug where databases with a different route from their name (as used by the  datasette-hashed-urls plugin ) returned errors when executing custom SQL queries. ( #1682 )", "sections_fts": 249, "rank": null}
{"rowid": 334, "title": "0.62 (2022-08-14)", "content": "Datasette can now run entirely in your browser using WebAssembly. Try out  Datasette Lite , take a look  at the code  or read more about it in  Datasette Lite: a server-side Python web application running in a browser . \n             Datasette now has a  Discord community  for questions and discussions about Datasette and its ecosystem of projects.", "sections_fts": 249, "rank": null}
{"rowid": 330, "title": "0.63 (2022-10-27)", "content": "See  Datasette 0.63: The annotated release notes  for more background on the changes in this release.", "sections_fts": 249, "rank": null}
{"rowid": 329, "title": "0.63.1 (2022-11-10)", "content": "Fixed a bug where Datasette's table filter form would not redirect correctly when run behind a proxy using the  base_url  setting. ( #1883 ) \n                 \n                 \n                     SQL query is now shown wrapped in a  <textarea>  if a query exceeds a time limit. ( #1876 ) \n                 \n                 \n                     Fixed an intermittent \"Too many open files\" error while running the test suite. ( #1843 ) \n                 \n                 \n                     New  db.close()  internal method.", "sections_fts": 249, "rank": null}
{"rowid": 328, "title": "0.63.2 (2022-11-18)", "content": "Fixed a bug in  datasette publish heroku  where deployments failed due to an older version of Python being requested. ( #1905 ) \n                 \n                 \n                     New  datasette publish heroku --generate-dir <dir>  option for generating a Heroku deployment directory without deploying it.", "sections_fts": 249, "rank": null}
{"rowid": 322, "title": "0.63.3 (2022-12-17)", "content": "Fixed a bug where  datasette --root , when running in Docker, would only output the URL to sign in root when the server shut down, not when it started up. ( #1958 ) \n                 \n                 \n                     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 )", "sections_fts": 249, "rank": null}
{"rowid": 321, "title": "0.64 (2023-01-09)", "content": "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. \n                 \n                 \n                     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 ) \n                 \n                 \n                     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. \n                 \n                 \n                     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 ) \n                 \n                 \n                     Fixed an accessibility issue: the  <select>  elements in the table filter form now show an outline when they are currently focused. ( #1771 )", "sections_fts": 249, "rank": null}
{"rowid": 320, "title": "0.64.1 (2023-01-11)", "content": "Documentation now links to a current source of information for installing Python 3. ( #1987 ) \n                 \n                 \n                     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 )", "sections_fts": 249, "rank": null}
{"rowid": 319, "title": "0.64.2 (2023-03-08)", "content": "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 )", "sections_fts": 249, "rank": null}
{"rowid": 313, "title": "0.64.4 (2023-09-21)", "content": "Fix for a crashing bug caused by viewing the table page for a named in-memory database. ( #2189 )", "sections_fts": 249, "rank": null}
{"rowid": 311, "title": "0.64.5 (2023-10-08)", "content": "Dropped dependency on  click-default-group-wheel , which could cause a dependency conflict. ( #2197 )", "sections_fts": 249, "rank": null}
{"rowid": 310, "title": "0.64.6 (2023-12-22)", "content": "Fixed a bug where CSV export with expanded labels could fail if a foreign key reference did not correctly resolve. ( #2214 )", "sections_fts": 249, "rank": null}
{"rowid": 482, "title": "0.8 (2017-11-13)", "content": "V0.8 - added PyPI metadata, ready to ship. \n                 \n                 \n                     Implemented offset/limit pagination for views ( #70 ). \n                 \n                 \n                     Improved pagination. ( #78 ) \n                 \n                 \n                     Limit on max rows returned, controlled by  --max_returned_rows  option. ( #69 ) \n                     If someone executes 'select * from table' against a table with a million rows\n                        in it, we could run into problems: just serializing that much data as JSON is\n                        likely to lock up the server. \n                     Solution: we now have a hard limit on the maximum number of rows that can be\n                        returned by a query. If that limit is exceeded, the server will return a\n                         \"truncated\": true  field in the JSON. \n                     This limit can be optionally controlled by the new  --max_returned_rows \n                        option. Setting that option to 0 disables the limit entirely.", "sections_fts": 249, "rank": null}
{"rowid": 481, "title": "0.9 (2017-11-13)", "content": "Added  --sql_time_limit_ms  and  --extra-options . \n                     The serve command now accepts  --sql_time_limit_ms  for customizing the SQL time\n                        limit. \n                     The publish and package commands now accept  --extra-options  which can be used\n                        to specify additional options to be passed to the datasite serve command when\n                        it executes inside the resulting Docker containers.", "sections_fts": 249, "rank": null}
{"rowid": 325, "title": "1.0a0 (2022-11-29)", "content": "This first alpha release of Datasette 1.0 introduces a brand new collection of APIs for writing to the database ( #1850 ), as well as a new API token mechanism baked into Datasette core. Previously, API tokens have only been supported by installing additional plugins. \n             This is very much a preview: expect many more backwards incompatible API changes prior to the full 1.0 release. \n             Feedback enthusiastically welcomed, either through  issue comments  or via the  Datasette Discord  community.", "sections_fts": 249, "rank": null}
{"rowid": 324, "title": "1.0a1 (2022-12-01)", "content": "Write APIs now serve correct CORS headers if Datasette is started in  --cors  mode. See the full list of  CORS headers  in the documentation. ( #1922 ) \n                 \n                 \n                     Fixed a bug where the  _memory  database could be written to even though writes were not persisted. ( #1917 ) \n                 \n                 \n                     The  https://latest.datasette.io/  demo instance now includes an  ephemeral  database which can be used to test Datasette's write APIs, using the new  datasette-ephemeral-tables  plugin to drop any created tables after five minutes. This database is only available if you sign in as the root user using the link on the homepage. ( #1915 ) \n                 \n                 \n                     Fixed a bug where hitting the write endpoints with a  GET  request returned a 500 error. It now returns a 405 (method not allowed) error instead. ( #1916 ) \n                 \n                 \n                     The list of endpoints in the API explorer now lists mutable databases first. ( #1918 ) \n                 \n                 \n                     The  \"ignore\": true  and  \"replace\": true  options for the insert API are  now documented . ( #1924 )", "sections_fts": 249, "rank": null}
{"rowid": 298, "title": "1.0a10 (2024-02-17)", "content": "The only changes in this alpha correspond to the way Datasette handles database transactions. ( #2277 ) \n             \n                 \n                     The  database.execute_write_fn()  method has a new  transaction=True  parameter. This defaults to  True  which means all functions executed using this method are now automatically wrapped in a transaction - previously the functions needed to roll transaction handling on their own, and many did not. \n                 \n                 \n                     Pass  transaction=False  to  execute_write_fn()  if you want to manually handle transactions in your function. \n                 \n                 \n                     Several internal Datasette features, including parts of the  JSON write API , had been failing to wrap their operations in a transaction. This has been fixed by the new  transaction=True  default.", "sections_fts": 249, "rank": null}
{"rowid": 297, "title": "1.0a11 (2024-02-19)", "content": "The  \"replace\": true  argument to the  /db/table/-/insert  API now requires the actor to have the  update-row  permission. ( #2279 ) \n                 \n                 \n                     Fixed some UI bugs in the interactive permissions debugging tool. ( #2278 ) \n                 \n                 \n                     The column action menu now aligns better with the cog icon, and positions itself taking into account the width of the browser window. ( #2263 )", "sections_fts": 249, "rank": null}
{"rowid": 296, "title": "1.0a12 (2024-02-29)", "content": "New  query_actions()  plugin hook, similar to  table_actions()  and  database_actions() . Can be used to add a menu of actions to the canned query or arbitrary SQL query page. ( #2283 ) \n                 \n                 \n                     New design for the button that opens the query, table and database actions menu. ( #2281 ) \n                 \n                 \n                     \"does not contain\" table filter for finding rows that do not contain a string. ( #2287 ) \n                 \n                 \n                     Fixed a bug in the  makeColumnActions(columnDetails)  JavaScript plugin mechanism where the column action menu was not fully reset in between each interaction. ( #2289 )", "sections_fts": 249, "rank": null}
{"rowid": 295, "title": "1.0a13 (2024-03-12)", "content": "Each of the key concepts in Datasette now has an  actions menu , which plugins can use to add additional functionality targeting that entity. \n             \n                 \n                     Plugin hook:  view_actions()  for actions that can be applied to a SQL view. ( #2297 ) \n                 \n                 \n                     Plugin hook:  homepage_actions()  for actions that apply to the instance homepage. ( #2298 ) \n                 \n                 \n                     Plugin hook:  row_actions()  for actions that apply to the row page. ( #2299 ) \n                 \n                 \n                     Action menu items for all of the  *_actions()  plugin hooks can now return an optional  \"description\"  key, which will be displayed in the menu below the action label. ( #2294 ) \n                 \n                 \n                     Plugin hooks  documentation page is now organized with additional headings. ( #2300 ) \n                 \n                 \n                     Improved the display of action buttons on pages that also display metadata. ( #2286 ) \n                 \n                 \n                     The header and footer of the page now uses a subtle gradient effect, and options in the navigation menu are better visually defined. ( #2302 ) \n                 \n                 \n                     Table names that start with an underscore now default to hidden. ( #2104 ) \n                 \n                 \n                     pragma_table_list  has been added to the allow-list of SQLite pragma functions supported by Datasette.  select * from pragma_table_list()  is no longer blocked. ( #2104 )", "sections_fts": 249, "rank": null}
{"rowid": 323, "title": "1.0a2 (2022-12-14)", "content": "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. \n             See  Datasette 1.0a2: Upserts and finely grained permissions  for an extended, annotated version of these release notes. \n             \n                 \n                     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 ) \n                 \n                 \n                     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 ) \n                 \n                 \n                     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 ) \n                 \n                 \n                     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 datasette.yaml  for details. ( #1636 ) \n                 \n                 \n                     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 ) \n                 \n                 \n                     Likewise, the  datasette create-token  CLI command can now create tokens with  a subset of permissions . ( #1855 ) \n                 \n                 \n                     New  datasette.create_token() API method  for programmatically creating signed API tokens. ( #1951 ) \n                 \n                 \n                     /db/-/create  API now requires actor to have  insert-row  permission in order to use the  \"row\"  or  \"rows\"  properties. ( #1937 )", "sections_fts": 249, "rank": null}
{"rowid": 317, "title": "1.0a3 (2023-08-09)", "content": "This alpha release previews the updated design for Datasette's default JSON API. ( #782 ) \n             The new  default JSON representation  for both table pages ( /dbname/table.json ) and arbitrary SQL queries ( /dbname.json?sql=... ) is now shaped like this: \n             {\n  \"ok\": true,\n  \"rows\": [\n    {\n      \"id\": 3,\n      \"name\": \"Detroit\"\n    },\n    {\n      \"id\": 2,\n      \"name\": \"Los Angeles\"\n    },\n    {\n      \"id\": 4,\n      \"name\": \"Memnonia\"\n    },\n    {\n      \"id\": 1,\n      \"name\": \"San Francisco\"\n    }\n  ],\n  \"truncated\": false\n} \n             Tables will include an additional  \"next\"  key for pagination, which can be passed to  ?_next=  to fetch the next page of results. \n             The various  ?_shape=  options continue to work as before - see  Different shapes  for details. \n             A new  ?_extra=  mechanism is available for tables, but has not yet been stabilized or documented. Details on that are available in  #262 .", "sections_fts": 249, "rank": null}
{"rowid": 316, "title": "1.0a4 (2023-08-21)", "content": "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. \n             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. \n             Also in this alpha: \n             \n                 \n                     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 ) \n                 \n                 \n                     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 ) \n                 \n                 \n                     The automatically generated border color for a database is now shown in more places around the application. ( #2119 ) \n                 \n                 \n                     Every instance of example shell script code in the documentation should now include a working copy button, free from additional syntax. ( #2140 )", "sections_fts": 249, "rank": null}
{"rowid": 315, "title": "1.0a5 (2023-08-29)", "content": "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 ) \n                 \n                 \n                     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. \n                 \n                 \n                     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 ) \n                 \n                 \n                     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 ) \n                 \n                 \n                     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 ).", "sections_fts": 249, "rank": null}
{"rowid": 314, "title": "1.0a6 (2023-09-07)", "content": "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 ) \n                 \n                 \n                     DATASETTE_LOAD_PLUGINS  environment variable for  controlling which plugins  are loaded by Datasette. ( #2164 ) \n                 \n                 \n                     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 ) \n                 \n                 \n                     The  execute-sql  permission now implies that the actor can also view the database and instance. ( #2169 ) \n                 \n                 \n                     Documentation describing a pattern for building plugins that themselves  define further hooks  for other plugins. ( #1765 ) \n                 \n                 \n                     Datasette is now tested against the Python 3.12 preview. ( #2175 )", "sections_fts": 249, "rank": null}
{"rowid": 312, "title": "1.0a7 (2023-09-21)", "content": "Fix for a crashing bug caused by viewing the table page for a named in-memory database. ( #2189 )", "sections_fts": 249, "rank": null}
{"rowid": 304, "title": "1.0a8 (2024-02-07)", "content": "This alpha release continues the migration of Datasette's configuration from  metadata.yaml  to the new  datasette.yaml  configuration file, introduces a new system for JavaScript plugins and adds several new plugin hooks. \n             See  Datasette 1.0a8: JavaScript plugins, new plugin hooks and plugin configuration in datasette.yaml  for an annotated version of these release notes.", "sections_fts": 249, "rank": null}
{"rowid": 299, "title": "1.0a9 (2024-02-16)", "content": "This alpha release adds basic alter table support to the Datasette Write API and fixes a permissions bug relating to the  /upsert  API endpoint.", "sections_fts": 249, "rank": null}
{"rowid": 440, "title": "?_through= for joins through many-to-many tables", "content": "The new  ?_through={json}  argument to the Table view allows records to be filtered based on a many-to-many relationship. See  Special table arguments  for full documentation - here's  an example . ( #355 ) \n                 This feature was added to help support  facet by many-to-many , which isn't quite ready yet but will be coming in the next Datasette release.", "sections_fts": 249, "rank": null}
{"rowid": 39, "title": "A note about extensions", "content": "SQLite supports extensions, such as  SpatiaLite  for geospatial operations. \n             These can be loaded using the  --load-extension  argument, like so: \n             datasette --load-extension=/usr/local/lib/mod_spatialite.dylib \n             Some Python installations do not include support for SQLite extensions. If this is the case you will see the following error when you attempt to load an extension: \n             \n                 Your Python installation does not have the ability to load SQLite extensions. \n             \n             In some cases you may see the following error message instead: \n             AttributeError: 'sqlite3.Connection' object has no attribute 'enable_load_extension' \n             On macOS the easiest fix for this is to install Datasette using Homebrew: \n             brew install datasette \n             Use  which datasette  to confirm that  datasette  will run that version. The output should look something like this: \n             /usr/local/opt/datasette/bin/datasette \n             If you get a different location here such as  /Library/Frameworks/Python.framework/Versions/3.10/bin/datasette  you can run the following command to cause  datasette  to execute the Homebrew version instead: \n             alias datasette=$(echo $(brew --prefix datasette)/bin/datasette) \n             You can undo this operation using: \n             unalias datasette \n             If you need to run SQLite with extension support for other Python code, you can do so by install Python itself using Homebrew: \n             brew install python \n             Then executing Python using: \n             /usr/local/opt/python@3/libexec/bin/python \n             A more convenient way to work with this version of Python may be to use it to create a virtual environment: \n             /usr/local/opt/python@3/libexec/bin/python -m venv datasette-venv \n             Then activate it like this: \n             source datasette-venv/bin/activate \n             Now running  python  and  pip  will work against a version of Python 3 that includes support for SQLite extensions: \n             pip install datasette\nwhich datasette\ndatasette --version", "sections_fts": 249, "rank": null}
{"rowid": 532, "title": "API Tokens", "content": "Datasette includes a default mechanism for generating API tokens that can be used to authenticate requests. \n             Authenticated users can create new API tokens using a form on the  /-/create-token  page. \n             Tokens created in this way can be further restricted to only allow access to specific actions, or to limit those actions to specific databases, tables or queries. \n             Created tokens can then be passed in the  Authorization: Bearer $token  header of HTTP requests to Datasette. \n             A token created by a user will include that user's  \"id\"  in the token payload, so any permissions granted to that user based on their ID can be made available to the token as well. \n             When one of these a token accompanies a request, the actor for that request will have the following shape: \n             {\n    \"id\": \"user_id\",\n    \"token\": \"dstok\",\n    \"token_expires\": 1667717426\n} \n             The  \"id\"  field duplicates the ID of the actor who first created the token. \n             The  \"token\"  field identifies that this actor was authenticated using a Datasette signed token ( dstok ). \n             The  \"token_expires\"  field, if present, indicates that the token will expire after that integer timestamp. \n             The  /-/create-token  page cannot be accessed by actors that are authenticated with a  \"token\": \"some-value\"  property. This is to prevent API tokens from being used to create more tokens. \n             Datasette plugins that implement their own form of API token authentication should follow this convention. \n             You can disable the signed token feature entirely using the  allow_signed_tokens  setting.", "sections_fts": 249, "rank": null}
{"rowid": 434, "title": "ASGI", "content": "ASGI  is the Asynchronous Server Gateway Interface standard. I've been wanting to convert Datasette into an ASGI application for over a year -  Port Datasette to ASGI #272  tracks thirteen months of intermittent development - but with Datasette 0.29 the change is finally released. This also means Datasette now runs on top of  Uvicorn  and no longer depends on  Sanic . \n                 I wrote about the significance of this change in  Porting Datasette to ASGI, and Turtles all the way down . \n                 The most exciting consequence of this change is that Datasette plugins can now take advantage of the ASGI standard.", "sections_fts": 249, "rank": null}
{"rowid": 525, "title": "Access permissions in ", "content": "There are two ways to configure permissions using  datasette.yaml  (or  datasette.json ). \n             For simple visibility permissions you can use  \"allow\"  blocks in the root, database, table and query sections. \n             For other permissions you can use a  \"permissions\"  block, described  in the next section . \n             You can limit who is allowed to view different parts of your Datasette instance using  \"allow\"  keys in your  Configuration . \n             You can control the following: \n             \n                 \n                     Access to the entire Datasette instance \n                 \n                 \n                     Access to specific databases \n                 \n                 \n                     Access to specific tables and views \n                 \n                 \n                     Access to specific  Canned queries \n                 \n             \n             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.", "sections_fts": 249, "rank": null}
{"rowid": 526, "title": "Access to an instance", "content": "Here's how to restrict access to your entire Datasette instance to just the  \"id\": \"root\"  user: \n                 [[[cog\nfrom metadata_doc import config_example\nconfig_example(cog, \"\"\"\n    title: My private Datasette instance\n    allow:\n      id: root\n  \"\"\") \n                 ]]] \n                 [[[end]]] \n                 To deny access to all users, you can use  \"allow\": false : \n                 [[[cog\nconfig_example(cog, \"\"\"\n    title: My entirely inaccessible instance\n    allow: false\n\"\"\") \n                 ]]] \n                 [[[end]]] \n                 One reason to do this is if you are using a Datasette plugin - such as  datasette-permissions-sql  - to control permissions instead.", "sections_fts": 249, "rank": null}
{"rowid": 529, "title": "Access to specific canned queries", "content": "Canned queries  allow you to configure named SQL queries in your  datasette.yaml  that can be executed by users. These queries can be set up to both read and write to the database, so controlling who can execute them can be important. \n                 To limit access to the  add_name  canned query in your  dogs.db  database to just the  root user : \n                 [[[cog\nconfig_example(cog, \"\"\"\n    databases:\n      dogs:\n        queries:\n          add_name:\n            sql: INSERT INTO names (name) VALUES (:name)\n            write: true\n            allow:\n              id:\n              - root\n\"\"\") \n                 ]]] \n                 [[[end]]]", "sections_fts": 249, "rank": null}
{"rowid": 527, "title": "Access to specific databases", "content": "To limit access to a specific  private.db  database to just authenticated users, use the  \"allow\"  block like this: \n                 [[[cog\nconfig_example(cog, \"\"\"\n    databases:\n      private:\n        allow:\n          id: \"*\"\n\"\"\") \n                 ]]] \n                 [[[end]]]", "sections_fts": 249, "rank": null}
{"rowid": 528, "title": "Access to specific tables and views", "content": "To limit access to the  users  table in your  bakery.db  database: \n                 [[[cog\nconfig_example(cog, \"\"\"\n    databases:\n      bakery:\n        tables:\n          users:\n            allow:\n              id: '*'\n\"\"\") \n                 ]]] \n                 [[[end]]] \n                 This works for SQL views as well - you can list their names in the  \"tables\"  block above in the same way as regular tables. \n                 \n                     Restricting access to tables and views in this way will NOT prevent users from querying them using arbitrary SQL queries,  like this  for example. \n                     If you are restricting access to specific tables you should also use the  \"allow_sql\"  block to prevent users from bypassing the limit with their own SQL queries - see  Controlling the ability to execute arbitrary SQL .", "sections_fts": 249, "rank": null}
{"rowid": 107, "title": "Action hooks", "content": "Action hooks can be used to add items to the action menus that appear at the top of different pages within Datasette. Unlike  menu_links() , actions which are displayed on every page, actions should only be relevant to the page the user is currently viewing. \n             Each of these hooks should return return a list of  {\"href\": \"...\", \"label\": \"...\"}  menu items, with optional  \"description\": \"...\"  keys describing each action in more detail. \n             They can alternatively return an  async def  awaitable function which, when called, returns a list of those menu items.", "sections_fts": 249, "rank": null}
{"rowid": 519, "title": "Actors", "content": "Through plugins, Datasette can support both authenticated users (with cookies) and authenticated API agents (via authentication tokens). The word \"actor\" is used to cover both of these cases. \n             Every request to Datasette has an associated actor value, available in the code as  request.actor . This can be  None  for unauthenticated requests, or a JSON compatible Python dictionary for authenticated users or API agents. \n             The actor dictionary can be any shape - the design of that data structure is left up to the plugins. A useful convention is to include an  \"id\"  string, as demonstrated by the \"root\" actor below. \n             Plugins can use the  actor_from_request(datasette, request)  hook to implement custom logic for authenticating an actor based on the incoming HTTP request.", "sections_fts": 249, "rank": null}
{"rowid": 56, "title": "Additional canned query options", "content": "Additional options can be specified for canned queries in the YAML or JSON configuration.", "sections_fts": 249, "rank": null}
{"rowid": 6, "title": "Advanced SQLite search queries", "content": "SQLite full-text search includes support for  a variety of advanced queries , including  AND ,  OR ,  NOT  and  NEAR . \n             By default Datasette disables these features to ensure they do not cause errors or confusion for users who are not aware of them. You can disable this escaping and use the advanced queries by adding  &_searchmode=raw  to the table page query string. \n             If you want to enable these operators by default for a specific table, you can do so by adding  \"searchmode\": \"raw\"  to the metadata configuration for that table, see  Configuring full-text search for a table or view . \n             If that option has been specified in the table metadata but you want to over-ride it and return to the default behavior you can append  &_searchmode=escaped  to the query string.", "sections_fts": 249, "rank": null}
{"rowid": 32, "title": "Advanced installation options", "content": "", "sections_fts": 249, "rank": null}
{"rowid": 141, "title": "Alpha and beta releases", "content": "Alpha and beta releases are published to preview upcoming features that may not yet be stable - in particular to preview new plugin hooks. \n             You are welcome to try these out, but please be aware that details may change before the final release. \n             Please join  discussions on the issue tracker  to share your thoughts and experiences with on alpha and beta features that you try out.", "sections_fts": 249, "rank": null}
{"rowid": 300, "title": "Alter table support for create, insert, upsert and update", "content": "The  JSON write API  can now be used to apply simple alter table schema changes, provided the acting actor has the new  alter-table  permission. ( #2101 ) \n                 The only alter operation supported so far is adding new columns to an existing table. \n                 \n                     \n                         The  /db/-/create  API now adds new columns during large operations to create a table based on incoming example  \"rows\" , in the case where one of the later rows includes columns that were not present in the earlier batches. This requires the  create-table  but not the  alter-table  permission. \n                     \n                     \n                         When  /db/-/create  is called with rows in a situation where the table may have been already created, an  \"alter\": true  key can be included to indicate that any missing columns from the new rows should be added to the table. This requires the  alter-table  permission. \n                     \n                     \n                         /db/table/-/insert  and  /db/table/-/upsert  and  /db/table/row-pks/-/update  all now also accept  \"alter\": true , depending on the  alter-table  permission. \n                     \n                 \n                 Operations that alter a table now fire the new  alter-table event .", "sections_fts": 249, "rank": null}
{"rowid": 178, "title": "Apache proxy configuration", "content": "For  Apache , you can use the  ProxyPass  directive. First make sure the following lines are uncommented: \n                 LoadModule proxy_module lib/httpd/modules/mod_proxy.so\nLoadModule proxy_http_module lib/httpd/modules/mod_proxy_http.so \n                 Then add these directives to proxy traffic: \n                 ProxyPass /my-datasette/ http://127.0.0.1:8009/my-datasette/\nProxyPreserveHost On \n                 A live demo of Datasette running behind Apache using this proxy setup can be seen at  datasette-apache-proxy-demo.datasette.io/prefix/ . The code for that demo can be found in the  demos/apache-proxy  directory. \n                 Using  --uds  you can use Unix domain sockets similar to the nginx example: \n                 ProxyPass /my-datasette/ unix:/tmp/datasette.sock|http://localhost/my-datasette/ \n                 The  ProxyPreserveHost On  directive ensures that the original  Host:  header from the incoming request is passed through to Datasette. Datasette needs this to correctly assemble links to other pages using the  .absolute_url(request, path)  method.", "sections_fts": 249, "rank": null}
{"rowid": 401, "title": "Authentication", "content": "Prior to this release the Datasette ecosystem has treated authentication as exclusively the realm of plugins, most notably through  datasette-auth-github . \n                 0.44 introduces  Authentication and permissions  as core Datasette concepts ( #699 ). This enables different plugins to share responsibility for authenticating requests - you might have one plugin that handles user accounts and another one that allows automated access via API keys, for example. \n                 You'll need to install plugins if you want full user accounts, but default Datasette can now authenticate a single root user with the new  --root  command-line option, which outputs a one-time use URL to  authenticate as a root actor  ( #784 ): \n                 datasette fixtures.db --root \n                 http://127.0.0.1:8001/-/auth-token?token=5b632f8cd44b868df625f5a6e2185d88eea5b22237fd3cc8773f107cc4fd6477\nINFO:     Started server process [14973]\nINFO:     Waiting for application startup.\nINFO:     Application startup complete.\nINFO:     Uvicorn running on http://127.0.0.1:8001 (Press CTRL+C to quit) \n                 Plugins can implement new ways of authenticating users using the new  actor_from_request(datasette, request)  hook.", "sections_fts": 249, "rank": null}
{"rowid": 518, "title": "Authentication and permissions", "content": "Datasette doesn't require authentication by default. Any visitor to a Datasette instance can explore the full data and execute read-only SQL queries. \n         Datasette's plugin system can be used to add many different styles of authentication, such as user accounts, single sign-on or API keys.", "sections_fts": 249, "rank": null}
{"rowid": 28, "title": "Basic installation", "content": "", "sections_fts": 249, "rank": null}
{"rowid": 397, "title": "Better plugin documentation", "content": "The plugin documentation has been re-arranged into four sections, including a brand new section on testing plugins. ( #687 ) \n                 \n                     \n                         Plugins  introduces Datasette's plugin system and describes how to install and configure plugins. \n                     \n                     \n                         Writing plugins  describes how to author plugins, from  one-off single file plugins to packaged plugins that can be published to PyPI. It also describes how to start a plugin using the new  datasette-plugin  cookiecutter template. \n                     \n                     \n                         Plugin hooks  is a full list of detailed documentation for every Datasette plugin hook. \n                     \n                     \n                         Testing plugins  describes how to write tests for Datasette plugins, using  pytest  and  HTTPX .", "sections_fts": 249, "rank": null}
{"rowid": 124, "title": "Binary data", "content": "SQLite tables can contain binary data in  BLOB  columns. \n         Datasette includes special handling for these binary values. The Datasette interface detects binary values and provides a link to download their content, for example on  https://latest.datasette.io/fixtures/binary_data \n         \n         Binary data is represented in  .json  exports using Base64 encoding. \n         https://latest.datasette.io/fixtures/binary_data.json?_shape=array \n         [\n    {\n        \"rowid\": 1,\n        \"data\": {\n            \"$base64\": true,\n            \"encoded\": \"FRwCx60F/g==\"\n        }\n    },\n    {\n        \"rowid\": 2,\n        \"data\": {\n            \"$base64\": true,\n            \"encoded\": \"FRwDx60F/g==\"\n        }\n    },\n    {\n        \"rowid\": 3,\n        \"data\": null\n    }\n]", "sections_fts": 249, "rank": null}
{"rowid": 379, "title": "Binary data", "content": "SQLite tables can contain binary data in  BLOB  columns. Datasette now provides links for users to download this data directly from Datasette, and uses those links to make binary data available from CSV exports. See  Binary data  for more details. ( #1036  and  #1034 ).", "sections_fts": 249, "rank": null}
{"rowid": 126, "title": "Binary plugins", "content": "Several Datasette plugins are available that change the way Datasette treats binary data. \n             \n                 \n                     datasette-render-binary  modifies Datasette's default interface to show an automatic guess at what type of binary data is being stored, along with a visual representation of the binary value that displays ASCII strings directly in the interface. \n                 \n                 \n                     datasette-render-images  detects common image formats and renders them as images directly in the Datasette interface. \n                 \n                 \n                     datasette-media  allows Datasette interfaces to be configured to serve binary files from configured SQL queries, and includes the ability to resize images directly before serving them.", "sections_fts": 249, "rank": null}
{"rowid": 337, "title": "Bug fixes", "content": "Don't show the facet option in the cog menu if faceting is not allowed. ( #1683 ) \n                     \n                     \n                         ?_sort  and  ?_sort_desc  now work if the column that is being sorted has been excluded from the query using  ?_col=  or  ?_nocol= . ( #1773 ) \n                     \n                     \n                         Fixed bug where  ?_sort_desc  was duplicated in the URL every time the Apply button was clicked. ( #1738 )", "sections_fts": 249, "rank": null}
{"rowid": 357, "title": "Bug fixes and other improvements", "content": "Custom pages  now work correctly when combined with the  base_url  setting. ( #1238 ) \n                     \n                     \n                         Fixed intermittent error displaying the index page when the user did not have permission to access one of the tables. Thanks, Guy Freeman. ( #1305 ) \n                     \n                     \n                         Columns with the name \"Link\" are no longer incorrectly displayed in bold. ( #1308 ) \n                     \n                     \n                         Fixed error caused by tables with a single quote in their names. ( #1257 ) \n                     \n                     \n                         Updated dependencies:  pytest-asyncio ,  Black ,  jinja2 ,  aiofiles ,  click , and  itsdangerous . \n                     \n                     \n                         The official Datasette Docker image now supports  apt-get install . ( #1320 ) \n                     \n                     \n                         The Heroku runtime used by  datasette publish heroku  is now  python-3.8.10 .", "sections_fts": 249, "rank": null}
{"rowid": 49, "title": "Building URLs within plugins", "content": "Plugins that define their own custom user interface elements may need to link to other pages within Datasette. \n             This can be a bit tricky if the Datasette instance is using the  base_url  configuration setting to run behind a proxy, since that can cause Datasette's URLs to include an additional prefix. \n             The  datasette.urls  object provides internal methods for correctly generating URLs to different pages within Datasette, taking any  base_url  configuration into account. \n             This object is exposed in templates as the  urls  variable, which can be used like this: \n             Back to the <a href=\"{{ urls.instance() }}\">Homepage</a> \n             See  datasette.urls  for full details on this object.", "sections_fts": 249, "rank": null}
{"rowid": 541, "title": "Built-in permissions", "content": "This section lists all of the permission checks that are carried out by Datasette core, along with the  resource  if it was passed.", "sections_fts": 249, "rank": null}
{"rowid": 64, "title": "CLI reference", "content": "The  datasette  CLI tool provides a number of commands. \n         Running  datasette  without specifying a command runs the default command,  datasette serve .  See  datasette serve  for the full list of options for that command. \n         [[[cog\nfrom datasette import cli\nfrom click.testing import CliRunner\nimport textwrap\ndef help(args):\n    title = \"datasette \" + \" \".join(args)\n    cog.out(\"\\n::\\n\\n\")\n    result = CliRunner().invoke(cli.cli, args)\n    output = result.output.replace(\"Usage: cli \", \"Usage: datasette \")\n    cog.out(textwrap.indent(output, '    '))\n    cog.out(\"\\n\\n\") \n         ]]] \n         [[[end]]]", "sections_fts": 249, "rank": null}
{"rowid": 273, "title": "CSRF protection", "content": "Datasette uses  asgi-csrf  to guard against CSRF attacks on form POST submissions. Users receive a  ds_csrftoken  cookie which is compared against the  csrftoken  form field (or  x-csrftoken  HTTP header) for every incoming request. \n             If your plugin implements a  <form method=\"POST\">  anywhere you will need to include that token. You can do so with the following template snippet: \n             <input type=\"hidden\" name=\"csrftoken\" value=\"{{ csrftoken() }}\"> \n             If you are rendering templates using the  await .render_template(template, context=None, request=None)  method the  csrftoken()  helper will only work if you provide the  request=  argument to that method. If you forget to do this you will see the following error: \n             form-urlencoded POST field did not match cookie \n             You can selectively disable CSRF protection using the  skip_csrf(datasette, scope)  hook.", "sections_fts": 249, "rank": null}
{"rowid": 406, "title": "CSRF protection", "content": "Since writable canned queries are built using POST forms, Datasette now ships with  CSRF protection  ( #798 ). This applies automatically to any POST request, which means plugins need to include a  csrftoken  in any POST forms that they render. They can do that like so: \n                 <input type=\"hidden\" name=\"csrftoken\" value=\"{{ csrftoken() }}\">", "sections_fts": 249, "rank": null}
{"rowid": 180, "title": "CSS classes on the <body>", "content": "Every default template includes CSS classes in the body designed to support\n                custom styling. \n             The index template (the top level page at  / ) gets this: \n             <body class=\"index\"> \n             The database template ( /dbname ) gets this: \n             <body class=\"db db-dbname\"> \n             The custom SQL template ( /dbname?sql=... ) gets this: \n             <body class=\"query db-dbname\"> \n             A canned query template ( /dbname/queryname ) gets this: \n             <body class=\"query db-dbname query-queryname\"> \n             The table template ( /dbname/tablename ) gets: \n             <body class=\"table db-dbname table-tablename\"> \n             The row template ( /dbname/tablename/rowid ) gets: \n             <body class=\"row db-dbname table-tablename\"> \n             The  db-x  and  table-x  classes use the database or table names themselves if\n                they are valid CSS identifiers. If they aren't, we strip any invalid\n                characters out and append a 6 character md5 digest of the original name, in\n                order to ensure that multiple tables which resolve to the same stripped\n                character version still have different CSS classes. \n             Some examples: \n             \"simple\" => \"simple\"\n\"MixedCase\" => \"MixedCase\"\n\"-no-leading-hyphens\" => \"no-leading-hyphens-65bea6\"\n\"_no-leading-underscores\" => \"no-leading-underscores-b921bc\"\n\"no spaces\" => \"no-spaces-7088d7\"\n\"-\" => \"336d5e\"\n\"no $ characters\" => \"no--characters-59e024\" \n             <td>  and  <th>  elements also get custom CSS classes reflecting the\n                database column they are representing, for example: \n             <table>\n    <thead>\n        <tr>\n            <th class=\"col-id\" scope=\"col\">id</th>\n            <th class=\"col-name\" scope=\"col\">name</th>\n        </tr>\n    </thead>\n    <tbody>\n        <tr>\n            <td class=\"col-id\"><a href=\"...\">1</a></td>\n            <td class=\"col-name\">SMITH</td>\n        </tr>\n    </tbody>\n</table>", "sections_fts": 249, "rank": null}
{"rowid": 1, "title": "CSV export", "content": "Any Datasette table, view or custom SQL query can be exported as CSV. \n         To obtain the CSV representation of the table you are looking, click the \"this\n            data as CSV\" link. \n         You can also use the advanced export form for more control over the resulting\n            file, which looks like this and has the following options: \n         \n         \n             \n                 download file  - instead of displaying CSV in your browser, this forces\n                    your browser to download the CSV to your downloads directory. \n             \n             \n                 expand labels  - if your table has any foreign key references this option\n                    will cause the CSV to gain additional  COLUMN_NAME_label  columns with a\n                    label for each foreign key derived from the linked table.  In this example \n                    the  city_id  column is accompanied by a  city_id_label  column. \n             \n             \n                 stream all rows  - by default CSV files only contain the first\n                     max_returned_rows  records. This option will cause Datasette to\n                    loop through every matching record and return them as a single CSV file. \n             \n         \n         You can try that out on  https://latest.datasette.io/fixtures/facetable?_size=4", "sections_fts": 249, "rank": null}
{"rowid": 460, "title": "CSV export", "content": "Any Datasette table, view or custom SQL query can now be exported as CSV. \n                 \n                 Check out the  CSV export documentation  for more details, or\n                    try the feature out on\n                     https://fivethirtyeight.datasettes.com/fivethirtyeight/bechdel%2Fmovies \n                 If your table has more than  max_returned_rows  (default 1,000)\n                    Datasette provides the option to  stream all rows . This option takes advantage\n                    of async Python and Datasette's efficient  pagination  to\n                    iterate through the entire matching result set and stream it back as a\n                    downloadable CSV file.", "sections_fts": 249, "rank": null}
{"rowid": 54, "title": "Canned queries", "content": "As an alternative to adding views to your database, you can define canned queries inside your  datasette.yaml  file. Here's an example: \n             [[[cog\nfrom metadata_doc import config_example, config_example\nconfig_example(cog, {\n    \"databases\": {\n       \"sf-trees\": {\n           \"queries\": {\n               \"just_species\": {\n                   \"sql\": \"select qSpecies from Street_Tree_List\"\n               }\n           }\n       }\n    }\n}) \n             ]]] \n             [[[end]]] \n             Then run Datasette like this: \n             datasette sf-trees.db -m metadata.json \n             Each canned query will be listed on the database index page, and will also get its own URL at: \n             /database-name/canned-query-name \n             For the above example, that URL would be: \n             /sf-trees/just_species \n             You can optionally include  \"title\"  and  \"description\"  keys to show a title and description on the canned query page. As with regular table metadata you can alternatively specify  \"description_html\"  to have your description rendered as HTML (rather than having HTML special characters escaped).", "sections_fts": 249, "rank": null}
{"rowid": 25, "title": "Canned queries configuration", "content": "Canned queries  are named SQL queries that appear in the Datasette interface. They can be configured in  datasette.yaml  using the  queries  key at the database level: \n                 [[[cog\nfrom metadata_doc import config_example, config_example\nconfig_example(cog, {\n    \"databases\": {\n       \"sf-trees\": {\n           \"queries\": {\n               \"just_species\": {\n                   \"sql\": \"select qSpecies from Street_Tree_List\"\n               }\n           }\n       }\n    }\n}) \n                 ]]] \n                 [[[end]]] \n                 See the  canned queries documentation  for more, including how to configure  writable canned queries .", "sections_fts": 249, "rank": null}
{"rowid": 55, "title": "Canned query parameters", "content": "Canned queries support named parameters, so if you include those in the SQL you will then be able to enter them using the form fields on the canned query page or by adding them to the URL. This means canned queries can be used to create custom JSON APIs based on a carefully designed SQL statement. \n                 Here's an example of a canned query with a named parameter: \n                 select neighborhood, facet_cities.name, state\nfrom facetable\n  join facet_cities on facetable.city_id = facet_cities.id\nwhere neighborhood like '%' || :text || '%'\norder by neighborhood; \n                 In the canned query configuration looks like this: \n                 [[[cog\nconfig_example(cog, \"\"\"\ndatabases:\n  fixtures:\n    queries:\n      neighborhood_search:\n        title: Search neighborhoods\n        sql: |-\n          select neighborhood, facet_cities.name, state\n          from facetable\n            join facet_cities on facetable.city_id = facet_cities.id\n          where neighborhood like '%' || :text || '%'\n          order by neighborhood\n\"\"\") \n                 ]]] \n                 [[[end]]] \n                 Note that we are using SQLite string concatenation here - the  ||  operator - to add wildcard  %  characters to the string provided by the user. \n                 You can try this canned query out here:\n                     https://latest.datasette.io/fixtures/neighborhood_search?text=town \n                 In this example the  :text  named parameter is automatically extracted from the query using a regular expression. \n                 You can alternatively provide an explicit list of named parameters using the  \"params\"  key, like this: \n                 [[[cog\nconfig_example(cog, \"\"\"\ndatabases:\n  fixtures:\n    queries:\n      neighborhood_search:\n        title: Search neighborhoods\n        params:\n        - text\n        sql: |-\n          select neighborhood, facet_cities.name, state\n          from facetable\n            join facet_cities on facetable.city_id = facet_cities.id\n          where neighborhood like '%' || :text || '%'\n          order by neighborhood\n\"\"\") \n                 ]]] \n                 [[[end]]]", "sections_fts": 249, "rank": null}
{"rowid": 294, "title": "Changelog", "content": "", "sections_fts": 249, "rank": null}
{"rowid": 535, "title": "Checking permissions in plugins", "content": "Datasette plugins can check if an actor has permission to perform an action using the  datasette.permission_allowed(...)  method. \n             Datasette core performs a number of permission checks,  documented below . Plugins can implement the  permission_allowed(datasette, actor, action, resource)  plugin hook to participate in decisions about whether an actor should be able to perform a specified action.", "sections_fts": 249, "rank": null}
{"rowid": 133, "title": "Code formatting", "content": "Datasette uses opinionated code formatters:  Black  for Python and  Prettier  for JavaScript. \n             These formatters are enforced by Datasette's continuous integration: if a commit includes Python or JavaScript code that does not match the style enforced by those tools, the tests will fail. \n             When developing locally, you can verify and correct the formatting of your code using these tools.", "sections_fts": 249, "rank": null}
{"rowid": 366, "title": "Code formatting with Black and Prettier", "content": "Datasette adopted  Black  for opinionated Python code formatting in June 2019. Datasette now also embraces  Prettier  for JavaScript formatting, which like Black is enforced by tests in continuous integration. Instructions for using these two tools can be found in the new section on  Code formatting  in the contributors documentation. ( #1167 )", "sections_fts": 249, "rank": null}
{"rowid": 203, "title": "Column descriptions", "content": "You can include descriptions for your columns by adding a  \"columns\": {\"name-of-column\": \"description-of-column\"}  block to your table metadata: \n             [[[cog\nmetadata_example(cog, {\n    \"databases\": {\n        \"database1\": {\n            \"tables\": {\n                \"example_table\": {\n                    \"columns\": {\n                        \"column1\": \"Description of column 1\",\n                        \"column2\": \"Description of column 2\"\n                    }\n                }\n            }\n        }\n    }\n}) \n             ]]] \n             [[[end]]] \n             These will be displayed at the top of the table page, and will also show in the cog menu for each column. \n             You can see an example of how these look at  latest.datasette.io/fixtures/roadside_attractions .", "sections_fts": 249, "rank": null}
{"rowid": 158, "title": "Column filter arguments", "content": "You can filter the data returned by the table based on column values using a query string argument. \n                 \n                     \n                         ?column__exact=value  or  ?_column=value \n                         \n                             Returns rows where the specified column exactly matches the value. \n                         \n                     \n                     \n                         ?column__not=value \n                         \n                             Returns rows where the column does not match the value. \n                         \n                     \n                     \n                         ?column__contains=value \n                         \n                             Rows where the string column contains the specified value ( column like \"%value%\"  in SQL). \n                         \n                     \n                     \n                         ?column__notcontains=value \n                         \n                             Rows where the string column does not contain the specified value ( column not like \"%value%\"  in SQL). \n                         \n                     \n                     \n                         ?column__endswith=value \n                         \n                             Rows where the string column ends with the specified value ( column like \"%value\"  in SQL). \n                         \n                     \n                     \n                         ?column__startswith=value \n                         \n                             Rows where the string column starts with the specified value ( column like \"value%\"  in SQL). \n                         \n                     \n                     \n                         ?column__gt=value \n                         \n                             Rows which are greater than the specified value. \n                         \n                     \n                     \n                         ?column__gte=value \n                         \n                             Rows which are greater than or equal to the specified value. \n                         \n                     \n                     \n                         ?column__lt=value \n                         \n                             Rows which are less than the specified value. \n                         \n                     \n                     \n                         ?column__lte=value \n                         \n                             Rows which are less than or equal to the specified value. \n                         \n                     \n                     \n                         ?column__like=value \n                         \n                             Match rows with a LIKE clause, case insensitive and with  %  as the wildcard character. \n                         \n                     \n                     \n                         ?column__notlike=value \n                         \n                             Match rows that do not match the provided LIKE clause. \n                         \n                     \n                     \n                         ?column__glob=value \n                         \n                             Similar to LIKE but uses Unix wildcard syntax and is case sensitive. \n                         \n                     \n                     \n                         ?column__in=value1,value2,value3 \n                         \n                             Rows where column matches any of the provided values. \n                             You can use a comma separated string, or you can use a JSON array. \n                             The JSON array option is useful if one of your matching values itself contains a comma: \n                             ?column__in=[\"value\",\"value,with,commas\"] \n                         \n                     \n                     \n                         ?column__notin=value1,value2,value3 \n                         \n                             Rows where column does not match any of the provided values. The inverse of  __in= . Also supports JSON arrays. \n                         \n                     \n                     \n                         ?column__arraycontains=value \n                         \n                             Works against columns that contain JSON arrays - matches if any of the values in that array match the provided value. \n                             This is only available if the  json1  SQLite extension is enabled. \n                         \n                     \n                     \n                         ?column__arraynotcontains=value \n                         \n                             Works against columns that contain JSON arrays - matches if none of the values in that array match the provided value. \n                             This is only available if the  json1  SQLite extension is enabled. \n                         \n                     \n                     \n                         ?column__date=value \n                         \n                             Column is a datestamp occurring on the specified YYYY-MM-DD date, e.g.  2018-01-02 . \n                         \n                     \n                     \n                         ?column__isnull=1 \n                         \n                             Matches rows where the column is null. \n                         \n                     \n                     \n                         ?column__notnull=1 \n                         \n                             Matches rows where the column is not null. \n                         \n                     \n                     \n                         ?column__isblank=1 \n                         \n                             Matches rows where the column is blank, meaning null or the empty string. \n                         \n                     \n                     \n                         ?column__notblank=1 \n                         \n                             Matches rows where the column is not blank.", "sections_fts": 249, "rank": null}
{"rowid": 19, "title": "Configuration", "content": "Datasette offers several ways to configure your Datasette instances: server settings, plugin configuration, authentication, and more. \n         Most configuration can be handled using a  datasette.yaml  configuration file, passed to datasette using the  -c/--config  flag: \n         datasette mydatabase.db --config datasette.yaml \n         This file can also use JSON, as  datasette.json . YAML is recommended over JSON due to its support for comments and multi-line strings.", "sections_fts": 249, "rank": null}
{"rowid": 305, "title": "Configuration", "content": "Plugin configuration now lives in the  datasette.yaml configuration file , passed to Datasette using the  -c/--config  option. Thanks, Alex Garcia. ( #2093 ) \n                         datasette -c datasette.yaml \n                         Where  datasette.yaml  contains configuration that looks like this: \n                         plugins:\n  datasette-cluster-map:\n    latitude_column: xlat\n    longitude_column: xlon \n                         Previously plugins were configured in  metadata.yaml , which was confusing as plugin settings were unrelated to database and table metadata. \n                     \n                     \n                         The  -s/--setting  option can now be used to set plugin configuration as well. See  Configuration via the command-line  for details. ( #2252 ) \n                         The above YAML configuration example using  -s/--setting  looks like this: \n                         datasette mydatabase.db \\\n  -s plugins.datasette-cluster-map.latitude_column xlat \\\n  -s plugins.datasette-cluster-map.longitude_column xlon \n                     \n                     \n                         The new  /-/config  page shows the current instance configuration, after redacting keys that could contain sensitive data such as API keys or passwords. ( #2254 ) \n                     \n                     \n                         Existing Datasette installations may already have configuration set in  metadata.yaml  that should be migrated to  datasette.yaml . To avoid breaking these installations, Datasette will silently treat table configuration, plugin configuration and allow blocks in metadata as if they had been specified in configuration instead. ( #2247 ) ( #2248 ) ( #2249 ) \n                     \n                 \n                 Note that the  datasette publish  command has not yet been updated to accept a  datasette.yaml  configuration file. This will be addressed in  #2195  but for the moment you can include those settings in  metadata.yaml  instead.", "sections_fts": 249, "rank": null}
{"rowid": 485, "title": "Configuration directory mode", "content": "Normally you configure Datasette using command-line options. For a Datasette instance with custom templates, custom plugins, a static directory and several databases this can get quite verbose: \n             datasette one.db two.db \\\n  --metadata=metadata.json \\\n  --template-dir=templates/ \\\n  --plugins-dir=plugins \\\n  --static css:css \n             As an alternative to this, you can run Datasette in  configuration directory  mode. Create a directory with the following structure: \n             # In a directory called my-app:\nmy-app/one.db\nmy-app/two.db\nmy-app/datasette.yaml\nmy-app/metadata.json\nmy-app/templates/index.html\nmy-app/plugins/my_plugin.py\nmy-app/static/my.css \n             Now start Datasette by providing the path to that directory: \n             datasette my-app/ \n             Datasette will detect the files in that directory and automatically configure itself using them. It will serve all  *.db  files that it finds, will load  metadata.json  if it exists, and will load the  templates ,  plugins  and  static  folders if they are present. \n             The files that can be included in this directory are as follows. All are optional. \n             \n                 \n                     *.db  (or  *.sqlite3  or  *.sqlite ) - SQLite database files that will be served by Datasette \n                 \n                 \n                     datasette.yaml  -  Configuration  for the Datasette instance \n                 \n                 \n                     metadata.json  -  Metadata  for those databases -  metadata.yaml  or  metadata.yml  can be used as well \n                 \n                 \n                     inspect-data.json  - the result of running  datasette inspect *.db --inspect-file=inspect-data.json  from the configuration directory - any database files listed here will be treated as immutable, so they should not be changed while Datasette is running \n                 \n                 \n                     templates/  - a directory containing  Custom templates \n                 \n                 \n                     plugins/  - a directory containing plugins, see  Writing one-off plugins \n                 \n                 \n                     static/  - a directory containing static files - these will be served from  /static/filename.txt , see  Serving static files", "sections_fts": 249, "rank": null}
{"rowid": 20, "title": "Configuration via the command-line", "content": "The recommended way to configure Datasette is using a  datasette.yaml  file passed to  -c/--config . You can also pass individual settings to Datasette using the  -s/--setting  option, which can be used multiple times: \n             datasette mydatabase.db \\\n  --setting settings.default_page_size 50 \\\n  --setting settings.sql_time_limit_ms 3500 \n             This option takes dotted-notation for the first argument and a value for the second argument. This means you can use it to set any configuration value that would be valid in a  datasette.yaml  file. \n             It also works for plugin configuration, for example for  datasette-cluster-map : \n             datasette mydatabase.db \\\n  --setting plugins.datasette-cluster-map.latitude_column xlat \\\n  --setting plugins.datasette-cluster-map.longitude_column xlon \n             If the value you provide is a valid JSON object or list it will be treated as nested data, allowing you to configure plugins that accept lists such as  datasette-proxy-url : \n             datasette mydatabase.db \\\n  -s plugins.datasette-proxy-url.paths '[{\"path\": \"/proxy\", \"backend\": \"http://example.com/\"}]' \n             This is equivalent to a  datasette.yaml  file containing the following: \n             [[[cog\nfrom metadata_doc import config_example\nimport textwrap\nconfig_example(cog, textwrap.dedent(\n  \"\"\"\n  plugins:\n    datasette-proxy-url:\n      paths:\n      - path: /proxy\n        backend: http://example.com/\n  \"\"\").strip()\n  ) \n             ]]] \n             [[[end]]]", "sections_fts": 249, "rank": null}
{"rowid": 12, "title": "Configuring FTS by hand", "content": "We recommend using  sqlite-utils , but if you want to hand-roll a SQLite full-text search table you can do so using the following SQL. \n                 To enable full-text search for a table called  items  that works against the  name  and  description  columns, you would run this SQL to create a new  items_fts  FTS virtual table: \n                 CREATE VIRTUAL TABLE \"items_fts\" USING FTS4 (\n    name,\n    description,\n    content=\"items\"\n); \n                 This creates a set of tables to power full-text search against  items . The new  items_fts  table will be detected by Datasette as the  fts_table  for the  items  table. \n                 Creating the table is not enough: you also need to populate it with a copy of the data that you wish to make searchable. You can do that using the following SQL: \n                 INSERT INTO \"items_fts\" (rowid, name, description)\n    SELECT rowid, name, description FROM items; \n                 If your table has columns that are foreign key references to other tables you can include that data in your full-text search index using a join. Imagine the  items  table has a foreign key column called  category_id  which refers to a  categories  table - you could create a full-text search table like this: \n                 CREATE VIRTUAL TABLE \"items_fts\" USING FTS4 (\n    name,\n    description,\n    category_name,\n    content=\"items\"\n); \n                 And then populate it like this: \n                 INSERT INTO \"items_fts\" (rowid, name, description, category_name)\n    SELECT items.rowid,\n    items.name,\n    items.description,\n    categories.name\n    FROM items JOIN categories ON items.category_id=categories.id; \n                 You can use this technique to populate the full-text search index from any combination of tables and joins that makes sense for your project.", "sections_fts": 249, "rank": null}
{"rowid": 11, "title": "Configuring FTS using csvs-to-sqlite", "content": "If your data starts out in CSV files, you can use Datasette's companion tool  csvs-to-sqlite  to convert that file into a SQLite database and enable full-text search on specific columns. For a file called  items.csv  where you want full-text search to operate against the  name  and  description  columns you would run the following: \n                 csvs-to-sqlite items.csv items.db -f name -f description", "sections_fts": 249, "rank": null}
{"rowid": 10, "title": "Configuring FTS using sqlite-utils", "content": "sqlite-utils  is a CLI utility and Python library for manipulating SQLite databases. You can use  it from Python code  to configure FTS search, or you can achieve the same goal  using the accompanying command-line tool . \n                 Here's how to use  sqlite-utils  to enable full-text search for an  items  table across the  name  and  description  columns: \n                 sqlite-utils enable-fts mydatabase.db items name description", "sections_fts": 249, "rank": null}
{"rowid": 7, "title": "Configuring full-text search for a table or view", "content": "If a table has a corresponding FTS table set up using the  content=  argument to  CREATE VIRTUAL TABLE  shown below, Datasette will detect it automatically and add a search interface to the table page for that table. \n             You can also manually configure which table should be used for full-text search using query string parameters or  Metadata . You can set the associated FTS table for a specific table and you can also set one for a view - if you do that, the page for that SQL view will offer a search option. \n             Use  ?_fts_table=x  to over-ride the FTS table for a specific page. If the primary key was something other than  rowid  you can use  ?_fts_pk=col  to set that as well. This is particularly useful for views, for example: \n             https://latest.datasette.io/fixtures/searchable_view?_fts_table=searchable_fts&_fts_pk=pk \n             The  fts_table  metadata property can be used to specify an associated FTS table. If the primary key column in your table which was used to populate the FTS table is something other than  rowid , you can specify the column to use with the  fts_pk  property. \n             The  \"searchmode\": \"raw\"  property can be used to default the table to accepting SQLite advanced search operators, as described in  Advanced SQLite search queries . \n             Here is an example which enables full-text search (with SQLite advanced search operators) for a  display_ads  view which is defined against the  ads  table and hence needs to run FTS against the  ads_fts  table, using the  id  as the primary key: \n             [[[cog\nfrom metadata_doc import metadata_example\nmetadata_example(cog, {\n    \"databases\": {\n        \"russian-ads\": {\n            \"tables\": {\n                \"display_ads\": {\n                    \"fts_table\": \"ads_fts\",\n                    \"fts_pk\": \"id\",\n                    \"searchmode\": \"raw\"\n                }\n            }\n        }\n    }\n}) \n             ]]] \n             [[[end]]]", "sections_fts": 249, "rank": null}
{"rowid": 510, "title": "Configuring the secret", "content": "Datasette uses a secret string to sign secure values such as cookies. \n             If you do not provide a secret, Datasette will create one when it starts up. This secret will reset every time the Datasette server restarts though, so things like authentication cookies and  API tokens  will not stay valid between restarts. \n             You can pass a secret to Datasette in two ways: with the  --secret  command-line option or by setting a  DATASETTE_SECRET  environment variable. \n             datasette mydb.db --secret=SECRET_VALUE_HERE \n             Or: \n             export DATASETTE_SECRET=SECRET_VALUE_HERE\ndatasette mydb.db \n             One way to generate a secure random secret is to use Python like this: \n             python3 -c 'import secrets; print(secrets.token_hex(32))'\ncdb19e94283a20f9d42cca50c5a4871c0aa07392db308755d60a1a5b9bb0fa52 \n             Plugin authors make use of this signing mechanism in their plugins using  .sign(value, namespace=\"default\")  and  .unsign(value, namespace=\"default\") .", "sections_fts": 249, "rank": null}
{"rowid": 564, "title": "Contents", "content": "Getting started Play with a live demo Follow a tutorial Datasette in your browser with Datasette Lite Try Datasette without installing anything using Glitch Using Datasette on your own computer Installation Basic installation Datasette Desktop for Mac Using Homebrew Using pip Advanced installation options Using pipx Using Docker A note about extensions Configuration Configuration via the command-line datasette.yaml  reference Settings Plugin configuration Permissions configuration Canned queries configuration Custom CSS and JavaScript The Datasette Ecosystem sqlite-utils Dogsheep CLI reference datasette --help datasette serve datasette --get datasette serve --help-settings datasette plugins datasette install datasette uninstall datasette publish datasette publish cloudrun datasette publish heroku datasette package datasette inspect datasette create-token Pages and API endpoints Top-level index Database Hidden tables Table Row Publishing data datasette publish Publishing to Google Cloud Run Publishing to Heroku Publishing to Vercel Publishing to Fly Custom metadata and plugins datasette package Deploying Datasette Deployment fundamentals Running Datasette using systemd Running Datasette using OpenRC Deploying using buildpacks Running Datasette behind a proxy Nginx proxy configuration Apache proxy configuration JSON API Default representation Different shapes Pagination Special JSON arguments Table arguments Column filter arguments Special table arguments Expanding foreign key references Discovering the JSON for a page Enabling CORS The JSON write API Inserting rows Upserting rows Updating a row Deleting a row Creating a table Creating a table from example data Dropping tables Running SQL queries Named parameters Views Canned queries Canned query parameters Additional canned query options Writable canned queries Magic parameters JSON API for writable canned queries Pagination Cross-database queries Authentication and permissions Actors Using the \"root\" actor Permissions How permissions are resolved Defining permissions with \"allow\" blocks The /-/allow-debug tool Access permissions in  datasette.yaml Access to an instance Access to specific databases Access to specific tables and views Access to specific canned queries Controlling the ability to execute arbitrary SQL Other permissions in  datasette.yaml API Tokens datasette create-token Checking permissions in plugins actor_matches_allow() The permissions debug tool The ds_actor cookie Including an expiry time The /-/logout page Built-in permissions view-instance view-database view-database-download view-table view-query insert-row delete-row update-row create-table alter-table drop-table execute-sql permissions-debug debug-menu Performance and caching Immutable mode Using \"datasette inspect\" HTTP caching datasette-hashed-urls CSV export URL parameters Streaming all records Binary data Linking to binary downloads Binary plugins Facets Facets in query strings Facets in metadata Suggested facets Speeding up facets with indexes Facet by JSON array Facet by date Full-text search The table page and table view API Advanced SQLite search queries Configuring full-text search for a table or view Searches using custom SQL Enabling full-text search for a SQLite table Configuring FTS using sqlite-utils Configuring FTS using csvs-to-sqlite Configuring FTS by hand FTS versions SpatiaLite Warning Installation Installing SpatiaLite on OS X Installing SpatiaLite on Linux Spatial indexing latitude/longitude columns Making use of a spatial index Importing shapefiles into SpatiaLite Importing GeoJSON polygons using Shapely Querying polygons using within() Metadata Per-database and per-table metadata Source, license and about Column descriptions Specifying units for a column Setting a default sort order Setting a custom page size Setting which columns can be used for sorting Specifying the label column for a table Hiding tables Metadata reference Top-level metadata Database-level metadata Table-level metadata Settings Using --setting Configuration directory mode Settings default_allow_sql default_page_size sql_time_limit_ms max_returned_rows max_insert_rows num_sql_threads allow_facet default_facet_size facet_time_limit_ms facet_suggest_time_limit_ms suggest_facets allow_download allow_signed_tokens max_signed_tokens_ttl default_cache_ttl cache_size_kb allow_csv_stream max_csv_mb truncate_cells_html force_https_urls template_debug trace_debug base_url Configuring the secret Using secrets with datasette publish Introspection /-/metadata /-/versions /-/plugins /-/settings /-/config /-/databases /-/threads /-/actor /-/messages Custom pages and templates CSS classes on the <body> Serving static files Publishing static assets Custom templates Custom pages Path parameters for pages Custom headers and status codes Returning 404s Custom redirects Custom error pages Plugins Installing plugins One-off plugins using --plugins-dir Deploying plugins using datasette publish Controlling which plugins are loaded Seeing what plugins are installed Plugin configuration Secret configuration values Writing plugins Tracing plugin hooks Writing one-off plugins Starting an installable plugin using cookiecutter Packaging a plugin Static assets Custom templates Writing plugins that accept configuration Designing URLs for your plugin Building URLs within plugins Plugins that define new plugin hooks JavaScript plugins The datasette_init event datasetteManager JavaScript plugin objects makeAboveTablePanelConfigs() makeColumnActions(columnDetails) Selectors Plugin hooks prepare_connection(conn, database, datasette) prepare_jinja2_environment(env, datasette) Page extras extra_template_vars(template, database, table, columns, view_name, request, datasette) extra_css_urls(template, database, table, columns, view_name, request, datasette) extra_js_urls(template, database, table, columns, view_name, request, datasette) extra_body_script(template, database, table, columns, view_name, request, datasette) publish_subcommand(publish) render_cell(row, value, column, table, database, datasette, request) register_output_renderer(datasette) register_routes(datasette) register_commands(cli) register_facet_classes() register_permissions(datasette) asgi_wrapper(datasette) startup(datasette) canned_queries(datasette, database, actor) actor_from_request(datasette, request) actors_from_ids(datasette, actor_ids) jinja2_environment_from_request(datasette, request, env) filters_from_request(request, database, table, datasette) permission_allowed(datasette, actor, action, resource) register_magic_parameters(datasette) forbidden(datasette, request, message) handle_exception(datasette, request, exception) skip_csrf(datasette, scope) get_metadata(datasette, key, database, table) menu_links(datasette, actor, request) Action hooks table_actions(datasette, actor, database, table, request) view_actions(datasette, actor, database, view, request) query_actions(datasette, actor, database, query_name, request, sql, params) row_actions(datasette, actor, request, database, table, row) database_actions(datasette, actor, database, request) homepage_actions(datasette, actor, request) Template slots top_homepage(datasette, request) top_database(datasette, request, database) top_table(datasette, request, database, table) top_row(datasette, request, database, table, row) top_query(datasette, request, database, sql) top_canned_query(datasette, request, database, query_name) Event tracking track_event(datasette, event) register_events(datasette) Testing plugins Setting up a Datasette test instance Using datasette.client in tests Using pdb for errors thrown inside Datasette Using pytest fixtures Testing outbound HTTP calls with pytest-httpx Registering a plugin for the duration of a test Internals for plugins Request object The MultiParams class Response class Returning a response with .asgi_send(send) Setting cookies with response.set_cookie() Datasette class .databases .permissions .plugin_config(plugin_name, database=None, table=None) await .render_template(template, context=None, request=None) await .actors_from_ids(actor_ids) await .permission_allowed(actor, action, resource=None, default=...) await .ensure_permissions(actor, permissions) await .check_visibility(actor, action=None, resource=None, permissions=None) .create_token(actor_id, expires_after=None, restrict_all=None, restrict_database=None, restrict_resource=None) .get_permission(name_or_abbr) .get_database(name) .get_internal_database() .add_database(db, name=None, route=None) .add_memory_database(name) .remove_database(name) await .track_event(event) .sign(value, namespace=\"default\") .unsign(value, namespace=\"default\") .add_message(request, message, type=datasette.INFO) .absolute_url(request, path) .setting(key) .resolve_database(request) .resolve_table(request) .resolve_row(request) datasette.client datasette.urls Database class Database(ds, path=None, is_mutable=True, is_memory=False, memory_name=None) db.hash await db.execute(sql, ...) Results await db.execute_fn(fn) await db.execute_write(sql, params=None, block=True) await db.execute_write_script(sql, block=True) await db.execute_write_many(sql, params_seq, block=True) await db.execute_write_fn(fn, block=True, transaction=True) await db.execute_isolated_fn(fn) db.close() Database introspection CSRF protection Datasette's internal database The datasette.utils module parse_metadata(content) await_me_maybe(value) derive_named_parameters(db, sql) Tilde encoding datasette.tracer Tracing child tasks Import shortcuts Events LoginEvent LogoutEvent CreateTokenEvent CreateTableEvent DropTableEvent AlterTableEvent InsertRowsEvent UpsertRowsEvent UpdateRowEvent DeleteRowEvent Contributing General guidelines Setting up a development environment Running the tests Using fixtures Debugging Code formatting Running Black blacken-docs Prettier Editing and building the documentation Running Cog Continuously deployed demo instances Release process Alpha and beta releases Releasing bug fixes from a branch Upgrading CodeMirror Changelog 1.0a13 (2024-03-12) 1.0a12 (2024-02-29) 1.0a11 (2024-02-19) 1.0a10 (2024-02-17) 1.0a9 (2024-02-16) Alter table support for create, insert, upsert and update Permissions fix for the upsert API Permission checks now consider opinions from every plugin Other changes 1.0a8 (2024-02-07) Configuration JavaScript plugins Plugin hooks Documentation Minor fixes 0.64.6 (2023-12-22) 0.64.5 (2023-10-08) 1.0a7 (2023-09-21) 0.64.4 (2023-09-21) 1.0a6 (2023-09-07) 1.0a5 (2023-08-29) 1.0a4 (2023-08-21) 1.0a3 (2023-08-09) Smaller changes 0.64.2 (2023-03-08) 0.64.1 (2023-01-11) 0.64 (2023-01-09) 0.63.3 (2022-12-17) 1.0a2 (2022-12-14) 1.0a1 (2022-12-01) 1.0a0 (2022-11-29) Signed API tokens Write API 0.63.2 (2022-11-18) 0.63.1 (2022-11-10) 0.63 (2022-10-27) Features Plugin hooks and internals Documentation 0.62 (2022-08-14) Features Plugin hooks Bug fixes Documentation 0.61.1 (2022-03-23) 0.61 (2022-03-23) 0.60.2 (2022-02-07) 0.60.1 (2022-01-20) 0.60 (2022-01-13) Plugins and internals Faceting Other small fixes 0.59.4 (2021-11-29) 0.59.3 (2021-11-20) 0.59.2 (2021-11-13) 0.59.1 (2021-10-24) 0.59 (2021-10-14) 0.58.1 (2021-07-16) 0.58 (2021-07-14) 0.57.1 (2021-06-08) 0.57 (2021-06-05) New features Bug fixes and other improvements 0.56.1 (2021-06-05) 0.56 (2021-03-28) 0.55 (2021-02-18) 0.54.1 (2021-02-02) 0.54 (2021-01-25) The _internal database Named in-memory database support JavaScript modules Code formatting with Black and Prettier Other changes 0.53 (2020-12-10) 0.52.5 (2020-12-09) 0.52.4 (2020-12-05) 0.52.3 (2020-12-03) 0.52.2 (2020-12-02) 0.52.1 (2020-11-29) 0.52 (2020-11-28) 0.51.1 (2020-10-31) 0.51 (2020-10-31) New visual design Plugins can now add links within Datasette Binary data URL building Running Datasette behind a proxy Smaller changes 0.50.2 (2020-10-09) 0.50.1 (2020-10-09) 0.50 (2020-10-09) 0.49.1 (2020-09-15) 0.49 (2020-09-14) 0.48 (2020-08-16) 0.47.3 (2020-08-15) 0.47.2 (2020-08-12) 0.47.1 (2020-08-11) 0.47 (2020-08-11) 0.46 (2020-08-09) 0.45 (2020-07-01) Magic parameters for canned queries Log out Better plugin documentation New plugin hooks Smaller changes 0.44 (2020-06-11) Authentication Permissions Writable canned queries Flash messages Signed values and secrets CSRF protection Cookie methods register_routes() plugin hooks Smaller changes The road to Datasette 1.0 0.43 (2020-05-28) 0.42 (2020-05-08) 0.41 (2020-05-06) 0.40 (2020-04-21) 0.39 (2020-03-24) 0.38 (2020-03-08) 0.37.1 (2020-03-02) 0.37 (2020-02-25) 0.36 (2020-02-21) 0.35 (2020-02-04) 0.34 (2020-01-29) 0.33 (2019-12-22) 0.32 (2019-11-14) 0.31.2 (2019-11-13) 0.31.1 (2019-11-12) 0.31 (2019-11-11) 0.30.2 (2019-11-02) 0.30.1 (2019-10-30) 0.30 (2019-10-18) 0.29.3 (2019-09-02) 0.29.2 (2019-07-13) 0.29.1 (2019-07-11) 0.29 (2019-07-07) ASGI New plugin hook: asgi_wrapper New plugin hook: extra_template_vars Secret plugin configuration options Facet by date Easier custom templates for table rows ?_through= for joins through many-to-many tables Small changes 0.28 (2019-05-19) Supporting databases that change Faceting improvements, and faceting plugins datasette publish cloudrun register_output_renderer plugins Medium changes Small changes 0.27.1 (2019-05-09) 0.27 (2019-01-31) 0.26.1 (2019-01-10) 0.26 (2019-01-02) 0.25.2 (2018-12-16) 0.25.1 (2018-11-04) 0.25 (2018-09-19) 0.24 (2018-07-23) 0.23.2 (2018-07-07) 0.23.1 (2018-06-21) 0.23 (2018-06-18) CSV export Foreign key expansions New configuration settings Control HTTP caching with ?_ttl= Improved support for SpatiaLite latest.datasette.io Miscellaneous 0.22.1 (2018-05-23) 0.22 (2018-05-20) 0.21 (2018-05-05) 0.20 (2018-04-20) 0.19 (2018-04-16) 0.18 (2018-04-14) 0.17 (2018-04-13) 0.16 (2018-04-13) 0.15 (2018-04-09) 0.14 (2017-12-09) 0.13 (2017-11-24) 0.12 (2017-11-16) 0.11 (2017-11-14) 0.10 (2017-11-14) 0.9 (2017-11-13) 0.8 (2017-11-13)", "sections_fts": 249, "rank": null}
{"rowid": 139, "title": "Continuously deployed demo instances", "content": "The demo instance at  latest.datasette.io  is re-deployed automatically to Google Cloud Run for every push to  main  that passes the test suite. This is implemented by the GitHub Actions workflow at  .github/workflows/deploy-latest.yml . \n             Specific branches can also be set to automatically deploy by adding them to the  on: push: branches  block at the top of the workflow YAML file. Branches configured in this way will be deployed to a new Cloud Run service whether or not their tests pass. \n             The Cloud Run URL for a branch demo can be found in the GitHub Actions logs.", "sections_fts": 249, "rank": null}
{"rowid": 127, "title": "Contributing", "content": "Datasette is an open source project. We welcome contributions! \n         This document describes how to contribute to Datasette core. You can also contribute to the wider Datasette ecosystem by creating new  Plugins .", "sections_fts": 249, "rank": null}