Datasette 1.0a35：建表改表来了，但真正的看点是 API 纪律

Datasette 1.0a35 不是正式 1.0。它还是 alpha。

但这次更新的味道变了。过去 Datasette 最顺手的用法，是把 SQLite 数据库发布成网页，方便浏览、查询、分享。偏只读，偏展示。现在它开始让用户在 Web 界面里建表、改表，甚至删表。

这不是多放了几个按钮那么简单。一个工具一旦允许改 schema，就进入了另一个责任区：它不再只是把数据摊开，而是开始参与数据结构本身的生成和维护。

1.0a35 改了三件事

这次更新可以压成一张表。

建表能力不只是填个表名。它支持定义列、主键、自定义列类型、NOT NULL 约束、字面量默认值、表达式默认值，以及单列外键。

改表能力更敏感。它支持新增、删除、重命名、重排列，修改列类型、默认值、NOT NULL 约束、主键、外键，也能重命名表。界面里还放了一个 Drop table 按钮。

这个按钮很有提醒意义。不是说这里有事故，也不能从发布说明里推导出安全问题。它只是告诉你：Datasette 开始碰更高风险的操作。只读工具出错，多半是页面展示错；可写工具出错，可能是结构被改掉。

受影响的人很明确。

用 Datasette 管 SQLite 数据的人，会多一个轻量入口：不用离开 Web 页面，就能做一部分结构调整。写插件和模板的人，会更关心后面的稳定 API，因为那决定了他们敢不敢把维护成本押上去。

分水岭在“能改结构”

我更在意建表、改表背后的产品边界。

Datasette 原来的好处，是心智负担低。给它一个 SQLite 文件，它把数据变成可浏览、可查询的网页。克制，清楚，也容易解释。

现在它开始接近另一类东西：小型后台、内部工具、个人或团队的数据应用底座。

但这一步不能夸大。目前材料只证明它支持建表、改表和相关 API，不证明它已经成了完整数据库管理平台。也不能直接说它要替代 Airtable、Retool 这类产品。SQLite 的轻，和低代码平台的全，不是一回事。

更现实的判断是：如果你已经在用 SQLite 做小工具，1.0a35 会让 Datasette 更像一个可操作的工作台。如果你需要权限体系、复杂流程、多人协作治理，这次发布说明没有给出足够证据，别把它当成完整方案。

对开发团队来说，动作也很具体。

正在把 Datasette 当数据展示层的人，可以先观望 alpha，不必急着迁移生产流程。正在写内部小工具的人，可以评估建表、改表 API 是否能少写一层后台。插件和模板开发者则应该盯住模板上下文的稳定承诺，因为那才关系到代码能不能跨版本活下来。

这里有一点历史回声。早期很多工具从“查看器”变成“工作台”，分水岭往往不是界面变复杂，而是它开始接管状态变化。铁路不只是铺轨，还要调度；数据库工具不只是看表，还要承受结构变更的后果。古话说“牵一发而动全身”，schema 就是那根发。

稳定模板上下文，比按钮更像长期承诺

真正让我觉得这次更新有分量的，是 Template context 文档化。

Datasette 现在列出了核心页面中自定义模板可用的变量，并承诺这些变量到 Datasette 2.0 前作为稳定 API。这里的核心页面包括数据库页、表页、查询页、行页这些 Datasette 的主要页面。

更关键的是，文档不是手写愿望清单。它由靠近视图代码的 dataclass 生成；测试会校验文档字段和实际渲染上下文一致。

这叫 API 纪律。

很多开源项目的问题不是功能少，而是边界飘。今天某个变量能用，明天版本一升级就碎。插件作者写一次，维护三年，最后只剩核心作者自己玩得动。

Datasette 这次把承诺塞进了工程流程：文档、类型结构、测试绑在一起。这比一句“重视生态”硬得多。生态不是靠口号养出来的，是靠稳定边界养出来的。

代价也在这里。

稳定 API 会限制未来重构的自由。建表、改表会带来更多边界条件。插件越多，核心越不能随手改。工具长大以后，最难的不是加能力，而是守规矩。

接下来最该看两件事。

所以，1.0a35 的重点不是 Datasette 多了几个数据库按钮。它是在试探一个新位置：继续保持 SQLite 世界里小而锋利的气质，同时允许别人把它当成更可操作、更可扩展的底座。

能不能站住，不看 demo 多顺。看它以后怎么处理破坏性变更、模板变量、插件边界，以及那些看起来不起眼但会拖垮维护者的兼容性承诺。

小工具一旦许诺稳定，就不再只卖灵巧。能改数据，更要守边界。