Любой способ "сжать" миграцию от Flyway?

Мы используем Flyway для миграции схемы базы данных, и у нас уже есть более 100 сценариев миграции.

Как только мы "раздавили" несколько миграций в один перенос первой версии, это нормально во время разработки, поскольку мы отбрасываем и воссоздаем схему. Но в производстве это не сработает, поскольку Flyway не сможет проверить миграцию.

Я не мог найти никакой документации или лучшей практики, что делать в этом случае. Проблема в том, что количество файлов увеличивается постоянно, я не хочу видеть тысячи файлов миграции каждый раз, в основном, если производство уже в последней версии. Я имею в виду, что сценарии миграции, которые имеют номер версии ниже, чем версия в производстве, не имеют отношения к нам, было бы здорово, если бы мы могли скворовать эти файлы в один перенос.

Мы используем MySQL.

Как нам это сделать?

Ответ 1

Разве это не то, что будет делать рекабельность?

Я все еще новичок в пролете, но я думаю, что это сработает. Перед тем, как выразить свое слово, сначала проверьте следующее.

Удалить таблицу schema_version. Удалите сценарии миграции.

Запуск базовой линии пролета (это воссоздает таблицу schema_version и добавляет базовую запись как версию 1)

Теперь тебе хорошо. Имейте в виду, что вы не сможете "перенести" на любую предыдущую версию, поскольку вы удалили все свои сценарии миграции, но это может быть не проблема для вас.

Пошаговое решение:

  • drop table schema_version;
  • Экспорт структуры базы данных как script через MySQL Workbench, например. Назовите это script V1__Baseline.sql
  • Удалите все сценарии миграции и добавьте V1__Baseline.sql в свою папку сценариев, так что это единственный script, доступный для Flyway
  • Запустить прогон "базовая" команда
  • Готово

Ответ 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()