我刚刚开始尝试基于Java的迁移，并通过实现MigrationChecksumProvider提供校验和。
目前，Flyway似乎将事情视为一个两步过程
如果JdbcMigration例程本质上是静态的（例如脚本），这个2步方法很有效，因为可以很容易地计算校验和。如果JdbcMigration例程本质上是动态的，那么它会变得更有趣，因为在调用校验和例程时它的结果是未知的。
当前的解决方案是让校验和例程还调用某种形式的pre JdbcMigration例程，该例程生成要进行校验和的动态DDL，从而允许计算并返回校验和。然后，Flyway可以调用JdbcMigration例程，然后执行DDL。
上述工作，但是Flyway将来处理这个作为一个可以正确跟踪和报告的三步过程并不会更好。
这个问题/评论/想法已经出现，因为我目前正在使用JOOQ来表达DDL，这意味着DDL仅在运行时存在。
跟进1
由于需要根据底层数据库计算校验和，因此需要将连接传递给校验和例程以及迁移例程。原因是JOOQ可能会根据数据库目标创建不同的DDL语句。
跟进2
如果ConfigurationAware接口可以提供有关它正在调用的java迁移的“已发现”信息，例如它从类名解码的版本和描述，那将非常有用。