遷徙路線和遷徙重複

報價遷徙路線文檔的初始化在https://flywaydb.org/documentation/migration/repeatable：遷徙路線和遷徙重複

重複的遷移不會有一個版本。相反，它們在每次校驗和改變時都應用（重新）。

這對於管理數據庫對象非常有用，其定義可以在版本控制中簡單地保存在單個文件中。

在單個遷移運行中，在所有待執行版本化遷移已執行之後，可重複遷移總是最後應用。可重複遷移按其描述的順序應用。

這聽起來令人興奮，但我似乎無法找到關於如何實際工作以及如何初始化可重複遷移的任何澄清。我知道，對於Versioned遷移，我可以創建基礎遷移（https://flywaydb.org/documentation/existing），然後運行基線命令爲我的未來版本準備好一切。但對於可重複的遷移我不明白flyway是如何能夠校驗和更改。

相反，它們

（再）應用於每一次的檢查和修改。

是遷徙路線讓我從頭開始重建我的數據庫來獲取校驗和比較工作的假設？這將解釋它如何能夠比較校驗和（因爲它可以訪問數據庫中已有的對象的文件定義）。

來源

2017-03-21 NicolasW

我測試過flyway，現在理解初始化：只要文件名沒有特定的preffix（我認爲'REPEATABLE'是默認值），flyway就會忽略現有的腳本/遷移 - 只要遷移不是改名爲執行flyway將忽略他們。

來源

2017-04-21 19:51:33 NicolasW

是的，正確的，Flyway不會調查數據庫中存在的表或其他類似的表，它只依賴於它本身存儲在schema_version中的內容。前綴只是「R」，可以[配置]（https://flywaydb.org/documentation/api/javadoc/org/flywaydb/core/Flyway.html#setRepeatableSqlMigrationPrefix-java.lang.String-） – jhncz

我們假設您的可重複遷移SQL腳本的校驗和爲123.

第一次運行Flyway它會檢查schema_version表，發現這個可重複的遷移沒有被應用，所以它會執行它。
第二次啓動Flyway時，它將檢查您的SQL腳本的校驗和是否等於123，這等於自上次以來在schema_version中記錄的內容，因此您的可重複移植腳本將不會執行。
現在我們假設您修改第三個版本的可重複遷移SQL腳本，並將校驗和更改爲例如987.當您啓動Flyway時，它會發現987與存儲在schema_version（123）中的內容不相等，因此這次它將執行新版本的可重複遷移SQL，然後將schema_version中的123校驗和值更新爲987。

這意味着您可以隨時根據需要隨每個新版本更改可重複的遷移腳本。您無法以這種方式更新基準（不可重複）腳本，因爲Flyway會拋出關於不匹配校驗和的錯誤。

來源

2017-04-22 16:10:13 jhncz

謝謝我瞭解flyway是如何在初始化後檢測到變化的 - 一旦它有一個用於sql代碼的散列。在進行測試時，我發現這裏沒有什麼魔法，第一次檢測到可重複的遷移時，flyway會運行它。這使得在處理非空項目時不太容易。 – NicolasW

遷徙路線和遷徙重複

回答

相關問題