名前付き制約のアップグレードパス
Prisma ORM 3 にアップグレードすると、制約名とインデックス名のデフォルトの命名規則が変更され、サポートされているデータベースでは、主キー名と外部キー名がスキーマの一部になります。そのため、既存のPrismaスキーマの意味が変わります。
スキーマとデータベースの進化を続ける前に、今後プロジェクトで使用する制約名とインデックス名を決定する必要があります。
データベースに存在する名前を維持することも、新しい命名規則に従うPrisma ORMが生成する名前を使用するように切り替えることもできます。
このページでは、Prisma ORM 3 にアップグレードした後に実行する必要がある手動アップグレード手順について説明します。以下の2つのオプションのいずれかを選択できます。
- オプション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
ファイルをバックアップします。 --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は、あなたがすでに適用済みとしてマークしたため、このマイグレーションを本番環境に適用しないことを認識しています。
これで環境が同期され、マイグレートユーザー向けのアップグレードパスに進むことができます。これにより、今後の命名規則を選択できます。