[Database] post CRUD 서버 애플리케이션 만들기(2)

prisma migrate

prisma migration?

Prisma Migration은 데이터베이스 스키마 변경 사항을 안전하게 추적, 관리, 반영하기 위한 버전 관리 도구. 일반적인 SQL 문을 직접 작성하지 않고도 모델 변경을 코드 수준에서 관리할 수 있으며, 변경사항을 .sql 파일로 남겨 이력 추적 및 협업이 쉬워진다.

prisma에서 db 관리시 장점

1. 스키마 변경 이력 관리
   • 모든 스키마 변경사항이 migrations 폴더에 SQL 파일로 저장되어 추후 변경 내용을 추적할 수 있음.
2. 협업 시 일관된 DB 구조 유지
   • 여러 개발자가 동시에 작업할 때, 동일한 마이그레이션 기준을 유지할 수 있음.
3. 개발/운영 환경 분리 및 자동화 가능
   • 개발 DB, 프리뷰 DB, 운영 DB에 각각 알맞게 적용 가능하며, CI/CD 파이프라인과도 쉽게 통합됨.

prisma migration 과정

마이그레이션은 이렇게 진행된다.

① 브랜치 생성 및 개발 DB 마이그레이션

• main 브랜치에는 기존 migration이 2개 (init, user_table) 존재
• 새로운 기능 개발을 위해 ft/comments 브랜치 생성
• 새로운 모델 또는 필드 추가 후, prisma migrate dev 실행
  → 개발 DB에 반영되고, comments_table에 대한 새 SQL 파일 생성됨

② Pull Request 생성 → Preview DB 마이그레이션

• PR을 생성하면 Preview 환경에서 마이그레이션이 적용됨 (prisma migrate deploy)
  → 팀원/QA가 미리 DB 변경 사항을 확인할 수 있음

③ 브랜치 병합 및 운영 반영

• ft/comments 브랜치를 main에 병합
• 운영 DB에 prisma migrate deploy를 실행하여 마이그레이션을 정식 반영
  → production 환경에 안전하게 스키마가 적용됨

1. migration init

Supabase의 postgresql에 접근해서 데이터베이스 스키마를 가져옴

npx prisma db pull

 

 

prisma/migrations/0_init 디렉터리 생성

 

 

prisma 스키마 기반 마이그레이션 sql 생성

npx prisma migrate diff \
--from-empty \
--to-schema-datamodel prisma/schema.prisma \
--script > prisma/migrations/0_init/migration.sql

 

마이그레이션 정보 적용

npx prisma migrate resolve --applied 0_init

 

마이그레이션 정보 확인

npx prisma migrate status

 

마이그레이션 기록을 남겨놓으면 이전기록을 파악할수있고, 되돌릴수도있다.

2. 스키마 변경 (NOT NULL 적용)

film_comment, film_post, mention, notification, post_reaction 테이블을 변경해보겠다.

mention, notification 1:1 관계 추가 설명

mention, notification과 1:1 관계를 설정할 떄 주의할 점이 있다.

prisma 스키마에는 데이터베이스에는 따로 지정하지 않는 가상의 관계 관련 속성이 있다.
아래 표로 보면, mention 테이블의 경우 실제 데이터베이스에서는 notification 관련 속성이 없는데, prisma 스키마에서는 mention에서 notification을 조회할 수 있게 가상의 속성을 만들어두었다.

prisma는 1:1 관계에서 이 속성은 '?'를 붙이도록 강제했다.
이 부분은 prisma prisma schema를 만들 때, prisma의 엔진 이슈로 강제된 부분이고 데이터베이스의 설계를 변경하지 않기 때문에, 크게 걱정하지 않고 prisma의 물을 따라도 되겠다.

Further Reading:
https://www.prisma.io/docs/orm/prisma-schema/data-model/relations/one-to-one-relations#1-1-relations-in-the-database
https://github.com/prisma/prisma/issues/3747

3. 변경 후 마이그레이션

npx prisma migrate dev

개발용 데이터베이스에 적용한다.
개발용 데이터베이스는 git staging area와 비슷한 개념으로 보면 된다.

 

배포용 데이터베이스에 적용하는 것은 위험! 잘 되는지 충분히 확인하고 npx prisma migrate deploy로 배포를 할 것.
Futher Reading: https://www.prisma.io/docs/orm/prisma-migrate/understanding-prisma-migrate/mental-model

A mental model for Prisma Migrate | Prisma Documentation

 

migration.sql에서 schema.prisma에서 변경한(optional한 속성? 제거)부분이 확인된다.

4. 스키마 2차 변경 & 마이그레이션

다시 또 스키마를 변경해보자.

created_at에 현재시간을 기본값으로 설정하고,
updated_at에 업데이트된 시점의 현재시각을 설정하는것을 추가한다.

model film_comment {
  comment_id  Int       @id @default(autoincrement())
  post_id     Int
  customer_id Int
  content     String
  created_at  DateTime  @db.Timestamp(6) @default(now())
  updated_at  DateTime  @db.Timestamp(6)) @updatedAt
  customer    customer  @relation(fields: [customer_id], references: [customer_id], onDelete: NoAction, onUpdate: NoAction)
  film_post   film_post @relation(fields: [post_id], references: [post_id], onDelete: NoAction, onUpdate: NoAction)
  mention     mention[]
}

-- AlterTable
ALTER TABLE "film_comment" ALTER COLUMN "created_at" SET DEFAULT CURRENT_TIMESTAMP;

-- AlterTable
ALTER TABLE "film_post" ALTER COLUMN "created_at" SET DEFAULT CURRENT_TIMESTAMP;

-- AlterTable
ALTER TABLE "mention" ALTER COLUMN "created_at" SET DEFAULT CURRENT_TIMESTAMP;

-- AlterTable
ALTER TABLE "notification" ALTER COLUMN "created_at" SET DEFAULT CURRENT_TIMESTAMP;

-- AlterTable
ALTER TABLE "post_reaction" ALTER COLUMN "created_at" SET DEFAULT CURRENT_TIMESTAMP;

다시 마이그레이션 후 migration.sql을 확인해보면 created_at에 DEFAULT CURRENT_TIMESTAMP가 잘 적용된 것을 확인할 수 있다. 하지만 @updatedAt은 적용되지 않았다.

 

@updatedAt은 SQL에 없는 Prisma 고유의 문법으로, Prisma Client를 통해 데이터를 수정할 때 자동으로 해당 필드의 값을 현재 시각으로 갱신해준다.

SQL 수준에서 updated_at을 자동으로 갱신하려면 트리거(Trigger)를 설정해야 한다.
하지만 Prisma를 사용하는 경우에는 이러한 트리거를 따로 설정하지 않아도 되며,
@updatedAt 필드가 Prisma Client의 update() 호출 시 자동으로 처리해준다.

 

(단일 ORM 기반의 애플리케이션이라면 Prisma 방식으로 관리하는 것이 간편하고,
여러 애플리케이션에서 데이터베이스를 공유하거나 SQL 레벨에서 일관성을 유지하고 싶다면 트리거 사용이 유리하다.)