如何测试Flyway中复杂jsonb结构转换的迁移操作？

一、完善的迁移测试流程 #

• 先把数据库环境恢复到倒数第二个迁移版本的状态，确保目标迁移还没执行
• 导入针对性的测试数据：一定要覆盖各种场景——空JSONB、嵌套层级极深的对象、含特殊字符/异常字段的结构、业务里的核心数据样本，别只测常规情况
• 执行负责JSONB转换的最后那个迁移
• 多维度验证结果：
  • 用SQL直接对比新旧列，检查existing_column_name_v2的结构完全符合预期
  • 用业务代码写测试用例，确保转换后的JSONB能被正常解析、使用，和业务逻辑兼容
  • 核对数据行数，保证没有数据丢失（原列非空的行，新列也不能空）

二、Flyway只执行指定迁移的操作方法 #

Flyway有几种靠谱的方式控制迁移范围：

1. 用target参数精准指定版本 #

假设你的迁移文件按Flyway规范命名，比如最后一个迁移是V1.2.3__convert_jsonb_to_v2.sql（版本号1.2.3），倒数第二个是V1.2.2__last_before_convert.sql：

• 先把数据库拉到倒数第二个版本：

  # 全新环境直接执行
  flyway migrate -target=1.2.2
  # 若之前跑过更高版本，先清理再迁移
  flyway clean migrate -target=1.2.2
  

• 然后只执行目标迁移：

  flyway migrate -target=1.2.3
  

2. 用baseline+repair适配已有数据的数据库 #

如果你的测试库已经有历史迁移记录，不想清空数据：

• 先查schema history表，确认倒数第二个已应用的版本号
• 执行以下命令锁定基线并执行目标迁移：

  flyway baseline -baselineVersion=1.2.2
  flyway migrate -target=1.2.3
  

  要是schema history表有异常，先跑flyway repair修复再执行上面的步骤

3. 临时禁用其他迁移（应急用，不推荐） #

把除了目标迁移之外的后续迁移文件重命名（比如加.disabled后缀），然后跑flyway migrate，测试完再改回来。这种方法容易漏改，尽量不用。

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