关于迁移历史

本页介绍了 Prisma ORM 如何使用迁移历史记录来跟踪架构的更改。

¥This page explains how Prisma ORM uses migration histories to track changes to your schema.

迁徙历史

¥Migration history

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

¥Your migration history is the story of the changes to your data model, and is represented by:

每次迁移都有一个 prisma/migrations 文件夹，其中包含一个子文件夹和 migration.sql 文件：

¥A prisma/migrations folder with a sub-folder and migration.sql file for each migration:
```
migrations/
  └─ 20210313140442_init/
    └─ migration.sql
  └─ 20210313140442_added_job_title/
    └─ migration.sql
```
migrations 文件夹是数据模型历史记录的真实来源。

¥The migrations folder is the source of truth for the history of your data model.
数据库中有一个 _prisma_migrations 表，用于检查：

¥A _prisma_migrations table in the database, which is used to check:
- 如果针对数据库运行迁移
  
  ¥If a migration was run against the database
- 如果应用的迁移被删除
  
  ¥If an applied migration was deleted
- 如果已应用的迁移发生更改
  
  ¥If an applied migration was changed
如果你更改或删除迁移（不推荐），后续步骤取决于你是处于开发环境（因此使用 migrate dev）还是生产/测试环境（因此使用 migrate deploy）。

¥If you change or delete a migration (not recommended), the next steps depend on whether you are in a development environment (and therefore using migrate dev) or a production / testing environment (and therefore using migrate deploy).

请勿编辑或删除已应用的迁移

¥Do not edit or delete migrations that have been applied

通常，你不应编辑或删除已应用的迁移。这样做可能会导致开发和生产环境迁移历史不一致，这可能会产生无法预料的后果 - 即使这种变化最初似乎没有破坏任何东西。

¥In general, you should not edit or delete a migration that has already been applied. Doing so can lead to inconsistencies between development and production environment migration histories, which may have unforeseen consequences — even if the change does not appear to break anything at first.

以下场景模拟了一个会产生看似无害的不一致的更改：

¥The following scenario simulates a change that creates a seemingly harmless inconsistency:

通过将 VARCHAR(550) 的值更改为 VARCHAR(560) 来修改已在开发环境中应用的现有迁移：

¥Modify an existing migration that has already been applied in a development environment by changing the value of VARCHAR(550) to VARCHAR(560):

./prisma/migrations/20210310143435_default_value/migrations.sql
```
  -- AlterTable
 ALTER TABLE "Post" ALTER COLUMN "content" SET DATA TYPE VARCHAR(560);
```
进行此更改后，迁移历史记录的最终状态不再与仍然具有 @db.VarChar(550) 的 Prisma 架构匹配。

¥After making this change, the end state of the migration history no longer matches the Prisma schema, which still has @db.VarChar(550).
运行 prisma migrate dev 会导致错误，因为迁移已更改并建议重置数据库。

¥Running prisma migrate dev results in an error because a migration has been changed and suggests resetting the database.
运行 prisma migrate reset - Prisma Migrate 重置数据库并重放所有迁移，包括你编辑的迁移。

¥Run prisma migrate reset - Prisma Migrate resets the database and replays all migrations, including the migration you edited.
应用所有现有迁移后，Prisma Migrate 会将迁移历史记录的最终状态与 Prisma 架构进行比较并检测差异：

¥After applying all existing migrations, Prisma Migrate compares the end state of the migration history to the Prisma schema and detects a discrepancy:
- Prisma 架构有 @db.VarChar(550)
  
  ¥Prisma schema has @db.VarChar(550)
- 数据库模式有 VARCHAR(560)
  
  ¥Database schema has VARCHAR(560)
Prisma Migrate 生成新的迁移以将值更改回 550，因为迁移历史记录的最终状态应与 Prisma 架构匹配。

¥Prisma Migrate generates a new migration to change the value back to 550, because the end state of the migration history should match the Prisma schema.
从现在开始，当你使用 prisma migrate deploy 将迁移部署到生产和测试环境时，Prisma Migrate 将始终警告你迁移历史记录不匹配（并在每次运行命令时继续警告你） - 即使模式结束状态匹配：

¥From now on, when you use prisma migrate deploy to deploy migrations to production and test environments, Prisma Migrate will always warn you that migration histories do not match (and continue to warn you each time you run the command ) - even though the schema end states match:
```
6 migrations found in prisma/migrations
WARNING The following migrations have been modified since they were applied:
20210310143435_change_type
```

在 migrate reset 之后看似不会破坏任何内容的更改可能会隐藏问题 - 你最终可能会在生产中遇到无法在开发中复制的错误，反之亦然 - 特别是如果更改涉及高度定制的迁移。

¥A change that does not appear to break anything after a migrate reset can hide problems - you may end up with a bug in production that you cannot replicate in development, or the other way around - particularly if the change concerns a highly customized migration.

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

¥If Prisma Migrate reports a missing or edited migration that has already been applied, we recommend fixing the root cause (restoring the file or reverting the change) rather than resetting.

将迁移历史提交到源代码管理

¥Committing the migration history to source control

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

¥You must commit the entire prisma/migrations folder to source control. This includes the prisma/migrations/migration_lock.toml file, which is used to detect if you have attempted to change providers.

对 schema.prisma 文件进行源代码控制还不够 - 你必须包括你的迁移历史。这是因为：

¥Source-controlling the schema.prisma file is not enough - you must include your migration history. This is because:

当你开始到自定义迁移时，你的迁移历史记录包含无法在 Prisma 架构中表示的信息。例如，你可以自定义迁移以减少因重大更改而导致的数据丢失。

¥As you start to customize migrations, your migration history contains information that cannot be represented in the Prisma schema. For example, you can customize a migration to mitigate data loss that would be caused by a breaking change.
prisma migrate deploy 命令用于将更改部署到暂存、测试和生产环境，仅运行迁移文件。它不使用 Prisma 模式来获取模型。

¥The prisma migrate deploy command, which is used to deploy changes to staging, testing, and production environments, only runs migration files. It does not use the Prisma schema to fetch the models.

迁徙历史​

请勿编辑或删除已应用的迁移​

将迁移历史提交到源代码管理​

迁徙历史

请勿编辑或删除已应用的迁移

将迁移历史提交到源代码管理