关于迁移历史

本页解释了 Prisma ORM 如何使用迁移历史来跟踪 schema 的更改。

迁移历史

你的迁移历史是数据模型更改的故事，由以下内容表示：

一个 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 之后，一个看似不会破坏任何东西的更改可能会隐藏问题 —— 你最终可能会在生产中遇到一个你无法在开发中复制的 bug，反之亦然 —— 尤其是当更改涉及高度定制的迁移时。

如果 Prisma Migrate 报告缺少或编辑了已应用的迁移，我们建议修复**根本原因**（恢复文件或还原更改），而不是重置。

你必须将整个 prisma/migrations 文件夹提交到源代码控制。这包括 prisma/migrations/migration_lock.toml 文件，该文件用于检测你是否尝试更改提供商。

仅源控制 schema.prisma 文件是不够的 —— 你必须包含你的迁移历史。这是因为