[内部优化] 以更好的方式记录 migration 是否执行过

[Xiangze-Li]

目前的 migration 主要以 文件是否存在/文件内是否存在特定内容 为判定条件，这不利于执行小规模 migration。例如 #872 中提及的迁移法术位的隐藏属性名，在当前模式下只能通过每次重新遍历来实现，这样的数据操作量是不能接受的。

考虑通过一个单独的数据库表/文件记录每个 migration 的执行情况。在执行迁移前检查记录中对应字段是否已设置，如果尚未设置才执行，如果已经设置就无需执行。在每次执行完成后将记录中的字段设置上。

如果采用文件的方式，它的内容可能类似：

{
  "ConvertLogs": true,
  "TryMigrateToV12": true,
  "...": true,
  "V144RemoveOldHelpdoc": true
}

可能的问题：如果用户手动用旧的配置覆盖了执行过迁移的数据，会导致需要再次执行的迁移无法再次执行

[JustAnotherID]

可能的问题：如果用户手动用旧的配置覆盖了执行过迁移的数据，会导致需要再次执行的迁移无法再次执行

是否可以通过在该设计中的 migration 执行记录上维护一个与所有配置项有关的 hash，来解决无法识别手动覆盖配置的问题？

[Xiangze-Li]

可能的问题：如果用户手动用旧的配置覆盖了执行过迁移的数据，会导致需要再次执行的迁移无法再次执行

是否可以通过在该设计中的 migration 执行记录上维护一个与所有配置项有关的 hash，来解决无法识别手动覆盖配置的问题？

不认为可行，如果记录 hash 就势必要每次都计算来判断这次启动有没有涉及内容被替换，导致数据吞吐量和计算量反而更大了

并且，migrate 之后再对新配置做修改，也会导致 hash 变化

[JustAnotherID]

可能的问题：如果用户手动用旧的配置覆盖了执行过迁移的数据，会导致需要再次执行的迁移无法再次执行

是否可以通过在该设计中的 migration 执行记录上维护一个与所有配置项有关的 hash，来解决无法识别手动覆盖配置的问题？

不认为可行，如果记录 hash 就势必要每次都计算来判断这次启动有没有涉及内容被替换，导致数据吞吐量和计算量反而更大了

并且，migrate 之后再对新配置做修改，也会导致 hash 变化

我的意思是计算config文件的hash，本身也是要读取的，比起比对文件具体内容来说应该会更简单。而对配置修改的时候，同步更新对应的hash。

[JustAnotherID]

可能的问题：如果用户手动用旧的配置覆盖了执行过迁移的数据，会导致需要再次执行的迁移无法再次执行

是否可以通过在该设计中的 migration 执行记录上维护一个与所有配置项有关的 hash，来解决无法识别手动覆盖配置的问题？

不认为可行，如果记录 hash 就势必要每次都计算来判断这次启动有没有涉及内容被替换，导致数据吞吐量和计算量反而更大了

并且，migrate 之后再对新配置做修改，也会导致 hash 变化

我的意思是计算config文件的hash，本身也是要读取的，比起比对文件具体内容来说应该会更简单。而对配置修改的时候，同步更新对应的hash。

还有种方案是直接换掉配置文件名或者调整到新路径，也能识别新旧配置。

[Xiangze-Li]

我的意思是计算config文件的hash，本身也是要读取的，比起比对文件具体内容来说应该会更简单。而对配置修改的时候，同步更新对应的hash。

config 的迁移算 hash 尚可，但是同步更新就成本太高了（包括计算量和修改量）。

另一部分是数据库里数据的迁移，尤其是只涉及数据内容而不涉及表结构的迁移，参考原文提到的 #872，这部分通过算 hash 是无法解决的