命名约束升级路径
升级到 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 模式,其中包含与 Prisma ORM 命名约定不匹配的约束和索引名称
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
文件的备份。 - 针对每个数据库环境运行
prisma db pull
,通过使用--schema
选项将结果保存到它们自己的单独文件中。 请参阅参考
然后,您可以手动检查这两个文件,或者在 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 知道不要将此迁移应用到生产环境,因为您已经将其标记为已应用。
您的环境现在已同步,您可以继续执行 migrate 用户的升级路径。 这些可以让您选择未来的命名方案。