壓縮遷移

本指南描述瞭如何將多個遷移檔案壓縮成一個遷移。

關於壓縮遷移

有時，將部分或所有遷移檔案壓縮成一個遷移會很有用。本指南將介紹兩種你可能需要這樣做的場景

在這兩種情況下，Prisma Migrate 都提供了實現此目的的工具，透過使用 migrate diff 命令比較兩個資料庫 schema 並輸出一個單個 SQL 檔案，該檔案將你從一個狀態帶到另一個狀態。本指南的其餘部分將詳細說明如何在以上兩種場景中執行此操作。

當使用基於分支的工作流進行開發時，壓縮遷移會很有用。在功能分支上進行大量的本地開發工作時，你可能會使用 migrate dev 生成多個遷移。功能完成後，遷移歷史記錄可能包含不需要在最終推送到 main 分支的最終遷移歷史記錄中的不必要的中間步驟。

可能存在避免在生產環境中應用中間步驟的重要原因——它們可能會丟失資料或極其緩慢/具有破壞性。即使情況並非如此，你可能也希望避免生產環境的遷移歷史記錄中出現混亂。

有關如何使用 migrate dev 實現此目的的詳細步驟，請參閱如何從開發環境乾淨地遷移部分。

壓縮遷移也可以在生產環境中使用，將所有遷移檔案壓縮成一個。當生產環境積累了較長的遷移歷史，並且在新環境中重放由於中間步驟需要額外時間而變得繁重時，這會很有用。由於團隊沒有從遷移步驟中獲得價值（並且可以在緊要關頭從版本控制歷史中找回它們），因此決定將整個歷史壓縮成單個遷移。

有關如何使用 migrate diff 和 migrate resolve 實現此目的的詳細步驟，請參閱如何在生產環境中建立乾淨的歷史記錄部分。

警告

壓縮遷移時，請注意 migration.sql 檔案中任何手動更改或新增的 SQL 都將不會保留。如果你的遷移檔案包含自定義新增，例如檢視或觸發器，請確保在遷移壓縮後重新新增它們。

本節提供了關於如何在上述兩種場景中壓縮遷移的逐步說明

在壓縮遷移之前，請確保你滿足以下起始條件

資訊

如果生產資料庫上的遷移歷史在你建立功能分支後發生了分歧，那麼你需要首先將生產環境的遷移歷史和資料模型更改合併到你的本地歷史中。

然後遵循以下步驟

現在可以使用 migrate deploy 將此單個遷移檔案應用於生產環境。

在壓縮遷移之前，請確保你滿足以下起始條件

然後遵循以下步驟，無論是在你的 main 分支上還是在新檢出的分支上（該分支在其他任何更改之前合併回 main）

刪除 ./prisma/migrations 目錄的所有內容
在 ./prisma/migrations 目錄中建立一個新的空目錄。在本指南中，它將被稱為 000000000000_squashed_migrations。在此目錄內，新增一個新的空 migration.sql 檔案。

資訊
我們將遷移命名為 000000000000_squashed_migrations，帶有所有前導零，因為我們希望它是遷移目錄中的第一個遷移。Migrate 會按字母（字典）順序執行目錄中的遷移。這就是為什麼當你使用 migrate dev 時，它會生成帶日期和時間作為字首的遷移。你可以給遷移起另一個名字，只要它在排序時低於後面的遷移，例如 0_squashed 或 202207180000_squashed。
建立單個遷移，該遷移將你帶到
- 從一個空資料庫開始
- 到你的 ./prisma/schema.prisma 檔案中描述的生產資料庫 schema 的當前狀態
- 並將其輸出到上面建立的 migration.sql 檔案中
你可以使用 migrate diff 命令來完成此操作。從專案的根目錄執行以下命令
```
npx prisma migrate diff \
 --from-empty \
 --to-schema-datamodel ./prisma/schema.prisma \
 --script > ./prisma/migrations/000000000000_squashed_migrations/migration.sql
```
將此遷移標記為已應用於生產環境，以防止其在那裡執行

你可以使用 migrate resolve 命令將 000000000000_squashed_migrations 目錄中的遷移標記為已應用
```
npx prisma migrate resolve \
 --applied 000000000000_squashed_migrations
```

你現在應該有一個標記為已應用於生產環境的單個遷移檔案。新的檢出將只獲得一個將它們帶到生產資料庫 schema 狀態的單個遷移。

生產資料庫仍然在遷移表中包含已應用遷移的歷史記錄。遷移資料夾和資料模型的歷史記錄也仍然可以在原始碼控制中找到。