【问题标题】:Any way to "compress" Flyway migrations?有什么方法可以“压缩” Flyway 迁移?
【发布时间】:2016-02-04 04:42:56
【问题描述】:

我们正在使用 Flyway 迁移数据库架构,我们已经有 100 多个迁移脚本。

一旦我们将多个迁移“压缩”到一个单一的第一版迁移中,这在开发过程中是可以的,因为我们会删除并重新创建架构。但在生产中这不起作用,因为 Flyway 无法验证迁移。

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

我们正在使用 MySQL。

我们应该如何处理?

【问题讨论】:

    标签: flyway


    【解决方案1】:

    这不是重新设置基线的作用吗?

    我还是 flyway 的新手,但我认为这就是它的工作方式。请先测试以下内容,然后再相信我的话。

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

    运行飞行路线基线 (这会重新创建 schema_version 表并添加基线记录作为版本 1)

    现在你可以开始了。请记住,由于您已删除所有迁移脚本,因此您将无法“迁移”到任何以前的版本,但这对您来说可能不是问题。

    逐步解决方案:

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

    【讨论】:

    • 这不是说,如果你是一个开发人员团队,那么所有其他开发人员也需要删除表 schema_version?
    • 是的。由该组 Flyway 迁移脚本“管理”的每个数据库都需要相同的处理。
    • 运行基线时,flyway 会检查现有架构是否与新的 V1__Baseline.sql 架构匹配?如果我不希望 flyway 针对 V1__Baseline.sql 验证现有架构怎么办,我可以在 schema_version 表中使用生成的校验和创建一行吗?
    • @Illioiacono - No flyway 不会针对现有架构进行验证。
    【解决方案2】:

    我们这样做是为了让我们可以在开发环境中压缩用于构建新数据库的脚本,但也可以针对现有的生产数据库运行,而无需登录和删除 flyway_version_history 表,并且我们可以保留脚本(主要供参考):

    将所有脚本压缩成一个新脚本,例如V1 到 V42 变成了新的脚本 V43。 通过将 .txt 放在末尾,将 V1 到 V42 转换为文本文件。

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

    在脚本 V43 中,使用“if”块来保护创建/插入语句,这样它们就不会为现有的生产数据库运行。我们使用 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()
    

    【讨论】:

      【解决方案3】:

      我还没有尝试过,但是如果您删除所有迁移,创建一个新的迁移,将新起点创建为版本 1,将其设置为基线版本,然后修改您的配置以使用不同的表(例如flyway_schema_history_2)?

      在现有数据库中,Flyway 将看到您有一个非空模式,没有(可识别的)flyway 表并忽略基线迁移。在新环境中,它也会运行基线迁移。

      我错过了什么吗?

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

      【讨论】:

        猜你喜欢
        • 2014-10-19
        • 2011-10-19
        • 2021-01-13
        • 1970-01-01
        • 2018-08-28
        • 1970-01-01
        • 2023-04-02
        • 1970-01-01
        相关资源
        最近更新 更多