命名约束升级路径
升级到 Prisma ORM 3 后,约束和索引名称的默认命名约定将更改,并且您的主键和外键名称现在将成为支持它们的数据库的模式的一部分。因此,您现有的 Prisma 模式含义将发生变化。
在您继续发展您的模式和数据库之前,您应该决定今后要在项目中使用哪些约束和索引名称。
您可以保留数据库中现有的名称,也可以切换到使用 Prisma ORM 生成的名称,这些名称遵循新的命名约定。
此页面描述了升级到 Prisma ORM 3 后需要执行的手动升级步骤。您可以选择这两个选项中的任何一个
- 选项 1: 我想保留我现有的约束和索引名称
- 选项 2: 我想使用 Prisma ORM 的默认约束和索引名称
选项 1:我想保留我现有的约束和索引名称
如果您想保持数据库不变并保留约束和索引的现有名称,则需要将它们拉入您的模式中,以便 Prisma ORM 知道它们。
保留现有名称的原因可能是
- 您必须遵循的命名约定
- 依赖名称的其他工具
- 个人喜好
要保留现有名称,请对目标环境运行 prisma db pull
。这将导致所有不符合 Prisma ORM 约束和索引名称命名约定的名称被拉入您的模式,作为其相应属性上的 map
参数。
-
示例模式
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 模式
npx prisma db pull
在此示例中,突出显示的约束不符合 Prisma ORM 的默认命名约定,现在包括
map
属性字段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 的默认约束和索引名称
如果您想保持 Prisma Schema 干净,并且您没有理由阻止您重命名数据库中的约束和索引,那么您可以创建一个迁移来更新名称。
运行 prisma migrate dev
创建一个迁移,将约束名称更新为 Prisma ORM 的默认值。
之后,如果您有生产环境,请不要忘记对生产环境运行 prisma migrate deploy
以更新那里的名称。下面的模式没有明确说明任何约束或索引名称,因此 Prisma ORM 将推断它们。
-
示例模式
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
命令以生成新的迁移npx prisma migrate dev
此迁移将重命名所有当前不遵循 Prisma ORM 命名约定的约束。
-
运行
prisma migrate deploy
命令将迁移应用于您的生产环境npx prisma migrate deploy
处理对同一应用程序使用多个数据库环境的情况
检查您的环境是否使用相同的名称
由于 Prisma ORM 以前没有提供明确定义约束或索引名称的方法,因此您可能会遇到不同的数据库环境具有不同约束或索引名称的情况。
为了检测这一点
- 创建当前
schema.prisma
文件的备份。 - 通过使用
--schema
选项将结果保存到他们自己的单独文件中,对每个数据库环境运行prisma db pull
。 参见参考
然后,您可以手动检查两个文件,也可以在 IDE 或终端中使用 diff
工具。如果您在约束名称中看到差异,那么您的生产和本地环境不同步,应该对齐。
在以下示例中,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")
}
生产环境:
model Post {
id Int @id @default(autoincrement())
title String
authorName String @default("Anonymous")
author User? @relation(fields: [authorName], references: [name], map: "Custom_Production_Name")
}
如果您的环境的约束或索引名称不同,则对齐环境
如果您的环境中的名称不同,最安全的选项是将您的开发环境与生产环境中的名称对齐。这确保您不需要对生产数据库进行任何更改。
为了实现这一点
- 对生产环境运行
prisma db pull
以拉入约束和索引名称 - 切换到开发并运行
prisma migrate dev
创建新的迁移。您可以将该迁移命名为migration-to-sync-names
- 切换到生产,并运行
prisma migrate resolve --applied migration-to-sync-names
以将迁移标记为已应用于生产
您的迁移历史现在包含一个迁移,以确保您启动的任何新环境的名称与您的生产数据库的名称相同。由于您已经将它标记为已应用,因此 Prisma ORM 知道不要将此迁移应用于生产。
您的环境现在已同步,您可以继续进行 迁移用户的升级路径。这些允许您选择将来的命名方案。