发布与审核变更
最后更新：2026 年 7 月 16 日
Schema 的每一次改动，都要先经过一次 Migration 才会生效。这给了你机会，在应用之前看清楚究竟哪些东西会变、以及会带来什么影响。
Migration 是怎么运作的
当你编辑 Schema —— 加一个字段、改一个 Enum、调一条约束 —— Backoffice 会把这次改动暂存为一个待处理的 Migration。在你审核并应用之前，它不会生效。
每个 Migration 都包含一份 Changes 摘要，列出将要新增、删除或修改的内容；还有一份 Impact 评估，说明这次改动是否向后兼容、会影响多少行。
把编辑和应用分开，能让 Schema 更安全：你可以连着改好几处，一起审核，等确信结果无误了再应用。
Review migration
有 staged 的改动时，Schema 视图右上角会出现 Review migration 按钮。点击它打开 Migration 对话框。
对话框分为两块。
Changes 列出将要应用的每一处修改 —— 新增的取值、删除的取值、添加的字段、更新的约束。每一处改动都以 diff 行的形式呈现，让你一眼看清到底加了什么、去了什么。
Impact 告诉你这个 Migration 应用起来是否安全。Backward compatible 标签意味着现有的读写照常工作，客户端一侧不需要任何改动。rows affected 的估算则告诉你有多少条现有 Record 会被触及 —— 在应用之前抓出那些意外波及过广的改动，靠的就是它。
Migration 看着没问题，就点 Apply migration。有哪里不对，就点 Cancel 继续编辑 —— staged 的改动会一直留着，直到你准备好为止。
删除一个已经被现有 Record 使用的 Enum 取值，是破坏性改动。应用删除类改动之前，请仔细看 rows affected 的估算。
需要额外留神的 Schema 改动
不是所有 Schema 改动的风险都一样。新增字段、新增 Enum 取值、新增 Entity 永远是向后兼容的 —— 现有 Record 不受影响，可以放心应用。
删除和修改就要更谨慎。删掉一个 Enum 取值、收紧一条约束、改动字段类型，都可能影响现有 Record 或破坏正在使用的查询。应用这类改动之前，先看对话框里的 Impact，再看对象面板底部的 Used by —— 它会显示还有哪些对象引用了你正要改的这一个。
一个对象在 Schema 中越处于中心位置，它的改动就越该被仔细审核。被十来个字段引用的 Enum，值得比一个冷门 Entity 上的字段花更多心思。
History
Schema 视图中的 History 标签页，是所有已上线 Migration 的完整记录 —— 最新的在最前。
每条记录都显示版本号、改动说明、由谁应用以及何时应用。点击任意一条上的 Diff，即可展开那次 Migration 究竟改了什么 —— 格式与 Review migration 对话框相同。
用 History 可以确认某个 Migration 是否被正确应用、追溯某项改动是什么时候引入的，或是了解 Schema 一路是怎么演变过来的。这份记录可以按时间范围筛选，也可以导出。
应用之前该检查什么
最常见的失误，是没看 diff 就把 Migration 应用了。diff 很短 —— 几秒钟就能读完，却能挡掉那些事后要花好久才补得回来的错误。
点击 Apply migration 之前，请确认：
- 改动说明与你的本意一致
- Impact 一栏显示 Backward compatible
- rows affected 的估算与你所做的改动相称
一处看似很小的编辑却影响了大量行，通常说明变动的范围比你以为的要广。
删掉的字段在一段时间内还能救回来
当某个 Migration 删除了一个字段时，该字段的数据不会立刻被抹掉。PlayServ 会先保留一个保留期（默认 7 天）再最终清除，因此在这段时间内重新加回同名字段，数据会一并恢复，而不是从空的开始。这是为“删了，结果发现还要用”这个经典失误准备的安全网。
这个窗口是宽限期，不是长期存储。一旦过期，被删字段的数据就彻底定案、不复存在 —— 那之后再加回这个字段，拿到的是个空字段。把保留期当作纠错的时间，而不是用来归档你日后还想要回的数据。
下一步
- Schema Object Reference —— 所有 Schema 概念的定义
- Building a Game Schema —— 如何创建并连接 Schema 对象
- Working with Game Data —— 创建和编辑 Record