FlywaySqlException: невозможно вставить строку для версии `11` в таблицу истории схем` schema_version`: поле `version_rank` не имеет значения по умолчанию - PullRequest
Новая
       10

FlywaySqlException: невозможно вставить строку для версии `11` в таблицу истории схем` schema_version`: поле `version_rank` не имеет значения по умолчанию

0 голосов
/ 02 октября 2018

Я получаю эту ошибку при запуске приложения Spring Boot с новой миграцией.Пока это сработало в течение 10 миграций.Поле действительно не имеет значения по умолчанию.Не должно быть необходимости по умолчанию, потому что Flyway должен вставить значение 11 в это поле.

Caused by: org.flywaydb.core.internal.exception.FlywaySqlException:
Unable to insert row for version '11' in Schema History table `app`.`schema_version`
--------------------------------------------------------------------------------------------
SQL State  : HY000
Error Code : 1364
Message    : Field 'version_rank' doesn't have a default value

    at org.flywaydb.core.internal.schemahistory.JdbcTableSchemaHistory.doAddAppliedMigration(JdbcTableSchemaHistory.java:174) ~[flyway-core-5.1.4.jar:na]
    at org.flywaydb.core.internal.schemahistory.SchemaHistory.addAppliedMigration(SchemaHistory.java:170) ~[flyway-core-5.1.4.jar:na]
    at org.flywaydb.core.internal.command.DbMigrate.applyMigrations(DbMigrate.java:299) ~[flyway-core-5.1.4.jar:na]
    at org.flywaydb.core.internal.command.DbMigrate.migrateGroup(DbMigrate.java:244) ~[flyway-core-5.1.4.jar:na]
    at org.flywaydb.core.internal.command.DbMigrate.access$100(DbMigrate.java:53) ~[flyway-core-5.1.4.jar:na]
    at org.flywaydb.core.internal.command.DbMigrate$2.call(DbMigrate.java:163) ~[flyway-core-5.1.4.jar:na]
    at org.flywaydb.core.internal.command.DbMigrate$2.call(DbMigrate.java:160) ~[flyway-core-5.1.4.jar:na]
    at org.flywaydb.core.internal.database.mysql.MySQLNamedLockTemplate.execute(MySQLNamedLockTemplate.java:60) ~[flyway-core-5.1.4.jar:na]
    at org.flywaydb.core.internal.database.mysql.MySQLConnection.lock(MySQLConnection.java:80) ~[flyway-core-5.1.4.jar:na]
    at org.flywaydb.core.internal.schemahistory.JdbcTableSchemaHistory.lock(JdbcTableSchemaHistory.java:150) ~[flyway-core-5.1.4.jar:na]
pom.xml 
<dependency>
  <groupId>org.flywaydb</groupId>
  <artifactId>flyway-core</artifactId>
  <version>5.1.4</version><!--$NO-MVN-MAN-VER$-->
</dependency>
application.properties 
# Prevent complaints when starting migrations with existing tables.
flyway.baselineOnMigrate = true
flyway.table=schema_version
schema_version 
| Field          | Type          | Null | Key | Default           | Extra |
+----------------+---------------+------+-----+-------------------+-------+
| version_rank   | int(11)       | NO   | MUL | NULL              |       |
| installed_rank | int(11)       | NO   | MUL | NULL              |       |
| version        | varchar(50)   | NO   | PRI | NULL              |       |
| description    | varchar(200)  | NO   |     | NULL              |       |
| type           | varchar(20)   | NO   |     | NULL              |       |
| script         | varchar(1000) | NO   |     | NULL              |       |
| checksum       | int(11)       | YES  |     | NULL              |       |
| installed_by   | varchar(100)  | NO   |     | NULL              |       |
| installed_on   | timestamp     | NO   |     | CURRENT_TIMESTAMP |       |
| execution_time | int(11)       | NO   |     | NULL              |       |
| success        | tinyint(1)    | NO   | MUL | NULL              |       |

Как мне создать миграцию, чтобы добавить значение по умолчанию, если миграции даже не работают?

Flyway 5.1.4, Spring Boot 5.1.13, mysql Ver 15.1 Distrib 10.1.30-MariaDB, для CYGWIN (i686)

Ответы [ 2 ]

0 голосов
/ 02 октября 2018

Похоже, эта проблема возникает, если вы переходите с Flyway 3.x прямо на 5.x, минуя 4.x.

Spring Boot 1.5 по умолчанию использует Flyway 3.x, тогда как Spring Boot 2.x использует Flyway 5.x.

Из примечаний к выпуску Flyway 5.0.0 :

Важное примечание для пользователей, обновляющихся с Flyway 3.x: этот выпускбольше не поддерживает обновление таблицы истории схемы с Flyway 3.x. Прежде чем перейти на Flyway 5.0.0 , необходимо выполнить обновление до Flyway 4.2.0 *.

Из Руководство по миграции Spring Boot 2 :

Обновление до Spring Boot 2 повысит Flyway с 3.x до 5.x.Чтобы убедиться, что обновление схемы проходит гладко, пожалуйста, следуйте следующим инструкциям:

  • Сначала обновите приложение Spring.ot 1.5.x до Flyway 4 (4.2.0 на момент написания)см. инструкции для Maven и Gradle.

  • Как только ваша схема будет обновлена ​​до Flyway 4, обновитесь до Spring Boot 2 и снова запустите миграцию, чтобы перенести ваше приложение на Flyway 5.

Руководство по миграции также ссылается на сообщение в блоге с альтернативным подходом.

Возникла проблема с Spring Bootпропустив Flyway 4.x и один против Flyway за исключение version_rank , которое вы получаете.

Похоже, довольно много других столкнулись с этой же проблемой.

0 голосов
/ 02 октября 2018

Пришлось

  • вручную добавить значение по умолчанию в поле, записав его в начало миграции, которая уже была выполнена, но не сохранит 

    alter table schema_version alter column version_rank set default 0;

  • прокомментируйте другие строки в миграции, потому что они уже выполнили 

    -- alter table myTable add column createdAt date;
-- ...

  • мигрируйте снова, чтобы добавить строку в schema_version

    mvn flyway:migrate -Dflyway.user=user -Dflyway.password= -Dflyway.url=jdbc:mysql://localhost:3306/app -Dflyway.table=schema_version

  • раскомментируйте строки в миграции, чтобы они были применены по конвейеру

  • подтвердите 

    mvn flyway:validate -Dflyway.user=user -Dflyway.password= -Dflyway.url=jdbc:mysql://localhost:3306/app -Dflyway.table=schema_version

[ERROR] -> Applied to database : 1445435712
[ERROR] -> Resolved locally    : -1275756780

  • copyконтрольную сумму в таблицу schema_version вручную, чтобы она больше не жаловалась на разработку 

    update schema_version set checksum = -1275756780 where version = 11;

Надеюсь, она будет работать только при подготовке и производстве.

Может бытьFlyWay должен использовать Rails-миграции для управления своей собственной схемой?

Я знаю, что управление версиями БД - сложная задача, и FlyWay должен облегчить ее, но иногда кажется, что это больше, чем просто использование пользовательских сценариев SQL или руководстваконтрольные списки развертывания.Я не смог найти упоминания об этой проблеме, и моя последняя миграция была в конце июля.Может быть, все уже прекратили его использовать?Я пользуюсь им только с мая, и у меня было так много проблем (смена имени таблицы, смена контрольной суммы, теперь это).

...