Почему flyway выдает предупреждающее сообщение, если для параметра outOfOrder установлено значение true?

Я получаю следующее предупреждающее сообщение в своих журналах, когда для outOfOrder установлено значение true:

ВНИМАНИЕ: активен режим outOfOrder. Выполнение миграции может быть невоспроизводимым.

Каков точный смысл этого сообщения? Будет хорошо, если кто-нибудь скажет мне, что произойдет, когда произойдет миграция. Любой пример будет полезен.


java flyway
person user1862868    schedule 06.03.2013    source источник
comment
По какой причине вы установили outOfOrder в true? Flyway 2.0: миграция не по порядку   -  person Kai    schedule 06.03.2013
comment
Причина в том, что я хочу, чтобы flyway выбирал любое исправление, которое я добавляю между основными ветками. Но мне нужно знать, почему Flyway говорит, что миграция не может быть воспроизведена?   -  person user1862868    schedule 07.03.2013
comment
Может ли кто-нибудь дать мне ответ на запрос?   -  person user1862868    schedule 12.03.2013

Ответы (2)


arrow_upward
7
arrow_downward

Предположим 3 миграции:

  1. Создайте два имени «Том» и «Джерри».
  2. Добавить «Микки» в качестве третьего
  3. Превратить имена в верхний регистр

Запуск с outOfOrder может привести к тому, что ваши миграции будут применены следующим образом:

1, 3, 2 -> В БД: ТОМ, ДЖЕРРИ, Микки

Повторный запуск позже произведет

1, 2, 3 -> В БД: ТОМ, ДЖЕРРИ, МИККИ

Вот почему outOfOrder потенциально опасен, а первый запуск миграции может оказаться невоспроизводимым.

person Axel Fontaine    schedule 12.03.2013
comment
Итак, какова альтернатива этому? - person TheRealChx101; 01.06.2021

arrow_upward
5
arrow_downward

Чтобы добавить к ответу Акселя, не только результирующие данные могут различаться в зависимости от порядка, но и миграция может быть даже невозможна. Рассмотреть возможность:

Миграции:

  1. Создать таблицу foo
  2. Добавить столбец foo.bar
  3. Переименовать столбец foo.bar в foo.baz

Порядок выполнения:

  • 1, 2, 3 → foo имеет столбец baz
  • 1, 3, … → ошибка применения 3: столбец foo.bar не найден
  • 2, … → ошибка применения 2: таблица foo не найдена
  • 3, … → ошибка применения 3: таблица foo не найдена
person pimlottc    schedule 13.01.2015
comment
Так что же тогда было бы лучшей практикой для обработки исправлений? Кажется, что в среде, где люди активно устанавливают исправления между ветвями, у вас не остается другого выбора, кроме как включить миграцию не по порядку, потому что более новые миграции ветвей будут иметь более поздний идентификатор. Я просто не могу примириться с тем, как в противном случае можно было бы поддерживать более старую ветку выпуска службы, независимо от выбранной схемы именования миграции. Зависимости миграции, кажется, в порядке, но это необходимо реализовать дома с обратным вызовом (по общему признанию, это может быть довольно просто). Это по-прежнему предполагает точную запись зависимостей. - person Kyle; 01.10.2015