命名约束升级路径

升级到 Prisma ORM 3 后，约束和索引名称的默认命名约定将发生变化，你的主键和外键名称现在将成为支持它们的数据库架构的一部分。因此，你现有的 Prisma 架构的含义将会改变。

¥After upgrading to Prisma ORM 3, the default naming convention for constraint and index names will change and your primary and foreign key names will now be part of the schema for databases that support them. Therefore the meaning of your existing Prisma schema will change.

在继续发展架构和数据库之前，你应该决定要在未来的项目中使用哪些约束和索引名称。

¥Before you continue to evolve your schema and your database, you should decide which names for constraints and indexes you want to use on your project going forward.

你可以保留数据库中存在的名称，也可以切换为使用 Prisma ORM 生成的名称，这些名称遵循新的命名约定。

¥You can either keep the names as they exist in your database or you can switch to use the names generated by Prisma ORM, which follow the new naming convention.

本页介绍升级到 Prisma ORM 3 后需要执行的手动升级步骤。你可以选择以下两个选项之一：

¥This page describes the manual upgrade steps that you need to perform after upgrading to Prisma ORM 3. You can pick either of the two options:

选项 1：我想保留现有的约束和索引名称

¥Option 1: I want to maintain my existing constraint and index names
选项 2：我想使用 Prisma ORM 的默认约束和索引名称

¥Option 2: I want to use Prisma ORM's default constraint and index names

选项 1：我想保留现有的约束和索引名称

¥Option 1: I want to maintain my existing constraint and index names

如果你想保持数据库不变并保留约束和索引的现有名称，你需要将它们拉入你的架构中，以便 Prisma ORM 能够识别它们。

¥If you want to keep your database unchanged and keep the existing names for constraints and indexes you need to pull them into your schema so Prisma ORM is aware of them.

保留现有名称的原因可能是：

¥Reasons to keep your existing names might be:

你必须遵循的命名约定

¥Naming conventions you have to follow
其他工具依赖名称

¥Other tooling relying on the names
个人喜好

¥Personal preference

要保留现有名称，请针对目标环境运行 prisma db pull。这将导致所有与 Prisma ORM 的约束和索引名称命名约定不匹配的名称被拉入你的架构中，作为其各自属性上的 map 参数。

¥To keep existing names, run prisma db pull against the target environment. This will result in all names that do not match Prisma ORM's naming convention for constraint and index names being pulled into your schema as map arguments on their respective attributes.

示例架构：

¥Example schema:

model User {
  id    Int    @id @default(autoincrement())
  name  String @unique
  posts Post[]
}

model Post {
  id         Int    @id @default(autoincrement())
  title      String
  authorName String @default("Anonymous")
  author     User?  @relation(fields: [authorName], references: [name])
}

检查你的开发数据库，使用底层数据库中与 Prisma ORM 的命名约定不匹配的约束和索引名称来填充 Prisma 架构：

¥Introspect your development database to populate the Prisma schema with constraint and index names in your underlying database that do not match Prisma ORM's naming convention:
```
npx prisma db pull
```
在此示例中，高亮的约束不符合 Prisma ORM 的默认命名约定，现在包含 map 属性字段：

¥In this example, the highlighted constraints did not conform to Prisma ORM's default naming convention and now include the map attribute field:
```
model User {
  id    Int    @id(map: "Custom_Constraint_Name") @default(autoincrement())
  name  String @unique
  posts Post[]
}

model Post {
  id         Int    @id @default(autoincrement())
  title      String
  authorName String @default("Anonymous")
  author     User?  @relation(fields: [authorName], references: [name], map: "Custom_Foreign_Key_Constraint")
}
```

选项 2：我想使用 Prisma ORM 的默认约束和索引名称

¥Option 2: I want to use Prisma ORM's default constraint and index names

如果你想保持 Prisma 架构干净，并且没有理由阻止你重命名数据库中的约束和索引，那么你可以创建迁移来更新名称。

¥If you want to keep your Prisma Schema clean and if you have no reasons preventing you from renaming constraints and indexes in your database, then you can create a migration to update the names.

运行 prisma migrate dev 创建迁移，将约束名称更新为 Prisma ORM 的默认值。

¥Run prisma migrate dev to create a migration updating the constraint names to Prisma ORM's defaults.

然后，如果你有生产环境也需要更新名称，请不要忘记对你的生产环境进行 prisma migrate deploy。下面的模式没有明确的约束或拼写出的索引名称，因此 Prisma ORM 将推断它们。

¥Afterwards, do not forget to prisma migrate deploy against your production environment if you have one to also update the names there. The schema below has no explicit constraint or index names spelled out, so Prisma ORM will infer them.

