安全迁移本地 AI 历史数据库模式

直接回答

本地 AI 历史数据库迁移改变的是用户记录的数据库表示，不是模型文件更新或应用重装流程。先标明数据库名称、schema 版本、发生变化的表和字段，以及每个存储值的含义。保留旧 schema 的可信测试副本，写明迁移如何从旧结构转换到新结构，并同时检查行数和字段语义。用户原始内容要与模型派生输出、模型身份、解析器版本和 UI 状态分开。如果某字段没有无歧义的迁移方式，应保留原始值或提供只读恢复状态，不能静默丢弃。 仓库包含多个彼此独立的 Room 数据库，而不是一个全局 AI 历史库。TranslationDatabase 当前为版本 2，并声明 v1 到 v2 的迁移：为非空 translationStyle 字段加默认值；NoteDatabase 则在另一文件中保存笔记、标签及关联关系，当前版本为 1。这些本地代码例子说明数据库 schema 和数据所有权都是按应用区分的。它们不证明所有应用拥有相同迁移历史，也不代表某次正式版本已完成生产数据迁移。本文讲工程验证方法，不宣称某个产品已经公开更新。 以下三类迁移要分开：Room schema 迁移修改表和行；模型/运行时迁移修改制品或执行环境；清除应用或恢复备份改变存储生命周期。它们可能出现在同一发布，但各自需要独立兼容和测试证据。例如，翻译记录新增一个风格字段，而源文和译文保持不变；切换模型变体不能自动成为重写历史行的授权。解析结果、摘要、嵌入或模型标注等派生值可能依赖模型或解析器修订，应与用户原始历史分别版本化。 将迁移设计为明确、确定的转换。定义旧 schema 输入和新 schema 输出、字段使用常量默认还是派生值、null 和异常旧数据如何处理，以及变化是否在事务中执行。将幂等性和回滚策略写清：Room 通常在版本推进时执行已注册迁移，但应用可能在启动期间崩溃，数据库文件也可能从某条获准恢复路径复制而来。测试所有仍支持的起始版本到当前版本，不只测试空数据库。若没有安全映射，不能把破坏性迁移当作含用户内容数据库的静默捷径。 要随数据保留来源信息。存有模型生成译文或分析的行，应区分哪些值是用户原始输入、哪些为派生结果；若实现有保存，还应记录产生派生结果的制品、提示或解析器修订。字段重命名或拆分时保留来源数据，只对规则无歧义的字段执行转换。如果派生字段与新模型不兼容，应标记过期、在源数据仍存在且策略允许时重建，或保留旧值并标注“未迁移”。不能把旧输出虚标为当前模型生成。 数据库迁移测试应使用各受支持版本的真实导出 schema 或测试夹具。验证主键、外键、索引、排序、时间戳、收藏、标签关联及内容。还要覆盖空数据库、可选字段缺失、特殊 Unicode、长文本和未知旧枚举值。迁移前留一份原始副本以验证恢复。使用 Room schema 校验和 DAO 行为测试，不仅看数据库是否能打开。已提交夹具不能包含真实用户内容；应使用具有相同边界形态的合成数据。 用户体验也需要边界。迁移可能因为存储、schema 或数据损坏失败。说明当前在做什么，以及用户原始历史是否还在。不能在没有证据关联时，把数据库迁移失败路由为“下载模型”。若产品决定用破坏性回退，必须明确说明并测试，以避免意外丢失。备份和导出属于另外的目标；Room 迁移成功不能证明数据已备份或其他位置已清除。 ### 操作步骤 1. 盘点数据库和版本历史：记录数据库名、版本、表、约束、索引、关系及每条仍支持的旧版升级路径。 2. 定义字段映射，区分用户原始记录、模型派生结果和来源信息；写明默认值、转换、异常值处理及必须原样保留的字段。 3. 实现明确的 Room 迁移事务，并保存未改动的测试副本；schema 转换使用专门迁移，不要静默清空用户库以绕过旧版路径。 4. 用每个受支持起始版本执行已填充、空、稀疏、异常和 Unicode 夹具测试；迁移后从 DAO 检查值和关联，不只打开数据库。 5. 验证恢复和用户文案：模拟中断及迁移失败，确认有可恢复原始副本，并说明历史数据库与模型/运行时设置的区别。 ### 验收标准 - 每个仍支持的旧 schema 都有确定迁移路径，所有变化字段都有明确映射规则。 - 用户原始记录和关联关系保留；派生值来源被如实保留或明确失效。 - 测试覆盖每个支持 schema 版本的边界夹具，并检查 DAO 读写行为。 - 迁移失败不会静默删除历史，也不会宣称无关的模型下载、备份或恢复成功。 ### 对照 | 变化类型 | 主要对象 | 必需证据 | |---|---|---| | Room schema 迁移 | 表、记录、约束和关联 | 旧/新 schema 夹具及数据保留断言 | | 模型/运行时迁移 | 制品与执行栈 | 模型身份、运行时兼容和制品回滚记录 | | 重装或恢复 | 应用存储生命周期和备份路径 | 新安装状态、备份规则、恢复文件及用户授权检查 | ### 常见问题 **Room 迁移和模型升级是一回事吗？**不是。数据库迁移转换历史表结构和记录；模型升级变更字节制品或运行时配置。同一应用发布若包含两者，应分别使用夹具和结果记录。 **能否用破坏性迁移解决缺少旧版本路径？**如果数据库里有用户记录，就不能静默这么做。应提供已披露的恢复或导出选择，并在可能时先保留原始副本，说明可能的数据影响。 **旧模型生成的结果应该改标成新模型版本吗？**不应该。要诚实保留来源信息。派生字段可以标过期或不可用；只有按明确规则从保留源数据重新计算后才能更新，不能伪造当前版本来源。 **只测试数据库能打开就够了吗？**不够。要使用每个支持旧版的已填充夹具验证行、键、关联、排序和 DAO 读写。新建空数据库不会覆盖迁移缺陷，也不能证明历史保留。

