Datasette 0.26 keeps database reloads and CSV exports aligned
Datasette 0.26 watches database files during development and fixes filtered CSV exports. Both changes concern how a published database stays consistent with what its reader sees.
A database publishing tool has to preserve the meaning of a reader's selection when that reader takes the data elsewhere. Datasette's advanced CSV form had a defect in that handoff. The form could omit the filters selected on the table page. A download initiated from a filtered view could therefore describe a different selection. The Datasette 0.26 release includes a correction, alongside database file watching during development and an alias option for publication to Now.
The release is small, but the export correction deserves attention. A page that shows a subset of rows establishes an expectation about the export beside it. The download must preserve that subset even when the reader changes how the result is packaged. File format and row selection are independent choices. A CSV form that loses the latter silently changes the question being answered.
I like SQLite because a database file remains a useful unit of work. Datasette adds a web interface around that unit without requiring the publisher to design a separate browsing application. That makes the fidelity of the transitions between table pages and downloads particularly important. The interface supplies much of the application behavior that a publisher has chosen not to write.
Export options must preserve selection
The CSV documentation shipped with 0.26 describes exports for tables, views and custom SQL queries. A reader can obtain CSV through a link or use the advanced form to choose download behavior. The form can request a downloaded file, expand foreign key labels or stream all matching rows. These options alter the representation or extent of the response without authorizing a different filter.
Foreign key expansion illustrates why the distinction matters. With that option enabled, an exported foreign key column can gain an accompanying label column derived from its referenced table. The identifier still identifies the same related row. Adding a human-readable label should not alter which source rows qualify. A consumer needs the selection to survive while the representation becomes more convenient.
Streaming introduces another distinction. The documentation says that ordinary exports contain only the first configured maximum number of returned records. Streaming traverses the matching result set through Datasette's pagination and sends it as one CSV response. An export can consequently contain more rows than the initial page without changing the predicate that selected them. Losing the filter changes membership, whereas streaming changes how much of the selected membership is delivered.
The documentation also sets a default 100 MB ceiling for streamed CSV responses. Exceeding that ceiling places a truncation error message on the final line. That is a documented limit on delivery, separate from the filter defect corrected in this release. A complete description of an export therefore includes the selection and whether the result reached the configured output limit. Calling a response CSV does not establish either property by itself.
Watching a database file
The other change affects the publisher's development loop. According to the version-pinned changelog, datasette serve --reload now restarts the process when a database file changes on disk. A local invocation can use the database as an explicit input to that loop.
datasette serve catalogue.db --reload
The 0.26 command implementation makes the mechanism concrete. When reload is enabled, it starts a hupper reloader and passes the supplied database paths to watch_files. It also watches the metadata file when one is present. The command constructs a new Datasette instance and forces initial inspection before running the application.
That sequence matters because database inspection is part of preparing the application. Restarting gives a changed file a fresh initialization path. This is a development mechanism based on process restart. It should not be described as a new protocol for continuously serving a changing production database. The implementation shown here watches files and restarts the serving process.
Reload mode also disables the normal cache headers in the command's Datasette construction. That fits the purpose of the mode. A developer replacing a database wants requests to reach the current process, rather than obtaining an older cached response while investigating the replacement. The source ties both decisions to the reload flag, which makes their relationship visible without requiring assumptions about the browser.
Publishing names and database artifacts
The release additionally gives datasette publish now an optional --alias argument. The changelog says the command attempts to set the alias after deployment completes. That ordering distinguishes the deployed application from the public name attached to it. The publication can finish before the alias operation is attempted, so the two operations should not be treated as a single indivisible action.
I value this kind of development around SQLite because it preserves the database file as the artifact being published. Watching that artifact reduces manual restarts during preparation. Preserving filters in an export keeps the reader's interpretation attached to the downloaded data. Neither change requires the publisher to introduce another database service merely to make a dataset inspectable.
For readers using the advanced export form, the immediate result is specific. Download options can now retain the filters selected on the table page. The existing CSV controls still determine label expansion and streaming behavior, including the documented output ceiling. That restores agreement between the selected dataset and its exported representation.