在一个架构中快速运行多个元数据表 [英] Flyway multiple metadata tables in one schema

问题描述

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

I'm trying to use Flyway to version the database of a modular application. Each module has its own separate set of tables, and migration scripts that will control the versioning of that set of tables.

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

Flyway allows me to specify a different metadata table for each module - this way I can version each module independently. When I try to upgrade the application, I run a migration process for each module, each with its own table and set of scripts. Note that these tables are all in the same schema.

但是，当我尝试迁移应用程序时，第一次迁移是唯一可行的方法。随后的迁移因以下异常而失败： org.flywaydb.core.api.FlywayException：找到了没有元数据表的非空模式 public！使用baseline（）或将baselineOnMigrate设置为true来初始化元数据表。

However, when I try to migrate my application, the first migration is the only one that works. Subsequent migrations fail with the following exception: org.flywaydb.core.api.FlywayException: Found non-empty schema(s) "public" without metadata table! Use baseline() or set baselineOnMigrate to true to initialize the metadata table.

如果我为每个模块手动创建元数据表，则将迁移每个模块正常工作。自己创建表而不是让Flyway为我创建表似乎是一种解决问题的技巧，而不是本身的解决方案。

If I create the metadata table for each module manually, migrations for each module work correctly. Creating the table myself rather than having Flyway create it for me seems like a hack to work around a problem, rather than a solution in itself.

这是一种有效的解决方法独立管理多组表，还是有更好的方法？

Is this a valid way of managing multiple sets of tables independently, or is there a better way of doing this? Is it a valid approach to create the metadata table myself?

推荐答案

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

An ideal solution for you would be to split your modules into schemas. This gives you an effective unit of isolation per module and is also a natural fit for modular applications (modules completely isolated and self managing), rather than dumping everything into a single schema (especially public). eg

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

第二个选择是保留使用公共模式来托管所有表，但对每个 schema_version 使用单独的架构。与上面提到的相比，这减少了重构工作，但肯定没有那么优雅的设计。例如

Your second option is to remain using the public schema to host all tables, but use an individual schema for each schema_version. This is less refactoring effort but certainly a less elegant design than that mentioned above. eg

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

这篇关于在一个架构中快速运行多个元数据表的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！