피드로 돌아가기
JPA 덕분에 DB에서 삽질한 이야기
컬리 기술블로그컬리 기술블로그
Backend

JPA 덕분에 DB에서 삽질한 이야기

JPA 엔티티의 UUID ID 컬럼을 BINARY(255)로 정의해 저장된 데이터를 조회하지 못하는 문제를 BINARY(16) 컬럼 정의로 해결

2020년 7월 6일10intermediate

Context

JPA로 작성한 엔티티에서 UUID를 ID로 사용할 때 H2 인메모리 데이터베이스에서는 정상 동작하지만 MySQL 개발 데이터베이스에서는 저장된 데이터를 조회할 수 없는 이상 현상이 발생했다.

Technical Solution

  • UUID 컬럼의 BINARY 길이를 255에서 16으로 명시적 지정: @Column(columnDefinition = "BINARY(16)")을 UUID 필드에 추가
  • 테스트 케이스를 통해 1번 기능(저장)은 H2 데이터베이스, 2번 기능(조회)은 MySQL 데이터베이스에서 각각 검증되어 환경 차이 파악
  • MySQL BINARY 타입의 우측 패딩 동작 확인: BINARY(255)로 저장 시 16바이트 UUID는 239바이트의 NULL 문자로 우측 패딩되어 조회 쿼리와 바이너리 값이 불일치
  • RFC 4122 표준 기반으로 UUID는 정확히 16바이트로 구성됨을 확인하고 컬럼 정의에 반영
  • Hibernate의 기본 동작(UUID를 binary로 저장)과 MySQL 문서의 BINARY 우측 패딩 동작을 조합하여 근본 원인 파악

Key Takeaway

ORM 프레임워크의 기본 동작과 데이터베이스별 데이터 타입 처리 방식의 불일치는 다양한 환경(H2, MySQL 등)에서 발견되지 않을 수 있으므로, 바이너리 데이터 컬럼 사용 시 명시적인 길이 정의가 필수다.


JPA에서 UUID를 ID로 사용하는 엔티티를 작성할 때 @Column(columnDefinition = "BINARY(16)")을 명시적으로 정의하면, H2와 MySQL 같은 서로 다른 데이터베이스 환경에서 저장 및 조회가 일관되게 동작한다.

원문 읽기