Повторяющиеся миграции Flyway - выполняются перед версиями?

Question

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

В рамках одного прогона миграции повторяющиеся миграции всегда применяются последними после выполнения всех ожидающих выполнения версий.

, но в моем случае кажется, что повторяющаяся миграция (которая воссоздает одно из представлений БД) терпит неудачу, поскольку выполняется до перенаправленных версий.

информации пролетного пути данные, от до перенастройки: +-------------------+---------------------+---------------------+---------+ | Version | Description | Installed on | State | +-------------------+---------------------+---------------------+---------+ | 1 | Initial | | <Baseln | | 2 | ███████████████████ | | <Baseln | | 5 | Initial data | | <Baseln | | 6 | Initial sample data | 2016-04-29 14:21:13 | Success | | 20160422002600000 | ███████████████████ | 2016-04-29 14:33:48 | Success | | 20160422003400000 | ███████████████████ | 2016-04-29 14:33:48 | Success | | 20160422004700000 | ███████████████████ | 2016-04-29 14:33:48 | Success | | 20160428152800000 | ███████████████████ | 2016-04-29 14:33:48 | Success | | 20160428163300000 | ███████████████████ | 2016-04-29 14:33:48 | Success | | 20160428171300000 | ███████████████████ | 2016-04-29 14:33:48 | Success | | | ProblematicView | 2016-04-29 14:33:48 | Outdate | | | Reports | 2016-04-29 14:33:49 | Success | | | OtherView | 2016-04-29 14:33:49 | Success | | 20160429115100000 | ███████████████████ | 2016-04-29 14:37:10 | Success | | 20160429160100000 | ███████████████████ | 2016-05-16 11:54:24 | Success | | 20160501090500000 | ███████████████████ | 2016-05-16 11:54:24 | Success | | 20160504111600000 | ███████████████████ | 2016-05-16 11:54:24 | Success | | 20160504120400000 | ███████████████████ | 2016-05-16 11:54:24 | Success | | 20160504143800000 | ███████████████████ | 2016-05-16 11:54:24 | Success | | 20160504145200000 | ███████████████████ | 2016-05-16 11:54:25 | Success | | 20160504161600000 | ███████████████████ | | Pending | | 20160506110300000 | ███████████████████ | | Pending | | 20160506162300000 | ███████████████████ | | Pending | | 20160506232000000 | ███████████████████ | | Pending | | 20160508144100000 | ███████████████████ | | Pending | | 20160509192400000 | ███████████████████ | | Pending | | 20160511160000000 | ███████████████████ | | Pending | | 20160511163659000 | ███████████████████ | | Pending | | 20160511163700000 | A newly_created_col | | Pending | | 20160511170000000 | ███████████████████ | | Pending | | 20160512112100000 | ███████████████████ | | Pending | | 20160512170500000 | ███████████████████ | | Pending | | 20160513134900000 | ███████████████████ | | Pending | +-------------------+---------------------+-------------------------------+

и журнал миграции:

[INFO] Database: jdbc:sqlserver://█:1433;authenticationScheme=nativeAuthentication;xopenStates=false;sendTimeAsDatetime=true;trustServerCertificate=false;sendStringParametersAsUnicode=true;selectMethod=direct;responseBuffering=adaptive;packetSize=8000;multiSubnetFailover=false;loginTimeout=15;lockTimeout=-1;lastUpdateCount=true;encrypt=false;disableStatementPooling=true;databaseName=█;applicationName=Microsoft JDBC Driver for SQL Server;applicationIntent=readwrite; (Microsoft SQL Server 11.0) 
[INFO] Successfully validated 33 migrations (execution time 00:00.052s) 
[INFO] SQLServer does not support setting the schema for the current session. Default schema NOT changed to dbo 
[INFO] Current version of schema [dbo]: 20160504145200000 
[WARNING] outOfOrder mode is active. Migration of schema [dbo] may not be reproducible. 
[INFO] Migrating schema [dbo] with repeatable migration ProblematicView 
[ERROR] Migration of schema [dbo] with repeatable migration ProblematicView failed! Changes successfully rolled back. 
[INFO] SQLServer does not support setting the schema for the current session. Default schema NOT changed to dbo 
[INFO] ------------------------------------------------------------------------ 
[INFO] BUILD FAILURE 
[INFO] ------------------------------------------------------------------------ 
[INFO] Total time: 3.550s 
[INFO] Finished at: Mon May 16 12:40:49 CEST 2016 
[INFO] Final Memory: 10M/243M 
[INFO] ------------------------------------------------------------------------ 
[ERROR] Failed to execute goal org.flywaydb:flyway-maven-plugin:4.0.1:migrate (migrate-¦) on project ¦-db: org.flywaydb.core.internal.dbsupport.FlywaySqlScriptException: 
[ERROR] Migration R__ProblematicView.sql failed 
[ERROR] ------------------------------------------------ 
[ERROR] SQL State : S0001 
[ERROR] Error Code : 207 
[ERROR] Message : Invalid column name 'newly_created_column'. /*<-- column created in V20160511163700000*/` 

Я делаю что-то не так?
Я использую Пролетный путь-Maven-плагин 4.0.1 (протестирован также на 4.0) со следующими свойствами:

Maven: 
<cleanDisabled>true</cleanDisabled> 
<outOfOrder>true</outOfOrder> 
<table>schema_version</table> 
<repeatableSqlMigrationPrefix>R</repeatableSqlMigrationPrefix> 
<sqlMigrationPrefix>V</sqlMigrationPrefix> 
Config file: 
flyway.user=flyway 
flyway.password=█ 
flyway.url=jdbc:sqlserver://█;databasename=█ 
flyway.locations=filesystem:flyway/upgrade/█` 

// EDIT1:

1. Когда outOfOrder устанавливается в ложь миграция по-прежнему не удалась,
2. clean + migrate похоже на работу, но это не совсем решает проблему,
3. Я заметил еще одну вещь - когда я откатил БД до версии 201605041 43800000 повторяющиеся миграции отображаются в конце списка (информация о пролетном пути), но когда миграция 20160504145200000 успешно выполняется внезапно, они находятся посредине (как в таблице выше). Я не уверен, хотя, если это имеет какое-либо отношение к фактическому исполнению.

Answer 1

Оказалось, что ошибка в пролете: LINK - она ​​влияет на версии 4.0 - 4.0.2 и была исправлена ​​в 4.0.3 (Release notes).

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

Answer 2

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

Если вы все еще видите проблему, можете ли вы также установить cleanDisabled на false, чтобы схема была полностью перестроена и сообщила, что вы видите.

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