如何实现Flyway按installed_rank而非版本执行Undo（回滚）操作？

我完全懂你的困扰——手动给几百个脚本加cherryPick参数简直是灾难。要实现用installed_rank替代版本号作为回滚目标的逻辑，这里有几个可行的方案，从精准定制到临时过渡都有：

1. 自定义Flyway扩展（最贴合需求的长期方案） #

Flyway本身支持通过API扩展核心逻辑，你可以定制回滚的目标解析和筛选规则：

• 重写目标解析逻辑：默认Flyway会把-target参数解析为版本号，你可以实现自定义的TargetParser，让它把传入的数值识别为installed_rank值。
• 修改回滚筛选规则：在Flyway的迁移执行器中，默认是按版本号判断是否需要回滚，你可以修改这部分逻辑，改为筛选所有installed_rank大于等于目标值的迁移记录，然后按installed_rank降序执行对应的undo脚本。
• 具体操作：可以继承Flyway类，重写getUndoMigrationExecutor()方法，在自定义的执行器里调整迁移记录的筛选条件——比如从schema_version表中查询installed_rank >= [目标值]的记录，再逆序获取对应的undo脚本执行。

这个方案完全匹配你的需求，但需要你熟悉Flyway的Java API，而且后续Flyway版本升级时要注意兼容性。

2. 自动生成cherryPick参数（低成本过渡方案） #

如果不想改动Flyway源码，可以写个小脚本自动生成cherryPick列表，省去手动输入的麻烦：

• 先查询Flyway的schema_version表，获取符合条件的版本号：

  SELECT version FROM schema_version 
  WHERE installed_rank >= [你的目标installed_rank] 
  ORDER BY installed_rank DESC;
  

• 把查询结果拼接成逗号分隔的字符串，比如得到4,2,1，然后传入Flyway命令：

  flyway undo -cherryPick=4,2,1
  

• 你可以用Shell、Python或者数据库脚本实现这个逻辑，每次回滚前先执行脚本生成参数，再调用Flyway命令，效率比手动操作高太多。

3. 调整迁移版本号规划（长远规避方案） #

如果项目还能调整版本号规则，建议让脚本的版本号和installed_rank保持一致——也就是按执行顺序命名脚本，比如V1__init.sql、V2__add_user_table.sql...这样默认的按版本号回滚逻辑就和你想要的按installed_rank回滚完全一致了，根本不需要额外配置。不过这个方案更适合新项目，老项目修改版本号可能需要协调团队和处理历史脚本，成本相对高一些。

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