設置新基線後更改飛路遷移文件

Question

我將flyway集成到我的一個項目中。我有很多遷移，並且遷移新的空數據庫需要很長時間，主要是因爲在此過程中還添加了種子數據。現在我想改變這一點。不幸的是，這些遷移已經被推到了生產階段（是的，某些時候種子數據也遷移到了那裏）。

我的想法是爲當前版本的生產系統設置一個基準，然後清理舊的遷移：壓縮模式遷移並將種子和測試數據移動到未部署的新位置到生產。

現在我的問題是：

1. 我如何設置我的生產數據庫的基準，在不影響其他所有？直接在數據庫上調用flyway baseline ...？或者我可以使用任何種類的特殊遷移文件？也許可以將基準線直接寫入數據庫的schema_version表中？這樣的查詢將如何？
2. 我的最新遷移是V4_6_3__...。所以我的基線需要在V5__...？或者V4__...已經足夠，並且包含相同主要版本的所有遷移？
3. 設置了基線後，是否可以/保存添加，編輯和刪除比基準更早的遷移，而不會在下一個遷移任務中斷開我的生產數據庫？

很抱歉的基本問題，但在我看來，那飛路文檔是沒有幫助...

提前感謝！

Answer 1

Sry爲已故的答案。我已經做了一個非常類似的事情@markdsievers建議：

我保證，生產環境至少在版本X（flyway.setTarget(X)）。然後我更改爲新的模式版本表（flyway.setTable('temporary_schema_version')）並運行一次遷移，即刪除舊錶。之後，我將模式版本表更改回原始版本，將基線設置爲版本Y > X，並運行另一個刪除臨時表的遷移。

現在我可以編輯/壓縮/刪除版本低於Y的所有遷移，而不會崩潰我的生產部署。

Answer 2

我經歷了一個非常相似的情景，甚至寫了我們自己的內部工具稱爲「Rebaser」，它可以完成你想要的大部分工作。我們的主要動機是從Flyway 3.x升級到4.3，但我們也有很大的歷史需要被壓扁。其要點是：

1. 把你所有的遷移壓制成無論多少有意義。我通常有V2__base_ddl.sql和V3__base_data.sql（Flyway可以使用第一對版本號進行模式創建等）。這是手冊的一部分。
2. 您的重新組合工具會檢測舊的schema_version表並將其刪除。
3. 然後，您的基準工具將使用新的基準版本集運行init + migrate。
4. 重做工具留下足跡（自定義表格中的重新鍵），表明它已完成。

對於我的集成測試構建（即旋轉了一個香草數據庫，並遷移轉發到最新的）我添加使用飛行路線locations參數測試數據的SQL腳本的一個額外的文件夾，從而保證我有測試數據，集成測試，但不在任何非測試環境中。

我們的Rebaser只是一個圍繞着Flyway Java API的薄包裝，在pretep中添加了如果已配置然後委託給Flyway的rebase。

Flyway沒有rebasing的概念，但是我們發現這是我們發現的必須做的事，因爲您的歷史變得很大並且包含過時的數據/ DDL。到目前爲止，這個系統工作完美無瑕。