如何优雅地进行db migration

[sampsonye]

数据库迁移分为量部分 ，结构变更 和 数据迁移 在当前系统中beego的orm已经帮我们做好了结构变更的事情，因此剩下的我们在讨论如何优雅地进行 数据迁移

方案一 使用成熟的三方框架

• https://github.com/golang-migrate/migrate
  它的方案是在指定目录下写sql文件参见Migrations
  支持升级和降级
• https://github.com/rubenv/sql-migrate
  这个方案是独立进程的，需要手动执行sql-migrate up 等命令，迁移的SQL需自行实现

方案一，有版本控制升降级、支持简单的SQL数据迁移

方案二 代码中简单实现

如这次PR：#96
在初始化完成后，执行upgrade升级

方案二，目前仅支持升级（降级需讨论），SQL在代码中写入，支持自动运行，支持复杂的数据迁移

大家有什么好的想法呢？

[fanhousanbu]

这么说来，方案二就是方案一的简化版本，但在使用成本上上两者几乎一致，都要手动编写迁移sql？

[sampsonye]

这么说来，方案二就是方案一的简化版本，但在使用成本上上两者几乎一致，都要手动编写迁移sql？

写迁移sql脚本这件事儿肯定绕不过去，方案二目前看确实是方案一的简化版，但实际上方案二是为了支持更复杂的迁移方案的，
比如之前的敏感数据加密的迁移，方案一的支持就很困难，方案二因为是编程方式实现的，因此会方便很多

[colynn]

方案一中 也要自己写迁移sql吗？

[sampsonye]

方案一中 也要自己写迁移sql吗？

需要的，可以参考他们的文档https://github.com/golang-migrate/migrate/blob/master/MIGRATIONS.md

[sampsonye]

系统升级时，我们期望数据迁移是自动完成的，是不需要用户手动参与的。

常见的数据迁移大多数数据的移动或者简单重组，针对复杂的数据迁移显得力不从心，因此我个人强烈建议采用编程的方式构建迁移脚本，以便在应对复杂数据迁移时可以更从容地应对。

同时迁移应该具备这些能力：

1. 自动感知迁移的版本，并确保不会重复执行（降低出错率和重复浪费）
2. 具备降级回滚能力（待定）

@colynn @fanhousanbu 针对这个问题大家给个结论性的讨论吧，如果定不下来，这个PR可以考虑先Pending，待以后有结论了再重启

[fanhousanbu]

系统是个持续迭代的演变，目前的系统体量不足以支撑我们做出正确的决策，甚至合适的决策，所以我建议先要有

[colynn]

基于 @fanhousanbu 的逻辑，可以先有，只是觉得通过编程的方式来维护迁移脚本的方式成本相对较高

[colynn]

基于这次PR #96 的tips:
基于 Upgrade方法在atomci每次启动时都会执行，因此注意规范，支持重复执行（优化点）， 这一点如何保证

如果新增 migrate 的cli， 用户根据自己的需要来执行，是不是更好些， 因为每次migrate的SQL 均支持重复执行 也是一个很大的挑战

[sampsonye]

这是本次实现的问题，因为一开始追求的是“有这个功能”，如果确定走这条路，接下来会考虑：

1. 在数据库中维护Migration Version，根据Version来确保所有脚本有且只能执行一次
2. 应用的Version可读，根据应用Version与数据库中的Migration Version进行对比，可以进行自由的升级和降级

[fanhousanbu]

我一直以为没有必须重复执行的说法（目的是降低编写脚本的成本），执不执行是程序根据当前版本与version比较，有更新才执行，version保证了版本以及执行顺序这两个作用吧？

[sampsonye]

@fanhousanbu 是的，正常的迁移应该只需执行一次 所以这次的实现是“基础迁移能力的实现”
接下来可以增强它的能力

[colynn]

@sampsonye 看到 initMigration()是在 init时触发执行，所以 重复执行不就是 是必须支持的吗，不然怎么保证只会执行一次呢

[sampsonye]

最新提交的PR已经增强本次Migration能力，支持迁移脚本最多执行一次