Room 历史表新增字段或调整结构

团队计划发布应用版本，改变翻译和笔记记录的存储方式。旧用户可能有多个数据库版本、缺失可选值、标签关系及模型派生字段。升级必须保护用户内容，不能把旧结果归到新模型名下。

决策

用明确 Room 路径迁移 schema 与数据，将用户原始内容与派生输出和模型来源分开，并测试所有受支持起始版本。

预期结果

应用能确定迁移记录，或展示可恢复状态；不会静默重置历史，也不会将数据库迁移与模型升级混同。

需要收集的证据

只有将以下证据与同一模型文件和测试运行关联起来，结论才可复核：

• 数据库及 Room schema 版本
• 旧到新字段映射和事务规则
• 历史数据保留及 DAO 测试结果

收到完整字节流还不够；最终落盘、完整性、运行时加载和恢复路径也必须验证。

实施流程

1. 梳理数据库版本历史. 列出每个应用独立数据库、schema 版本、表、字段、关系、索引及用户可升级的确切起始版本。不要假设各应用共用一份数据库。
2. 规定原始与派生字段映射. 识别用户文本、模型生成输出、标签、收藏、制品引用和解析器信息。定义默认值，保留未知旧枚举，不对其含义自行猜测。
3. 编写显式 Room 迁移路径. 为每个受支持起始版本编写确定迁移。适用时在事务中执行；不要用破坏性重置代替未实现的历史迁移。
4. 测试填充过的历史夹具. 用各版本 schema 导出或合成等价数据测试。经 DAO 检查主键、关联、时间戳、Unicode、缺失字段和旧值，并确认原始记录仍可读取。
5. 验证失败恢复与披露. 注入迁移中断及错误，保留可恢复旧副本，并清楚说明历史数据迁移与模型下载或运行时设置无关。

让每个阶段的状态都可观察。失败信息应指出阶段、模型、运行时和恢复动作，同时避免记录用户私密内容。

验收标准

• 每个仍支持的旧 schema 均有明确且确定的迁移路径。
• 用户内容、键与关系保留；派生输出来源保留或明确失效。
• 每个支持版本都有填充边界夹具及 DAO 行为测试。
• 迁移失败不会静默清库，也不会声称模型下载、备份或恢复已成功。

决策对照表

需要避免的失败模式

• 用清空数据库绕过未实现的旧版本路径
• 把派生模型输出改标成新模型结果
• 把重装恢复与数据库迁移混成同一操作

还要避免静默回退、版本未固定、缺少取消处理，以及把不同配置的结果混在一起下结论。失败运行也应与成功记录一并保存。

最小复现记录

发布检查表

• ☐ 主要搜索问题已回答，且没有未经支持的数字。
• ☐ 所有模型文件和运行时版本均已固定。
• ☐ 代表性任务和失败处理策略均有说明。
• ☐ 生命周期、取消、清理和回退均已测试。
• ☐ 用户内容与网络边界均有说明。
• ☐ 结论只适用于被记录的配置。
• ☐ 新增测试结果时链接到原始方法或证据。

来源与相关证据

• Android Room 数据库迁移
• Android Room 数据库测试
• Android Auto Backup 行为与恢复边界

中文部署与排错专题见。奇连 AI 端侧专题。

常见问题