Мы пытаемся перейти от пролета 2.0.3 до 4.0.3. Это не удается, потому что пролетный путь пытается удалить первичный ключ из таблицы schema_version, но в 2.0.3 он не был установлен. Читая предыдущие сообщения о проблемах с обновлением пролета, кажется, у нас есть два варианта. Попробуйте выполнить миграцию в несколько шагов, сначала до 2.3 (обновление до 3 можно пропустить?), А затем до 4.0.3 или вручную обновить таблицу schema_version. По разным причинам мы хотели бы сделать последнее.Как выполнить скрипт preFlywayUpgrade перед обновлением schema_version
Каков наилучший способ сделать это с помощью пролета? У наших клиентов нет доступных клиентских инструментов db, которые позволяли бы им выполнять SQL непосредственно в базе данных. Есть ли способ выполнить sql-скрипт до того, как произойдет обновление до таблицы schema_version, например.
preFlywayUpgrade.sql
? Я попробовал preRepair.sql, но это выполняется только после того, как flyway успешно обновил таблицу schema_version.
Редактировать: 2016-08-18: Я закончил загрузку пролетного пути src из версий 2.3.1, 3.2 и 4.0.3, объединив требуемые операторы sql для перехода с 2.0.3 на 4.0.3 и добавив результат sql до flyway-core-4.0.3, заменив существующий сценарий миграции 4.0.3. Я могу понять, что вы не хотите сохранять старый код перехода навсегда, но проекты, с которыми я работал, хранят свои сценарии миграции базы данных в течение многих лет, а некоторые клиенты часто не обновляют их. Учитывая, что пролетная дорога - это инструмент, используемый для постепенного обновления с любой данной версии, было бы неплохо, если бы он поддерживал модернизацию себя немного более комфортно. (Не поймите меня неправильно, я очень благодарен за всю работу, которую вы сделали на нем, и я думаю, что это отличный инструмент!) Одна из идей может заключаться в том, чтобы flyway записывал запись своей собственной версии в таблицу schema_version , Таким образом, было бы легче определить, какие изменения необходимо сделать для самой таблицы schema_version.