https://www.prisma.io/docs/orm/getting-started

Prisma

pnpm add prisma tsx @types/pg --save-dev
pnpm add @prisma/client @prisma/adapter-pg dotenv pg

pull と migrate / push

両者は「方向」が逆
pull - DBの構造を元にSchemaを作成
migrate / push - Schemaを元にDBを変更
- migrateは履歴が残るので安全だが、pushは何も残らない

Prisma v7

prisma.ts ：

import { PrismaPg } from "@prisma/adapter-pg";
import { PrismaClient } from "./generated/prisma";

const adapter = new PrismaPg({
  connectionString: process.env.VERCEL_DATABASE_URL,
});

const globalForPrisma = global as unknown as {
  prisma: PrismaClient;
};

export const prisma =
  globalForPrisma.prisma ||
  new PrismaClient({
    adapter,
  });

if (process.env.NODE_ENV !== "production") globalForPrisma.prisma = prisma;

dotenv-cli：

pnpm add -D dotenv-cli

next.config.ts ：

import "dotenv/config";
import { defineConfig, env } from "prisma/config";

if (process.env.NODE_ENV !== "production") {
  import("dotenv").then((dotenv) => {
    dotenv.config({ path: ".env.development" });
  });
}

export default defineConfig({
  schema: "prisma/schema.prisma",
  migrations: {
    path: "prisma/migrations",
  },
  datasource: {
    url: env("DATABASE_URL"),
  },
});

schema

v7~で環境変数にDBのスキーマを書くと、そのスキーマではなくpulbicスキーマの構造が取得される

対策１（推奨）： prisma.ts

const adapter = new PrismaPg(
  {
    connectionString: process.env.DATABASE_URL,
  },
  {
    schema: "", // 追加
  }
);

対策２：

generator client {
  provider = "prisma-client"
  output   = "./generated/prisma"
}

datasource db {
  provider = "postgresql"
  schemas  = ["scheme_name"]
}

model User {
  ...
  @@schema("scheme_name")
}

@@schema("")をすべてのモデルに書く

スクリプトコマンド

  "scripts": {
    "db:pull": "dotenv -e .env.development.local -- npx prisma db pull",
    "db:generate": "dotenv -e .env.development.local -- npx prisma generate",
    "db:push": "dotenv -e .env.development.local -- npx prisma db push",
    "db:studio": "dotenv -e .env.development -- npx prisma studio"
    "db:migrate": "dotenv -e .env.development -- npx prisma migrate dev"
  },

migrateのやり方に慣れたらdb pushコマンドは削除した方が良い

エラー

prisma.config.ts

TypeScript/JavaScript module. Error: PrismaConfigEnvError: Cannot resolve environment variable: DATABASE_URL.

スクラッチで始めたアプリで発生。これまで遭遇したことがない。URL文字列やPrisma関係の設定は間違っていない。

対策：以下を prisma.config.tsの上部に追加

import dotenv from "dotenv";
import fs from "fs";

if (fs.existsSync(".env")) {
  dotenv.config({ path: ".env" });
} else {
  dotenv.config({ path: ".env.development" });
}

serverAction

TypeError: The "payload" argument must be of type object. Received null

上記のエラーはserverActionに関連したエラーであることが多い

原因１：

使っていない(Schema)モデル内の要素がある

対策：

使うか確定的ではない要素はモデル定義でname String?のようにする
あるいは使用していない要素に空文字やbooleanを渡す

原因２：

serverAction内で使っている型とモデルの型が違う

