Сценарии до и после миграции для Flyway

Question

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

1. Отбросить все просмотры и хранимые процедуры.
2. Запустите миграцию.
3. Пересмотр представлений и хранимых процедур.

Это гарантирует, что любое изменение в схеме отражается в связанных представлениях и хранимых процедурах. Шаги (1) и (3) будут скриптами bash.

Возможно ли это на Flyway?

Answer 1

Обновление 2014-04-29: Теперь это возможно с Flyway 3.0 с помощью интерфейса FlywayCallback.

Предыдущий ответ

Краткий ответ: нет,не в этот момент.

Вот причина: я думал об этом так же, как и разрабатывал первоначальный проект для Flyway.Однако чем больше я размышлял над этим аспектом, тем больше мне становилось ясно, что эти сценарии pre и post также являются неотъемлемой частью миграции , или, по крайней мере, миграция не может обойтись без необходимостибыть успешным.Поэтому я бы порекомендовал:

• Объединить 1, 2 и 3 в одну миграцию
• иметь 3 отдельных миграции x.1 (отбрасывание просмотров), x.2 (фактическая миграция), x.3 (перестроить представления)

Возможно, вы даже сможете использовать хранимые процедуры вызова x.1 и x.3, которые помогут вам избежать дублирования кода между миграциями, если эти шаги

Благодаря тому, что Flyway позаботится о внесении всех изменений в структуру базы данных, все станет проще, избегая сочетания различных технологий.

Answer 2

Чтобы расширить на Ответ Акселя : обратные вызовы с помощью сценариев sql просто означают помещение beforeMigrate.sql (например, это одно ключевое слово среди других) в каталог, содержащий миграции, и Flyway выполнит beforeMigrate.sql до других сценариев миграции. Еще до того, как schema_version будет заблокирован.

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