命名约束升级路径
升级到 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 模式整洁,并且没有任何原因阻止你在数据库中重命名约束和索引,那么你可以创建一个迁移来更新名称。
运行 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 知道不要将此迁移应用于生产环境,因为你已将其标记为已应用。
你的环境现在已同步,你可以继续执行 迁移用户的升级路径。这些让你可以选择未来的命名方案。