新字段填满了，为什么还不能删掉旧字段？

先把字段含义固定下来：本例只是同一份显示名字更换字段名，不拆分姓名，不改变编码，旧名字不允许为 NULL。旧版本读取并写入 full_name；过渡版本仍可读旧字段，但每次修改用同一条 UPDATE 同时写两列；最后版本只读写 display_name。每次名字修改还递增 version。

把两个字段放进同一条语句，可以避免本例在第一次写成功、第二次写失败后留下半套更新。这里不是跨数据库双写；若两份数据位于不同系统，需要另一套失败处理。也别把两个字段都存在，当成两个版本自然兼容：兼容取决于每个读取方和写入方实际使用什么。

实验先保留旧列，再新增允许为空的 display_name。旧查询仍然能找到原字段，旧写入也还能运行。新列中的空值表示“这一行尚未迁移”，而不是合法的业务值。这个约定只适合本例；如果新字段本来就可以为空，需要另外设计完成标记，不能把两种空值混为一谈。

Danilo Sato 的 Parallel Change 将这种过程分为扩展、迁移、收缩：先容纳两种接口，再迁走使用者，最后移除旧接口。文中的接口范围比数据库列更广。本项目把该思路用于一个字段名，具体 SQL 和检查数据由本实验定义，不把模式名称当成数据库自动提供的功能。

第一份临时数据库故意走错顺序。程序先把三行旧名字复制到新字段，再让旧写入方只更新第一行的 full_name。此时 missing 是零，表示没有待填的空值；mismatch 却是一，表示有一行的两份名字不同。旧读取看到修改后的名字，新读取仍看到先前那份。

因此，检查“新字段全部非空”不够。切换读取前，还要确认旧写入方已经退出，并核对新旧值是否满足本次迁移定义。本例切换门同时检查旧写入状态、空值数和差异数。旧写入是否退出由脚本中的明确阶段变量表示，它不是探测真实进程的办法；生产环境需要另有版本与流量证据。

第二份数据库用两个连接排列动作。回填先读到旧名字和版本号，随后旧写入修改同一行。回填提交时要求 id 相同、version 仍等于读取值，而且 display_name 仍为空。由于版本已变化，这次更新影响零行，旧快照不会被写成新字段；下一批应重新读取最新数据。

脚本也安排过渡写入先更新另一行，再尝试提交该行旧快照。过渡写入已把两列填为新名字，旧回填依然影响零行。零行不是成功复制了一行，也不一定是 SQL 错误；它可能表示条件已经不成立。处理方式是重新检查剩余工作，不能忽略影响行数后仍宣布全部完成。

只有在旧写入方退出、后续写入都遵守双列规则之后，本例才完成剩余回填并允许新读取切换。两个连接只是控制交错顺序，没有并行压力测试。它证明所列顺序中的条件更新有效，不证明任何数据库上的锁等待、性能或整套发布流程。

每批只取仍为空的记录，按编号排序并限制条数。本例故意每批取一行，完成一批后关闭全部连接，再打开同一个临时文件。重新查询仍能看到一行未完成，继续一批便完成；完成后再跑一批，更新数应为零。进度来自数据库状态，不能只记在进程内计数器里。

下载练习包，在 schema_migration.py 所在目录执行下方命令。输出包含错误路径的差异数、旧快照影响行数、关闭重开前后的空值数，以及最终字段清单。程序逐项断言后才打印 PASS，并检查临时目录已清理。这是正常关闭后的续跑验证，没有模拟突然断电、损坏文件或回填进程崩溃。

新读取启用后，过渡写入仍同步更新两列。实验在这个阶段再次改名，断言旧读取和新读取相等。这支持“旧读取代码目前还可用”，却不能扩大成“整个旧版本随时都能安全回来”：旧版本若恢复只写一列，又会让已经切换的新读取变旧。回滚计划必须同时说明读写路径。

清理旧列之前，要确认旧读取、旧写入、脚本与报表等使用者都已经迁走，并说明兼容窗口何时结束。本文没有替你决定等待多少分钟；时间本身不能证明没有旧使用者。观察哪些版本仍在使用字段、有没有遗漏调用，以及如何阻止旧写入恢复，才是需要交付的依据。

最后，实验在自动提交模式执行 DROP COLUMN full_name，再用新列读写。随后故意执行旧查询，它因为旧字段不存在而失败。把应用代码切回旧版，不会撤销已经提交的数据库结构变化。要恢复旧接口，需要另行设计恢复结构与数据的迁移，不能把“回滚应用”当成这一步已经完成。

这不表示 SQLite 的所有结构修改都无法放进事务，也不表示任何数据都不可能重建；本例展示的是已经提交后的边界。SQLite 对删除列还有限制，例如相关约束和引用可能阻止操作。这里只删除没有额外索引、外键或视图依赖的教学字段，没有覆盖生产表改造的完整检查。