export const deleteAction = async (formData: FormData) => {
  const id = Number(formData.get("id"));

モデルの型に変換する

.env以外の環境変数が読まれない

.env.local や .env.developmentに環境変数（ DATABASE_URL ）があると npx prisma db pull / generate時に以下のエラーが出る：

Error: Prisma schema validation - (get-config wasm)
Error code: P1012
error: Environment variable not found: DATABASE_URL.

原因：

Prismaは.envしか読まないため
- .evn.developmentも読まない

簡単な対策：

.envを作成しDATABASE_URLだけペースト
Prisma以外の環境変数は .env.development(.local) から引き続き読み込まれる

dotenv-cli

npm i -D dotenv-cli
package.json のscriptにコマンドを追加

  "scripts": {
    "db:pull": "dotenv -e .env.development.local -- npx prisma db pull",
    "db:generate": "dotenv -e .env.development.local -- npx prisma generate",
    "db:studio": "dotenv -e .env.development -- npx prisma studio"
    "db:migrate": "dotenv -e .env.development -- npx prisma migrate dev"
  },

以降はnpm run db:pull(or generate) で実行する

dotenv -e .env.development.local

-e で別の environment file を指定するという意味

prisma.config.ts：

import "dotenv/config";
import { defineConfig, env } from "prisma/config";

if (process.env.NODE_ENV !== "production") {
  import("dotenv").then((dotenv) => {
    dotenv.config({ path: ".env.development" });
  });
}

export default defineConfig({
  schema: "prisma/schema.prisma",
  migrations: {
    path: "prisma/migrations",
  },
  datasource: {
    url: env("DATABASE_URL"),
  },
});

* migrate

"db:migrate": "dotenv -e .env.development -- npx prisma migrate dev"

pull/pushコマンドで管理している既存のDBに対してmigrateコマンドを実行するとデータを全削除することが促される。Yキーを押した時点でDB ( schema )からデータがすべて削除される。

migrate：

npx prisma migrate devでprisma.schemaのモデルをもとに、DBにテーブルが作られる。
npx prisma db pushとの違いは、migrate dev実行時に変更履歴がsqlファイルとして残る点
migrateが行われると、DBに作成された _prisma_migrationsテーブルにデータが追加される。

開発時と本番でDBを分ける

docker-compose.yml

version: '3.9'

services:
  db:
    image: postgres:16
    container_name: dev_db
    ports:
      - "5432:5432"
    environment:
      POSTGRES_USER: user
      POSTGRES_PASSWORD: pass
      POSTGRES_DB: dev_db
    volumes:
      - pgdata:/var/lib/postgresql/data

volumes:
  pgdata:

開発時はdocker compose up -dでコンテナのPostgresを使う
*Docker理解の途中。詳細Docker個別メモで

.env(.local)

DATABASE_URL="postgresql://user:pass@localhost:5432/dev_db?schema=test"

*（開発時）schemaを使う場合、環境変数にschemaを書かないとmigrate devでpublicスキーマにテーブルが作成される。
Vercel等の環境変数にはNeon等の本番用DATABASE_URLをペーストする

package.json

"vercel-build": "prisma generate && prisma migrate deploy && next build"

package.jsonに追加
Vercelダッシュボードのビルドコマンドを上記に変更

migrateを途中から取り入れる場合

前提のセットアップは上記の流れ

1 . 環境変数で既存データがあるDBの接続URLに切り替えてdb pull をして prisma.schemaにモデルを作成

2 . prisma/migrations/0_initフォルダを作成

3 .

npx dotenv -q -e .env.development -- npx prisma migrate diff \
--from-empty \
--to-schema prisma/schema.prisma \
--script > prisma/migrations/0_init/migration.sql

*4（重要）.

migrations/0_initに作成された migration.sql１行から以下の行を削除

[dotenv@17.2.3] injecting env (0) from .env.development -- tip: ✅ audit secrets and track compliance: https://dotenvx.com/ops

5 .

npx dotenv -q -e .env.development -- npx prisma migrate resolve --applied 0_init

事前に色々いじっていて本番DBのテーブルに _prisma_migrationsがある場合は慎重に削除する。

6 . *"接続URLをコンテナのものに切り替えてから"以下を実行

pnpm run db:migrate 
  or 
dotenv -e .env.development -- npx prisma migrate dev

コンテナのテーブル（スキーマ）が空じゃない場合はエラーが出るので、削除してから再実行

7 . Githubにpushして migrate deploy を本番DBに実行させる

以降の流れ：

開発環境でschema.prismaに変更を行ったら、 migrate devでmigrationファイルを作成
Githubにpushして初めて本番DB側のテーブル構造が変わる

エラーが出るケース：

Vercelにデプロイしたときに migrate deployでエラーが出る頻出ケースが、idのStringをIntに変えたようなケース。DBには既にStringのidとしてデータがあるので、それに対する警告。
- 対策はモデルを変えたテーブルのデータを全て消すこと。現状他の対策がわからないのでプロダクションレベルではmigration管理ではこのような変更が出来ないということになる。

vercelにデプロイする場合

Prisma Client

Prismaを使ったNextjsアプリをそのままVercelにデプロイするとエラーになる

原因：

Prisma Client はschema.prismaを元に生成されるコードを必要とするが、Vercelのビルドコマンドはnext build だけなので、ビルド時にPrisma Client が未生成になりエラーが出る

対策 1：

Vercelダッシュボードの build command を以下にoverride

npx prisma generate && turbo run build

対策２：

package.jsonの scripts に以下を追加

  "scripts": {
    "postinstall": "npx prisma generate"
  },

開発環境でターミナル使用に毎回 postinstall が走るので「対策１」の方が良い

connection_limit

Error occurred prerendering page. Read more: https://nextjs.org/docs/messages/prerender-error
Error [PrismaClientKnownRequestError]:
Timed out fetching a new connection from the connection pool. More info: http://pris.ly/d/connection-pool (Current connection pool timeout: 10, connection limit: 3)

原因：

多くの静的ページをSSGするアプリで起こった
ビルド時に静的ページのプリレンダリングを行う際に並行処理で同時にPrismaへの接続が行われるので、すぐにデフォルトのconnection_limit = 3 に達したのが原因

対策：

環境変数のDATABASE_URL の後ろに以下を追加

&connection_limit=5

これでビルドエラーがなくなった

The database server was reached but timed out

migrateを取り入れてから発生。本格的な対策ではない気がするが以下でこのエラーは消える

対策：

Vercelのダッシュボードから環境に以下を追加

PRISMA_SCHEMA_DISABLE_ADVISORY_LOCK=true

モデルの型を使用

Schema.prismaのモデルをそのまま型として使える

import { User } from "@/prisma/generated/prisma";

// User 型として使用
const exampleUser: User = {
  id: "asd",
  name: "rwe",
  age: 25,
};

prisma clientを生成すれば補完でモデルの型が出る

リレーションも含めた型

import { Prisma } from "@/prisma/generated/prisma";

type Props = Prisma.ItemsGetPayload<{
  include: { categories: { include: { category: true } } };
}>[];

モデルの内容

@map

  userId             String  @map("user_id")

「Prismaで使うフィールド名」と「実際のデータベースのカラム名」が違うときに対応づける」ための仕組み
上記はDBではuser_id だが、補完ではuserIdとして使える
DBのカラムはsnake_caseが一般的な為 @mapを使うことがある

@relation

 model User {
  id    Int    @id @default(autoincrement())
  name  String

  posts Post[] // User は複数の Post を持てる
}

model Post {
  id      Int    @id @default(autoincrement())
  title   String
  content String

  authorId Int     // 外部キー
  author   User    @relation(fields: [authorId], references: [id])
}

上記は誰の投稿かを示す情報（＝外部キー）はPostが持つ
- 1対多の関係では「多」の方（Post）が外部キーを持つ

fields:：外部キー
references:：外部キーの参照先

@enum

enum Role {
  USER
  ADMIN
}

model User {
  type Role
}

@enumはDB側に設定を追加するので、後で変更が大変になる場合がある。まだ設計が固まっていない場合はzodでenumを作った方がいい

import { z } from "zod";

const Role = z.enum(["USER", "ADMIN"]);

@@unique([ , ])

model User {
  id    Int    @id @default(autoincrement())
  email String @unique
  memos Memo[]
}

model Memo {
  id     Int    @id @default(autoincrement())
  userId Int
  title  String
  body   String?

  user   User   @relation(fields: [userId], references: [id])

  @@unique([userId, title])
}

Userが複数いることを想定すると、titleをUniqueにしてしまったら複数ユーザーが同じtitleを作れないので不便になる。
@@uniqueで user_id と title を紐付けることで、「各ユーザーは同一のtitleを作れない」ということを実現できる。
- titleの方はnullableでも構わない

idはモデル側で自動生成

schema.prisma：

model Bookmark {
  id            String

このようにしている時にCRUD操作を行う時に、コード側でidの生成を行わないといけない

  await prisma.item.create({
    data: {
      id: uuid(),
    },
  });

以下のようにするとコード側にid生成ロジックを書かなくて済む

model Bookmark {
  id            String   @id @default(cuid())

取得データの制御

omit

  const Lists: Omit<Lists, "user_id" | "role">[] =
    await prisma.Lists.findMany({
      where: { role: "admin" },
      omit: {
        user_id: true,
        role: true,
      },
    });

上記はadminのデータを取得しつつ、返すのは user_id と role を除外したもの
sanitize用の関数を作る必要が無い

Prisma：スタート , エラーや注意点 , tips

Prisma：スタート , エラーや注意点 , tips