Изменение миграционных файлов пролета после установки новой базовой линии

Question

У меня есть пролет, интегрированный в один из моих проектов. У меня много миграций, и для переноса новой пустой базы данных требуется много времени, главным образом потому, что на этом пути также добавлены данные о семени. Теперь я хочу изменить это. К сожалению, эти миграции уже были перенесены на производство (и да, в какой-то момент там также были перенесены данные семян).

Моя идея состояла в том, чтобы установить базовую линию для текущей версии производственной системы и затем очистить старые миграции: сквойте схемы-миграции и переместите семенные и тестовые данные в новое место, которое не развернуто к производству.

Теперь мои вопросы:

1. Как я могу установить базовую линию в моей производственной базе данных, не затрагивая все остальные? Позвоните по телефону flyway baseline ... в базе данных напрямую? Или я могу использовать какой-либо специальный файл миграции? Может быть, написать базовую линию непосредственно в таблицу schema_version базы данных? Как бы выглядел такой запрос?
2. Моя самая новая миграция V4_6_3__.... Итак, моя базовая линия должна быть на V5__...? Или V4__..., и все миграции с той же основной версией включены?
3. Когда базовая линия установлена, возможно ли сохранить/изменить, добавить и изменить миграцию, более старую, чем базовую, без нарушения моей производственной базы данных в следующей задаче миграции?

Извините за основные вопросы, но мне кажется, что документация пролетного пути не поможет вообще ...

Заранее спасибо!

Answer 1

Sry для позднего ответа. Я сделал очень похожее на то, что @markdsievers предложил:

Я заверил, что производственная среда была по крайней мере на версии X (flyway.setTarget(X)). Затем я перешел на новую таблицу версий схемы (flyway.setTable('temporary_schema_version')) и выполнил одно перемещение, которое удалило старую таблицу. Впоследствии я изменил таблицу версий схемы на исходную, установил базовую линию до версии Y > X и выполнил другую миграцию, которая удалила временную таблицу.

Теперь я могу редактировать/сквош/удалять все миграции с версией ниже Y без сбоев моего производства-развертывания.

Answer 2

Я прошел очень похожий сценарий и даже написал собственный инструмент для дома под названием «Ребазер», который делает большую часть того, чего вы хотите. Наша главная мотивация заключалась в том, чтобы перейти с Flyway 3.x на 4.3, но у нас также была большая история, которую нужно было раздавить. Суть его заключается в следующем:

1. Сквош все ваши миграции во многие из них имеют смысл. Обычно у меня есть V2__base_ddl.sql и V3__base_data.sql (Flyway может использовать первую пару номеров версий для создания схемы и т. Д.). Это ручная часть.
2. Ваш инструмент для восстановления обнаруживает старую таблицу schema_version и удаляет ее.
3. Затем ваш инструмент для переустановки запускает init + migrate с вашей новой базой версии.
4. Инструмент «Ребаза» оставляет за собой след (ключ переустановки в пользовательской таблице), который указывает, что это было сделано.

Для моей интеграции тестовых сборок (что раскрутить базу ванили и мигрируют вперед к последнему) добавить дополнительную папку сценариев SQL тестовых данных с помощью пролетных locations аргумента, обеспечивая таким образом у меня есть тестовые данные для интеграции тестов, но не в любых не тестируемых средах.

Наш Rebaser - это всего лишь тонкая обертка вокруг API-интерфейса Flyway, добавляющая предварительную настройку, чтобы выполнить переустановку, если она настроена, и затем делегировать ее в Flyway.

Flyway не имеет понятия о переустановке, но это то, что мы нашли, необходимо сделать, поскольку ваша история становится большой и содержит устаревшие данные/DDL. Пока эта система работает безупречно.