名前付き制約のアップグレードパス

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スキーマをpopulateします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スキーマをクリーンに保ちたい場合、およびデータベース内の制約とインデックスの名前を変更することを妨げる理由がない場合は、移行を作成して名前を更新できます。

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は、すでに適用済みとしてマークされているため、この移行を本番環境に適用しないことを認識しています。

環境が同期され、migrateユーザー向けのアップグレードパスに進むことができます。これにより、将来の命名スキームを選択できます。

オプション1：既存の制約名とインデックス名を維持したい​

オプション2：Prisma ORMのデフォルトの制約名とインデックス名を使用したい​

同じアプリケーションに複数のデータベース環境が使用されている場合の対処法​

環境が同一の名前を使用しているかどうかを確認する​

開発環境：​

本番環境：​

環境の制約名またはインデックス名が異なる場合、環境を調整する​