Flyway在一个架构中有多个元数据表

Question

我试图使用Flyway来版本模块化应用程序的数据库。每个模块都有自己独立的表集和迁移脚本，这些脚本将控制该表集的版本控制。

Flyway允许我为每个模块指定不同的元数据表——这样我就可以独立地版本每个模块。当我尝试升级应用程序时，我为每个模块运行一个迁移过程，每个模块都有自己的表和一组脚本。请注意，这些表都在同一个架构中。

但是，当我尝试迁移我的应用程序时，第一次迁移是唯一有效的。后续迁移失败，出现以下异常：org。flywaydb。果心应用程序编程接口。FlywayException:找到不带元数据表的非空架构“public”！使用baseline（）或将baselineOnMigrate设置为true来初始化元数据表

如果我手动为每个模块创建元数据表，每个模块的迁移都会正常工作。自己创建表而不是让Flyway为我创建表似乎是解决问题的黑客手段，而不是解决方案本身。

这是独立管理多组表的有效方法，还是有更好的方法？自己创建元数据表是一种有效的方法吗？




Answer 1

我认为您需要在执行迁移之前对每个模块进行基线检查。您需要传递table选项来覆盖每个模块的schema_版本，例如flyway。table=schema\u version\u module1。正如错误消息所提示的，您也可以baselineOnMigrate，但文档中会对此提出警告(https://flywaydb.org/documentation/commandline/migrate).

我们正在考虑一种类似的方法，使用另一个schema_version表来应用和记录不能干净地推广到每个环境的数据修复。

Answer 2

理想的解决方案是将模块拆分为模式。这为每个模块提供了一个有效的隔离单元，也很适合模块化应用程序（模块完全隔离和自我管理），而不是将所有内容都转储到单个模式（尤其是公共模式）。如

application_database
    ├── public
    ├── module_1
    │   ├── schema_version
    │   ├── m1_t1
    │   └── m1_t2
    ├── module_2
    │   ├── schema_version
    │   ├── m2_t1
    │   └── m2_t2
    ...

第二种选择是继续使用公共模式来承载所有表，但对每个schema\u版本使用单独的模式。这是较少的重构工作，但肯定是一个不太优雅的设计比上述提到的。如

application_database
    ├── public
    │   ├── m1_t1
    │   ├── m1_t2
    │   ├── m2_t1
    │   └── m2_t2
    ├── module_1
    │   └── schema_version
    │
    ├── module_2
    │   └── schema_version
    ...