Datasette 1.0a28 fixes critical bugs from the previous alpha that broke compatibility during a real-world upgrade of Datasette Cloud, the hosted service. Developers hit errors with custom write callbacks, and resource leaks threatened file descriptor limits in tests. These patches restore stability for write operations and cleanup, essential steps toward a production-ready 1.0 release.
Datasette, Simon Willison’s open-source Python tool, serves SQLite databases through a web interface. It lets users query, facet, and publish data without building custom apps. Version 1.0 introduces major features like multi-database support, write permissions, and temporary disk databases. But alphas like 1.0a27 exposed rough edges—changes to connection handling broke existing code, forcing this quick 1.0a28 follow-up.
Key Fixes and Their Impact
The standout repair targets execute_write_fn() callbacks. In 1.0a27, functions expecting parameters other than conn failed with errors. Issue #2691 now handles this: plugins and custom code using named params like db or connection work again. Why does this matter? Datasette plugins often wrap writes for safety—think audit logs or validation. A breakage here halts deployments. Here’s a fixed example:
from datasette import hookimpl
@hookimpl
def execute_write_fn(db, sql, args=()):
# Custom logic before execute
result = db.execute(sql, args)
# Log or validate
return result
Next, database.close() now closes the write connection alongside the read one. Previously, writes lingered, risking stale locks or leaks in multi-threaded setups. This aligns with SQLite’s connection model, where writes need exclusive access.
A new datasette.close() method (#2693) shuts down all databases and resources instance-wide. The server calls it automatically on exit, preventing orphaned SQLite files and sockets. In long-running processes—like Datasette Cloud—this avoids accumulation of open handles, which could crash under load.
For testers, a pytest plugin auto-cleans temporary Datasette instances in function-scoped fixtures (#2692). Pre-1.0a27 tests spawned Database(is_temp_disk=True) without proper teardown, exhausting file descriptors (ulimit often caps at 1024). Now, plugin suites run cleanly. Install via pip install datasette[pytest] and use fixtures like:
import pytest
from datasette import Datasette
from datasette.database import Database
@pytest.fixture
def ds_tmp():
return Datasette([Database(is_temp_disk=True)])
Why This Release Matters for Users and Developers
These aren’t cosmetic tweaks; they address deployment pain. Upgrading Datasette Cloud to 1.0a27 revealed breakages that could sideline hosted projects—data journalists, analysts, and indie devs rely on it for quick SQLite publishing. Fixes ensure write-enabled Datasette scales without surprises.
Consider the numbers: Datasette’s GitHub repo logs 500+ issues, with 1.0 alphas iterating weekly. From 0.66 in 2023 to a28 now, Willison tests aggressively—temporary disks for CI, pytest integration for plugins. Skeptically, alphas remain risky for prod; stick to 0.66 or 1.0 betas if stability trumps features. But rapid fixes like this build confidence. Resource management prevents real outages: one leaked connection per request snowballs in high-traffic facets.
Broader implications hit SQLite ecosystems. Datasette powers tools like Datasette Publish, LLM integrations, and data portals (e.g., LA Metro’s transit data). Write support unlocks editing UIs, collaborative datasets—vital for non-devs. Clean shutdowns matter in containers (Docker/K8s), where processes restart frequently. File descriptor exhaustion? Common killer in loops: 100 tests × 10 DBs = 1,000 fds, hitting limits fast.
Upgrade via pip install datasette==1.0a28. Test locally: datasette mydata.db --reload. For Cloud, Willison already pushed it live. Watch for a29; 1.0 final needs row-level security polish and perf tweaks. This alpha proves the project’s maturity—bugs found and squashed in days, not months.
In short, 1.0a28 unblocks progress. It stabilizes writes, cleans resources, and streamlines tests. For anyone shipping data apps on SQLite, it reduces risk. Ignore if you’re on stable; jump in if writes or plugins are your edge.
