Datasette learns its public URL prefix

Putting a web application behind a reverse proxy does not automatically teach it the address that visitors use. A proxy can forward a request successfully while the application still generates links for the wrong location. Datasette 0.39 adds base_url to address this problem for deployments beneath a URL prefix. The March 25 release announcement describes the setting as a way to serve correct links when Datasette runs under a different prefix.

For SQLite publishing, this concerns the application around the database file. The file does not determine whether visitors reach it through a dedicated host or through a path shared with other tools. Those are deployment choices, and generated links need to reflect them. A dataset that loads at one URL but sends navigation to another path is awkward to integrate even when its SQL queries work correctly.

I value SQLite's modest operational requirements, and that makes small publishing applications around it attractive. An explicit URL prefix helps preserve that proportionality when the application joins an existing website. It allows the publishing layer to describe its external location without making that location part of the dataset.

The public path is configuration

The configuration documentation in the release tag gives a concrete deployment example. Requests arriving at https://www.example.com/tools/datasette/ pass through to a proxied Datasette instance. The application needs /tools/datasette/ as its root URL, so that its links retain the path visible to visitors.

The command uses the configuration syntax available in this release. Its argument combines the setting name with the intended prefix.

datasette mydatabase.db --config base_url:/tools/datasette/

The trailing slash is present in the documented example. This command configures Datasette's root URL, while the proxy still needs its own routing configuration. Specifying the prefix does not establish a proxy server or reserve a path on an existing one. The two configurations describe related parts of the request's route.

There are consequently two different questions in such a deployment. The proxy must deliver traffic to the application, and the application must generate addresses that make sense at its public location. A successful initial request answers only the first question. The new setting makes the second question something the deployment can answer explicitly.

That distinction is useful when several tools share one host. The chosen prefix expresses where this particular instance belongs without requiring a separate hostname in the example. It also makes the deployment assumption visible in the application's launch command. Someone reading that command can see that root-relative deployment is not the intended arrangement.

Default ordering belongs to the table's presentation

The same release introduces sort and sort_desc metadata properties. The tagged metadata documentation explains that Datasette ordinarily sorts tables by primary key. A publisher can now override that default for an individual table. The ascending form names a column through sort, while sort_desc selects descending order.

An illustrative database can contain an example_table with a created column. Its descending metadata specifies that column by name.

{
  "databases": {
    "mydatabase": {
      "tables": {
        "example_table": {
          "sort_desc": "created"
        }
      }
    }
  }
}

The names identify the database and table to which the choice applies. This is publishing metadata, not a change to a SQLite table definition. It expresses how Datasette should initially present those rows. A primary key may be useful for identifying records without being the order that best introduces the dataset to a reader.

For example, a publisher may want recent records first when created describes their creation order. That is an illustrative choice, and its meaning depends on the actual column. The metadata cannot establish that the column contains suitable values or that they represent the interpretation the publisher intends. It provides the mechanism for selecting the initial sort once those data semantics are known.

Deployment and presentation need separate names

These additions operate at different scopes. base_url describes the location of the instance, while the sorting properties describe an individual table's initial presentation. Keeping those meanings separate is useful because a move beneath a different prefix does not inherently change how records should be ordered. Conversely, changing the default sort need not change the public route to the application.

I prefer this arrangement to burying either choice in an unexplained deployment assumption. A URL prefix can be read in the launch configuration, and a table's default ordering can be read in its metadata. Both choices remain outside the stored rows, where their role as publishing decisions is clearer.

The release also changes the primary-key sort indicator so that its direction arrow appears by default. According to the announcement, reversing that order then takes one click instead of two. This complements the metadata change at the interface level. The initial order has an explicit representation, and the reader can change its direction without first establishing an indicator that the table's existing order already implies.