Odoo 企业版电子表格修订为什么不是“存一份最新 JSON 就好”：revision UUID 链、唯一约束与清理边界讲透

协作式文档如果只保留“最新一份 JSON”，调试、并发和回滚都会非常难看。电子表格模块显然没有走这条偷懒路线。

主要参考：

• enterprise/spreadsheet_edition/models/spreadsheet_revision.py
• enterprise/spreadsheet_edition/models/spreadsheet_mixin.py

一、revision 记录的重点不是内容，而是顺序事实

修订模型真正有价值的，是每版修订的 UUID、父子关系和提交顺序。这样后端才能回答几个关键问题：

• 这版是基于哪一版改出来的
• 当前提交是否落后于最新版本
• 哪些差异需要广播给别的会话

二、唯一约束不是数据库洁癖，而是协作底线

一旦 revision UUID 或关键组合关系不唯一，协作顺序就会失真：你无法稳定判断“同一版”是不是被重复提交，也很难安全去重或回放。

因此 unique index 在这类模块里属于业务约束，而不是纯技术优化。

三、为什么还需要 GC / 清理策略

协作编辑会产生大量历史版本；如果无限累积，读取、同步、恢复和存储成本都会上升。所以 revision 系统通常需要保留足够历史用于追踪，同时清理不再必要的细碎中间版本。

四、结论

电子表格 revision 最值得开发者学习的地方，是它把“多人同时编辑”转成了一条可验证、可排序、可清理的后端版本链，而不是只保留一个最新快照。