示例架构：

¥Example schema:

model User {
  name  String @id //inferred as User_pkey
  posts Post[]
}

model Post {
  id         Int    @id @default(autoincrement()) //inferred as Post_pkey
  authorName String @default("Anonymous")
  author     User?  @relation(fields: [authorName], references: [name]) //inferred as Post_authorName_fkey
}

运行 prisma migrate dev 命令生成新的迁移：

¥Run the prisma migrate dev command to generate a new migration:
```
npx prisma migrate dev
```
此迁移会重命名当前不遵循 Prisma ORM 命名约定的任何约束。

¥This migration renames any constraints that do not currently follow Prisma ORM's naming convention.
运行 prisma migrate deploy 命令将迁移应用到你的生产环境：

¥Run the prisma migrate deploy command to apply the migration to your production environment:
```
npx prisma migrate deploy
```

处理同一应用使用多个数据库环境的情况

¥Dealing with cases where more than one database environment is used for the same application

检查你的环境是否使用相同的名称

¥Checking whether your environments use identical names

由于 Prisma ORM 过去没有提供明确定义约束或索引名称的方法，因此你可能会面临不同数据库环境具有不同约束或索引名称的情况。

¥Since Prisma ORM did not offer a way to define constraint or index names explicitly in the past, you can face situations where your different database environments have differing constraint or index names.

为了检测到这一点：

¥In order to detect this:

创建当前 schema.prisma 文件的备份。

¥Create a backup of your current schema.prisma file.
通过使用 --schema 选项将结果保存到各自的单独文件中，针对每个数据库环境运行 prisma db pull。参见参考资料

¥Run prisma db pull against each database environment, by saving the results to their own separate files using the --schema option. See reference

然后，你可以手动检查这两个文件，也可以在 IDE 或终端中使用 diff 工具。如果你发现约束名称存在差异，则表明你的生产环境和本地环境不同步，应该保持一致。

¥Then you can either manually inspect both files or use a diff tool in your IDE or in the terminal. If you see differences in constraint names, your production and local environments are out of sync and should be aligned.

在以下示例中，Post 模型具有一个外键约束，其生产中的自定义名称与开发不匹配。

¥In the following example, the Post model has a foreign key constraint with a custom name in production that does not match development.

开发环境：

¥Development environment:

model Post {
  id         Int    @id @default(autoincrement())
  title      String
  authorName String @default("Anonymous")
  author     User?  @relation(fields: [authorName], references: [name], map: "Custom_Foreign_Key_Constraint")
}

生产环境：

¥Production environment:

model Post {
  id         Int    @id @default(autoincrement())
  title      String
  authorName String @default("Anonymous")
  author     User?  @relation(fields: [authorName], references: [name], map: "Custom_Production_Name")
}

如果环境的约束或索引名称不同，则调整环境

¥Aligning your environments if their constraint or index names differ

如果环境中的名称不同，最安全的选择是将开发环境与生产环境中的名称保持一致。这可确保无需对生产数据库执行任何更改。

¥If the names in your environments differ, the safest option is to align your development environment with the names in your production environment. This makes sure that no changes need to be performed on your production database.

为了实现这一目标：

¥In order to achieve this:

针对生产环境运行 prisma db pull 以提取约束和索引名称

¥Run prisma db pull against your production environment to pull in the constraint and index names
切换到开发并运行 prisma migrate dev 以创建新的迁移。你可以称该迁移为 migration-to-sync-names

¥Switch to development and run prisma migrate dev to create a new migration. You can call that migration migration-to-sync-names
切换到生产，并运行 prisma migrate resolve --applied migration-to-sync-names 将迁移标记为应用于生产

¥Switch to production, and run prisma migrate resolve --applied migration-to-sync-names to mark the migration as applied on production

你的迁移历史记录现在包含一个迁移，以确保你启动的任何新环境的名称包含与生产数据库相同的名称。Prisma ORM 知道不要将此迁移应用于生产，因为你已经将其标记为已应用。

¥Your migration history now contains a migration to ensure that the names of any new environments you spin up contain the same names as your production database. And Prisma ORM knows not to apply this migration to production since you already marked it as applied.

你的环境现已同步，你可以继续进行迁移用户的升级路径。这些可以让你选择未来的命名方案。

¥Your environments are now in sync and you can proceed to the upgrade paths for migrate users. These let you choose your future naming scheme.

选项 1：我想保留现有的约束和索引名称​

选项 2：我想使用 Prisma ORM 的默认约束和索引名称​

处理同一应用使用多个数据库环境的情况​

检查你的环境是否使用相同的名称​

开发环境：​

生产环境：​

如果环境的约束或索引名称不同，则调整环境​