将创建和迁移脚本与飞行路线混合

Question

Flyway是否可以用于混合创建和迁移脚本，以便：

• 新安装运行架构创建脚本
• 现有安装运行迁移脚本，并且永远看不到后续版本的创建脚本

?

例如给定:

db/create/V1/V1__schema.sql
db/create/V2/V2__schema.sql
db/create/V3/V3__schema.sql
db/migration/V1/V1.1__migrateA.sql
db/migration/V2/V2.1__migrateB.sql
db/migration/V2/V2.2__migrateC.sql

现有的V1安装将运行以下操作以访问V3：

• 数据库/迁移/V1/V1.1__migrateA.sql
• 数据库/迁移/V2/V2.1__migrateB.sql
• 数据库/迁移/V2/V2.2__migrateC.sql

它永远不会运行以下内容，因为它们表示由 mysql 转储生成的仅架构 SQL：

• 数据库/创建/V2/V2__schema.sql
• 数据库/创建/V3/V3__schema.sql

新的 V3 安装将运行：

< Li > db/create/V3/V3 _ _ schema . SQL

上述方法与使用 Flyway 时升级方案建议的方法冲突，但是必需的，因为数据是独立于迁移填充的。

看起来应该可以使用flyway.locations来支持这一点，但是安装总是需要包含创建脚本的路径，以便Flyway可以看到它。

替代方案似乎是在Flyway之外运行创建脚本并设置基线，但如果Flyway可以管理一切就更好了。

Answer 1

最后，我开发了一个工具来做到这一点。该工具具有最新的模式：

db/schema/schema.sql

和中的迁移脚本:

db/migration/<version>/<version>.<sequence>__<JIRA issue>.sql

例如：

db/migration/V1/V1.1__JIRA-15.sql    
db/migration/V2/V2.1__JIRA-12.sql
db/migration/V2/V2.2__JIRA-22.sql
db/migration/V3/V3.0__JIRA-34.sql

如果数据库没有表，请使用schema。执行sql，然后根据flyway的MigrationInfoService报告，使用最新版本对flyway进行基线化。pending（）方法。

即，pending()返回的最后一个MigrationInfo元素确定在调用Flway.baseline()之前要传递给Flyway.setBaselineVersion()的版本，例如:

DbSupport support = DbSupportFactory.createDbSupport(connection, true);
Schema schema = support.getOriginalSchema();
if (schema.allTables().length == 0) {
  Resource resource = new ClassPathResource("db/schema/schema.sql", getClass().getClassLoader());
  SqlScript script = new SqlScript(resource.loadAsString("UTF-8"), support);
  script.execute(support.getJdbcTemplate());
  MigrationInfo[] pending = flyway.info().pending();
  MigrationInfo version = pending.length > 0 ? pending[pending.length - 1] : null;
  if (version != null) {
    flyway.setBaselineVersion(version.getVersion());
    flyway.setBaselineDescription(version.getDecription());
    flyway.baseline();
  }
}

这可确保不会为新创建的数据库调用任何迁移脚本，但确实意味着架构.sql必须已包含所有更改。

如果数据库有表，但没有Flyway信息，则根据检测到的模式版本对其进行基线化。