{"id": "metadata:table-level-metadata", "page": "metadata", "ref": "table-level-metadata", "title": "Table-level metadata", "content": "\"Table-level\" metadata refers to fields that can be specified for each table in a Datasette instance. These attributes should be listed under a specific table using the  \"tables\"  field. \n                 The following are the full list of allowed table-level metadata fields: \n                 \n                     \n                         source \n                     \n                     \n                         source_url \n                     \n                     \n                         license \n                     \n                     \n                         license_url \n                     \n                     \n                         about \n                     \n                     \n                         about_url \n                     \n                     \n                         hidden \n                     \n                     \n                         sort/sort_desc \n                     \n                     \n                         size \n                     \n                     \n                         sortable_columns \n                     \n                     \n                         label_column \n                     \n                     \n                         facets \n                     \n                     \n                         fts_table \n                     \n                     \n                         fts_pk \n                     \n                     \n                         searchmode \n                     \n                     \n                         columns", "breadcrumbs": "[\"Metadata\", \"Metadata reference\"]", "references": "[]"}
{"id": "metadata:top-level-metadata", "page": "metadata", "ref": "top-level-metadata", "title": "Top-level metadata", "content": "\"Top-level\" metadata refers to fields that can be specified at the root level  of a metadata file. These attributes are meant to describe the entire Datasette instance. \n                 The following are the full list of allowed top-level metadata fields: \n                 \n                     \n                         title \n                     \n                     \n                         description \n                     \n                     \n                         description_html \n                     \n                     \n                         license \n                     \n                     \n                         license_url \n                     \n                     \n                         source \n                     \n                     \n                         source_url", "breadcrumbs": "[\"Metadata\", \"Metadata reference\"]", "references": "[]"}
{"id": "pages:databaseview-hidden", "page": "pages", "ref": "databaseview-hidden", "title": "Hidden tables", "content": "Some tables listed on the database page are treated as hidden. Hidden tables are not completely invisible - they can be accessed through the \"hidden tables\" link at the bottom of the page. They are hidden because they represent low-level implementation details which are generally not useful to end-users of Datasette. \n                 The following tables are hidden by default: \n                 \n                     \n                         Any table with a name that starts with an underscore - this is a Datasette convention to help plugins easily hide their own internal tables. \n                     \n                     \n                         Tables that have been configured as  \"hidden\": true  using  Hiding tables . \n                     \n                     \n                         *_fts  tables that implement SQLite full-text search indexes. \n                     \n                     \n                         Tables relating to the inner workings of the SpatiaLite SQLite extension. \n                     \n                     \n                         sqlite_stat  tables used to store statistics used by the query optimizer.", "breadcrumbs": "[\"Pages and API endpoints\", \"Database\"]", "references": "[]"}
{"id": "pages:pages", "page": "pages", "ref": "pages", "title": "Pages and API endpoints", "content": "The Datasette web application offers a number of different pages that can be accessed to explore the data in question, each of which is accompanied by an equivalent JSON API.", "breadcrumbs": "[]", "references": "[]"}
{"id": "pages:queryview", "page": "pages", "ref": "queryview", "title": "Queries", "content": "The  /database-name/-/query  page can be used to execute an arbitrary SQL query against that database, if the  execute-sql  permission is enabled. This query is passed as the  ?sql=  query string parameter. \n             This means you can link directly to a query by constructing the following URL: \n             /database-name/-/query?sql=SELECT+*+FROM+table_name \n             Each configured  canned query  has its own page, at  /database-name/query-name . Viewing this page will execute the query and display the results. \n             In both cases adding a  .json  extension to the URL will return the results as JSON.", "breadcrumbs": "[\"Pages and API endpoints\"]", "references": "[]"}
{"id": "performance:performance", "page": "performance", "ref": "performance", "title": "Performance and caching", "content": "Datasette runs on top of SQLite, and SQLite has excellent performance.  For small databases almost any query should return in just a few milliseconds, and larger databases (100s of MBs or even GBs of data) should perform extremely well provided your queries make sensible use of database indexes. \n         That said, there are a number of tricks you can use to improve Datasette's performance.", "breadcrumbs": "[]", "references": "[]"}
{"id": "performance:performance-immutable-mode", "page": "performance", "ref": "performance-immutable-mode", "title": "Immutable mode", "content": "If you can be certain that a SQLite database file will not be changed by another process you can tell Datasette to open that file in  immutable mode . \n             Doing so will disable all locking and change detection, which can result in improved query performance. \n             This also enables further optimizations relating to HTTP caching, described below. \n             To open a file in immutable mode pass it to the datasette command using the  -i  option: \n             datasette -i data.db \n             When you open a file in immutable mode like this Datasette will also calculate and cache the row counts for each table in that database when it first starts up, further improving performance.", "breadcrumbs": "[\"Performance and caching\"]", "references": "[]"}
{"id": "performance:performance-inspect", "page": "performance", "ref": "performance-inspect", "title": "Using \"datasette inspect\"", "content": "Counting the rows in a table can be a very expensive operation on larger databases. In immutable mode Datasette performs this count only once and caches the results, but this can still cause server startup time to increase by several seconds or more. \n             If you know that a database is never going to change you can precalculate the table row counts once and store then in a JSON file, then use that file when you later start the server. \n             To create a JSON file containing the calculated row counts for a database, use the following: \n             datasette inspect data.db --inspect-file=counts.json \n             Then later you can start Datasette against the  counts.json  file and use it to skip the row counting step and speed up server startup: \n             datasette -i data.db --inspect-file=counts.json \n             You need to use the  -i  immutable mode against the database file here or the counts from the JSON file will be ignored. \n             You will rarely need to use this optimization in every-day use, but several of the  datasette publish  commands described in  Publishing data  use this optimization for better performance when deploying a database file to a hosting provider.", "breadcrumbs": "[\"Performance and caching\"]", "references": "[]"}
{"id": "plugin_hooks:plugin-actions", "page": "plugin_hooks", "ref": "plugin-actions", "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.", "breadcrumbs": "[\"Plugin hooks\"]", "references": "[]"}
{"id": "plugin_hooks:plugin-event-tracking", "page": "plugin_hooks", "ref": "plugin-event-tracking", "title": "Event tracking", "content": "Datasette includes an internal mechanism for tracking notable events. This can be used for analytics, but can also be used by plugins that want to listen out for when key events occur (such as a table being created) and take action in response. \n             Plugins can register to receive events using the  track_event  plugin hook. \n             They can also define their own events for other plugins to receive using the  register_events() plugin hook , combined with calls to the  datasette.track_event() internal method .", "breadcrumbs": "[\"Plugin hooks\"]", "references": "[]"}
{"id": "plugin_hooks:plugin-hook-forbidden", "page": "plugin_hooks", "ref": "plugin-hook-forbidden", "title": "forbidden(datasette, request, message)", "content": "datasette  -  Datasette class \n                     \n                         You can use this to access plugin configuration options via  datasette.plugin_config(your_plugin_name) , or to render templates or execute SQL queries. \n                     \n                 \n                 \n                     request  -  Request object \n                     \n                         The current HTTP request. \n                     \n                 \n                 \n                     message  - string \n                     \n                         A message hinting at why the request was forbidden. \n                     \n                 \n             \n             Plugins can use this to customize how Datasette responds when a 403 Forbidden error occurs - usually because a page failed a permission check, see  Permissions . \n             If a plugin hook wishes to react to the error, it should return a  Response object . \n             This example returns a redirect to a  /-/login  page: \n             from datasette import hookimpl\nfrom urllib.parse import urlencode\n\n\n@hookimpl\ndef forbidden(request, message):\n    return Response.redirect(\n        \"/-/login?=\" + urlencode({\"message\": message})\n    ) \n             The function can alternatively return an awaitable function if it needs to make any asynchronous method calls. This example renders a template: \n             from datasette import hookimpl, Response\n\n\n@hookimpl\ndef forbidden(datasette):\n    async def inner():\n        return Response.html(\n            await datasette.render_template(\n                \"render_message.html\", request=request\n            )\n        )\n\n    return inner", "breadcrumbs": "[\"Plugin hooks\"]", "references": "[]"}
{"id": "plugin_hooks:plugin-hook-homepage-actions", "page": "plugin_hooks", "ref": "plugin-hook-homepage-actions", "title": "homepage_actions(datasette, actor, request)", "content": "datasette  -  Datasette class \n                         \n                             You can use this to access plugin configuration options via  datasette.plugin_config(your_plugin_name) , or to execute SQL queries. \n                         \n                     \n                     \n                         actor  - dictionary or None \n                         \n                             The currently authenticated  actor . \n                         \n                     \n                     \n                         request  -  Request object \n                         \n                             The current HTTP request. \n                         \n                     \n                 \n                 Populates an actions menu on the top-level index homepage of the Datasette instance. \n                 This example adds a link an imagined tool for editing the homepage, only for signed in users: \n                 from datasette import hookimpl\n\n\n@hookimpl\ndef homepage_actions(datasette, actor):\n    if actor:\n        return [\n            {\n                \"href\": datasette.urls.path(\n                    \"/-/customize-homepage\"\n                ),\n                \"label\": \"Customize homepage\",\n            }\n        ]", "breadcrumbs": "[\"Plugin hooks\", \"Action hooks\"]", "references": "[]"}
{"id": "plugin_hooks:plugin-hook-register-events", "page": "plugin_hooks", "ref": "plugin-hook-register-events", "title": "register_events(datasette)", "content": "datasette  -  Datasette class \n                         \n                             You can use this to access plugin configuration options via  datasette.plugin_config(your_plugin_name) . \n                         \n                     \n                 \n                 This hook should return a list of  Event  subclasses that represent custom events that the plugin might send to the  datasette.track_event()  method. \n                 This example registers event subclasses for  ban-user  and  unban-user  events: \n                 from dataclasses import dataclass\nfrom datasette import hookimpl, Event\n\n\n@dataclass\nclass BanUserEvent(Event):\n    name = \"ban-user\"\n    user: dict\n\n\n@dataclass\nclass UnbanUserEvent(Event):\n    name = \"unban-user\"\n    user: dict\n\n\n@hookimpl\ndef register_events():\n    return [BanUserEvent, UnbanUserEvent] \n                 The plugin can then call  datasette.track_event(...)  to send a  ban-user  event: \n                 await datasette.track_event(\n    BanUserEvent(user={\"id\": 1, \"username\": \"cleverbot\"})\n)", "breadcrumbs": "[\"Plugin hooks\", \"Event tracking\"]", "references": "[]"}
{"id": "plugin_hooks:plugin-hook-register-magic-parameters", "page": "plugin_hooks", "ref": "plugin-hook-register-magic-parameters", "title": "register_magic_parameters(datasette)", "content": "datasette  -  Datasette class \n                     \n                         You can use this to access plugin configuration options via  datasette.plugin_config(your_plugin_name) . \n                     \n                 \n             \n             Magic parameters  can be used to add automatic parameters to  canned queries . This plugin hook allows additional magic parameters to be defined by plugins. \n             Magic parameters all take this format:  _prefix_rest_of_parameter . The prefix indicates which magic parameter function should be called - the rest of the parameter is passed as an argument to that function. \n             To register a new function, return it as a tuple of  (string prefix, function)  from this hook. The function you register should take two arguments:  key  and  request , where  key  is the  rest_of_parameter  portion of the parameter and  request  is the current  Request object . \n             This example registers two new magic parameters:  :_request_http_version  returning the HTTP version of the current request, and  :_uuid_new  which returns a new UUID. It also registers an  :_asynclookup_key  parameter, demonstrating that these functions can be asynchronous: \n             from datasette import hookimpl\nfrom uuid import uuid4\n\n\ndef uuid(key, request):\n    if key == \"new\":\n        return str(uuid4())\n    else:\n        raise KeyError\n\n\ndef request(key, request):\n    if key == \"http_version\":\n        return request.scope[\"http_version\"]\n    else:\n        raise KeyError\n\n\nasync def asynclookup(key, request):\n    return await do_something_async(key)\n\n\n@hookimpl\ndef register_magic_parameters(datasette):\n    return [\n        (\"request\", request),\n        (\"uuid\", uuid),\n        (\"asynclookup\", asynclookup),\n    ]", "breadcrumbs": "[\"Plugin hooks\"]", "references": "[]"}
{"id": "plugin_hooks:plugin-hook-top-canned-query", "page": "plugin_hooks", "ref": "plugin-hook-top-canned-query", "title": "top_canned_query(datasette, request, database, query_name)", "content": "datasette  -  Datasette class \n                         \n                             You can use this to access plugin configuration options via  datasette.plugin_config(your_plugin_name) . \n                         \n                     \n                     \n                         request  -  Request object \n                         \n                             The current HTTP request. \n                         \n                     \n                     \n                         database  - string \n                         \n                             The name of the database. \n                         \n                     \n                     \n                         query_name  - string \n                         \n                             The name of the canned query. \n                         \n                     \n                 \n                 Returns HTML to be displayed at the top of the canned query page.", "breadcrumbs": "[\"Plugin hooks\", \"Template slots\"]", "references": "[]"}
{"id": "plugin_hooks:plugin-hook-top-database", "page": "plugin_hooks", "ref": "plugin-hook-top-database", "title": "top_database(datasette, request, database)", "content": "datasette  -  Datasette class \n                         \n                             You can use this to access plugin configuration options via  datasette.plugin_config(your_plugin_name) . \n                         \n                     \n                     \n                         request  -  Request object \n                         \n                             The current HTTP request. \n                         \n                     \n                     \n                         database  - string \n                         \n                             The name of the database. \n                         \n                     \n                 \n                 Returns HTML to be displayed at the top of the database page.", "breadcrumbs": "[\"Plugin hooks\", \"Template slots\"]", "references": "[]"}
{"id": "plugin_hooks:plugin-hook-top-homepage", "page": "plugin_hooks", "ref": "plugin-hook-top-homepage", "title": "top_homepage(datasette, request)", "content": "datasette  -  Datasette class \n                         \n                             You can use this to access plugin configuration options via  datasette.plugin_config(your_plugin_name) . \n                         \n                     \n                     \n                         request  -  Request object \n                         \n                             The current HTTP request. \n                         \n                     \n                 \n                 Returns HTML to be displayed at the top of the Datasette homepage.", "breadcrumbs": "[\"Plugin hooks\", \"Template slots\"]", "references": "[]"}
{"id": "plugin_hooks:plugin-hook-top-query", "page": "plugin_hooks", "ref": "plugin-hook-top-query", "title": "top_query(datasette, request, database, sql)", "content": "datasette  -  Datasette class \n                         \n                             You can use this to access plugin configuration options via  datasette.plugin_config(your_plugin_name) . \n                         \n                     \n                     \n                         request  -  Request object \n                         \n                             The current HTTP request. \n                         \n                     \n                     \n                         database  - string \n                         \n                             The name of the database. \n                         \n                     \n                     \n                         sql  - string \n                         \n                             The SQL query. \n                         \n                     \n                 \n                 Returns HTML to be displayed at the top of the query results page.", "breadcrumbs": "[\"Plugin hooks\", \"Template slots\"]", "references": "[]"}
{"id": "plugin_hooks:plugin-hook-top-row", "page": "plugin_hooks", "ref": "plugin-hook-top-row", "title": "top_row(datasette, request, database, table, row)", "content": "datasette  -  Datasette class \n                         \n                             You can use this to access plugin configuration options via  datasette.plugin_config(your_plugin_name) . \n                         \n                     \n                     \n                         request  -  Request object \n                         \n                             The current HTTP request. \n                         \n                     \n                     \n                         database  - string \n                         \n                             The name of the database. \n                         \n                     \n                     \n                         table  - string \n                         \n                             The name of the table. \n                         \n                     \n                     \n                         row  -  sqlite.Row \n                         \n                             The SQLite row object being displayed. \n                         \n                     \n                 \n                 Returns HTML to be displayed at the top of the row page.", "breadcrumbs": "[\"Plugin hooks\", \"Template slots\"]", "references": "[]"}
{"id": "plugin_hooks:plugin-hook-top-table", "page": "plugin_hooks", "ref": "plugin-hook-top-table", "title": "top_table(datasette, request, database, table)", "content": "datasette  -  Datasette class \n                         \n                             You can use this to access plugin configuration options via  datasette.plugin_config(your_plugin_name) . \n                         \n                     \n                     \n                         request  -  Request object \n                         \n                             The current HTTP request. \n                         \n                     \n                     \n                         database  - string \n                         \n                             The name of the database. \n                         \n                     \n                     \n                         table  - string \n                         \n                             The name of the table. \n                         \n                     \n                 \n                 Returns HTML to be displayed at the top of the table page.", "breadcrumbs": "[\"Plugin hooks\", \"Template slots\"]", "references": "[]"}
{"id": "plugin_hooks:plugin-hook-view-actions", "page": "plugin_hooks", "ref": "plugin-hook-view-actions", "title": "view_actions(datasette, actor, database, view, request)", "content": "datasette  -  Datasette class \n                         \n                             You can use this to access plugin configuration options via  datasette.plugin_config(your_plugin_name) , or to execute SQL queries. \n                         \n                     \n                     \n                         actor  - dictionary or None \n                         \n                             The currently authenticated  actor . \n                         \n                     \n                     \n                         database  - string \n                         \n                             The name of the database. \n                         \n                     \n                     \n                         view  - string \n                         \n                             The name of the SQL view. \n                         \n                     \n                     \n                         request  -  Request object  or None \n                         \n                             The current HTTP request. This can be  None  if the request object is not available. \n                         \n                     \n                 \n                 Like  table_actions(datasette, actor, database, table, request)  but for SQL views.", "breadcrumbs": "[\"Plugin hooks\", \"Action hooks\"]", "references": "[]"}
{"id": "plugin_hooks:plugin-page-extras", "page": "plugin_hooks", "ref": "plugin-page-extras", "title": "Page extras", "content": "These plugin hooks can be used to affect the way HTML pages for different Datasette interfaces are rendered.", "breadcrumbs": "[\"Plugin hooks\"]", "references": "[]"}
{"id": "plugin_hooks:plugin-register-permissions", "page": "plugin_hooks", "ref": "plugin-register-permissions", "title": "register_permissions(datasette)", "content": "If your plugin needs to register additional permissions unique to that plugin -  upload-csvs  for example - you can return a list of those permissions from this hook. \n             from datasette import hookimpl, Permission\n\n\n@hookimpl\ndef register_permissions(datasette):\n    return [\n        Permission(\n            name=\"upload-csvs\",\n            abbr=None,\n            description=\"Upload CSV files\",\n            takes_database=True,\n            takes_resource=False,\n            default=False,\n        )\n    ] \n             The fields of the  Permission  class are as follows: \n             \n                 \n                     name  - string \n                     \n                         The name of the permission, e.g.  upload-csvs . This should be unique across all plugins that the user might have installed, so choose carefully. \n                     \n                 \n                 \n                     abbr  - string or None \n                     \n                         An abbreviation of the permission, e.g.  uc . This is optional - you can set it to  None  if you do not want to pick an abbreviation. Since this needs to be unique across all installed plugins it's best not to specify an abbreviation at all. If an abbreviation is provided it will be used when creating restricted signed API tokens. \n                     \n                 \n                 \n                     description  - string or None \n                     \n                         A human-readable description of what the permission lets you do. Should make sense as the second part of a sentence that starts \"A user with this permission can ...\". \n                     \n                 \n                 \n                     takes_database  - boolean \n                     \n                         True  if this permission can be granted on a per-database basis,  False  if it is only valid at the overall Datasette instance level. \n                     \n                 \n                 \n                     takes_resource  - boolean \n                     \n                         True  if this permission can be granted on a per-resource basis. A resource is a database table, SQL view or  canned query . \n                     \n                 \n                 \n                     default  - boolean \n                     \n                         The default value for this permission if it is not explicitly granted to a user.  True  means the permission is granted by default,  False  means it is not. \n                         This should only be  True  if you want anonymous users to be able to take this action.", "breadcrumbs": "[\"Plugin hooks\"]", "references": "[]"}
{"id": "plugins:deploying-plugins-using-datasette-publish", "page": "plugins", "ref": "deploying-plugins-using-datasette-publish", "title": "Deploying plugins using datasette publish", "content": "The  datasette publish  and  datasette package  commands both take an optional  --install  argument. You can use this one or more times to tell Datasette to  pip install  specific plugins as part of the process: \n                 datasette publish cloudrun mydb.db --install=datasette-vega \n                 You can use the name of a package on PyPI or any of the other valid arguments to  pip install  such as a URL to a  .zip  file: \n                 datasette publish cloudrun mydb.db \\\n    --install=https://url-to-my-package.zip", "breadcrumbs": "[\"Plugins\", \"Installing plugins\"]", "references": "[]"}
{"id": "plugins:one-off-plugins-using-plugins-dir", "page": "plugins", "ref": "one-off-plugins-using-plugins-dir", "title": "One-off plugins using --plugins-dir", "content": "You can also define one-off per-project plugins by saving them as  plugin_name.py  functions in a  plugins/  folder and then passing that folder to  datasette  using the  --plugins-dir  option: \n                 datasette mydb.db --plugins-dir=plugins/", "breadcrumbs": "[\"Plugins\", \"Installing plugins\"]", "references": "[]"}
{"id": "plugins:plugins-configuration", "page": "plugins", "ref": "plugins-configuration", "title": "Plugin configuration", "content": "Plugins can have their own configuration, embedded in a  configuration file . Configuration options for plugins live within a  \"plugins\"  key in that file, which can be included at the root, database or table level. \n             Here is an example of some plugin configuration for a specific table: \n             [[[cog\nfrom metadata_doc import config_example\nconfig_example(cog, {\n    \"databases\": {\n        \"sf-trees\": {\n            \"tables\": {\n                \"Street_Tree_List\": {\n                    \"plugins\": {\n                        \"datasette-cluster-map\": {\n                            \"latitude_column\": \"lat\",\n                            \"longitude_column\": \"lng\"\n                        }\n                    }\n                }\n            }\n        }\n    }\n}) \n             ]]] \n             [[[end]]] \n             This tells the  datasette-cluster-map  column which latitude and longitude columns should be used for a table called  Street_Tree_List  inside a database file called  sf-trees.db .", "breadcrumbs": "[\"Plugins\"]", "references": "[]"}
{"id": "plugins:plugins-configuration-secret", "page": "plugins", "ref": "plugins-configuration-secret", "title": "Secret configuration values", "content": "Some plugins may need configuration that should stay secret - API keys for example. There are two ways in which you can store secret configuration values. \n                 As environment variables . If your secret lives in an environment variable that is available to the Datasette process, you can indicate that the configuration value should be read from that environment variable like so: \n                 [[[cog\nconfig_example(cog, {\n    \"plugins\": {\n        \"datasette-auth-github\": {\n            \"client_secret\": {\n                \"$env\": \"GITHUB_CLIENT_SECRET\"\n            }\n        }\n    }\n}) \n                 ]]] \n                 [[[end]]] \n                 As values in separate files . Your secrets can also live in files on disk. To specify a secret should be read from a file, provide the full file path like this: \n                 [[[cog\nconfig_example(cog, {\n    \"plugins\": {\n        \"datasette-auth-github\": {\n            \"client_secret\": {\n                \"$file\": \"/secrets/client-secret\"\n            }\n        }\n    }\n}) \n                 ]]] \n                 [[[end]]] \n                 If you are publishing your data using the  datasette publish  family of commands, you can use the  --plugin-secret  option to set these secrets at publish time. For example, using Heroku you might run the following command: \n                 datasette publish heroku my_database.db \\\n    --name my-heroku-app-demo \\\n    --install=datasette-auth-github \\\n    --plugin-secret datasette-auth-github client_id your_client_id \\\n    --plugin-secret datasette-auth-github client_secret your_client_secret \n                 This will set the necessary environment variables and add the following to the deployed  metadata.yaml : \n                 [[[cog\nconfig_example(cog, {\n    \"plugins\": {\n        \"datasette-auth-github\": {\n            \"client_id\": {\n                \"$env\": \"DATASETTE_AUTH_GITHUB_CLIENT_ID\"\n            },\n            \"client_secret\": {\n                \"$env\": \"DATASETTE_AUTH_GITHUB_CLIENT_SECRET\"\n            }\n        }\n    }\n}) \n                 ]]] \n                 [[[end]]]", "breadcrumbs": "[\"Plugins\", \"Plugin configuration\"]", "references": "[]"}
{"id": "plugins:plugins-datasette-load-plugins", "page": "plugins", "ref": "plugins-datasette-load-plugins", "title": "Controlling which plugins are loaded", "content": "Datasette defaults to loading every plugin that is installed in the same virtual environment as Datasette itself. \n             You can set the  DATASETTE_LOAD_PLUGINS  environment variable to a comma-separated list of plugin names to load a controlled subset of plugins instead. \n             For example, to load just the  datasette-vega  and  datasette-cluster-map  plugins, set  DATASETTE_LOAD_PLUGINS  to  datasette-vega,datasette-cluster-map : \n             export DATASETTE_LOAD_PLUGINS='datasette-vega,datasette-cluster-map'\ndatasette mydb.db \n             Or: \n             DATASETTE_LOAD_PLUGINS='datasette-vega,datasette-cluster-map' \\\n  datasette mydb.db \n             To disable the loading of all additional plugins, set  DATASETTE_LOAD_PLUGINS  to an empty string: \n             export DATASETTE_LOAD_PLUGINS=''\ndatasette mydb.db \n             A quick way to test this setting is to use it with the  datasette plugins  command: \n             DATASETTE_LOAD_PLUGINS='datasette-vega' datasette plugins \n             This should output the following: \n             [\n    {\n        \"name\": \"datasette-vega\",\n        \"static\": true,\n        \"templates\": false,\n        \"version\": \"0.6.2\",\n        \"hooks\": [\n            \"extra_css_urls\",\n            \"extra_js_urls\"\n        ]\n    }\n]", "breadcrumbs": "[\"Plugins\"]", "references": "[]"}
{"id": "plugins:plugins-installing", "page": "plugins", "ref": "plugins-installing", "title": "Installing plugins", "content": "If a plugin has been packaged for distribution using setuptools you can use the plugin by installing it alongside Datasette in the same virtual environment or Docker container. \n             You can install plugins using the  datasette install  command: \n             datasette install datasette-vega \n             You can uninstall plugins with  datasette uninstall : \n             datasette uninstall datasette-vega \n             You can upgrade plugins with  datasette install --upgrade  or  datasette install -U : \n             datasette install -U datasette-vega \n             This command can also be used to upgrade Datasette itself to the latest released version: \n             datasette install -U datasette \n             You can install multiple plugins at once by listing them as lines in a  requirements.txt  file like this: \n             datasette-vega\ndatasette-cluster-map \n             Then pass that file to  datasette install -r : \n             datasette install -r requirements.txt \n             The  install  and  uninstall  commands are thin wrappers around  pip install  and  pip uninstall , which ensure that they run  pip  in the same virtual environment as Datasette itself.", "breadcrumbs": "[\"Plugins\"]", "references": "[]"}
{"id": "publish:publishing", "page": "publish", "ref": "publishing", "title": "Publishing data", "content": "Datasette includes tools for publishing and deploying your data to the internet. The  datasette publish  command will deploy a new Datasette instance containing your databases directly to a Heroku or Google Cloud hosting account. You can also use  datasette package  to create a Docker image that bundles your databases together with the datasette application that is used to serve them.", "breadcrumbs": "[]", "references": "[]"}
{"id": "settings:config-dir", "page": "settings", "ref": "config-dir", "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", "breadcrumbs": "[\"Settings\"]", "references": "[]"}
{"id": "settings:id1", "page": "settings", "ref": "id1", "title": "Settings", "content": "", "breadcrumbs": "[]", "references": "[]"}
{"id": "settings:id2", "page": "settings", "ref": "id2", "title": "Settings", "content": "The following options can be set using  --setting name value , or by storing them in the  settings.json  file for use with  Configuration directory mode .", "breadcrumbs": "[\"Settings\"]", "references": "[]"}
{"id": "settings:setting-allow-csv-stream", "page": "settings", "ref": "setting-allow-csv-stream", "title": "allow_csv_stream", "content": "Enables  the CSV export feature  where an entire table\n                    (potentially hundreds of thousands of rows) can be exported as a single CSV\n                    file. This is turned on by default - you can turn it off like this: \n                 datasette mydatabase.db --setting allow_csv_stream off", "breadcrumbs": "[\"Settings\", \"Settings\"]", "references": "[]"}
{"id": "settings:setting-allow-download", "page": "settings", "ref": "setting-allow-download", "title": "allow_download", "content": "Should users be able to download the original SQLite database using a link on the database index page? This is turned on by default. However, databases can only be downloaded if they are served in immutable mode and not in-memory. If downloading is unavailable for either of these reasons, the download link is hidden even if  allow_download  is on. To disable database downloads, use the following: \n                 datasette mydatabase.db --setting allow_download off", "breadcrumbs": "[\"Settings\", \"Settings\"]", "references": "[]"}
{"id": "settings:setting-allow-facet", "page": "settings", "ref": "setting-allow-facet", "title": "allow_facet", "content": "Allow users to specify columns they would like to facet on using the  ?_facet=COLNAME  URL parameter to the table view. \n                 This is enabled by default. If disabled, facets will still be displayed if they have been specifically enabled in  metadata.json  configuration for the table. \n                 Here's how to disable this feature: \n                 datasette mydatabase.db --setting allow_facet off", "breadcrumbs": "[\"Settings\", \"Settings\"]", "references": "[]"}
{"id": "settings:setting-allow-signed-tokens", "page": "settings", "ref": "setting-allow-signed-tokens", "title": "allow_signed_tokens", "content": "Should users be able to create signed API tokens to access Datasette? \n                 This is turned on by default. Use the following to turn it off: \n                 datasette mydatabase.db --setting allow_signed_tokens off \n                 Turning this setting off will disable the  /-/create-token  page,  described here . It will also cause any incoming  Authorization: Bearer dstok_...  API tokens to be ignored.", "breadcrumbs": "[\"Settings\", \"Settings\"]", "references": "[]"}
{"id": "settings:setting-base-url", "page": "settings", "ref": "setting-base-url", "title": "base_url", "content": "If you are running Datasette behind a proxy, it may be useful to change the root path used for the Datasette instance. \n                 For example, if you are sending traffic from  https://www.example.com/tools/datasette/  through to a proxied Datasette instance you may wish Datasette to use  /tools/datasette/  as its root URL. \n                 You can do that like so: \n                 datasette mydatabase.db --setting base_url /tools/datasette/", "breadcrumbs": "[\"Settings\", \"Settings\"]", "references": "[]"}
{"id": "settings:setting-default-allow-sql", "page": "settings", "ref": "setting-default-allow-sql", "title": "default_allow_sql", "content": "Should users be able to execute arbitrary SQL queries by default? \n                 Setting this to  off  causes permission checks for  execute-sql  to fail by default. \n                 datasette mydatabase.db --setting default_allow_sql off \n                 Another way to achieve this is to add  \"allow_sql\": false  to your  datasette.yaml  file, as described in  Controlling the ability to execute arbitrary SQL . This setting offers a more convenient way to do this.", "breadcrumbs": "[\"Settings\", \"Settings\"]", "references": "[]"}
{"id": "settings:setting-default-cache-ttl", "page": "settings", "ref": "setting-default-cache-ttl", "title": "default_cache_ttl", "content": "Default HTTP caching max-age header in seconds, used for  Cache-Control: max-age=X . Can be over-ridden on a per-request basis using the  ?_ttl=  query string parameter. Set this to  0  to disable HTTP caching entirely. Defaults to 5 seconds. \n                 datasette mydatabase.db --setting default_cache_ttl 60", "breadcrumbs": "[\"Settings\", \"Settings\"]", "references": "[]"}
{"id": "settings:setting-default-facet-size", "page": "settings", "ref": "setting-default-facet-size", "title": "default_facet_size", "content": "The default number of unique rows returned by  Facets  is 30. You can customize it like this: \n                 datasette mydatabase.db --setting default_facet_size 50", "breadcrumbs": "[\"Settings\", \"Settings\"]", "references": "[]"}
{"id": "settings:setting-default-page-size", "page": "settings", "ref": "setting-default-page-size", "title": "default_page_size", "content": "The default number of rows returned by the table page. You can over-ride this on a per-page basis using the  ?_size=80  query string parameter, provided you do not specify a value higher than the  max_returned_rows  setting. You can set this default using  --setting  like so: \n                 datasette mydatabase.db --setting default_page_size 50", "breadcrumbs": "[\"Settings\", \"Settings\"]", "references": "[]"}
{"id": "settings:setting-facet-suggest-time-limit-ms", "page": "settings", "ref": "setting-facet-suggest-time-limit-ms", "title": "facet_suggest_time_limit_ms", "content": "When Datasette calculates suggested facets it needs to run a SQL query for every column in your table. The default for this time limit is 50ms to account for the fact that it needs to run once for every column. If the time limit is exceeded the column will not be suggested as a facet. \n                 You can increase this time limit like so: \n                 datasette mydatabase.db --setting facet_suggest_time_limit_ms 500", "breadcrumbs": "[\"Settings\", \"Settings\"]", "references": "[]"}
{"id": "settings:setting-facet-time-limit-ms", "page": "settings", "ref": "setting-facet-time-limit-ms", "title": "facet_time_limit_ms", "content": "This is the time limit Datasette allows for calculating a facet, which defaults to 200ms: \n                 datasette mydatabase.db --setting facet_time_limit_ms 1000", "breadcrumbs": "[\"Settings\", \"Settings\"]", "references": "[]"}
{"id": "settings:setting-force-https-urls", "page": "settings", "ref": "setting-force-https-urls", "title": "force_https_urls", "content": "Forces self-referential URLs in the JSON output to always use the  https:// \n                    protocol. This is useful for cases where the application itself is hosted using\n                    HTTP but is served to the outside world via a proxy that enables HTTPS. \n                 datasette mydatabase.db --setting force_https_urls 1", "breadcrumbs": "[\"Settings\", \"Settings\"]", "references": "[]"}
{"id": "settings:setting-max-csv-mb", "page": "settings", "ref": "setting-max-csv-mb", "title": "max_csv_mb", "content": "The maximum size of CSV that can be exported, in megabytes. Defaults to 100MB.\n                    You can disable the limit entirely by settings this to 0: \n                 datasette mydatabase.db --setting max_csv_mb 0", "breadcrumbs": "[\"Settings\", \"Settings\"]", "references": "[]"}
{"id": "settings:setting-max-insert-rows", "page": "settings", "ref": "setting-max-insert-rows", "title": "max_insert_rows", "content": "Maximum rows that can be inserted at a time using the bulk insert API, see  Inserting rows . Defaults to 100. \n                 You can increase or decrease this limit like so: \n                 datasette mydatabase.db --setting max_insert_rows 1000", "breadcrumbs": "[\"Settings\", \"Settings\"]", "references": "[]"}
{"id": "settings:setting-max-returned-rows", "page": "settings", "ref": "setting-max-returned-rows", "title": "max_returned_rows", "content": "Datasette returns a maximum of 1,000 rows of data at a time. If you execute a query that returns more than 1,000 rows, Datasette will return the first 1,000 and include a warning that the result set has been truncated. You can use OFFSET/LIMIT or other methods in your SQL to implement pagination if you need to return more than 1,000 rows. \n                 You can increase or decrease this limit like so: \n                 datasette mydatabase.db --setting max_returned_rows 2000", "breadcrumbs": "[\"Settings\", \"Settings\"]", "references": "[]"}
{"id": "settings:setting-max-signed-tokens-ttl", "page": "settings", "ref": "setting-max-signed-tokens-ttl", "title": "max_signed_tokens_ttl", "content": "Maximum allowed expiry time for signed API tokens created by users. \n                 Defaults to  0  which means no limit - tokens can be created that will never expire. \n                 Set this to a value in seconds to limit the maximum expiry time. For example, to set that limit to 24 hours you would use: \n                 datasette mydatabase.db --setting max_signed_tokens_ttl 86400 \n                 This setting is enforced when incoming tokens are processed.", "breadcrumbs": "[\"Settings\", \"Settings\"]", "references": "[]"}
{"id": "settings:setting-publish-secrets", "page": "settings", "ref": "setting-publish-secrets", "title": "Using secrets with datasette publish", "content": "The  datasette publish  and  datasette package  commands both generate a secret for you automatically when Datasette is deployed. \n             This means that every time you deploy a new version of a Datasette project, a new secret will be generated. This will cause signed cookies to become invalid on every fresh deploy. \n             You can fix this by creating a secret that will be used for multiple deploys and passing it using the  --secret  option: \n             datasette publish cloudrun mydb.db --service=my-service --secret=cdb19e94283a20f9d42cca5", "breadcrumbs": "[\"Settings\"]", "references": "[]"}
{"id": "settings:setting-secret", "page": "settings", "ref": "setting-secret", "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 can make use of this signing mechanism in their plugins using the  datasette.sign()  and  datasette.unsign()  methods.", "breadcrumbs": "[\"Settings\"]", "references": "[]"}
{"id": "settings:setting-sql-time-limit-ms", "page": "settings", "ref": "setting-sql-time-limit-ms", "title": "sql_time_limit_ms", "content": "By default, queries have a time limit of one second. If a query takes longer than this to run Datasette will terminate the query and return an error. \n                 If this time limit is too short for you, you can customize it using the  sql_time_limit_ms  limit - for example, to increase it to 3.5 seconds: \n                 datasette mydatabase.db --setting sql_time_limit_ms 3500 \n                 You can optionally set a lower time limit for an individual query using the  ?_timelimit=100  query string argument: \n                 /my-database/my-table?qSpecies=44&_timelimit=100 \n                 This would set the time limit to 100ms for that specific query. This feature is useful if you are working with databases of unknown size and complexity - a query that might make perfect sense for a smaller table could take too long to execute on a table with millions of rows. By setting custom time limits you can execute queries \"optimistically\" - e.g. give me an exact count of rows matching this query but only if it takes less than 100ms to calculate.", "breadcrumbs": "[\"Settings\", \"Settings\"]", "references": "[]"}
{"id": "settings:setting-suggest-facets", "page": "settings", "ref": "setting-suggest-facets", "title": "suggest_facets", "content": "Should Datasette calculate suggested facets? On by default, turn this off like so: \n                 datasette mydatabase.db --setting suggest_facets off", "breadcrumbs": "[\"Settings\", \"Settings\"]", "references": "[]"}
{"id": "settings:setting-truncate-cells-html", "page": "settings", "ref": "setting-truncate-cells-html", "title": "truncate_cells_html", "content": "In the HTML table view, truncate any strings that are longer than this value.\n                    The full value will still be available in CSV, JSON and on the individual row\n                    HTML page. Set this to 0 to disable truncation. \n                 datasette mydatabase.db --setting truncate_cells_html 0", "breadcrumbs": "[\"Settings\", \"Settings\"]", "references": "[]"}
{"id": "settings:using-setting", "page": "settings", "ref": "using-setting", "title": "Using --setting", "content": "Datasette supports a number of settings. These can be set using the  --setting name value  option to  datasette serve . \n             You can set multiple settings at once like this: \n             datasette mydatabase.db \\\n  --setting default_page_size 50 \\\n  --setting sql_time_limit_ms 3500 \\\n  --setting max_returned_rows 2000 \n             Settings can also be specified  in the database.yaml configuration file .", "breadcrumbs": "[\"Settings\"]", "references": "[]"}
{"id": "spatialite:installing-spatialite-on-linux", "page": "spatialite", "ref": "installing-spatialite-on-linux", "title": "Installing SpatiaLite on Linux", "content": "SpatiaLite is packaged for most Linux distributions. \n                 apt install spatialite-bin libsqlite3-mod-spatialite \n                 Depending on your distribution, you should be able to run Datasette something like this: \n                 datasette --load-extension=/usr/lib/x86_64-linux-gnu/mod_spatialite.so \n                 If you are unsure of the location of the module, try running  locate mod_spatialite  and see what comes back.", "breadcrumbs": "[\"SpatiaLite\", \"Installation\"]", "references": "[]"}
{"id": "spatialite:querying-polygons-using-within", "page": "spatialite", "ref": "querying-polygons-using-within", "title": "Querying polygons using within()", "content": "The  within()  SQL function can be used to check if a point is within a geometry: \n             select\n    name\nfrom\n    places\nwhere\n   within(GeomFromText('POINT(-3.1724366 51.4704448)'), places.geom); \n             The  GeomFromText()  function takes a string of well-known text. Note that the order used here is  longitude  then   latitude . \n             To run that same  within()  query in a way that benefits from the spatial index, use the following: \n             select\n    name\nfrom\n    places\nwhere\n    within(GeomFromText('POINT(-3.1724366 51.4704448)'), places.geom)\n    and rowid in (\n        SELECT pkid FROM idx_places_geom\n        where xmin < -3.1724366\n        and xmax > -3.1724366\n        and ymin < 51.4704448\n        and ymax > 51.4704448\n    );", "breadcrumbs": "[\"SpatiaLite\"]", "references": "[]"}
{"id": "spatialite:spatial-indexing-latitude-longitude-columns", "page": "spatialite", "ref": "spatial-indexing-latitude-longitude-columns", "title": "Spatial indexing latitude/longitude columns", "content": "Here's a recipe for taking a table with existing latitude and longitude columns, adding a SpatiaLite POINT geometry column to that table, populating the new column and then populating a spatial index: \n             import sqlite3\n\nconn = sqlite3.connect(\"museums.db\")\n# Lead the spatialite extension:\nconn.enable_load_extension(True)\nconn.load_extension(\"/usr/local/lib/mod_spatialite.dylib\")\n# Initialize spatial metadata for this database:\nconn.execute(\"select InitSpatialMetadata(1)\")\n# Add a geometry column called point_geom to our museums table:\nconn.execute(\n    \"SELECT AddGeometryColumn('museums', 'point_geom', 4326, 'POINT', 2);\"\n)\n# Now update that geometry column with the lat/lon points\nconn.execute(\n    \"\"\"\n    UPDATE museums SET\n    point_geom = GeomFromText('POINT('||\"longitude\"||' '||\"latitude\"||')',4326);\n\"\"\"\n)\n# Now add a spatial index to that column\nconn.execute(\n    'select CreateSpatialIndex(\"museums\", \"point_geom\");'\n)\n# If you don't commit your changes will not be persisted:\nconn.commit()\nconn.close()", "breadcrumbs": "[\"SpatiaLite\"]", "references": "[]"}
{"id": "spatialite:spatialite-installation", "page": "spatialite", "ref": "spatialite-installation", "title": "Installation", "content": "", "breadcrumbs": "[\"SpatiaLite\"]", "references": "[]"}
{"id": "sql_queries:canned-queries-json-api", "page": "sql_queries", "ref": "canned-queries-json-api", "title": "JSON API for writable canned queries", "content": "Writable canned queries can also be accessed using a JSON API. You can POST data to them using JSON, and you can request that their response is returned to you as JSON. \n                 To submit JSON to a writable canned query, encode key/value parameters as a JSON document: \n                 POST /mydatabase/add_message\n\n{\"message\": \"Message goes here\"} \n                 You can also continue to submit data using regular form encoding, like so: \n                 POST /mydatabase/add_message\n\nmessage=Message+goes+here \n                 There are three options for specifying that you would like the response to your request to return JSON data, as opposed to an HTTP redirect to another page. \n                 \n                     \n                         Set an  Accept: application/json  header on your request \n                     \n                     \n                         Include  ?_json=1  in the URL that you POST to \n                     \n                     \n                         Include  \"_json\": 1  in your JSON body, or  &_json=1  in your form encoded body \n                     \n                 \n                 The JSON response will look like this: \n                 {\n    \"ok\": true,\n    \"message\": \"Query executed, 1 row affected\",\n    \"redirect\": \"/data/add_name\"\n} \n                 The  \"message\"  and  \"redirect\"  values here will take into account  on_success_message ,  on_success_message_sql ,   on_success_redirect ,  on_error_message  and  on_error_redirect , if they have been set.", "breadcrumbs": "[\"Running SQL queries\", \"Canned queries\"]", "references": "[]"}
{"id": "sql_queries:canned-queries-magic-parameters", "page": "sql_queries", "ref": "canned-queries-magic-parameters", "title": "Magic parameters", "content": "Named parameters that start with an underscore are special: they can be used to automatically add values created by Datasette that are not contained in the incoming form fields or query string. \n                 These magic parameters are only supported for canned queries: to avoid security issues (such as queries that extract the user's private cookies) they are not available to SQL that is executed by the user as a custom SQL query. \n                 Available magic parameters are: \n                 \n                     \n                         _actor_*  - e.g.  _actor_id ,  _actor_name \n                         \n                             Fields from the currently authenticated  Actors . \n                         \n                     \n                     \n                         _header_*  - e.g.  _header_user_agent \n                         \n                             Header from the incoming HTTP request. The key should be in lower case and with hyphens converted to underscores e.g.  _header_user_agent  or  _header_accept_language . \n                         \n                     \n                     \n                         _cookie_*  - e.g.  _cookie_lang \n                         \n                             The value of the incoming cookie of that name. \n                         \n                     \n                     \n                         _now_epoch \n                         \n                             The number of seconds since the Unix epoch. \n                         \n                     \n                     \n                         _now_date_utc \n                         \n                             The date in UTC, e.g.  2020-06-01 \n                         \n                     \n                     \n                         _now_datetime_utc \n                         \n                             The ISO 8601 datetime in UTC, e.g.  2020-06-24T18:01:07Z \n                         \n                     \n                     \n                         _random_chars_*  - e.g.  _random_chars_128 \n                         \n                             A random string of characters of the specified length. \n                         \n                     \n                 \n                 Here's an example configuration that adds a message from the authenticated user, storing various pieces of additional metadata using magic parameters: \n                 [[[cog\nconfig_example(cog, \"\"\"\ndatabases:\n  mydatabase:\n    queries:\n      add_message:\n        allow:\n          id: \"*\"\n        sql: |-\n          INSERT INTO messages (\n            user_id, message, datetime\n          ) VALUES (\n            :_actor_id, :message, :_now_datetime_utc\n          )\n        write: true\n\"\"\") \n                 ]]] \n                 [[[end]]] \n                 The form presented at  /mydatabase/add_message  will have just a field for  message  - the other parameters will be populated by the magic parameter mechanism. \n                 Additional custom magic parameters can be added by plugins using the  register_magic_parameters(datasette)  hook.", "breadcrumbs": "[\"Running SQL queries\", \"Canned queries\"]", "references": "[]"}
{"id": "sql_queries:canned-queries-options", "page": "sql_queries", "ref": "canned-queries-options", "title": "Additional canned query options", "content": "Additional options can be specified for canned queries in the YAML or JSON configuration.", "breadcrumbs": "[\"Running SQL queries\", \"Canned queries\"]", "references": "[]"}
{"id": "sql_queries:canned-queries-writable", "page": "sql_queries", "ref": "canned-queries-writable", "title": "Writable canned queries", "content": "Canned queries by default are read-only. You can use the  \"write\": true  key to indicate that a canned query can write to the database. \n                 See  Access to specific canned queries  for details on how to add permission checks to canned queries, using the  \"allow\"  key. \n                 [[[cog\nconfig_example(cog, {\n    \"databases\": {\n        \"mydatabase\": {\n            \"queries\": {\n                \"add_name\": {\n                    \"sql\": \"INSERT INTO names (name) VALUES (:name)\",\n                    \"write\": True\n                }\n            }\n        }\n    }\n}) \n                 ]]] \n                 [[[end]]] \n                 This configuration will create a page at  /mydatabase/add_name  displaying a form with a  name  field. Submitting that form will execute the configured  INSERT  query. \n                 You can customize how Datasette represents success and errors using the following optional properties: \n                 \n                     \n                         on_success_message  - the message shown when a query is successful \n                     \n                     \n                         on_success_message_sql  - alternative to  on_success_message : a SQL query that should be executed to generate the message \n                     \n                     \n                         on_success_redirect  - the path or URL the user is redirected to on success \n                     \n                     \n                         on_error_message  - the message shown when a query throws an error \n                     \n                     \n                         on_error_redirect  - the path or URL the user is redirected to on error \n                     \n                 \n                 For example: \n                 [[[cog\nconfig_example(cog, {\n    \"databases\": {\n        \"mydatabase\": {\n            \"queries\": {\n                \"add_name\": {\n                    \"sql\": \"INSERT INTO names (name) VALUES (:name)\",\n                    \"params\": [\"name\"],\n                    \"write\": True,\n                    \"on_success_message_sql\": \"select 'Name inserted: ' || :name\",\n                    \"on_success_redirect\": \"/mydatabase/names\",\n                    \"on_error_message\": \"Name insert failed\",\n                    \"on_error_redirect\": \"/mydatabase\",\n                }\n            }\n        }\n    }\n}) \n                 ]]] \n                 [[[end]]] \n                 You can use  \"params\"  to explicitly list the named parameters that should be displayed as form fields - otherwise they will be automatically detected.  \"params\"  is not necessary in the above example, since without it  \"name\"  would be automatically detected from the query. \n                 You can pre-populate form fields when the page first loads using a query string, e.g.  /mydatabase/add_name?name=Prepopulated . The user will have to submit the form to execute the query. \n                 If you specify a query in  \"on_success_message_sql\" , that query will be executed after the main query. The first column of the first row return by that query will be displayed as a success message. Named parameters from the main query will be made available to the success message query as well.", "breadcrumbs": "[\"Running SQL queries\", \"Canned queries\"]", "references": "[]"}
{"id": "sql_queries:hide-sql", "page": "sql_queries", "ref": "hide-sql", "title": "hide_sql", "content": "Canned queries default to displaying their SQL query at the top of the page. If the query is extremely long you may want to hide it by default, with a \"show\" link that can be used to make it visible. \n                     Add the  \"hide_sql\": true  option to hide the SQL query by default.", "breadcrumbs": "[\"Running SQL queries\", \"Canned queries\", \"Additional canned query options\"]", "references": "[]"}
{"id": "sql_queries:id1", "page": "sql_queries", "ref": "id1", "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).", "breadcrumbs": "[\"Running SQL queries\"]", "references": "[]"}
{"id": "sql_queries:id2", "page": "sql_queries", "ref": "id2", "title": "Pagination", "content": "Datasette's default table pagination is designed to be extremely efficient. SQL OFFSET/LIMIT pagination can have a significant performance penalty once you get into multiple thousands of rows, as each page still requires the database to scan through every preceding row to find the correct offset. \n             When paginating through tables, Datasette instead orders the rows in the table by their primary key and performs a WHERE clause against the last seen primary key for the previous page. For example: \n             select rowid, * from Tree_List where rowid > 200 order by rowid limit 101 \n             This represents page three for this particular table, with a page size of 100. \n             Note that we request 101 items in the limit clause rather than 100. This allows us to detect if we are on the last page of the results: if the query returns less than 101 rows we know we have reached the end of the pagination set. Datasette will only return the first 100 rows - the 101st is used purely to detect if there should be another page. \n             Since the where clause acts against the index on the primary key, the query is extremely fast even for records that are a long way into the overall pagination set.", "breadcrumbs": "[\"Running SQL queries\"]", "references": "[]"}
{"id": "sql_queries:sql", "page": "sql_queries", "ref": "sql", "title": "Running SQL queries", "content": "Datasette treats SQLite database files as read-only and immutable. This means it is not possible to execute INSERT or UPDATE statements using Datasette, which allows us to expose SELECT statements to the outside world without needing to worry about SQL injection attacks. \n         The easiest way to execute custom SQL against Datasette is through the web UI. The database index page includes a SQL editor that lets you run any SELECT query you like. You can also construct queries using the filter interface on the tables page, then click \"View and edit SQL\" to open that query in the custom SQL editor. \n         Note that this interface is only available if the  execute-sql  permission is allowed. See  Controlling the ability to execute arbitrary SQL . \n         Any Datasette SQL query is reflected in the URL of the page, allowing you to bookmark them, share them with others and navigate through previous queries using your browser back button. \n         You can also retrieve the results of any query as JSON by adding  .json  to the base URL.", "breadcrumbs": "[]", "references": "[]"}
{"id": "testing_plugins:testing-plugins-datasette-test-instance", "page": "testing_plugins", "ref": "testing-plugins-datasette-test-instance", "title": "Setting up a Datasette test instance", "content": "The above example shows the easiest way to start writing tests against a Datasette instance: \n             from datasette.app import Datasette\nimport pytest\n\n\n@pytest.mark.asyncio\nasync def test_plugin_is_installed():\n    datasette = Datasette(memory=True)\n    response = await datasette.client.get(\"/-/plugins.json\")\n    assert response.status_code == 200 \n             Creating a  Datasette()  instance like this as useful shortcut in tests, but there is one detail you need to be aware of. It's important to ensure that the async method  .invoke_startup()  is called on that instance. You can do that like this: \n             datasette = Datasette(memory=True)\nawait datasette.invoke_startup() \n             This method registers any  startup(datasette)  or  prepare_jinja2_environment(env, datasette)  plugins that might themselves need to make async calls. \n             If you are using  await datasette.client.get()  and similar methods then you don't need to worry about this - Datasette automatically calls  invoke_startup()  the first time it handles a request.", "breadcrumbs": "[\"Testing plugins\"]", "references": "[]"}
{"id": "testing_plugins:testing-plugins-pdb", "page": "testing_plugins", "ref": "testing-plugins-pdb", "title": "Using pdb for errors thrown inside Datasette", "content": "If an exception occurs within Datasette itself during a test, the response returned to your plugin will have a  response.status_code  value of 500. \n             You can add  pdb=True  to the  Datasette  constructor to drop into a Python debugger session inside your test run instead of getting back a 500 response code. This is equivalent to running the  datasette  command-line tool with the  --pdb  option. \n             Here's what that looks like in a test function: \n             def test_that_opens_the_debugger_or_errors():\n    ds = Datasette([db_path], pdb=True)\n    response = await ds.client.get(\"/\") \n             If you use this pattern you will need to run  pytest  with the  -s  option to avoid capturing stdin/stdout in order to interact with the debugger prompt.", "breadcrumbs": "[\"Testing plugins\"]", "references": "[]"}
{"id": "testing_plugins:testing-plugins-register-in-test", "page": "testing_plugins", "ref": "testing-plugins-register-in-test", "title": "Registering a plugin for the duration of a test", "content": "When writing tests for plugins you may find it useful to register a test plugin just for the duration of a single test. You can do this using  pm.register()  and  pm.unregister()  like this: \n             from datasette import hookimpl\nfrom datasette.app import Datasette\nfrom datasette.plugins import pm\nimport pytest\n\n\n@pytest.mark.asyncio\nasync def test_using_test_plugin():\n    class TestPlugin:\n        __name__ = \"TestPlugin\"\n\n        # Use hookimpl and method names to register hooks\n        @hookimpl\n        def register_routes(self):\n            return [\n                (r\"^/error$\", lambda: 1 / 0),\n            ]\n\n    pm.register(TestPlugin(), name=\"undo\")\n    try:\n        # The test implementation goes here\n        datasette = Datasette()\n        response = await datasette.client.get(\"/error\")\n        assert response.status_code == 500\n    finally:\n        pm.unregister(name=\"undo\") \n             To reuse the same temporary plugin in multiple tests, you can register it inside a fixture in your  conftest.py  file like this: \n             from datasette import hookimpl\nfrom datasette.app import Datasette\nfrom datasette.plugins import pm\nimport pytest\nimport pytest_asyncio\n\n\n@pytest_asyncio.fixture\nasync def datasette_with_plugin():\n    class TestPlugin:\n        __name__ = \"TestPlugin\"\n\n        @hookimpl\n        def register_routes(self):\n            return [\n                (r\"^/error$\", lambda: 1 / 0),\n            ]\n\n    pm.register(TestPlugin(), name=\"undo\")\n    try:\n        yield Datasette()\n    finally:\n        pm.unregister(name=\"undo\")\n \n             Note the  yield  statement here - this ensures that the  finally:  block that unregisters the plugin is executed only after the test function itself has completed. \n             Then in a test: \n             @pytest.mark.asyncio\nasync def test_error(datasette_with_plugin):\n    response = await datasette_with_plugin.client.get(\"/error\")\n    assert response.status_code == 500", "breadcrumbs": "[\"Testing plugins\"]", "references": "[]"}
{"id": "upgrade_guide:id1", "page": "upgrade_guide", "ref": "id1", "title": "Upgrade guide", "content": "", "breadcrumbs": "[]", "references": "[]"}
{"id": "upgrade_guide:metadata-fallback-has-been-removed", "page": "upgrade_guide", "ref": "metadata-fallback-has-been-removed", "title": "Metadata \"fallback\" has been removed", "content": "Certain keys in metadata like  license  used to \"fallback\" up the chain of ownership.\n                        For example, if you set an  MIT  to a database and a table within that database did not have a specified license, then that table would inherit an  MIT  license. \n                     This behavior has been removed in Datasette 1.0. Now license fields must be placed on all items, including individual databases and tables.", "breadcrumbs": "[\"Upgrade guide\", \"Datasette 0.X -> 1.0\", \"Metadata changes\"]", "references": "[]"}
{"id": "upgrade_guide:upgrade-guide-v1", "page": "upgrade_guide", "ref": "upgrade-guide-v1", "title": "Datasette 0.X -> 1.0", "content": "This section reviews breaking changes Datasette  1.0  has when upgrading from a  0.XX  version. For new features that  1.0  offers, see the  Changelog .", "breadcrumbs": "[\"Upgrade guide\"]", "references": "[]"}
{"id": "upgrade_guide:upgrade-guide-v1-metadata", "page": "upgrade_guide", "ref": "upgrade-guide-v1-metadata", "title": "Metadata changes", "content": "Metadata was completely revamped for Datasette 1.0.  There are a number of related breaking changes, from the  metadata.yaml  file to Python APIs, that you'll need to consider when upgrading.", "breadcrumbs": "[\"Upgrade guide\", \"Datasette 0.X -> 1.0\"]", "references": "[]"}
{"id": "upgrade_guide:upgrade-guide-v1-metadata-json-removed", "page": "upgrade_guide", "ref": "upgrade-guide-v1-metadata-json-removed", "title": "The ", "content": "As of Datasette  1.0a14 , the root level  /metadata.json  endpoint has been removed. Metadata for tables will become available through currently in-development extras in a future alpha.", "breadcrumbs": "[\"Upgrade guide\", \"Datasette 0.X -> 1.0\", \"Metadata changes\"]", "references": "[]"}
{"id": "upgrade_guide:upgrade-guide-v1-metadata-method-removed", "page": "upgrade_guide", "ref": "upgrade-guide-v1-metadata-method-removed", "title": "The ", "content": "As of Datasette  1.0a14 , the  .metadata()  method on the Datasette Python API has been removed. \n                     Instead, one should use the following methods on a Datasette class: \n                     \n                         \n                             get_instance_metadata() \n                         \n                         \n                             get_database_metadata() \n                         \n                         \n                             get_resource_metadata() \n                         \n                         \n                             get_column_metadata()", "breadcrumbs": "[\"Upgrade guide\", \"Datasette 0.X -> 1.0\", \"Metadata changes\"]", "references": "[]"}
{"id": "upgrade_guide:upgrade-guide-v1-metadata-removed", "page": "upgrade_guide", "ref": "upgrade-guide-v1-metadata-removed", "title": "The ", "content": "In Datasette  0.x  plugins could implement a  get_metadata()  plugin hook to customize how metadata was retrieved for different instances, databases and tables. \n                     This hook could be inefficient, since some pages might load metadata for many different items (to list a large number of tables, for example) which could result in a large number of calls to potentially expensive plugin hook implementations. \n                     As of Datasette  1.0a14  (2024-08-05), the  get_metadata()  hook has been deprecated: \n                     # \u274c DEPRECATED in Datasette 1.0\n@hookimpl\ndef get_metadata(datasette, key, database, table):\n    pass \n                     Instead, plugins are encouraged to interact directly with Datasette's in-memory metadata tables in SQLite using the following methods on the  Datasette class : \n                     \n                         \n                             get_instance_metadata()  and   set_instance_metadata() \n                         \n                         \n                             get_database_metadata()  and   set_database_metadata() \n                         \n                         \n                             get_resource_metadata()  and   set_resource_metadata() \n                         \n                         \n                             get_column_metadata()  and   set_column_metadata() \n                         \n                     \n                     A plugin that stores or calculates its own metadata can implement the  startup(datasette)  hook to populate those items on startup, and then call those methods while it is running to persist any new metadata changes.", "breadcrumbs": "[\"Upgrade guide\", \"Datasette 0.X -> 1.0\", \"Metadata changes\"]", "references": "[]"}
{"id": "upgrade_guide:upgrade-guide-v1-metadata-split", "page": "upgrade_guide", "ref": "upgrade-guide-v1-metadata-split", "title": null, "content": "Before Datasette 1.0, the  metadata.yaml  file became a kitchen sink if a mix of metadata, configuration, and settings. Now  metadata.yaml  is strictly for metaata (ex title and descriptions of database and tables, licensing info, etc). Other settings have been moved to a  datasette.yml  configuration file, described in  Configuration . \n                     To start Datasette with both metadata and configuration files, run it like this: \n                     datasette --metadata metadata.yaml --config datasette.yaml\n# Or the shortened version:\ndatasette -m metadata.yml -c datasette.yml", "breadcrumbs": "[\"Upgrade guide\", \"Datasette 0.X -> 1.0\", \"Metadata changes\"]", "references": "[]"}
{"id": "upgrade_guide:upgrade-guide-v1-sql-queries", "page": "upgrade_guide", "ref": "upgrade-guide-v1-sql-queries", "title": "New URL for SQL queries", "content": "Prior to  1.0a14  the URL for executing a SQL query looked like this: \n                 /databasename?sql=select+1\n# Or for JSON:\n/databasename.json?sql=select+1 \n                 This endpoint served two purposes: without a  ?sql=  it would list the tables in the database, but with that option it would return results of a query instead. \n                 The URL for executing a SQL query now looks like this: \n                 /databasename/-/query?sql=select+1\n# Or for JSON:\n/databasename/-/query.json?sql=select+1 \n                 This isn't a breaking change.  API calls to the older  /databasename?sql=...  endpoint will redirect to the new  databasename/-/query?sql=...  endpoint. Upgrading to the new URL is recommended to avoid the overhead of the additional redirect.", "breadcrumbs": "[\"Upgrade guide\", \"Datasette 0.X -> 1.0\"]", "references": "[]"}
{"id": "writing_plugins:writing-plugins-building-urls", "page": "writing_plugins", "ref": "writing-plugins-building-urls", "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.", "breadcrumbs": "[\"Writing plugins\"]", "references": "[]"}
{"id": "writing_plugins:writing-plugins-configuration", "page": "writing_plugins", "ref": "writing-plugins-configuration", "title": "Writing plugins that accept configuration", "content": "When you are writing plugins, you can access plugin configuration like this using the  datasette plugin_config()  method. If you know you need plugin configuration for a specific table, you can access it like this: \n             plugin_config = datasette.plugin_config(\n    \"datasette-cluster-map\", database=\"sf-trees\", table=\"Street_Tree_List\"\n) \n             This will return the  {\"latitude_column\": \"lat\", \"longitude_column\": \"lng\"}  in the above example. \n             If there is no configuration for that plugin, the method will return  None . \n             If it cannot find the requested configuration at the table layer, it will fall back to the database layer and then the root layer. For example, a user may have set the plugin configuration option inside  datasette.yaml  like so: \n             [[[cog\nfrom metadata_doc import metadata_example\nmetadata_example(cog, {\n    \"databases\": {\n        \"sf-trees\": {\n            \"plugins\": {\n                \"datasette-cluster-map\": {\n                    \"latitude_column\": \"xlat\",\n                    \"longitude_column\": \"xlng\"\n                }\n            }\n        }\n    }\n}) \n             ]]] \n             [[[end]]] \n             In this case, the above code would return that configuration for ANY table within the  sf-trees  database. \n             The plugin configuration could also be set at the top level of  datasette.yaml : \n             [[[cog\nmetadata_example(cog, {\n    \"plugins\": {\n        \"datasette-cluster-map\": {\n            \"latitude_column\": \"xlat\",\n            \"longitude_column\": \"xlng\"\n        }\n    }\n}) \n             ]]] \n             [[[end]]] \n             Now that  datasette-cluster-map  plugin configuration will apply to every table in every database.", "breadcrumbs": "[\"Writing plugins\"]", "references": "[]"}
{"id": "writing_plugins:writing-plugins-tracing", "page": "writing_plugins", "ref": "writing-plugins-tracing", "title": "Tracing plugin hooks", "content": "The  DATASETTE_TRACE_PLUGINS  environment variable turns on detailed tracing showing exactly which hooks are being run. This can be useful for understanding how Datasette is using your plugin. \n             DATASETTE_TRACE_PLUGINS=1 datasette mydb.db \n             Example output: \n             actor_from_request:\n{   'datasette': <datasette.app.Datasette object at 0x100bc7220>,\n    'request': <asgi.Request method=\"GET\" url=\"http://127.0.0.1:4433/\">}\nHook implementations:\n[   <HookImpl plugin_name='codespaces', plugin=<module 'datasette_codespaces' from '.../site-packages/datasette_codespaces/__init__.py'>>,\n    <HookImpl plugin_name='datasette.actor_auth_cookie', plugin=<module 'datasette.actor_auth_cookie' from '.../datasette/datasette/actor_auth_cookie.py'>>,\n    <HookImpl plugin_name='datasette.default_permissions', plugin=<module 'datasette.default_permissions' from '.../datasette/default_permissions.py'>>]\nResults:\n[{'id': 'root'}]", "breadcrumbs": "[\"Writing plugins\"]", "references": "[]"}
{"id": "installation:installing-plugins", "page": "installation", "ref": "installing-plugins", "title": "Installing plugins", "content": "If you want to install plugins into your local Datasette Docker image you can do\n                        so using the following recipe. This will install the plugins and then save a\n                        brand new local image called  datasette-with-plugins : \n                     docker run datasetteproject/datasette \\\n    pip install datasette-vega\n\ndocker commit $(docker ps -lq) datasette-with-plugins \n                     You can now run the new custom image like so: \n                     docker run -p 8001:8001 -v `pwd`:/mnt \\\n    datasette-with-plugins \\\n    datasette -p 8001 -h 0.0.0.0 /mnt/fixtures.db \n                     You can confirm that the plugins are installed by visiting\n                         http://127.0.0.1:8001/-/plugins \n                     Some plugins such as  datasette-ripgrep  may need additional system packages. You can install these by running  apt-get install  inside the container: \n                     docker run datasette-057a0 bash -c '\n    apt-get update &&\n    apt-get install ripgrep &&\n    pip install datasette-ripgrep'\n\ndocker commit $(docker ps -lq) datasette-with-ripgrep", "breadcrumbs": "[\"Installation\", \"Advanced installation options\", \"Using Docker\"]", "references": "[{\"href\": \"http://127.0.0.1:8001/-/plugins\", \"label\": \"http://127.0.0.1:8001/-/plugins\"}, {\"href\": \"https://datasette.io/plugins/datasette-ripgrep\", \"label\": \"datasette-ripgrep\"}]"}
{"id": "installation:loading-spatialite", "page": "installation", "ref": "loading-spatialite", "title": "Loading SpatiaLite", "content": "The  datasetteproject/datasette  image includes a recent version of the\n                         SpatiaLite extension  for SQLite. To load and enable that\n                        module, use the following command: \n                     docker run -p 8001:8001 -v `pwd`:/mnt \\\n    datasetteproject/datasette \\\n    datasette -p 8001 -h 0.0.0.0 /mnt/fixtures.db \\\n    --load-extension=spatialite \n                     You can confirm that SpatiaLite is successfully loaded by visiting\n                         http://127.0.0.1:8001/-/versions", "breadcrumbs": "[\"Installation\", \"Advanced installation options\", \"Using Docker\"]", "references": "[{\"href\": \"http://127.0.0.1:8001/-/versions\", \"label\": \"http://127.0.0.1:8001/-/versions\"}]"}
{"id": "plugin_hooks:plugin-hook-prepare-jinja2-environment", "page": "plugin_hooks", "ref": "plugin-hook-prepare-jinja2-environment", "title": "prepare_jinja2_environment(env, datasette)", "content": "env  - jinja2 Environment \n                     \n                         The template environment that is being prepared \n                     \n                 \n                 \n                     datasette  -  Datasette class \n                     \n                         You can use this to access plugin configuration options via  datasette.plugin_config(your_plugin_name) \n                     \n                 \n             \n             This hook is called with the Jinja2 environment that is used to evaluate\n                Datasette HTML templates. You can use it to do things like  register custom\n                    template filters , for\n                example: \n             from datasette import hookimpl\n\n\n@hookimpl\ndef prepare_jinja2_environment(env):\n    env.filters[\"uppercase\"] = lambda u: u.upper() \n             You can now use this filter in your custom templates like so: \n             Table name: {{ table|uppercase }} \n             This function can return an awaitable function if it needs to run any async code. \n             Examples:  datasette-edit-templates", "breadcrumbs": "[\"Plugin hooks\"]", "references": "[{\"href\": \"http://jinja.pocoo.org/docs/2.10/api/#custom-filters\", \"label\": \"register custom\\n                    template filters\"}, {\"href\": \"https://datasette.io/plugins/datasette-edit-templates\", \"label\": \"datasette-edit-templates\"}]"}
{"id": "getting_started:getting-started-your-computer", "page": "getting_started", "ref": "getting-started-your-computer", "title": "Using Datasette on your own computer", "content": "First, follow the  Installation  instructions. Now you can run Datasette against a SQLite file on your computer using the following command: \n             datasette path/to/database.db \n             This will start a web server on port 8001 - visit  http://localhost:8001/ \n                to access the web interface. \n             Add  -o  to open your browser automatically once Datasette has started: \n             datasette path/to/database.db -o \n             Use Chrome on OS X? You can run datasette against your browser history\n                like so: \n             datasette ~/Library/Application\\ Support/Google/Chrome/Default/History --nolock \n             The  --nolock  option ignores any file locks. This is safe as Datasette will open the file in read-only mode. \n             Now visiting  http://localhost:8001/History/downloads  will show you a web\n                interface to browse your downloads data: \n             \n                 \n             \n             http://localhost:8001/History/downloads.json  will return that data as\n                JSON: \n             {\n    \"database\": \"History\",\n    \"columns\": [\n        \"id\",\n        \"current_path\",\n        \"target_path\",\n        \"start_time\",\n        \"received_bytes\",\n        \"total_bytes\",\n        ...\n    ],\n    \"rows\": [\n        [\n            1,\n            \"/Users/simonw/Downloads/DropboxInstaller.dmg\",\n            \"/Users/simonw/Downloads/DropboxInstaller.dmg\",\n            13097290269022132,\n            626688,\n            0,\n            ...\n        ]\n    ]\n} \n             http://localhost:8001/History/downloads.json?_shape=objects  will return that data as\n                JSON in a more convenient format: \n             {\n    ...\n    \"rows\": [\n        {\n            \"start_time\": 13097290269022132,\n            \"interrupt_reason\": 0,\n            \"hash\": \"\",\n            \"id\": 1,\n            \"site_url\": \"\",\n            \"referrer\": \"https://www.dropbox.com/downloading?src=index\",\n            ...\n        }\n    ]\n}", "breadcrumbs": "[\"Getting started\"]", "references": "[{\"href\": \"http://localhost:8001/\", \"label\": \"http://localhost:8001/\"}, {\"href\": \"http://localhost:8001/History/downloads\", \"label\": \"http://localhost:8001/History/downloads\"}, {\"href\": \"http://localhost:8001/History/downloads.json\", \"label\": \"http://localhost:8001/History/downloads.json\"}, {\"href\": \"http://localhost:8001/History/downloads.json?_shape=objects\", \"label\": \"http://localhost:8001/History/downloads.json?_shape=objects\"}]"}
{"id": "writing_plugins:writing-plugins-one-off", "page": "writing_plugins", "ref": "writing-plugins-one-off", "title": "Writing one-off plugins", "content": "The quickest way to start writing a plugin is to create a  my_plugin.py  file and drop it into your  plugins/  directory. Here is an example plugin, which adds a new custom SQL function called  hello_world()  which takes no arguments and returns the string  Hello world! . \n             from datasette import hookimpl\n\n\n@hookimpl\ndef prepare_connection(conn):\n    conn.create_function(\n        \"hello_world\", 0, lambda: \"Hello world!\"\n    ) \n             If you save this in  plugins/my_plugin.py  you can then start Datasette like this: \n             datasette serve mydb.db --plugins-dir=plugins/ \n             Now you can navigate to  http://localhost:8001/mydb  and run this SQL: \n             select hello_world(); \n             To see the output of your plugin.", "breadcrumbs": "[\"Writing plugins\"]", "references": "[{\"href\": \"http://localhost:8001/mydb\", \"label\": \"http://localhost:8001/mydb\"}]"}
{"id": "changelog:id92", "page": "changelog", "ref": "id92", "title": "0.27 (2019-01-31)", "content": "New command:  datasette plugins  ( documentation ) shows you the currently installed list of plugins. \n                 \n                 \n                     Datasette can now output  newline-delimited JSON  using the new  ?_shape=array&_nl=on  query string option. \n                 \n                 \n                     Added documentation on  The Datasette Ecosystem . \n                 \n                 \n                     Now using Python 3.7.2 as the base for the official  Datasette Docker image .", "breadcrumbs": "[\"Changelog\"]", "references": "[{\"href\": \"http://ndjson.org/\", \"label\": \"newline-delimited JSON\"}, {\"href\": \"https://hub.docker.com/r/datasetteproject/datasette/\", \"label\": \"Datasette Docker image\"}]"}
{"id": "changelog:id89", "page": "changelog", "ref": "id89", "title": "0.28 (2019-05-19)", "content": "A  salmagundi  of new features!", "breadcrumbs": "[\"Changelog\"]", "references": "[{\"href\": \"https://adamj.eu/tech/2019/01/18/a-salmagundi-of-django-alpha-announcements/\", \"label\": \"salmagundi\"}]"}
{"id": "changelog:asgi", "page": "changelog", "ref": "asgi", "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.", "breadcrumbs": "[\"Changelog\", \"0.29 (2019-07-07)\"]", "references": "[{\"href\": \"https://asgi.readthedocs.io/\", \"label\": \"ASGI\"}, {\"href\": \"https://github.com/simonw/datasette/issues/272\", \"label\": \"Port Datasette to ASGI #272\"}, {\"href\": \"https://www.uvicorn.org/\", \"label\": \"Uvicorn\"}, {\"href\": \"https://github.com/huge-success/sanic\", \"label\": \"Sanic\"}, {\"href\": \"https://simonwillison.net/2019/Jun/23/datasette-asgi/\", \"label\": \"Porting Datasette to ASGI, and Turtles all the way down\"}]"}
{"id": "plugin_hooks:plugin-asgi-wrapper", "page": "plugin_hooks", "ref": "plugin-asgi-wrapper", "title": "asgi_wrapper(datasette)", "content": "Return an  ASGI  middleware wrapper function that will be applied to the Datasette ASGI application. \n             This is a very powerful hook. You can use it to manipulate the entire Datasette response, or even to configure new URL routes that will be handled by your own custom code. \n             You can write your ASGI code directly against the low-level specification, or you can use the middleware utilities provided by an ASGI framework such as  Starlette . \n             This example plugin adds a  x-databases  HTTP header listing the currently attached databases: \n             from datasette import hookimpl\nfrom functools import wraps\n\n\n@hookimpl\ndef asgi_wrapper(datasette):\n    def wrap_with_databases_header(app):\n        @wraps(app)\n        async def add_x_databases_header(\n            scope, receive, send\n        ):\n            async def wrapped_send(event):\n                if event[\"type\"] == \"http.response.start\":\n                    original_headers = (\n                        event.get(\"headers\") or []\n                    )\n                    event = {\n                        \"type\": event[\"type\"],\n                        \"status\": event[\"status\"],\n                        \"headers\": original_headers\n                        + [\n                            [\n                                b\"x-databases\",\n                                \", \".join(\n                                    datasette.databases.keys()\n                                ).encode(\"utf-8\"),\n                            ]\n                        ],\n                    }\n                await send(event)\n\n            await app(scope, receive, wrapped_send)\n\n        return add_x_databases_header\n\n    return wrap_with_databases_header \n             Examples:  datasette-cors ,  datasette-pyinstrument ,  datasette-total-page-time", "breadcrumbs": "[\"Plugin hooks\"]", "references": "[{\"href\": \"https://asgi.readthedocs.io/\", \"label\": \"ASGI\"}, {\"href\": \"https://www.starlette.io/middleware/\", \"label\": \"Starlette\"}, {\"href\": \"https://datasette.io/plugins/datasette-cors\", \"label\": \"datasette-cors\"}, {\"href\": \"https://datasette.io/plugins/datasette-pyinstrument\", \"label\": \"datasette-pyinstrument\"}, {\"href\": \"https://datasette.io/plugins/datasette-total-page-time\", \"label\": \"datasette-total-page-time\"}]"}
{"id": "internals:internals-request", "page": "internals", "ref": "internals-request", "title": "Request object", "content": "The request object is passed to various plugin hooks. It represents an incoming HTTP request. It has the following properties: \n             \n                 \n                     .scope  - dictionary \n                     \n                         The ASGI scope that was used to construct this request, described in the  ASGI HTTP connection scope  specification. \n                     \n                 \n                 \n                     .method  - string \n                     \n                         The HTTP method for this request, usually  GET  or  POST . \n                     \n                 \n                 \n                     .url  - string \n                     \n                         The full URL for this request, e.g.  https://latest.datasette.io/fixtures . \n                     \n                 \n                 \n                     .scheme  - string \n                     \n                         The request scheme - usually  https  or  http . \n                     \n                 \n                 \n                     .headers  - dictionary (str -> str) \n                     \n                         A dictionary of incoming HTTP request headers. Header names have been converted to lowercase. \n                     \n                 \n                 \n                     .cookies  - dictionary (str -> str) \n                     \n                         A dictionary of incoming cookies \n                     \n                 \n                 \n                     .host  - string \n                     \n                         The host header from the incoming request, e.g.  latest.datasette.io  or  localhost . \n                     \n                 \n                 \n                     .path  - string \n                     \n                         The path of the request excluding the query string, e.g.  /fixtures . \n                     \n                 \n                 \n                     .full_path  - string \n                     \n                         The path of the request including the query string if one is present, e.g.  /fixtures?sql=select+sqlite_version() . \n                     \n                 \n                 \n                     .query_string  - string \n                     \n                         The query string component of the request, without the  ?  - e.g.  name__contains=sam&age__gt=10 . \n                     \n                 \n                 \n                     .args  - MultiParams \n                     \n                         An object representing the parsed query string parameters, see below. \n                     \n                 \n                 \n                     .url_vars  - dictionary (str -> str) \n                     \n                         Variables extracted from the URL path, if that path was defined using a regular expression. See  register_routes(datasette) . \n                     \n                 \n                 \n                     .actor  - dictionary (str -> Any) or None \n                     \n                         The currently authenticated actor (see  actors ), or  None  if the request is unauthenticated. \n                     \n                 \n             \n             The object also has two awaitable methods: \n             \n                 \n                     await request.post_vars()  - dictionary \n                     \n                         Returns a dictionary of form variables that were submitted in the request body via  POST . Don't forget to read about  CSRF protection ! \n                     \n                 \n                 \n                     await request.post_body()  - bytes \n                     \n                         Returns the un-parsed body of a request submitted by  POST  - useful for things like incoming JSON data. \n                     \n                 \n             \n             And a class method that can be used to create fake request objects for use in tests: \n             \n                 \n                     fake(path_with_query_string, method=\"GET\", scheme=\"http\", url_vars=None) \n                     \n                         Returns a  Request  instance for the specified path and method. For example: \n                         from datasette import Request\nfrom pprint import pprint\n\nrequest = Request.fake(\n    \"/fixtures/facetable/\",\n    url_vars={\"database\": \"fixtures\", \"table\": \"facetable\"},\n)\npprint(request.scope) \n                         This outputs: \n                         {'http_version': '1.1',\n 'method': 'GET',\n 'path': '/fixtures/facetable/',\n 'query_string': b'',\n 'raw_path': b'/fixtures/facetable/',\n 'scheme': 'http',\n 'type': 'http',\n 'url_route': {'kwargs': {'database': 'fixtures', 'table': 'facetable'}}}", "breadcrumbs": "[\"Internals for plugins\"]", "references": "[{\"href\": \"https://asgi.readthedocs.io/en/latest/specs/www.html#connection-scope\", \"label\": \"ASGI HTTP connection scope\"}]"}
{"id": "plugin_hooks:plugin-hook-skip-csrf", "page": "plugin_hooks", "ref": "plugin-hook-skip-csrf", "title": "skip_csrf(datasette, scope)", "content": "datasette  -  Datasette class \n                     \n                         You can use this to access plugin configuration options via  datasette.plugin_config(your_plugin_name) , or to execute SQL queries. \n                     \n                 \n                 \n                     scope  - dictionary \n                     \n                         The  ASGI scope  for the incoming HTTP request. \n                     \n                 \n             \n             This hook can be used to skip  CSRF protection  for a specific incoming request. For example, you might have a custom path at  /submit-comment  which is designed to accept comments from anywhere, whether or not the incoming request originated on the site and has an accompanying CSRF token. \n             This example will disable CSRF protection for that specific URL path: \n             from datasette import hookimpl\n\n\n@hookimpl\ndef skip_csrf(scope):\n    return scope[\"path\"] == \"/submit-comment\" \n             If any of the currently active  skip_csrf()  plugin hooks return  True , CSRF protection will be skipped for the request.", "breadcrumbs": "[\"Plugin hooks\"]", "references": "[{\"href\": \"https://asgi.readthedocs.io/en/latest/specs/www.html#http-connection-scope\", \"label\": \"ASGI scope\"}]"}
{"id": "installation:installation-homebrew", "page": "installation", "ref": "installation-homebrew", "title": "Using Homebrew", "content": "If you have a Mac and use  Homebrew , you can install Datasette by running this command in your terminal: \n                 brew install datasette \n                 This should install the latest version. You can confirm by running: \n                 datasette --version \n                 You can upgrade to the latest Homebrew packaged version using: \n                 brew upgrade datasette \n                 Once you have installed Datasette you can install plugins using the following: \n                 datasette install datasette-vega \n                 If the latest packaged release of Datasette has not yet been made available through Homebrew, you can upgrade your Homebrew installation in-place using: \n                 datasette install -U datasette", "breadcrumbs": "[\"Installation\", \"Basic installation\"]", "references": "[{\"href\": \"https://brew.sh/\", \"label\": \"Homebrew\"}]"}
{"id": "spatialite:installing-spatialite-on-os-x", "page": "spatialite", "ref": "installing-spatialite-on-os-x", "title": "Installing SpatiaLite on OS X", "content": "The easiest way to install SpatiaLite on OS X is to use  Homebrew . \n                 brew update\nbrew install spatialite-tools \n                 This will install the  spatialite  command-line tool and the  mod_spatialite  dynamic library. \n                 You can now run Datasette like so: \n                 datasette --load-extension=spatialite", "breadcrumbs": "[\"SpatiaLite\", \"Installation\"]", "references": "[{\"href\": \"https://brew.sh/\", \"label\": \"Homebrew\"}]"}
{"id": "plugin_hooks:plugin-hook-register-commands", "page": "plugin_hooks", "ref": "plugin-hook-register-commands", "title": "register_commands(cli)", "content": "cli  - the root Datasette  Click command group \n                     \n                         Use this to register additional CLI commands \n                     \n                 \n             \n             Register additional CLI commands that can be run using  datsette yourcommand ... . This provides a mechanism by which plugins can add new CLI commands to Datasette. \n             This example registers a new  datasette verify file1.db file2.db  command that checks if the provided file paths are valid SQLite databases: \n             from datasette import hookimpl\nimport click\nimport sqlite3\n\n\n@hookimpl\ndef register_commands(cli):\n    @cli.command()\n    @click.argument(\n        \"files\", type=click.Path(exists=True), nargs=-1\n    )\n    def verify(files):\n        \"Verify that files can be opened by Datasette\"\n        for file in files:\n            conn = sqlite3.connect(str(file))\n            try:\n                conn.execute(\"select * from sqlite_master\")\n            except sqlite3.DatabaseError:\n                raise click.ClickException(\n                    \"Invalid database: {}\".format(file)\n                ) \n             The new command can then be executed like so: \n             datasette verify fixtures.db \n             Help text (from the docstring for the function plus any defined Click arguments or options) will become available using: \n             datasette verify --help \n             Plugins can register multiple commands by making multiple calls to the  @cli.command()  decorator. Consult the  Click documentation  for full details on how to build a CLI command, including how to define arguments and options. \n             Note that  register_commands()  plugins cannot used with the  --plugins-dir mechanism  - they need to be installed into the same virtual environment as Datasette using  pip install . Provided it has a  setup.py  file (see  Packaging a plugin ) you can run  pip install  directly against the directory in which you are developing your plugin like so: \n             pip install -e path/to/my/datasette-plugin \n             Examples:  datasette-auth-passwords ,  datasette-verify", "breadcrumbs": "[\"Plugin hooks\"]", "references": "[{\"href\": \"https://click.palletsprojects.com/en/latest/commands/#callback-invocation\", \"label\": \"Click command group\"}, {\"href\": \"https://click.palletsprojects.com/\", \"label\": \"Click documentation\"}, {\"href\": \"https://datasette.io/plugins/datasette-auth-passwords\", \"label\": \"datasette-auth-passwords\"}, {\"href\": \"https://datasette.io/plugins/datasette-verify\", \"label\": \"datasette-verify\"}]"}
{"id": "publish:publish-cloud-run", "page": "publish", "ref": "publish-cloud-run", "title": "Publishing to Google Cloud Run", "content": "Google Cloud Run  allows you to publish data in a scale-to-zero environment, so your application will start running when the first request is received and will shut down again when traffic ceases. This means you only pay for time spent serving traffic. \n                 \n                     Cloud Run is a great option for inexpensively hosting small, low traffic projects - but costs can add up for projects that serve a lot of requests. \n                     Be particularly careful if your project has tables with large numbers of rows. Search engine crawlers that index a page for every row could result in a high bill. \n                     The  datasette-block-robots  plugin can be used to request search engine crawlers omit crawling your site, which can help avoid this issue. \n                 \n                 You will first need to install and configure the Google Cloud CLI tools by following  these instructions . \n                 You can then publish one or more SQLite database files to Google Cloud Run using the following command: \n                 datasette publish cloudrun mydatabase.db --service=my-database \n                 A Cloud Run  service  is a single hosted application. The service name you specify will be used as part of the Cloud Run URL. If you deploy to a service name that you have used in the past your new deployment will replace the previous one. \n                 If you omit the  --service  option you will be asked to pick a service name interactively during the deploy. \n                 You may need to interact with prompts from the tool. Many of the prompts ask for values that can be  set as properties for the Google Cloud SDK  if you want to avoid the prompts. \n                 For example, the default region for the deployed instance can be set using the command: \n                 gcloud config set run/region us-central1 \n                 You should replace  us-central1  with your desired  region . Alternately, you can specify the region by setting the  CLOUDSDK_RUN_REGION  environment variable. \n                 Once it has finished it will output a URL like this one: \n                 Service [my-service] revision [my-service-00001] has been deployed\nand is serving traffic at https://my-service-j7hipcg4aq-uc.a.run.app \n                 Cloud Run provides a URL on the  .run.app  domain, but you can also point your own domain or subdomain at your Cloud Run service - see  mapping custom domains  in the Cloud Run documentation for details. \n                 See  datasette publish cloudrun  for the full list of options for this command.", "breadcrumbs": "[\"Publishing data\", \"datasette publish\"]", "references": "[{\"href\": \"https://cloud.google.com/run/\", \"label\": \"Google Cloud Run\"}, {\"href\": \"https://datasette.io/plugins/datasette-block-robots\", \"label\": \"datasette-block-robots\"}, {\"href\": \"https://cloud.google.com/sdk/\", \"label\": \"these instructions\"}, {\"href\": \"https://cloud.google.com/sdk/docs/properties\", \"label\": \"set as properties for the Google Cloud SDK\"}, {\"href\": \"https://cloud.google.com/about/locations\", \"label\": \"region\"}, {\"href\": \"https://cloud.google.com/run/docs/mapping-custom-domains\", \"label\": \"mapping custom domains\"}]"}
{"id": "changelog:v0-28-publish-cloudrun", "page": "changelog", "ref": "v0-28-publish-cloudrun", "title": "datasette publish cloudrun", "content": "Google Cloud Run  is a brand new serverless hosting platform from Google, which allows you to build a Docker container which will run only when HTTP traffic is received and will shut down (and hence cost you nothing) the rest of the time. It's similar to Zeit's Now v1 Docker hosting platform which sadly is  no longer accepting signups  from new users. \n                 The new  datasette publish cloudrun  command was contributed by Romain Primet ( #434 ) and publishes selected databases to a new Datasette instance running on Google Cloud Run. \n                 See  Publishing to Google Cloud Run  for full documentation.", "breadcrumbs": "[\"Changelog\", \"0.28 (2019-05-19)\"]", "references": "[{\"href\": \"https://cloud.google.com/run/\", \"label\": \"Google Cloud Run\"}, {\"href\": \"https://hyperion.alpha.spectrum.chat/zeit/now/cannot-create-now-v1-deployments~d206a0d4-5835-4af5-bb5c-a17f0171fb25?m=MTU0Njk2NzgwODM3OA==\", \"label\": \"no longer accepting signups\"}, {\"href\": \"https://github.com/simonw/datasette/pull/434\", \"label\": \"#434\"}]"}
{"id": "contributing:contributing-upgrading-codemirror", "page": "contributing", "ref": "contributing-upgrading-codemirror", "title": "Upgrading CodeMirror", "content": "Datasette bundles  CodeMirror  for the SQL editing interface, e.g. on  this page . Here are the steps for upgrading to a new version of CodeMirror: \n             \n                 \n                     Install the packages with: \n                     npm i codemirror @codemirror/lang-sql \n                 \n                 \n                     Build the bundle using the version number from package.json with: \n                     node_modules/.bin/rollup datasette/static/cm-editor-6.0.1.js \\\n  -f iife \\\n  -n cm \\\n  -o datasette/static/cm-editor-6.0.1.bundle.js \\\n  -p @rollup/plugin-node-resolve \\\n  -p @rollup/plugin-terser \n                 \n                 \n                     Update the version reference in the  codemirror.html  template.", "breadcrumbs": "[\"Contributing\"]", "references": "[{\"href\": \"https://codemirror.net/\", \"label\": \"CodeMirror\"}, {\"href\": \"https://latest.datasette.io/fixtures\", \"label\": \"this page\"}]"}
{"id": "facets:id1", "page": "facets", "ref": "id1", "title": "Facets", "content": "Datasette facets can be used to add a faceted browse interface to any database table.\n            With facets, tables are displayed along with a summary showing the most common values in specified columns.\n            These values can be selected to further filter the table. \n         Here's  an example : \n         \n         Facets can be specified in two ways: using query string parameters, or in  metadata.json  configuration for the table.", "breadcrumbs": "[]", "references": "[{\"href\": \"https://congress-legislators.datasettes.com/legislators/legislator_terms?_facet=type&_facet=party&_facet=state&_facet_size=10\", \"label\": \"an example\"}]"}