有什么方法可以“压缩”飞行路线迁移吗？

Question

我们正在使用Flyway迁移数据库模式，我们已经有100多个迁移脚本。

一旦我们将多个迁移“挤压”成一个单一的第一版本迁移，在开发过程中就可以了，因为我们删除并重新创建了模式。但在生产中，这是行不通的，因为Flyway无法验证迁移。

在这种情况下，我找不到任何文档或最佳实践。问题是，文件数量不断增加，我不希望每次都看到数千个迁移文件，基本上是在产品已经是最新版本的情况下。我的意思是，版本号低于生产版本的迁移脚本与我们无关，如果我们可以将这些文件压缩到一次迁移中，那将是非常棒的。

我们正在使用MySQL。

我们应该如何处理？

Answer 1

我还没有尝试过，但是如果您删除了所有迁移，创建一个新的迁移，将新的起点创建为版本1，将其设置为基准版本，然后修改配置以使用不同的表（例如flyway\u schema\u history\u 2）？

在现有数据库中，Flyway将看到您有一个没有（已识别）Flyway表的非空模式，并忽略基线迁移。在新环境中，它也将运行基线迁移。

我遗漏了什么吗？

（当然，另一个问题是如何生成“压缩”迁移。如果您不需要任何种子数据，您可以只对数据库进行模式备份并使用它。如果您的迁移也填充数据，您可能需要手动解决。（

Answer 2

我们这样做是为了允许我们压缩脚本，以便在开发环境中构建新的数据库，但也可以在现有的生产数据库上运行，而无需登录和删除flyway_version_history表，我们可以保留脚本（主要用于参考）：

将所有脚本压缩为一个新脚本，例如V1到V42压缩为一个新脚本V43。将V1到V42转换为文本文件。最后是txt。

将基线设置为43。设置飞行路线以忽略丢失的迁移。

在脚本V43中，使用“if”块来保护create/insert语句，以便它们不会针对现有生产数据库运行。我们使用postgres，所以它是这样的：

DO $$
  DECLARE
    flywayVersion INTEGER;
  BEGIN

    SELECT coalesce(max(installed_rank), 0) INTO flywayVersion FROM flyway_schema_history;
    RAISE NOTICE 'flywayVersion = %', flywayVersion;
    IF flywayVersion = 0 THEN
      RAISE NOTICE 'Creating the DB from scratch';
      CREATE TABLE...
      .....
    END IF;
END$$;

“flyway”命令如下所示：

Flyway.configure()
      .dataSource(...)
      .baselineVersion("43")
      .ignoreMissingMigrations(true)
      .load()
      .migrate()

Answer 3

这不就是重新基线化所能做的吗？

我对flyway还是个新手，但我认为这就是它的工作原理。请先测试以下内容，然后再相信我的话。

删除schema_version表。删除迁移脚本。

运行flyway基线（这将重新创建schema_版本表，并将基线记录添加为版本1）

现在你可以走了。请记住，您将无法迁移到任何以前的版本，因为您已经删除了所有的迁移脚本，但这对您来说可能不是问题。

逐步解决方案：

1. drop table schema\u版本
2. 例如，通过MySQL Workbench将数据库结构导出为脚本。将此脚本命名为V1\u基线。sql
3. 删除所有迁移脚本并添加V1\u基线。sql添加到脚本文件夹中，因此它是Flyway唯一可用的脚本
4. 运行Flyway的“基线”命令
5. 完成