当前位置: 首页 > 知识库问答 >
问题:

Flyway:校验和和可重复Java迁移

魏熠彤
2023-03-14

Flyway 4.2.0中的可重复Java迁移存在问题。

例如,我编写了一个可重复的Java迁移,它为每个具有特定列的表创建一个触发器。此迁移的ChecksumProvider计算缺少触发器的表的连接名称的哈希代码。

    @Override
    public int getChecksum(Connection conn) throws SQLException {
        return queryTableNames(conn).stream().collect(Collectors.joining(",")).hashCode();
    }

>

当表列表不为空时,hashcode不同于零(将其命名为xxx),并且对于每个表,都会向数据库添加一个合适的触发器。在这种情况下,hascode xxx被写入“schema_version”。下一次执行flyway:info时,它会显示一个过时的迁移,因为所有触发器都存在,新的校验和为零。因此,我必须执行一个“flyway:repair”或附加的“flyway:migrate”,以获得一个干净的表“schema\u version”。

在Java可重复迁移之后,是否有简单的机会自动更新校验和?

我检查了飞行路线。每次迁移后,但只能以只读方式访问MigrationInfo。使用此方法的进一步步骤将使用过多的flyway内部构件(即单独更新“schema_版本”)。

实现一个自己的MigrationResolver和一个定制的migrationxecutor似乎太重了。

共有1个答案

傅翰池
2023-03-14

校验和的定义是错误的。校验和应该引用当前目标状态。

在示例中,方法queryTableNames()应该返回带有此类触发器的所有表,迁移应该使用所需触发器完成这些表。

 类似资料:
  • 所以我有几个可重复的迁移。 创建一个视图(删除它 现在假设我修改了第一次迁移,结果视图不再包含第二次迁移使用的列。Flyway将愉快地重新运行第一次迁移,第一个视图将被重新创建,第二个视图将由于级联选项而被删除。 在此之后,我希望第二次(依赖的)迁移也会运行,并且会抛出一个错误(因为它使用了一个不再存在的列)。 这样可能吗? 以某种方式强制flyway检查现有迁移的结果是否不再存在?或者可能存在类

  • 将Flyway Maven插件从2.3升级到3.0后,我得到了: [错误]无法在项目xxx上执行目标org.flywaydb:flyway-maven-plugin:3.0:migrate(default-cli):org.flywaydb.core.api.flywayexception:验证失败。发现应用的迁移和可用的迁移之间存在差异:迁移V003__data_feed_sources_loc

  • 报价飞行路线文件https://flywaydb.org/documentation/migration/repeatable : 可重复迁移没有版本。相反,每次校验和更改时,都会(重新)应用它们。 这对于管理数据库对象非常有用,这些对象的定义可以简单地在版本控制中的单个文件中维护。 在一次迁移运行中,可重复迁移始终在所有挂起的版本化迁移执行完毕后最后应用。可重复迁移按其描述的顺序应用。 这听起来

  • 从升级到时,我收到以下错误,尽管SQL脚本没有改变: Spring Boot建议 为确保架构升级顺利进行,请按照以下说明操作: > < li> 首先将您的1.5.x Spring Boot应用程序升级到Flyway 4(撰写本文时为4.2.0),请参见Maven和Gradle的说明。 将架构升级到 Flyway 4 后,升级到Spring启动 2 并再次运行迁移以将应用程序移植到 Flyway 5

  • 每次更改DB结构时,我都使用时间戳创建一个新的迁移文件,以便按顺序执行,在一个干净的数据库中使用migrate命令(使用maven插件或命令行工具),它可以很好地工作,但在一个生产数据库中,使用相同的DB结构但添加了数据,我会得到以下错误:

  • 在使用可重复迁移时,我观察到一些奇怪的飞行路线行为。文件指出: 在一次迁移运行中,可重复迁移始终在所有挂起的版本化迁移执行完毕后最后应用。 但在我的例子中,可重复迁移(正在重新创建一个DB视图)似乎失败了,因为它是在版本化迁移之前执行的。 迁移前的Flyway信息数据: