Flyway: Как заменить устаревшую SpringJdbcMigration без получения сообщения «FlywayException: Validate failed»?

Обновление springboot 2.0.3 до 2.1.1 также приносит новую версию flyway: 5.2.3 вместо 5.0.7.

В версии 5.2.3 SpringJdbcMigration устарел и будет удален на пролетном пути 6. Я использую в основном сценарии sql, но у меня также есть один класс миграции java в проекте (есть 4 миграции sql, а последняя, ​​4.2, является миграцией java - это был просто быстрый и грязный прием по изменению старых данных, и он мне больше не нужен).

Итак, я изменил этот класс:

class V4_2__Update_foo implements SpringJdbcMigration {
    public void migrate(JdbcTemplate jdbcTemplate) throws Exception {
    ...
    }
}

к

class V4_2__Update_foo extends BaseJavaMigration {
    public void migrate(Context context) throws Exception {
    JdbcTemplate jdbcTemplate = 
      new JdbcTemplate(new SingleConnectionDataSource(context.getConnection(), true));
    ......
    }
}

Это единственное изменение, в остальном все то же самое. Результат

Application run failed
org.springframework.beans.factory.BeanCreationException: 
Error creating bean with name 'flywayInitializer' defined in class path resource [org/springframework/boot/autoconfigure/flyway/FlywayAutoConfiguration$FlywayConfiguration.class]:
Invocation of init method failed; nested exception is org.flywaydb.core.api.FlywayException:
Validate failed: Migration type mismatch for migration version 4.2
....
Caused by: org.flywaydb.core.api.FlywayException:
Validate failed: Migration type mismatch for migration version 4.2
-> Applied to database : SPRING_JDBC
-> Resolved locally    : JDBC
at org.flywaydb.core.Flyway.doValidate(Flyway.java:1479)

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

Repair of failed migration in Schema History table "PUBLIC"."schema_version" not necessary. No failed migration detected.
Successfully repaired schema history table "PUBLIC"."schema_version"

Тип миграции 4.2 по-прежнему "SPRING_JDBC" после выполнения восстановления. Позже я полностью удалил класс java, что вызвало предупреждение о том, что

Schema "PUBLIC" has a version (4.2) that is newer than the latest available migration (4) !

но, по крайней мере, приложение снова работало. Однако мне не очень комфортно делать это в продакшене. Есть другие идеи?

Пользовательский скаляр GraphQL
Пользовательский скаляр GraphQL
Листовые узлы системы типов GraphQL называются скалярами. Достигнув скалярного типа, невозможно спуститься дальше по иерархии типов. Скалярный тип...
Поднятие тревоги для долго выполняющихся методов в Spring Boot
Поднятие тревоги для долго выполняющихся методов в Spring Boot
Приходилось ли вам сталкиваться с требованиями, в которых вас могли попросить поднять тревогу или выдать ошибку, когда метод Java занимает больше...
Версия Java на основе версии загрузки
Версия Java на основе версии загрузки
Если вы зайдете на официальный сайт Spring Boot , там представлен start.spring.io , который упрощает создание проектов Spring Boot, как показано ниже.
Документирование API с помощью Swagger на Springboot
Документирование API с помощью Swagger на Springboot
В предыдущей статье мы уже узнали, как создать Rest API с помощью Springboot и MySql .
5
0
2 844
2
Перейти к ответу Данный вопрос помечен как решенный

Ответы 2

Ответ принят как подходящий

Это определенно ошибка. К сожалению, это не будет исправлено в 5.2.x. Flyway 6.0 (должен появиться в первом квартале 2019 года) автоматически исправит вашу таблицу истории схемы и исправит это.

В качестве альтернативы, если вы действительно не хотите ждать, вы можете вручную перейти к таблице истории схемы, чтобы это сообщение исчезло.

Я испытал то же самое, используя flyway 5.2.4. Обновление до 6.5.5 решило проблему.

Michael Yakobi 14.09.2020 17:21

Проблема:

[таблица schema_version с SPRING_JDBC] [1] [1]: https://i.stack.imgur.com/GI9So.png

РЕШЕНИЕ: Я решаю эту проблему, вручную обновляя таблицу schema_version, используя запрос ниже: update schema_version set type='SQL', checksum=662979041 where script='V001_026__initial_reconciliation_config_env_NonProd.sql';

Однако для создания вышеупомянутого оператора UPDATE вам понадобится контрольная сумма фактического скрипта, который вы перенесли ранее с использованием класса spring / java, в котором не будет контрольной суммы.

Как получить эту контрольную сумму? На вашем локальном компьютере удалите таблицу schema_version в local. Запустите приложение успешно, теперь у вас должна быть создана новая таблица schema_version с правильной контрольной суммой и типом SQL.

Контрольная сумма предназначена для проверки целостности файла, это означает, что не изменяйте файл после получения контрольной суммы.

Затем выполните вышеупомянутый оператор UPDATE вручную в своей непродовольственной среде.

Следующим шагом удалите класс java, переместите этот скрипт в папку, например db / non-prod, и настройте эту папку в application.yaml, например

весна: пролет: местоположения: "путь к классам: db / migration, classpath: db / env / migration / V001 / NON-PROD"

Другие вопросы по теме