如何强制Flyway基线化当前代码版本且不重新部署可重复对象？

这确实是Flyway在处理可重复对象（比如数据库PACKAGES、存储过程、视图这类）时的一个常见困惑点——它的基线规则对**版本化脚本（V前缀）和可重复脚本（R前缀）**的处理逻辑是不一样的：

• 对于普通的版本化脚本，Flyway会严格按照基线版本判断，只有版本号高于基线的新脚本才会被执行，已执行过的脚本不会重复运行。
• 但对于可重复脚本，Flyway的设计逻辑是每次迁移都会计算脚本的哈希值，如果哈希值和flyway_schema_history表中记录的不一致，就会重新执行该脚本——这是因为这类对象通常需要随业务逻辑更新而同步刷新，默认不会受基线的“一次性执行”规则限制。

如果你想把现有数据库纳入Flyway管理，同时避免重新部署已存在的对象，可以按照以下步骤操作：

1. 导出当前数据库的完整对象定义 #

先把数据库中所有现有对象（包括PACKAGES、存储过程、视图等可重复对象）的DDL脚本完整导出，确保脚本内容和当前数据库中的对象定义完全一致。

2. 执行Flyway基线初始化 #

使用flyway baseline命令初始化Flyway的元数据表，将当前数据库的状态标记为基线版本。这会在flyway_schema_history中插入一条基线记录，告诉Flyway“当前数据库已经处于这个基线版本的状态”。
示例命令：

flyway baseline -baselineVersion="1.0" -baselineDescription="Initial production database state"

• baselineVersion：可以自定义基线的版本号，建议使用一个低于后续新脚本版本的数值，比如1.0。
• baselineDescription：用于描述基线的状态，方便后续识别。

3. 放置可重复对象脚本到指定目录 #

把之前导出的可重复对象脚本（比如PACKAGES的DDL）放到Flyway配置的repeatable目录下。此时Flyway会计算这些脚本的哈希值，并和当前数据库对象的实际状态做比对：

• 如果脚本哈希值和当前对象的定义匹配，Flyway不会重新执行这些脚本，只会在flyway_schema_history中记录这些可重复脚本的哈希值。
• 只有当后续你修改了这些脚本的内容，哈希值发生变化时，Flyway才会重新执行它们，实现对象的更新。

额外注意事项 #

• 确保你的版本化脚本（V前缀）的版本号都高于基线版本，这样后续的正常迁移流程才会执行这些新脚本。
• 如果你的数据库中已经有部分对象是通过Flyway部署的，执行基线前要确认元数据表的状态，避免冲突。

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