關於遷移歷史

本頁介紹 Prisma ORM 如何使用遷移歷史來跟蹤您的資料模型變更。

遷移歷史

您的遷移歷史是資料模型變更的記錄，它透過以下方式表示：

一個 prisma/migrations 資料夾，其中包含每個遷移的子資料夾和 migration.sql 檔案
```
migrations/
  └─ 20210313140442_init/
    └─ migration.sql
  └─ 20210313140442_added_job_title/
    └─ migration.sql
```
migrations 資料夾是您的資料模型歷史的唯一真實來源。
資料庫中的 _prisma_migrations 表，用於檢查
- 遷移是否已在資料庫上執行
- 已應用的遷移是否被刪除
- 已應用的遷移是否被更改
如果您更改或刪除遷移（不推薦），接下來的步驟取決於您是在開發環境（因此使用 migrate dev）還是在生產/測試環境（因此使用 migrate deploy）。

通常，您不應編輯或刪除已應用的遷移。這樣做可能導致開發環境和生產環境的遷移歷史之間出現不一致，從而產生不可預見的後果——即使更改最初看起來沒有破壞任何東西。

以下場景模擬了導致看似無害不一致的更改：

透過將 VARCHAR(550) 的值更改為 VARCHAR(560)，修改已在開發環境中應用的現有遷移
./prisma/migrations/20210310143435_default_value/migrations.sql
```
  -- AlterTable
 ALTER TABLE "Post" ALTER COLUMN "content" SET DATA TYPE VARCHAR(560);
```
進行此更改後，遷移歷史的最終狀態不再與 Prisma Schema 匹配，Prisma Schema 仍為 @db.VarChar(550)。
執行 prisma migrate dev 會導致錯誤，因為遷移已被更改，並建議重置資料庫。
執行 prisma migrate reset - Prisma Migrate 會重置資料庫並重新執行所有遷移，包括您編輯的遷移。
應用所有現有遷移後，Prisma Migrate 將遷移歷史的最終狀態與 Prisma Schema 進行比較並檢測到差異：
- Prisma Schema 為 @db.VarChar(550)
- 資料庫 Schema 為 VARCHAR(560)
Prisma Migrate 會生成一個新的遷移，將值改回 550，因為遷移歷史的最終狀態應與 Prisma Schema 匹配。
從現在起，當您使用 prisma migrate deploy 將遷移部署到生產和測試環境時，Prisma Migrate 將始終警告您遷移歷史不匹配（並且每次執行命令時都會繼續警告您）——即使 Schema 的最終狀態匹配。
```
6 migrations found in prisma/migrations
WARNING The following migrations have been modified since they were applied:
20210310143435_change_type
```

在 migrate reset 後看似沒有破壞任何東西的更改可能會隱藏問題——您最終可能會在生產環境中遇到在開發環境中無法復現的錯誤，反之亦然——特別是如果更改涉及高度定製的遷移。

如果 Prisma Migrate 報告已應用的遷移缺失或被編輯，我們建議修復根本原因（恢復檔案或撤銷更改），而不是重置。

您必須將整個 prisma/migrations 資料夾提交到原始碼管理。這包括 prisma/migrations/migration_lock.toml 檔案，該檔案用於檢測您是否嘗試更改提供程式。

僅對 schema.prisma 檔案進行原始碼管理是不夠的——您必須包含遷移歷史。這是因為：

當您開始自定義遷移時，您的遷移歷史包含無法在 Prisma Schema 中表示的資訊。例如，您可以自定義遷移以減輕由破壞性更改引起的資料丟失。
用於將更改部署到預生產、測試和生產環境的 prisma migrate deploy 命令僅執行遷移檔案。它不使用 Prisma Schema 來獲取模型。