回退至旧应用版本时，如何回滚未包含的数据库迁移？

下面是几个可行的解决方案，按实用性排序：

1. 先通过新版本代码回滚，再切换到旧版本 #

这是最直接的操作方案，流程如下：

• 不要直接切换到旧版本代码，先保持当前的新版本代码环境
• 执行Umzug的回滚命令，回滚到目标旧版本对应的迁移节点：

  # 回滚到指定迁移的状态（旧版本最后一个迁移文件的名称）
  npx umzug down --to 20240501_initial_setup.js
  # 或者按数量回滚，比如回滚2个新版本新增的迁移
  npx umzug down --count 2
  

• 确认数据库已回滚到旧版本对应的状态后，再切换到旧版本代码启动应用

优点：完全依赖Umzug原生功能，无需修改现有代码配置，风险最低
缺点：需要额外操作步骤，不能直接切换版本后自动处理

2. 将所有迁移文件永久保留在代码仓库中 #

修改团队版本控制规范：

• 所有迁移文件一旦提交，永远不删除、不修改（哪怕后续业务不再依赖）
• 每个版本的分支/tag中，都包含从项目初始化到该版本的所有迁移文件

这样切换到旧版本时，本地代码仍包含所有已执行过的迁移文件（直到该版本之前的），Umzug会对比数据库中的迁移记录和本地文件列表，自动识别需要回滚的迁移（即旧版本代码中不存在但已执行的迁移），并调用对应的down函数完成回滚。

优点：自动兼容版本切换，无需额外手动操作
缺点：仓库会积累历史迁移文件，但这类文件体积小，对仓库影响可忽略

3. 自定义Umzug存储适配器，在数据库中保存迁移的down函数 #

如果无法保留所有迁移文件，可以扩展Umzug的存储逻辑，将迁移的down函数序列化后存入数据库：

• 自定义一个继承自Umzug默认存储类（比如SequelizeStorage）的适配器
• 在logMigration方法中，除了记录迁移名称，额外将down函数转换为字符串存入数据库字段
• 回滚时从数据库取出该字符串，通过动态执行的方式运行回滚逻辑

示例代码片段：

const { SequelizeStorage } = require('umzug');

class CustomStorage extends SequelizeStorage {
  async logMigration(migration) {
    await super.logMigration(migration);
    // 额外存储down函数代码
    await this.sequelize.models.Migration.update(
      { downFunction: migration.down.toString() },
      { where: { name: migration.name } }
    );
  }

  async getExecutedMigrations() {
    const migrations = await super.getExecutedMigrations();
    // 为迁移记录附加down函数
    return Promise.all(migrations.map(async (mig) => {
      const dbRecord = await this.sequelize.models.Migration.findOne({ where: { name: mig.name } });
      return {
        ...mig,
        down: eval(`(${dbRecord.downFunction})`)
      };
    }));
  }
}

// 在Umzug配置中使用自定义存储
const umzug = new Umzug({
  migrations: { /* 你的迁移配置 */ },
  storage: new CustomStorage({ sequelize }),
});

优点：无需保留历史迁移文件，回滚逻辑完全依赖数据库存储
缺点：需要自定义开发存储适配器，存在eval执行代码的安全风险（需确保迁移文件可信），且包含闭包的down函数可能无法正确序列化

4. 标准化迁移命名与通用回滚逻辑（仅适合简单场景） #

如果你的迁移逻辑比较标准化（比如单表创建/删除、字段添加/移除），可以给迁移文件加统一命名规则（比如v20240501_add_user_table.js），然后在旧版本中添加通用回滚逻辑：

• 在旧版本的Umzug配置中添加resolve钩子，遇到数据库中存在但本地没有的迁移时，根据名称解析出操作类型
• 生成对应的通用回滚代码（比如删除对应表）

这个方案仅适合极简单的迁移场景，复杂逻辑（比如数据迁移、关联表修改）无法覆盖，不推荐生产环境使用。

内容的提问来源于stack exchange，提问作者Pavan