Flyway:如何处理迁移文件名中的v1.x风格版本(例如1.2.0.a)？

Question

目前，我们正在使用Flyway 2.0.3，并最终完成了升级到Flyway最新版本的功课。

我知道首先进入2.3.0的步骤。通过该步骤，我们调整了Flyway的版本模式。

现在我正在寻找一种使用以下命名模式迁移我们的sql迁移文件的方法：

V1_2_0_a__AddFileDescription-oracle.sql
V1_2_0_b__ModifyFileDescription-oracle.sql
...
V1_3_0_a__DoSomeStuff-oracle.sql

随着对非数字字符的支持的放弃，我收到了已知的错误com.谷歌代码.飞路.core.api.飞途例外：包含非数字字符的无效版本。只有 0..9 和 .是允许的。无效的版本： 1.2.0.a

有没有针对旧版本的最佳实践迁移指南
欢迎任何建议。谢谢，
J0er9

更新：按照建议重命名迁移文件并不能解决问题。对于重命名的迁移文件，sql文件的解析将成功。但在下一步，Flyway会从元数据表中读取已经应用的迁移（在我的例子中是“schema_version”）。这失败了，因为旧模式版本号仍然存在于数据库中。结果是

 org.flywaydb.core.api.FlywayException: Version may only contain 0..9 and . (dot). Invalid version: 1.2.0.a
at org.flywaydb.core.api.MigrationVersion.toBigInteger(MigrationVersion.java:258)
at org.flywaydb.core.api.MigrationVersion.tokenize(MigrationVersion.java:241)
at org.flywaydb.core.api.MigrationVersion.<init>(MigrationVersion.java:82)
at org.flywaydb.core.api.MigrationVersion.fromVersion(MigrationVersion.java:71)
at org.flywaydb.core.internal.schemahistory.JdbcTableSchemaHistory$2.mapRow(JdbcTableSchemaHistory.java:202)
at org.flywaydb.core.internal.schemahistory.JdbcTableSchemaHistory$2.mapRow(JdbcTableSchemaHistory.java:184)
at org.flywaydb.core.internal.jdbc.JdbcTemplate.query(JdbcTemplate.java:367)
at org.flywaydb.core.internal.schemahistory.JdbcTableSchemaHistory.refreshCache(JdbcTableSchemaHistory.java:184)
at org.flywaydb.core.internal.schemahistory.JdbcTableSchemaHistory.allAppliedMigrations(JdbcTableSchemaHistory.java:174)
at org.flywaydb.core.internal.info.MigrationInfoServiceImpl.refresh(MigrationInfoServiceImpl.java:131)
at org.flywaydb.core.internal.command.DbValidate$2.call(DbValidate.java:138)
at org.flywaydb.core.internal.command.DbValidate$2.call(DbValidate.java:126)
at org.flywaydb.core.internal.jdbc.TransactionTemplate.execute(TransactionTemplate.java:74)
at org.flywaydb.core.internal.command.DbValidate.validate(DbValidate.java:126)
at org.flywaydb.core.Flyway.doValidate(Flyway.java:267)

是否有某种修复逻辑？或者这可以通过Flyway.repair（）调用来实现？如果我理解正确，它会从元数据表中擦除不再可用的迁移。在我的情况下，由于重命名，旧的迁移将不再可用。

Answer 1

将更改＜code＞V1_2_0_a__Foo。sql转换为V1_2_0_10__Foo。sql等不适合您吗？

编辑：如果您在数据库中有旧版本的记录，那么可以在将脚本重命名为数字模式的同时，将UPDATE重命名为模式历史表，以保持两者一致。尽管此时您可能最好重新确定生产数据库的基线，只考虑较低环境中的旧迁移。

此外，v2.0.3已经有六年历史了，没有直接迁移到当前v6.1的路径。有没有什么特别的原因让您以前没有升级到更高版本？