드림코딩의 Github Actions를 참고해서 작성하였습니다.

Github Actions 는 특정한 이벤트가 발생했을 때 내가 원하는 일을 자동으로 수행할 수 있도록 만들어주는 도구입니다.

주요 개념

[ Events ]

어떤 일이 발생했을 때 수행할 것인지를 지정합니다. 이때 이벤트에는 깃허브에서 발생하는 대부분의 이벤트를 지정할 수 있습니다. 예를 들어 특정 브랜치에 커밋을 하거나 머지를 하는 등의 이벤트를 지정할 수 있습니다.

[ Workflows ]

특정한 이벤트가 발생했을 때 어떤 일을 수행할 지를 지정합니다. Workflows 안에는 Job 이 있는데 하나의 workflow 안에는 하나 이상의 job 을 가질 수 있습니다.

.github/workflows 디렉토리에 yaml 파일을 만들고 여기에 작성합니다. 파일명은 아무거나 지정해도 됩니다.

[ Jobs ]

Workflows 의 Job 은 동시에 병렬적으로 수행됩니다. 반대로 순차적으로 진행하도록 지정하는 것도 가능합니다.

하나의 Job 안에는 어떤 순서로 Job 이 실행되어야 하는지 Step 을 지정할 수 있습니다. 쉘 스크립트를 사용해서 어떤 step 을 해야 하는지 명시해줄 수 있습니다. 또 actions 를 사용할 수 있습니다.

[ Actions ]

step 에는 직접만든 Action 을 사용할 수 있지만 Github Actions 에는 우리가 재사용할 수 있는, 공개적으로 오픈된 액션들이 존재하며, actions/ 으로 시작합니다.

[ Runners ]

지정한 Job 들을 실행하는 것이 바로 Runner( VM ) 입니다. 각각의 Job 들은 독립적인 각각의 Runner 라는 컨터이너에서 실행됩니다.

yml 파일 형태

name: [workflow 이름]
on: [이벤트 지정]
jobs: 
    [job 이름]:
        runs-on: [어떤 Runner(VM) 를 사용할 것인지]
        steps: [어떤 순서대로 job 을 실행해야 하는지 step 을 지정]  
            ## step 1
            - uses:
            ## step 2
            - name: [step 이름 지정]
              uses:
              with:
            ## step 3
            - name: [step 이름 지정]  
              run: 
            ...

Github Actions 사용하기

1. Github Secrets( 환경변수 ) 설정

Settings ➜ Secrets and Variables ➜ Actions 에 들어가서 Github Actions 에 쓰일 환경변수를 지정합니다.

2. Workflow 생성

Actions ➜ Java with Gradle 을 선택하면 어느 정도 작성되어 있는 yml 파일을 생성할 수 있습니다. 상단의 set up a workflow yourself 를 선택하면 처음부터 본인이 작성할 수 있습니다.

3. Workflow 작성

# Workflow 이름
name: CI/CD with Gradle

# Event 지정
on:
  push:
    branches: [ "main" ]

# Workflow 내 Job 을 정의
jobs:
  # Job 의 이름
  CI-CD-build:
    # Runner 환경 정의
    runs-on: ubuntu-latest

    # Step 정의
    steps:
    # 정의된 Actions 의 체크아웃 사용
    - uses: actions/checkout@v4

    # 1. jdk 세팅
    - name: Set up JDK 17
      uses: actions/setup-java@v4
      with:
        java-version: '17'
        distribution: 'temurin'

    # 2. Gradle Caching
    - name: Gradle Caching
      uses: actions/cache@v3
      with:
        path: |
          ~/.gradle/caches
          ~/.gradle/wrapper
        key: ${{ runner.os }}-gradle-${{ hashFiles('**/*.gradle*', '**/gradle-wrapper.properties') }}
        restore-keys: |
          ${{ runner.os }}-gradle-

    # 3. craete firebase key
    - name: create firebase key
      run: |
        cd ./src/main/resources
        ls -a .
        touch ./firebaseKey.json
        echo "${{ secrets.FIREBASE_KEY }}" > ./firebaseKey.json
      shell: bash

    # 4. Gradle build
    - name: Build with Gradle Wrapper
      run: |
          chmod +x ./gradlew
          ./gradlew clean build -x test

    # 5. docker build & push
    - name: docker build and push
      run: |
          docker login -u ${{ secrets.DOCKER_USERNAME }} -p ${{ secrets.DOCKER_PASSWORD }}
          docker build -f Dockerfile -t ${{ secrets.DOCKER_USERNAME }}/vitalroutes-spring ./
          docker push ${{ secrets.DOCKER_USERNAME }}/vitalroutes-spring

    # 6. Docker Compose Start
    - name: SSH into Ubuntu Server
      uses: appleboy/ssh-action@master
      with:
        host: ${{ secrets.SERVER_HOST }}
        username: ${{ secrets.SERVER_USERNAME }}
        password: ${{ secrets.SERVER_PASSWORD }}
        script: |
          docker-compose stop
          docker rm -f $(docker ps -qa)
          docker pull ${{ secrets.DOCKER_USERNAME }}/vitalroutes-spring
          docker-compose up -d

workflow 이름

# Workflow 이름
name: CI/CD with Gradle

workflow 의 이름을 지정하면 Actions 에 들어갔을 때 해당 이름으로 workflow 가 생성된 것을 확인할 수 있습니다.

Jobs 이름

# Event 지정
on:
  push:
    branches: [ "main" ]

# Workflow 내 Job 을 정의
jobs:
  # Job 의 이름
  CI-CD-build:

수행된 workflow 를 들어가면 Jobs 의 이름이 지정된 것을 볼 수 있고, 우측에 보면 on push 라고 되어 있습니다.

이벤트를 main 브랜치에 push 한 경우에 실행되도록 했기 때문에 정상적으로 실행된 것을 확인할 수 있습니다.

Runner 환경 정의

# Workflow 내 Job 을 정의
jobs:
  # Job 의 이름
  CI-CD-build:
    # Runner 환경 정의
    runs-on: ubuntu-latest

runs-on 으로 runner 가 수행될 환경을 지정합니다. 저는 우분투 서버를 사용하기 때문에 ubuntu 로 지정하였습니다.

step 정의

steps:
    # 정의된 Actions 의 체크아웃 사용
    - uses: actions/checkout@v4

    # 1. jdk 세팅
    - name: Set up JDK 17
      uses: actions/setup-java@v4
      with:
        java-version: '17'
        distribution: 'temurin'

steps 를 이용해 job 안에서 수행할 작업들을 지정합니다. 먼저 미리 정의된 action 을 활용하기 위해 actions 를 이용해 체크아웃을 합니다.

그 후 runner 는 각각의 독립적인 환경이기 때문에 JDK 를 setup 합니다.

Gradle 캐싱

# 2. Gradle Caching
    - name: Gradle Caching
      uses: actions/cache@v3
      with:
        path: |
          ~/.gradle/caches
          ~/.gradle/wrapper
        key: ${{ runner.os }}-gradle-${{ hashFiles('**/*.gradle*', '**/gradle-wrapper.properties') }}
        restore-keys: |
          ${{ runner.os }}-gradle-

gradle 캐싱을 수행합니다. 해당 step을 작성하면 빌드가 조금 빠르다고 합니다.

firebaseKey 생성

# 3. craete firebase key
    - name: create firebase key
      run: |
        cd ./src/main/resources
        ls -a .
        touch ./firebaseKey.json
        echo "${{ secrets.FIREBASE_KEY }}" > ./firebaseKey.json
      shell: bash

기존에는 로컬에서 테스트를 했기 때문에 main/resources 에 firebaseKey 파일이 있었는데 github 리포지토리에는 존재하지 않기 때문에 해당 파일을 생성해줍니다.

이때 Github Secret 에 지정한 환경변수인 FIREBASE_KEY 를 참조하도록 하였습니다. FIREBASE_KEY 는 파일의 내용을 붙여넣었으며, " 를 인식하기 위해서는 \" 를 사용해야 합니다.

// 기존 파일 내용
{
  "type": "service_account",
  "project_id": "...",
}

// secret 에 작성한 내용
{
  \"type\": \"service_account\",
  \"project_id\": \"...\",
}

COPY src/main/resources/firebaseKey.json firebaseKey.json

이 과정을 거치면 /main/resources 에 파일이 생성되며, 기존에 dockerfile 에 작성한 위의 명령어가 수행되어 도커 이미지 생성 시에 정상적으로 파일이 복사됩니다.

gradle build

# 4. Gradle build
    - name: Build with Gradle Wrapper
      run: |
          chmod +x ./gradlew
          ./gradlew clean build -x test

gradle 빌드를 수행합니다. 이때 chmod 를 통해 실행 권한을 부여해야 합니다.

도커 이미지 build & push

# 5. docker build & push
    - name: docker build and push
      run: |
          docker login -u ${{ secrets.DOCKER_USERNAME }} -p ${{ secrets.DOCKER_PASSWORD }}
          docker build -f Dockerfile -t ${{ secrets.DOCKER_USERNAME }}/vitalroutes-spring ./
          docker push ${{ secrets.DOCKER_USERNAME }}/vitalroutes-spring

docker image 를 build 하고 push 하는 작업입니다. 해당 명령어에 필요한 USERNAME 과 PASSWORD 는 github secret 에 정의되어야 합니다.

docker-compose 실행

 # 6. Docker Compose Start
    - name: SSH into Ubuntu Server
      uses: appleboy/ssh-action@master
      with:
        host: ${{ secrets.SERVER_HOST }}
        username: ${{ secrets.SERVER_USERNAME }}
        password: ${{ secrets.SERVER_PASSWORD }}
        script: |
          docker-compose stop
          docker rm -f $(docker ps -qa)
          docker pull ${{ secrets.DOCKER_USERNAME }}/vitalroutes-spring
          docker-compose up -d

그 후 서버에 접속하여 새로운 이미지를 pull 받고, docker-compose 를 실행하는 과정입니다. 이때 다른 사람의 정의한 action 을 사용하도록 uses 에 작성하였습니다.

먼저 서버의 정보를 with 에 작성하고, 서버에서 실행할 명령어들을 script 에 작성합니다.

docker-compose logs -f -t

그 후 서버에 접속해서 위 명령어를 입력하면 로그를 확인할 수 있습니다.

참고> docker 권한 오류

err: permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock: Get "http://%2Fvar%2Frun%2Fdocker.sock/v1.24/containers/json?all=1": dial unix /var/run/docker.sock:

위처럼 권한 오류가 뜨는 경우에는 아래 명령어를 통해 docker.sock 의 권한을 수정하면 됩니다.

sudo chmod 666 /var/run/docker.sock

최종 구조

지금까지 총 4단계에 걸쳐 서버 구축, Docker-Compose, NGINX 및 HTTPS 설정, Github Actions 를 진행하였고, 자동화된 CI/CD 구축을 완료하였습니다. 최종적인 구조는 위와 같습니다.

HTTPS

브라우저에서 서버로 데이터를 전송할 때 HTTP 를 사용하면 입력한 그대로 누구든 알아볼 수 있게 전달됩니다. 만약 로그인 정보가 위처럼 전달되면 보안 상 좋지 않습니다.

그래서 HTTPS 를 사용하는데 HTTPS 는 위처럼 서버로 전달하는 정보들을 암호화해서 보내기 때문에 다른 사람이 보더라도 알아볼 수 없습니다. 이때 정보를 암호화할 때는 대칭키 암호화 방식을 사용하는데 이는 아래에서 살펴보도록 하겠습니다.

대칭키 암호화

대칭키 암호화는 암호키와 복호화키가 동일하며, 대칭키는 통신 주체들 사이마다 필요합니다. 서버와 브라우저가 동일한 대칭키를 가지고 있어야 브라우저에서 대칭키로 암호화 한 정보를 서버에서 복호화할 수 있습니다.

만약 대칭키가 노출된다면 대칭키를 가진 누군가가 암호화 된 정보를 볼 수 있게 되기 때문에 통신 당사자 간 대칭키를 안전하게 공유하는데 많은 노력이 필요한데 이를 해결할 수 있는 것이 바로 DH( Diffie-Hellman ) 알고리즘이며, 안전하게 대칭키를 생성하기 위해 공개키 암호화 방식을 사용합니다.

아래에서 공개키 암호화 방식과 인증서를 살펴본 뒤, 공개키 암호화 방식을 이용해서 대칭키를 생성하는 방법에 대해 알아보도록 하겠습니다.

공개키 암호화

공개키 암호화 방식에는 암호화, 복호화에 두 가지 키가 사용됩니다. 하나는 공개키이고 다른 하나는 개인키인데 만약 공개키로 암호화하면 개인키로 복호화가 가능하고, 개인키로 암호화하면 공개키로 복호화할 수 있습니다.

예를 들어, 브라우저가 서버의 공개키로 암호화해서 전송하면 서버는 자신의 개인키로 이를 복호화해서 정보를 확인할 수 있게 됩니다.

추가적으로 개인키로 암호화하고, 자신의 공개키로 복호화할 수 있게 하는 것은 보통 송신자가 누구인지에 대한 정보가 필요할 때 사용하는데 대표적인 예시로 디지털 서명이 있습니다.

인증서

신뢰할 수 있는 기관에서 서버의 공개키를 검증해준다면 이를 기준으로 안전하게 서버를 이용할 수 있게 됩니다. 이를 위해서 사이트는 인증서가 필요합니다. 인증서란 인증기관( CA ) 에서 사이트에 발급하는 문서입니다.

인증서를 발급받기 위해 사이트에서 인증기관에 사이트 정보와 사이트의 공개키를 전달합니다. 인증 기관에서는 전달 받은 데이터를 검증하고, 검증이 완료되었다면 인증기관의 개인키로 서명을 하고 인증서를 생성합니다. 생성된 인증서는 사이트에 전달됩니다.

브라우저가 사이트에 접속하게 되면 사이트는 핸드쉐이크 과정을 거치면서 자신이 신뢰할 수 있는 사이트임을 증명하기 위해 브라우저에 사이트의 인증서를 전달합니다. 브라우저들은 이 CA 목록들이 내장되어 있고, 사이트로부터 전달받은 인증서를 CA 의 공개키로 복호화하여 진짜인지 가짜인지 판별할 수 있습니다.

공개키 방식으로 대칭키 생성하기

브라우저가 사이트에 접속할 때 핸드 쉐이크 과정을 거치면서 인증서를 전달한다고 했습니다. 인증서를 전달 받은 후에는 공개키 방식을 이용해 통신에 사용할 대칭키를 생성하게 되는데 이를 간단하게만 알아보도록 하겠습니다.

1. 먼저 브라우저에서 임의로 난수를 생성해서 서버로 전달합니다.

2. 서버도 임의로 난수를 생성한 뒤, 인증서와 함께 난수를 전달합니다.

3. 서버에서 전달받은 인증서를 CA 의 공개키로 복호화합니다. 복호화를 하면 서버의 공개키가 나오게 됩니다.

4. 브라우저는 자신이 생성한 난수와 서버가 전달한 난수를 조합해서 대칭키를 생성하고, 이를 서버의 공개키로 암호화하여 전달합니다.

5. 서버는 자신의 개인키로 암호화된 대칭키를 복호화합니다.

6. 핸드쉐이크가 종료되고, 생성된 대칭키로 HTTPS 통신이 시작됩니다.

HTTPS 설정하기

1. 인증서 발급

Let's Encrypt 라는 비영리 기관을 통해 무료로 인증서를 발급받을 수 있습니다. 3가지 방식으로 할 수 있다고 하는데 저는 standalone 방식을 사용하였습니다.

sudo certbot certonly --standalone -d {도메인}

위 명령어를 입력하면 이메일 입력하라 동의하라고 뜨는데 이미 이전에 다른 방식을 시도하면서 입력해서 그런가 뜨지 않았습니다. 명령어 수행 결과로 /etc/letsencrypt/live/{도메인명} 위치에 pem 파일이 생성됩니다.

2. NGINX 설정

docker-compose.yml 이 위치한 곳에서 data/nginx 디렉터리를 만들고 내부에 app.conf 파일을 작성합니다.

server {
        listen 80;
        server_name {도메인명};
        location / {
                return 301 https://$host$request_uri;
        }

}

server {
        listen 443 ssl;
        server_name {도메인명};

        ssl_certificate /etc/letsencrypt/live/{도메인명};/fullchain.pem;
        ssl_certificate_key /etc/letsencrypt/live/{도메인명};/privkey.pem;

        location / {
                proxy_pass  http://application:8080;
                proxy_set_header   Host                    $http_host;
                proxy_set_header   X-Real-IP               $remote_addr;
                proxy_set_header   X-Forwarded-For         $proxy_add_x_forwarded_for;
                proxy_set_header   X-Forwarded-Proto       $scheme;
        }
}

여기서 application 은 docker-compose.yml 에 작성한 스프링 애플리케이션의 이름입니다.

3. docker-compose.yml 작성

services:
  nginx:
    container_name: nginx
    image: nginx
    volumes:
      - ./data/nginx:/etc/nginx/conf.d
      - /etc/letsencrypt:/etc/letsencrypt
    ports:
      - 80:80
      - 443:443
    depends_on:
      - application

작성한 내용 app.conf 를 nginx 의 /etc/nginx/conf.d 에 위치할 수 있도록 volumes 에 작성합니다. 또 인증 후 생성된 키를 연결하기 위해 /etc/letsencrypt 도 추가합니다.

해당 내용은 드림코딩 도커 영상을 보고 작성하였습니다.

스프링은 애플리케이션 코드와 함께 여러 dependencies 로 이루어져 있고, 이를 실행하기 위해서는 JDK 가 필요합니다.

도커는 컨테이너 안에 애플리케이션 실행에 필요한 모든 것을 담고 있습니다. 이를 활용하여 어떤 환경에서도 애플리케이션을 실행할 수 있도록 도와줍니다.

VM vs Container

Virtual Machine

infrastructure 위에 VM ware 같은 Hypervisor 소프트웨어를 사용하여 각각의 가상 머신을 만들 수 있습니다. 가상머신은 PC 의 운영체제 위해 가상머신 각각의 운영체제를 포함하고 있기 때문에 굉장히 무겁고 infrastructure 의 리소스를 많이 잡아먹게 됩니다.

Container

이런 가상머신에서 조금 경량화된 컨셉이 바로 컨테이너입니다. 컨테이너는 각각의 OS 설치 없이 호스트 OS 에 Container Engine 이라는 소프트웨어를 설치하면 개별적인 컨테이너를 만들어서 각 애플리케이션을 고립된 환경에서 구동할 수 있게 해줍니다. Container Engine 중에서 가장 많이 사용되는 것이 바로 Docker 입니다.

Docker

도커를 이용할 때는 컨테이너를 만들고, 배포하고, 컨테이너를 실행하는 과정을 거치게 되는데 컨테이너를 만들기 위해서는 아래 3가지의 과정이 필요합니다.

1. Dockerfile 을 작성합니다.

Dockerfile 에는 컨테이너를 어떻게 만들어야 하는지를 작성합니다.

도커 파일에는 애플리케이션을 구동하기 위해 필요한 jar 와 같은 파일, 필요한 외부 라이브러리, 환경 변수를 작성할 수 있으며, 어떻게 실행시켜야 하는지 스크립트도 작성할 수 있습니다.

2. Image 를 생성합니다.

Image 는 작성한 도커 파일을 이용해서 만들 수 있으며 Image 는 불변의 상태입니다.

3. 컨테이너를 구동합니다.

Image 를 고립된 환경에서 실행할 수 있도록 해주는 것이 컨테이너입니다. 컨테이너 안에서 애플리케이션이 동작한다고 생각하면 됩니다. 또 하나의 Image 로 여러 개의 컨테이너를 구동할 수 있습니다.

로컬에서 생성한 Image 를 Docker Hub 에 push 하면, 서버에서 pull 을 받아, Image 를 통해 컨테이너를 생성하고 구동할 수 있습니다.

Docker Compose

컨테이너를 실행할 때 각각의 image 를 push 하고, pull 받아서 실행하는데 만약 여러 개의 image 를 한 번에 실행해야 한다면 해당 과정을 여러 번 반복해야 합니다.

이러한 작업을 편하게 할 수 있도록 도와주는 것이 바로 Docker Compose 입니다. docker-compose.yml 설정 파일을 통해 여러 개의 도커 컨테이너를 정의하고 실행할 수 있으며, 컨테이너 간 종속성을 설정할 수 있습니다.

도커로 스프링부트 배포하기

1. 도커 로그인

docker login -u [사용자명]

2. 스프링 빌드

Gradle ➜ Tasks ➜ build ➜ bootJar 실행

이 과정을 수행하면 build/libs 에 jar 파일이 생성됩니다.

3. Dockerfile 생성

FROM openjdk:17

ARG JAR_FILE=build/libs/*.jar

COPY ${JAR_FILE} app.jar
COPY src/main/resources/firebaseKey.json firebaseKey.json

ENTRYPOINT ["java","-jar","/app.jar"]

스프링부트 프로젝트 루트 디렉터리에 Dockerfile 을 생성합니다.

이때 저는 firebaseKey 가 담긴 json 파일까지 함께 실행되어야 하기 때문에 COPY 명령어로 파일도 추가해주었습니다.

COPY [파일위치] [도커 내 파일위치]

COPY 는 위와 같은 형태로 작성하는데, 위처럼 작성한 파일의 경로는 /firebaseKey.json 이 됩니다.

4. 도커 이미지 생성

docker build -t [사용자명]/[이미지명] [도커파일위치]

ex> docker build -t test/testDemo ./

터미널을 열고 Dockerfile 이 위치한 곳까지 이동합니다. 그 후 [도커파일위치] 에 ./ 을 입력합니다.

5. 생성된 이미지 확인

docker images

6. 도커 허브에 이미지 업로드

docker push [사용자명]/[이미지명]

ex> docker push test/testDemo

7. 도커 이미지 pull

sudo docker pull [사용자명]/[이미지명]

8. 환경변수 세팅 방법

환경변수명=VALUE

.env 에 따옴표 없이 위와 같은 형태로 환경변수 파일을 생성합니다.

9. 도커 실행

# 실행
docker run -p [로컬 port]:[도커 port] [사용자명]/[이미지명]

# 환경변수 파일 포함 실행
docker run -p 8080:8080 --env-file ./파일명.env [사용자명]/[이미지명]

-d 옵션을 주면 백그라운드로 실행되게 됩니다.

10. 실행 중인 컨테이너 조회

sudo docker ps

-a 옵션을 주면 중지된 컨테이너까지 조회됩니다.

11. 컨테이너 중지

sudo docker stop [컨테이너ID]

12. 삭제

컨테이너 확인

sudo docker ps -a 

컨테이너 삭제

sudo docker rm [컨테이너ID]

이미지 삭제

sudo docker image rm [사용자명]/[이미지명]

이미지를 삭제하기 전, 컨테이너 삭제가 필요합니다.

Docker Compose (with mariaDB)

Docker Compose 로 스프링과 mariaDB 를 함께 실행해보겠습니다. 수행해본 결과 따로 mariaDB 이미지를 pull 받지 않아도, docker-compose 를 실행하면 자동으로 이미지를 가져와 실행해줍니다.

저는 docker-compose.yml 파일을 바로 서버에서 작성하였습니다.

1. docker-compose.yml 작성

version: "3"
services:
  database:
    container_name: mariadb
    image: mariadb
    volumes:
      - ~/docker/mariadb/etc/mysql/conf.d:/etc/mysql/conf.d:ro
      - ~/docker/mariadb/var/lib/mysql:/var/lib/mysql
      - ~/docker/mariadb/var/log/maria:/var/log/maria
    environment:
      - MYSQL_DATABASE=데이터베이스명
      - MYSQL_ROOT_PASSWORD=root
      - MYSQL_ROOT_HOST=root
    command: ['--character-set-server=utf8mb4','--collation-server=utf8mb4_unicode_ci']
    ports:
      - 3306:3306

  application:
    container_name: spring-app
    image: "test/testDemo"
    ports:
      - 8080:8080
    environment:
      - BUCKET=${BUCKET}
      - CONFIG_FILE_PATH=${CONFIG_FILE_PATH}
    depends_on:
      - database

depends_on 명령어는 서비스 간의 종속성 순서대로 실행되게 합니다. 위에서는 mariadb 가 실행된 후에 spring-app 이 실행됩니다.

docker-compose.yml 과 같은 위치에 .env 로 환경변수 파일을 만들면 별도로 파일을 지정하지 않아도 자동으로 불러옵니다. 저는 env 파일에 파일명을 주니 읽어오지 못했고, 파일명 없이 .env 만 작성하니 정상적으로 읽어왔습니다.

그냥 실행하면 데이터베이스를 찾을 수 없다는 오류가 뜨면서 실행되지 않습니다. 찾아보니 스크립트를 작성하면 된다는데 저는 스크립트 파일을 읽지 못하는 것 같아 application.yml 에서 설정해주었습니다.

데이터베이스를 자동으로 생성하게 할 때는 application.yml 에서 데이터베이스 URL 뒤에 ?createDatabaseIfNotExist=true 옵션을 추가하면 됩니다.

2. 실행

docker-compose up

이미지를 pull 받지 않아도 docker-compose.yml 을 작성해놓고 docker-compose up 을 실행하면 자동으로 이미지를 pull 받아서 수행합니다.

네트워크 개념 살펴보기

공인 IP, 사설 IP

먼저 서버를 구축하기에 앞서 알아야 하는 내용은 공인 IP 와 사설 IP 입니다.

공인 IP 는 인터넷에서 사용되는 주소로, IP 주소 할당 기관에 의해 할당된 주소이며, 인터넷 상에서 유효한 주소입니다.

사설 IP 는 인터넷 미연결 TCP/IP 네트워크를 위한 IP 주소입니다. 인터넷 IP 주소 관리 대상에 포함되지 않으며, 인터넷에서 사용이 불가능한 주소입니다.

우리가 자주 사용하는 와이파이를 예시로 들어보겠습니다. AP 는 Access Point 의 약자로 쉽게 말해서 우리가 생각하는 공유기입니다.

WRT300N 을 보면 외부와 연결된 것을 볼 수 있는데 바로 여기에 공인 IP 가 할당되는 것입니다.

AP 에 연결된 장치의 IP 주소를 보면 192.168.0.2 인 것을 볼 수 있는데 AP 내부에서 각 장치 별로 부여되는 것이 사설 IP 입니다. 이때 사설 IP 는 동적으로 부여되게 됩니다.

그리고 AP 에는 Default 게이트웨이가 있는데 AP 에 연결된 모든 장치들은 인터넷에 접속하기 위해 먼저 게이트웨이 주소로 요청을 보내게 됩니다.

NAT 와 NAPT

사설 IP 는 인터넷에 연결할 수 없기 때문에 사설 IP 주소와 인터넷 공인 IP 주소 간의 변환 프로토콜 NAT 가 사용됩니다.

내부에 연결된 장치가 인터넷에 접속하려고 하면 라우터의 디폴트 게이트웨이로 요청이 가게 되는데 이때 미리 정의되거나, 동적으로 정의되는 NAT 변환 테이블에 의해 하나의 사설 IP 가 하나의 공인 IP 로 변환됩니다.

이렇게 하면 인터넷에 접속할 때만 공인 IP 주소를 사용할 수 있기 때문에 IP 주소를 절약할 수 있습니다. 하지만 NAT 는 하나의 사설 IP 에 하나의 공인 IP 를 부여하게 되므로, 많은 장치가 있다면 이를 전부 다른 IP 주소로 변환할 수는 없습니다. 그래서 등장한 것이 NAPT 입니다.

NAPT 는 하나의 공인 IP 주소에 여러 개의 사설 IP 주소를 변환할 수 있습니다. 하나의 공인 IP 에 포트번호를 사용하여 사설 IP 주소와 공인 IP 주소 변환을 하면서 포트 번호 변환을 동시에 수행하는 것입니다.

홈서버를 구축할 때 알아야 하는 내용이 바로 이 NAPT 의 개념과, 사설 IP 는 동적으로 할당된다는 점입니다.

홈 서버 구축하기

1. 네트워크 환경

현재 저의 네트워크 환경은 sk 공유기 안에서 iptime 공유기를 사용하고 있었고, 이 iptime 공유기에 서버용 노트북이 연결되어 있습니다.

iptime 의 관리자 화면은 192.168.0.1 이고, 연결된 동적 ip 를 보면 192.168.25.52 인 것을 볼 수 있는데 이 의미는 sk 공유기 내부에서 iptime 공유기가 해당 사설 ip 를 할당 받았다는 의미이고, 관리자 화면으로 접속하기 위해 192.168.25.1 로 접속하였습니다.

2. 서버 ip 고정

앞엣 사설 ip 내부에서는 연결된 기기에 할당되는 ip 는 동적이라고 하였습니다. 예를 들어, 서버의 사설 ip 가 192.168.0.2 로 되어 있는 상태로 모든 설정을 마쳤는데 ip 가 다른 주소로 바뀌어 버리면 설정값을 또 바꿔주어야 합니다. 이를 방지하기 위해 서버의 사설 ip 를 고정시켜야 합니다.

현재 서버용 노트북이 192.168.0.6 에 연결되어 있습니다. DHCP 서버 설정에 들어간 후 사용중인 ip 주소에서 해당하는 ip 를 클릭한 뒤 우측의 등록 버튼을 누르면 해당 사설 ip 가 고정됩니다.

3. 포트 포워딩

포트 포워딩에 들어가서 공유기의 몇 번 포트로 들어왔을 때 어떤 ip 의 몇 번 포트로 연결할 것인지를 지정합니다.

앞에 sk 공유기가 있기 때문에 조금 다르지만 앞에서 살펴보았던 NAPT 를 생각하면 됩니다. iptime 외부에서 iptime 의 ip 주소의 n 번 포트로 들어오게 되면 iptime 내부 장치의 m 번 포트로 보내주는 역할을 수행합니다.

4. DNS 설정

가비아에서 도메인을 구매한 후, DNS 설정을 들어갑니다. 여기서 DNS 정보를 추가하는데 타입은 A, 호스트는 @ 를 지정합니다. 호스트를 @ 로 지정하면 example.com 처럼 바로 접속할 수 있게 됩니다. www 를 지정하면 www.example.com 으로 접속해야 합니다. 그 후 오른쪽에 외부 IP 주소를 작성하면 됩니다.

5. DDNS 설정

가비아에서 네임서버를 확인할 수 있습니다. 저는 ns.gabia.co.kr 로 지정되어 있고 이는 DDNS 를 설정할 때 사용됩니다.

그 후 sk 공유기 관리자 화면에서 DDNS 를 설정하는데 DDNS 서버에 위의 네임 서버를 작성하고, DDNS 도메인에 구입한 도메인을 입력하면 됩니다.

6. 포트 포워딩

이제 외부에서 접속했을 때 iptime 에 연결되어 있는 서버까지 연결되도록 해야 합니다. 이전처럼 포트 포워딩을 사용해서 이를 설정할 수 있는데 포워딩 ip 주소는 현재 iptime 에 부여된( sk 공유기 하위의 ) 사설 ip 주소를 입력합니다.

웹의 기본 포트가 80이기 때문에 외부 포트를 80으로 지정하고, iptime 에서 80번으로 들어오는 요청을 다시 서버의 80으로 보냈기 때문에 sk 공유기에서 iptime 으로 보내는 포트 역시 80 번으로 지정합니다.

즉, sk 공유기 80 ➜ iptime 80 ➜ 서버 80 흐름대로 진행되도록 설정합니다. 추가로 뒤에서 https 도 설정할 것이기 때문에 443 포트도 동일하게 443 으로 연결되도록 설정합니다.

주의!!! 443 포트를 추가하면 문제가 발생할 수도 있습니다. 저는 문제가 발생하였고, 가장 아래에 적어두었습니다.

7. 최종 구축 환경

최종 구축 환경은 위와 같습니다. 이제 가비아에서 구매한 도메인으로 접속하면 포트번호 없이 서버에 접근할 수 있게 됩니다.

이후 발생한 문제

NGINX 를 설정하면서 실행에 오류가 뜨길래 혹시나 하는 마음으로 sk 공유기에 443 포트포워딩을 설정하니 문제가 해결되었습니다. 하지만 여기서 집에서 사용하는 공유기가 인터넷 연결이 되지 않는다는 문제가 생겨버렸습니다.

그래서 sk 공유기에 설정한 모든 내용을 지우고, 브릿지 모드로 변경하여 iptime 공유기에 공인 ip 가 할당되도록 변경하였습니다. 하지만 브릿지 모드로 변경하게 되면 sk 공유기의 관리자 페이지의 접속은 불가능해집니다.

김영한 님의 실전! Querydsl 강의를 보고 작성한 내용입니다.

1. 사용자 정의 리포지토리

Spring Data JPA 를 사용하면 findByUsername 과 같은 쿼리를 자동으로 생성해주지만, 검색 조건에 따른 동적 쿼리를 작성할 수 없습니다. 그래서 사용자 정의 인터페이스를 사용하여 QueryDSL 을 활용한 동적 쿼리를 작성합니다.

[ 1. 인터페이스 생성 ]

public interface MemberRepositoryCustom {
    List<MemberTeamDto> search(MemberSearchCond condition);
}

[ 2. 인터페이스 상속 ]

public interface MemberRepository extends JpaRepository<Member, Long>, 
                                          MemberRepositoryCustom {
    ...
}

JpaRepository 를 상속 받는 인터페이스가 새롭게 정의한 인터페이스를 상속 받도록 합니다. 이렇게 하면 생성한 동적 쿼리를 MemberRepository.search() 로 사용할 수 있습니다.

[ 3. 구현체 생성 ]

public class MemberRepositoryCustomImpl implements MemberRepositoryCustom {

    private final JPAQueryFactory queryFactory;

    public MemberRepositoryCustomImpl(EntityManager em) {
        this.queryFactory = new JPAQueryFactory(em);
    }

    @Override
    public List<MemberTeamDto> search(MemberSearchCond condition) {
        ...
    }
}

사용자 정의 인터페이스의 구현체를 만들 때 MemberRepositoryImpl 혹은 MemberRepositoryCustomImpl 둘 중 아무거나 선택해서 이름을 지정하면 됩니다. ( Spring Data JPA 강의 참고 )

QueryDSL 을 활용하기 때문에 생성자를 통해 EntityManager 를 주입받아 JpaQueryFactory 를 생성하고, 이를 이용해 동적 쿼리를 작성하면 됩니다. 동적 쿼리는 이전 시간에 작성한 것과 동일하게 작성하면 됩니다.

2. QueryDSL 과 페이징 연동

fetchResult() 를 사용하면 데이터를 가져오는 쿼리와 총 데이터 수를 가져오는 쿼리가 실행되는데 해당 기능은 deprecated 되었습니다.

그래서 QueryDSL 5.0 부터 페이징 처리를 할 때는 데이터를 조회하는 쿼리, 데이터 수를 가져오는 쿼리를 따로 작성해서 구현해야 합니다.

또 content 를 가져올 때는 조인이 필요하지만 count 를 가져올 때는 조인 여부에 관계 없이 데이터의 수가 동일한 경우가 있습니다. 이러한 이유로 count 쿼리를 따로 작성하는 것이 성능 상 이점을 가져갈 수 있습니다.

public class MemberRepositoryCustomImpl implements MemberRepositoryCustom {
    ...
    @Override
    public Page<MemberTeamDto> searchPageComplex(MemberSearchCond condition, 
                                                 Pageable pageable) {
        // content 쿼리
        List<MemberTeamDto> content = queryFactory
                .select(new QMemberTeamDto(
                        member.id,
                        member.username,
                        member.age,
                        team.id,
                        team.name
                ))
                .from(member)
                .leftJoin(member.team, team)
                .where(
                        usernameEq(condition.getUsername()),
                        teamNameEq(condition.getTeamName()),
                        ageGoe(condition.getAgeGoe()),
                        ageLoe(condition.getAgeLoe()))
                .offset(pageable.getOffset())
                .limit(pageable.getPageSize())
                .fetch();

        // count 쿼리
        Long total = queryFactory
                .select(member.count())
                .from(member)
                .leftJoin(member.team, team)
                .where(
                        usernameEq(condition.getUsername()),
                        teamNameEq(condition.getTeamName()),
                        ageGoe(condition.getAgeGoe()),
                        ageLoe(condition.getAgeLoe()))
                .fetchOne();

        return new PageImpl<>(content, pageable, total);
    }
}

1. content 를 가져올 때는 fetch() 를 사용합니다.

2. count 를 가져올 때는 select 에 count() 를 사용하며, fetchOne() 으로 실행합니다.

3. CountQuery 최적화

페이지의 시작이면서 content 사이즈가 page 사이즈보다 작은 경우, 혹은 마지막 페이지인 경우에는 count 쿼리를 생략할 수 있습니다.

Spring Data 가 제공하는 라이브러리를 사용하면 count 쿼리를 생략할 수 있는 경우, 자동으로 count 쿼리를 생략합니다.

public class MemberRepositoryCustomImpl implements MemberRepositoryCustom {
    ...
    @Override
    public Page<MemberTeamDto> searchPageComplex(MemberSearchCond condition, 
                                                 Pageable pageable) {
        // content 쿼리 생략
        JPAQuery<Long> countQuery = queryFactory
                .select(member.count())
                .from(member)
                .leftJoin(member.team, team)
                .where(
                        usernameEq(condition.getUsername()),
                        teamNameEq(condition.getTeamName()),
                        ageGoe(condition.getAgeGoe()),
                        ageLoe(condition.getAgeLoe()));

        return PageableExecutionUtils.getPage(content, pageable, countQuery::fetchOne);
    }
}

count 쿼리를 작성한 후에 fetchXXX 를 사용하지 않으면 실제 쿼리가 수행되지 않고 fetchXXX 를 호출해야 쿼리가 실행됩니다.

count 쿼리를 반환받고, 위처럼 반환하면 getPage() 에서 content 와 pageable 의 totalSize 를 보고 count 쿼리를 생략할 수 있다면 count 쿼리를 실행하지 않게 됩니다.

4. Spring Data JPA 가 제공하는 QueryDSL 기능

여기서 소개하는 기능은 제약이 커서 복잡한 실무 환경에서 사용하기에는 많이 부족하다고 합니다.

4-1. QuerydslPredicateExecutor

[ 인터페이스 ]

public interface QuerydslPredicateExecutor<T> {
    Optional<T> findOne(Predicate predicate);
    Iterable<T> findAll(Predicate predicate);
    Page<T> findAll(Predicate predicate, Pageable pageable);
    long count(Predicate predicate);
    boolean exists(Predicate predicate);
    ...
}

[ 테스트 코드 ]

@Test
void querydslPredicateExecutor() {
    QMember member = QMember.member;
    Iterable<Member> result = memberRepository.findAll(
                                    member.age.between(10, 40)
                                        .and(member.username.eq("member1")));
}

JpaRepository 를 상속 받는 인터페이스에서 해당 인터페이스를 상속 받으면 인터페이스가 제공하는 모든 기능을 사용할 수 있으며, 파라미터로 QueryDSL 조건을 넣을 수 있게 됩니다.

Pagable, Sort를 모두 지원하고 정상적으로 동작하지만 left join 이 불가능하며, 서비스 클래스가 QueryDSL 이라는 구현 기술에 의존해야 합니다.

4-2. QuerydslRepositorySupport

[ 생성 및 쿼리 작성 ]

public class MemberRepositoryCustomImpl extends QuerydslRepositorySupport 
                                        implements MemberRepositoryCustom {

    public MemberRepositoryCustomImpl() {
        super(Member.class);
    }

    @Override
    public List<MemberTeamDto> search(MemberSearchCond condition) {
        return from(member)
                .leftJoin(member.team, team)
                .where(
                        usernameEq(condition.getUsername()),
                        teamNameEq(condition.getTeamName()),
                        ageGoe(condition.getAgeGoe()),
                        ageLoe(condition.getAgeLoe())
                )
                .select(new QMemberTeamDto(
                        member.id,
                        member.username,
                        member.age,
                        team.id,
                        team.name
                ))
                .fetch();
    }
}

기존에는 EntityManager 를 주입 받고 JpaQueryFactory 를 생성했는데 해당 인터페이스가 엔티티 매니저를 주입 받기 때문에 super(Member.class) 만 하면 됩니다.

JpaQueryFactory 없이 from 으로 시작하도록 하고 마지막에 select 를 넣는 형식으로 쿼리를 작성할 수 있습니다.

[ 엔티티 매니저와 쿼리 팩토리 ]

public class MemberRepositoryCustomImpl extends QuerydslRepositorySupport {

    private final JPAQueryFactory queryFactory;

    // queryFactory 사용
    public MemberRepositoryCustomImpl(EntityManager em) {
        super(Member.class);
        this.queryFactory = new JPAQueryFactory(em);
    }

    // entityManager
    private final EntityManager entityManager = getEntityManager();
}

생성자에서 EntityManager 를 주입 받아 JpaQueryFactory 를 사용할 수 있으며, getEntityManager() 를 통해 엔티티 매니저를 사용할 수 있습니다.

[ 페이징 ]

@Override
public void searchPage(MemberSearchCond condition, Pageable pageable) {
    JPQLQuery<MemberTeamDto> query = 
            from(member)
            .leftJoin(member.team, team)
            .where(
                    usernameEq(condition.getUsername()),
                    teamNameEq(condition.getTeamName()),
                    ageGoe(condition.getAgeGoe()),
                    ageLoe(condition.getAgeLoe()))
            .select(new QMemberTeamDto(
                    member.id,
                    member.username,
                    member.age,
                    team.id,
                    team.name
            ));

    JPQLQuery<MemberTeamDto> pagingQuery = getQuerydsl()
                                            .applyPagination(pageable, query);
    List<MemberTeamDto> result = pagingQuery.fetch();
}

getQuerydsl().applyPagination() 을 사용하면 Spring Data 가 제공하는 페이징을 QueryDSL 로 편리하게 변환할 수 있으며, offset 과 limit 를 자동으로 넣어주게 됩니다.

이 메서드로 스프링 데이터가 제공하는 페이징을 Querydsl로 편리하게 변환할 수 있지만 Sort는 오류가 발생합니다.

[ 단점 ]

1. Querydsl 3.x 버전을 대상으로 만들었기 때문에 Querydsl 4.x에 나온 JPAQueryFactory로 시작할 수 없습니다.

2. Spring Data 가 제공하는 Sort 기능이 정상적으로 동작하지 않습니다.

김영한 님의 실전! Querydsl 강의를 보고 작성한 내용입니다.

1. 순수 JPA Repository

1-1. 생성하기

@Repository
public class MemberJpaRepository {

    private final EntityManager em;
    private final JPAQueryFactory queryFactory;

    public MemberJpaRepository(EntityManager em) {
        this.em = em;
        this.queryFactory = new JPAQueryFactory(em);
    }

    public List<Member> findByUsername_QueryDSL(String username) {
        return queryFactory
                .selectFrom(member)
                .where(member.username.eq(username))
                .fetch();
    }
}

순수 JPA 를 이용한 Repository 이기 때문에 JPA 에 접근하기 위해 EntityManger 가 필요합니다. 또 QueryDSL 을 사용하려면 JpaQueryFactory 가 필요한데 EntityManager 를 파라미터로 넘겨주어 생성합니다.

1-2. 스프링 빈 등록하기

@Bean
JPAQueryFactory jpaQueryFactory(EntityManager em) {
    return new JPAQueryFactory(em);
}

생성자를 사용하지 않고, JpaQueryFactory 를 스프링 빈으로 등록해서 사용할 수도 있습니다. 이때 Repository 에서는 @RequiredArgsConstructor 를 사용해서 주입받으면 됩니다.

스프링 빈은 싱글톤이기 때문에 같은 객체를 모든 멀티스레드에서 사용하기 때문에 동시성 문제에 대해 걱정할 수 있는데 전혀 문제가 되지 않습니다.

JpaQueryFactory 에 대한 모든 동시성 문제는 엔티티 매니저에 의존하는데, 엔티티 매니저를 스프링과 함께 사용하면 동시성 문제랑 전혀 관계 없이 트랜잭션 단위로 분리돼서 동작합니다.

여기서 스프링이 주입해주는 엔티티 매니저는 실제 동작 시점에 진짜 엔티티 매니저를 찾아주는 프록시용 가짜 엔티티 매니저입니다. 이 가짜 엔티티 매니저는 실제 사용 시점에 트랜잭션 단위로 실제 엔티티 매니저( 영속성 컨텍스트 )를 할당해주기 때문에 동시성 문제는 걱정하지 않아도 됩니다.

2. 준비하기

2-1. DTO 생성

@Data
public class MemberTeamDto {
    private Long memberId;
    private String username;
    private int age;
    private Long teamId;
    private String teamName;

    @QueryProjection
    public MemberTeamDto(Long memberId, String username, int age, 
                         Long teamId, String teamName) {
        this.memberId = memberId;
        this.username = username;
        this.age = age;
        this.teamId = teamId;
        this.teamName = teamName;
    }
}

@QueryProjection 을 생성자에 붙여 Q 클래스를 생성합니다. 해당 어노테이션을 사용하면 select 에서 new 를 통해 DTO 를 바로 생성할 수 있지만 DTO 가 QueryDSL 라이브러리에 의존하게 된다는 단점이 있습니다.

2-2. 검색 조건 생성

@Data
public class MemberSearchCond {
    private String username;
    private String teamName;
    private Integer ageGoe;
    private Integer ageLoe;
}

회원명, 팀명, 나이를 검색 조건에 사용하기 위해 생성합니다.

3. 동적 쿼리와 DTO 조회

3-1. Builder 사용

public List<MemberTeamDto> searchByBuilder(MemberSearchCond condition) {

    BooleanBuilder builder = new BooleanBuilder();

    if (StringUtils.hasText(condition.getUsername())) {
        builder.and(member.username.eq(condition.getUsername()));
    }


    if (condition.getAgeGoe() != null) {
        builder.and(member.age.goe(condition.getAgeGoe()));
    }

    return queryFactory
            .select(new QMemberTeamDto(
                    member.id,
                    member.username,
                    member.age,
                    team.id,
                    team.name))
            .from(member)
            .leftJoin(member.team, team)
            .where(builder)
            .fetch();
}

1. 검색조건에서 문자는 null 이거나 빈 문자열이 들어올 수 있는데 StringUtils.hasText() 가 그런 것을 다 체크해줍니다.

2. @QueryProjection 를 사용했기 때문에 new 키워드와 생성자를 통해 바로 DTO 를 조회할 수 있습니다.

3. 어노테이션을 사용하지 않는다면 현재 사용하는 DTO 와 엔티티들의 필드명이 다르기 때문에 as 를 사용해서 DTO 와 엔티티의 필드명을 맞춰주어야 합니다.

참고로 검색 조건이 없다면 모든 데이터를 가져오게 됩니다. 하지만 데이터가 많이 쌓이다보면 모든 것을 가져오는게 성능 상 좋지 않습니다. 그래서 기본 조건을 넣거나, limit 를 설정하는 것이 좋습니다.

3-2. where 절 파라미터 사용

public List<MemberTeamDto> search(MemberSearchCond condition) {
    return queryFactory
            .select(new QMemberTeamDto(
                    member.id,
                    member.username,
                    member.age,
                    team.id,
                    team.name))
            .from(member)
            .leftJoin(member.team, team)
            .where(
                    usernameEq(condition.getUsername()),
                    teamNameEq(condition.getTeamName()),
                    ageGoe(condition.getAgeGoe()),
                    ageLoe(condition.getAgeLoe()))
            .fetch();
}

private BooleanExpression usernameEq(String username) {
    return hasText(username) ? member.username.eq(username) : null;
}

private BooleanExpression ageGoe(Integer ageGoe) {
    return ageGoe == null ? null : member.age.goe(ageGoe);
}

1. where 절 다중 파라미터에 각 검색 조건들에 대한 메서드를 사용합니다.

2. 각 메서드는 null 과 빈 문자열에 주의해서 검색 조건을 작성합니다. 이때 hasText 는 StringUtils 의 메서드입니다.

3. 작성된 검색 조건 메서드들은 재사용이 가능하며, Predicate 가 아닌 BooleanExpression 을 사용하면 검색 조건들을 조합할 수 있습니다.

참고> 프로파일 분리

[ 설정 파일 작성 ]

spring:
  profiles:
    active: local    # main/resources/application.yml

spring:
  profiles:
    active: test    # test/resources/application.yml

로컬에서의 실행과 테스트에서의 실행 프로파일을 분리하기 위해 test/resources 에 application.yml 파일을 추가합니다. 추가 후에는 위처럼 로컬과 테스트 프로파일을 각각 설정합니다.

[ 프로파일 적용 ]

@Profile("local")
@Component
@RequiredArgsConstructor
public class InitMember {
    ...
}

위처럼 @Profile("local") 을 붙여주면 local 프로파일이 실행될 때만 동작하게 됩니다.

김영한 님의 실전! Querydsl 강의를 보고 작성한 내용입니다.

1. 프로젝션 결과 반환 DTO

프로젝션 대상이 하나라면 타입을 명확히 지정할 수 있습니다.

대상이 둘 이상인 경우 튜플이나 DTO 를 통해 반환 받게 됩니다.

1-1. 순수 JPA 에서 DTO 반환

List<MemberDto> result = em.createQuery(
                "select new study.querydsl.dto.MemberDto(m.username, m.age) " +
                "from Member m", MemberDto.class)
            .getResultList();

순수 JPA 에서 DTO 를 조회할 때는 new 명령어를 사용해서 생성자를 통해 반환합니다. 또한 DTO 의 패키지 경로까지 모두 작성해야 합니다.

1-2. QueryDSL 빈 ( Bean population )

QueryDSL 에서 DTO 를 쉽게 조회할 수 있도록 빈 생성 방식을 제공합니다. 이때 3가지 방법으로 DTO 에 값을 담아 반환할 수 있습니다.

1. 프로퍼티 접근( setter )

2. 필드 직접 접근

3. 생성자 사용

1-2-1. 프로퍼티 접근( setter )

List<MemberDto> result = queryFactory
                .select(Projections.bean(MemberDto.class,
                        member.username,
                        member.age))
                .from(member)
                .fetch();

Projections.bean() 을 사용해서 DTO 를 바로 조회할 수 있습니다. 첫 번째 파라미터로 어떤 DTO 인지를 명시하고, 그 뒤에 필요한 필드들을 넣어주면 됩니다. 이때 DTO 에는 기본 생성자가 필요합니다.

1-2-2. 필드 직접 접근

List<MemberDto> result = queryFactory
                .select(Projections.fields(MemberDto.class,
                        member.username,
                        member.age))
                .from(member)
                .fetch();

Projections.fields 를 통해 필드에 값을 바로 넣어버리기 때문에 DTO 에 getter, setter 는 필요하지 않습니다. 형태는 프로퍼티 접근과 동일합니다.

1-2-3. 생성자 접근

List<MemberDto> result = queryFactory
                .select(Projections.constructor(MemberDto.class,
                        member.username,
                        member.age))
                .from(member)
                .fetch();

Projections.constructor 를 통해 생성자 접근 방식으로 DTO 를 생성할 수 있습니다. 이때 전달하는 username 과 age 는 DTO 에 선언된 username, age 와 타입이 일치해야 합니다.

1-3. 필드명이 다른 경우

Projection 에서 사용한 username, age 이 필드명 그대로 MemberDto 에 존재하기 때문에 사용할 수 있었습니다. 즉, 엔티티와 DTO 의 필드명이 동일하게 매칭되었기 때문에 가능했습니다.

하지만 만약 username 이 아닌 name 이라는 필드를 가진 DTO 가 있으면 어떻게 될까요?

[ UserDto ]

public class UserDto {
    private String name;
    private int age;
}

[ 테스트 코드 ]

@Test
void findUserDto() {
    List<UserDto> result = queryFactory
            .select(Projections.fields(UserDto.class,
                    member.username,
                    member.age))
            .from(member)
            .fetch();

    for (UserDto userDto : result) {
        System.out.println("userDto = " + userDto);
    }
}

[ 출력 결과 ]

userDto = UserDto(name=null, age=10) userDto = UserDto(name=null, age=20) userDto = UserDto(name=null, age=30) userDto = UserDto(name=null, age=40)

테스트 실행 결과를 보면 username 과 name 이 매칭이 되지 않기 때문에 name 에 null 값이 들어간 것을 볼 수 있습니다.

생성자의 경우 DTO 에 생성자가 존재하면 문제없이 동작하지만, 프로퍼티나 필드 접근 생성 방식에서 이름이 다를 때는 문제가 발생하며, 이를 해결할 수 있는 방법은 2가지가 존재합니다.

[ 해결 방법 1. 별칭 사용 ]

@Test
void findUserDto() {
    List<UserDto> result = queryFactory
            .select(Projections.fields(UserDto.class,
                    member.username.as("name"),
                    member.age))
            .from(member)
            .fetch();
}

엔티티 필드에 .as("dto 필드명") 를 붙이면 정상적으로 username 이 name 필드에 들어가게 됩니다.

[ 해결 방법 2. ExpressionUtils 사용 ]

@Test
void findUserDto() {
    QMember memberSub = new QMember("memberSub");

    List<UserDto> result = queryFactory
            .select(Projections.fields(UserDto.class,
                    member.username.as("name"),
                    ExpressionUtils.as(
                        JPAExpressions
                            .select(memberSub.age.max())
                            .from(memberSub), "age")
                        )
                    )
            .from(member)
            .fetch();
}

ExpressionUtils.as(source, alias) 형태로 필드나 서브 쿼리에 별칭을 지정하는 형태로 이름이 다른 문제를 해결할 수 있습니다.

필드의 경우는 별칭을 사용하는 방식으로 해결하고, 서브 쿼리의 경우 ExpressionUtils 를 사용해서 해결합니다.

1-4. @QueryProection

[ DTO ]

@Data
public class MemberDto {
    @QueryProjection
    public MemberDto(String username, int age) {
        this.username = username;
        this.age = age;
    }
}

응답으로 사용할 DTO 의 생성자에 @QueryProection 을 붙이면 Q 클래스가 생성되고, 그 내부에 생성자를 가지게 됩니다.

[ 테스트 코드 ]

@Test
void findDtoByQueryProjection() {
   List<MemberDto> result = queryFactory
        .select(new QMemberDto(member.username, member.age))
        .from(member)
        .fetch();
}

그 후 select 절에서 new 를 통해 Q 클래스를 생성하면 기존 DTO 가 생성돼서 반환됩니다.

@QueryProjection 을 사용하면 컴파일 시점에 오류를 잡을 수 있는 반면, Projections.constructor 를 사용하면 런타임에 오류가 발생하게 됩니다.

하지만 DTO 에 QueryDSL 어노테이션을 유지해야 하는 점과 DTO 까지 Q 클래스를 생성해야 하는 단점이 있습니다.

2. 동적 쿼리

2-1. BooleanBuilder

private List<Member> searchMember1(String usernameCond, Integer ageCond) {
    BooleanBuilder builder = new BooleanBuilder();

    if (usernameCond != null) {
        builder.and(member.username.eq(usernameCond));
    }

    if (ageCond != null) {
        builder.and(member.age.eq(ageCond));
    }

    return queryFactory
            .selectFrom(member)
            .where(builder)
            .fetch();
}

BooleanBuilder 를 생성해서 동적 쿼리를 작성할 수 있습니다. builder 에 조건을 추가할 수 있는데 null 인지 판단하는 로직을 추가하면 동적 쿼리를 작성할 수 있습니다. 그 후 where 절 안에 builder 를 넣으면 자동으로 조건이 생성됩니다.

만약 usernameCond 가 필수라면 new BooleanBuilder(member.username.eq(usernameCond)) 로 작성해서 초기 조건을 지정할 수 있습니다.

또 where 절에 builder.and() 와 같이 계속해서 조건을 작성할 수 있습니다.

2-2. where 절 다중 파라미터

private List<Member> searchMember2(String usernameCond, Integer ageCond) {
    return queryFactory
            .selectFrom(member)
            .where(usernameEq(usernameCond), ageEq(ageCond))
            .fetch();
}

private BooleanExpression usernameEq(String usernameCond) {
    return usernameCond == null ? null : member.username.eq(usernameCond);
}

private BooleanExpression ageEq(Integer ageCond) {
    return ageCond == null ? null : member.age.eq(ageCond);
}

where 에 조건을 여러 개 나열하면 and 조건으로 들어가고, null 이 들어가면 무시됩니다. 이 방식을 사용하면 메서드를 다른 쿼리에서도 재활용 할 수 있다는 장점이 있습니다.

또 아래처럼 두 조건을 조합해서 사용할 수 있지만, null 체크에 주의해야 합니다.

private BooleanExpression allEq(String usernameCond, Integer ageCond) {
    return usernameEq(usernameCond).and(ageEq(ageCond));
}

3. 수정, 삭제 벌크 연산

[ 수정 ]

long count = queryFactory
        .update(member)
        .set(member.username, "성인")
        .where(member.age.lt(19))
        .execute();

execute() 를 사용하며, 반환값은 영향을 받은 로우의 수가 됩니다.

[ 삭제 ]

long count = queryFactory
        .delete(member)
        .where(member.age.gt(18))
        .execute();

영속성 컨텍스트에 있는 엔티티를 무시하고 실행되기 때문에 벌크연산을 실행하고 나면 영속성 컨텍스트를 초기화 하는 것이 좋습니다.

4. SQL Function 호출

String result = queryFactory
        .select(Expressions.stringTemplate(
                    "function('replace', {0}, {1}, {2})", 
                        member.username, "member", "M"))
        .from(member)
        .fetchFirst();

member 를 M 으로 변경하는 replace 함수를 호출하는 코드입니다. SQL function 은 JPA 와 같이 Dialect 에 등록된 내용만 호출할 수 있습니다.

김영한 님의 실전! Querydsl 강의를 보고 작성한 내용입니다.

1. JPQL vs QueryDSL

1-1. 비교하기

[ JPQL ]

@Test
public void jpql() {
    String jpql = "select m from Member m where m.username = :username";
    Member findMember = em.createQuery(jpql, Member.class)
                .setParameter("username", "member1")
                .getSingleResult();

    assertThat(findMember.getUsername()).isEqualTo("member1");
}

[ QueryDSL ]

@Test
void queryDSL() {
    JPAQueryFactory queryFactory = new JPAQueryFactory(em);
    QMember m = new QMember("m");

    Member findMember = queryFactory
                .select(m)
                .from(m)
                .where(m.username.eq("member1"))
                .fetchOne();
    assertThat(findMember.getUsername()).isEqualTo("member1");
}

JpaQueryFactory 의 생성자에 EntityManager 를 넘겨줍니다. 그러면 QueryFactory 가 Entitymanager 를 가지고 데이터를 찾거나 하는 등의 작업을 수행합니다.

쿼리는 일반적인 sql 처럼 select, from, where 를 사용하여 작성하면 되고, QueryDSL 은 자동으로 preparedStatement 와 파라미터 바인딩 방식을 사용해서 기존에 setParameter 로 수행했던 과정을 자동으로 수행해줍니다.

쉽게 생각하면 Querydsl은 JPQL 빌더이며, 가장 큰 차이점으로는 JPQL 은 문자로 작성해야 하지만 QueryDSL 은 코드로 작성하기 때문에 컴파일 시점에 오류를 잡아낼 수 있습니다.

1-2. JPAQueryFactory를 필드로

public class QuerydslBasicTest {

    @PersistenceContext
    EntityManager em;

    JPAQueryFactory queryFactory;

    @BeforeEach
    public void before() {
        queryFactory = new JPAQueryFactory(em);
        ...
    }
}

JPAQueryFactory 를 필드로 빼고, 이를 생성할 때 entityManager 를 넘겨주는 방식으로 사용해도 됩니다.

스프링 프레임워크는 여러 쓰레드에서 동시에 같은 EntityManager 에 접근해도, 트랜잭션 마다 별도의 영속성 컨텍스트를 제공하기 때문에 JPAQueryFacytory 는 멀티 스레드 환경에서 동시성 문제 없이 동작합니다.

2. Q-Type

Q 클래스 인스턴스를 사용하는 방법에는 2가지가 존재합니다.

QMember m = new QMember("m");   // 별칭 직접 사용
QMember qMember = QMember.member; // Q 클래스 내부에 자동으로 생성된 인스턴스를 사용

2-1. 인스턴스 사용

import static study.querydsl.entity.QMember.*;

@Test
void queryDSL() {
    Member findMember = queryFactory
                .select(member)
                .from(member)
                .where(member.username.eq("member1"))
                .fetchOne();
    assertThat(findMember.getUsername()).isEqualTo("member1");
}

위의 코드는 인스턴스를 사용 + static import 를 사용하는 방식입니다. select 내부에 QMember.member 를 작성한 후 QMember 를 static import 를 하면 위처럼 사용할 수 있습니다.

2-2. 별칭 사용

QueryDSL 은 JPQL 의 빌더 역할을 하며, QueryDSL 로 작성된 것은 JPQL 로 변환되어 실행됩니다. 실행되는 JPQL 을 확인하고 싶다면 아래 설정을 추가하면 됩니다.

spring:
  jpa:
    properties:
      hibernate:
        use_sql_comments: true

설정을 추가하고 실행되는 JPQL 을 살펴보면 아래와 같습니다.

select member1
from Member member1
where member1.username = ?1 

현재 별칭이 member1 이라고 지정된 것을 볼 수 있습니다. 이는 QMember 를 들어가보면 왜 member1 이라고 지정되는지 알 수 있습니다.

QMember 에서 인스턴스 (member )를 만들 때 member1 이라는 이름으로 생성하기 때문에 JPQL 에서 member1 이라고 표시됩니다.

@Test
void queryDSL() {
    QMember m = new QMember("m");

    Member findMember = queryFactory
                .select(m)
                .from(m)
                .where(m.username.eq("member1"))
                .fetchOne();
    assertThat(findMember.getUsername()).isEqualTo("member1");
}

select m
from Member m
where m.username = ?1

만약 별칭을 사용하도록 테스트 코드를 수정하고 실행하면 member1 으로 나오던 것이 별칭으로 지정한 m 으로 변경됩니다.

하지만 같은 테이블을 조인해야 하는 경우가 아니면 기본 인스턴스를 사용하는 것을 권장하신다고 합니다.

3. QueryDSL 기본 문법

3-1. 검색 조건

QueryDSL 은 JPQL 이 지원하는 모든 검색 조건을 제공합니다. 아래 예시 몇 가지가 있습니다.

member.username.isNotNull()             // 이름이 is not null

member.age.in(10, 20)                   // age in (10,20)

member.age.goe(30)                      // age >= 30
member.age.gt(30)                       // age > 30

member.username.like("member%")         // like 검색
member.username.contains("member")      // like ‘%member%’ 검색
member.username.startsWith("member")    // like ‘member%’ 검색

이때 여러 조건을 한 번에 사용하기 위해 and() 와 파라미터 처리를 제공합니다.

[ and ]

@Test
void search() {
    Member findMember = queryFactory
            .selectFrom(member)
            .where(member.username.eq("member1")
                    .and(member.age.eq(10)))
            .fetchOne();
    assertThat(findMember.getUsername()).isEqualTo("member1");
    assertThat(findMember.getAge()).isEqualTo(10);
}

where 안에 여러 개의 조건을 and 로 묶을 수 있습니다. 참고로 and 말고 or 도 가능하며, select 와 from 을 selectFrom() 으로 줄여서 사용할 수 있습니다.

[ 파라미터 ]

@Test
void search() {
    Member findMember = queryFactory
            .selectFrom(member)
            .where(member.username.eq("member1"), (member.age.eq(10)))
            .fetchOne();
    assertThat(findMember.getUsername()).isEqualTo("member1");
    assertThat(findMember.getAge()).isEqualTo(10);
}

and 로 묶지 않고 쉼표를 통해 끊어서 사용할 수 있습니다. 이 경우에는 AND 조건으로 묶이게 되며 null 값은 무시됩니다. 이 기능과 메서드 추출을 활용해서 동적 쿼리를 깔끔하게 만들 수 있습니다.

3-2. 결과 조회

fetch : 리스트를 조회, 없으면 빈 리스트가 반환

fetchOne : 단건 조회, 결과가 없으면 null, 둘 이상이면 NonUniqueResultException

fetchFirst : limit(1).fetchOne() 을 실행

fetchResults : 페이징 정보 포함한 결과 반환, count 쿼리가 추가로 실행됨

fetchCount : count 를 조회

//페이징에서 사용
QueryResults<Member> results = queryFactory
                .selectFrom(member)
                .fetchResults();

long limit = results.getLimit();
long offset = results.getOffset();
long total = results.getTotal();
List<Member> content = results.getResults();

fetchResult 의 결과에서 getTotal() 로 count 쿼리의 결과를 얻을 수 있고, getResult() 로 데이터를 가져올 수 있습니다. 이때 쿼리는 count 쿼리와 데이터를 가져오는 쿼리 총 2번이 실행됩니다.

fetchCount 와 fetchResult 는 개발자가 작성한 select 쿼리를 기반으로 count 용 쿼리를 내부에서 만들어서 실행합니다.

그런데 이 기능은 단순히 select 구문을 count 처리하는 용도로 바꾸는 정도입니다. 따라서 단순한 쿼리에서는 잘 동작하지만, 복잡한 쿼리에서는 제대로 동작하지 않는다고 합니다.

또 fetchResults 와 fetchCount 는 Querydsl 5.0 부터 Deprecated 되었습니다. 그 대안으로 fetch 를 사용하고, count 쿼리는 필요한 경우 직접 작성하며, fetchOne 을 실행하면 됩니다.

3-3. 정렬

@Test
void sort() {
    List<Member> result = queryFactory
            .selectFrom(member)
            .where(member.age.eq(100))
            .orderBy(member.age.desc(),
                    member.username.asc().nullsLast())
            .fetch();            
}

위의 예시는 나이 내림차순, 이름 오름차순 + null 은 가장 마지막에 위치를 기준으로 정렬한 예시입니다.

정렬은 orderBy() 에 지정할 수 있으며, 쉼표를 통해 여러 개를 지정할 수 있습니다. 또 null 데이터의 순서를 지정할 수 있는데 nullsLast(), nullsFirst() 가 있습니다.

3-4. 페이징

@Test
void paging1() {
    List<Member> result = queryFactory
            .selectFrom(member)
            .orderBy(member.username.desc())
            .offset(0)  // 0부터 시작
            .limit(2)
            .fetch();
}

offset 과 limit 를 사용해서 페이징 쿼리를 작성할 수 있으며, offset 은 0 부터 시작합니다.

페이징 쿼리를 작성할 때, 데이터를 조회하는 쿼리는 여러 테이블을 조인해야 하지만, count 쿼리는 조인이 필요 없는 경우도 있습니다. 만약 fetchResult() 를 사용한다면 자동화된 count 쿼리가 원본 쿼리처럼 모두 조인을 해버리기 때문에 성능이 좋지 않을 수도 있습니다. 따라서 count 쿼리에 조인이 필요없는 성능 최적화가 필요하다면, count 전용 쿼리를 별도로 작성해야 합니다.

3-5. 집합 함수

@Test
void group() {
    List<Tuple> result = queryFactory
            .select(team.name, 
                    member.age.avg(),
                    member.age.sum(),
                    member.age.avg(),
                    member.age.max(),
                    member.age.min()
                    )
            .from(member)
            .join(member.team, team)
            .groupBy(team.name)
            .fetch();

Tuple teamA = result.get(0);

assertThat(teamA.get(team.name)).isEqualTo("teamA");
assertThat(teamA.get(member.age.avg())).isEqualTo(15);
}

기본적인 집계 함수들을 다 사용할 수 있으며, Tuple 이 반환됩니다. tuple 안에 담긴 데이터를 가져올 때는 get() 내부에 조회한 것을 넣어주면 됩니다. 추가로 having() 을 통해 그룹된 결과를 제한할 수 있습니다.

4. 조인

4-1. 기본 조인

join(조인대상, 별칭으로 사용할 Q타입)

@Test
void join() {
    List<Member> result = queryFactory
            .selectFrom(member)
            .join(member.team, team)
            .where(team.name.eq("teamA"))
            .fetch();
}

JPQL 에서 join m.team t 로 조인을 사용했는데 QueryDSL 도 조인대상을 지정하고 별칭처럼 Q 타입을 지정합니다. join 외에도 innerJoin, leftJoin 과 같은 다른 조인도 사용할 수 있습니다.

select
    member1 
from
    Member member1   
inner join
    member1.team as team 
where
    team.name = ?1

테스트 코드 실행 결과 위와 같은 JPQL 이 생성되고 실행됩니다.

4-2. 세타 조인

@Test
void theta_join() {
    List<Member> result = queryFactory
            .select(member)
            .from(member, team)
            .where(member.username.eq(team.name))
            .fetch();
}

연관관계가 없어도 세타 조인을 통해 조인을 실행할 수 있습니다. 이때는 from 절에 여러 개의 엔티티를 사용하면 됩니다. 하지만 세타 조인은 외부 조인 불가능한데 뒤에 나오는 조인 on 을 사용하면 외부 조인이 가능합니다.

4-3. 조인 ON 절

ON 절을 활용하면 아래 두 가지를 수행할 수 있습니다

1. 조인 대상 필터링
2. 연관관계가 없는 엔티티 외부 조인

[ 조인 대상 필터링 ]

@Test
void join_on_filtering() {
    List<Tuple> result = queryFactory
            .select(member, team)
            .from(member)
            .leftJoin(member.team, team)
            .on(team.name.eq("teamA"))
            .fetch();
}

tuple = [Member(id=1, username=member1, age=10), Team(id=1, name=teamA)] tuple = [Member(id=2, username=member2, age=20), Team(id=1, name=teamA)] tuple = [Member(id=3, username=member3, age=30), null] tuple = [Member(id=4, username=member4, age=40), null]

테스트 코드를 수행한 결과는 위와 같습니다. ON 절을 통해 team.name 에 조건을 걸었기 때문에 teamA 만 출력되었고, left join 이기 때문에 teamB 에 해당하는 Member3, Member4 는 team 이 null 로 출력되었습니다.

on 절을 활용해 조인 대상을 필터링 할 때, 외부조인이 아니라 내부조인을 사용하면 where 절에서 필터링 하는 것과 기능이 동일합니다. 따라서 내부조인이면 where 절로 해결하고, 정말 외부조인이 필요한 경우에만 이 기능을 사용하는 것을 권장한다고 하십니다.

[ 연관관계가 없는 엔티티 외부 조인 ]

@Test
void join_on_no_relation() {
    List<Tuple> result = queryFactory
            .select(member, team)
            .from(member)
            .leftJoin(team)
            .on(member.username.eq(team.name))
            .fetch();

    for (Tuple tuple : result) {
        System.out.println("tuple = " + tuple);
    }
}

하이버네이트 5.1부터 on 을 사용해서 서로 관계가 없는 필드로 내부 조인, 외부조인을 하는 기능이 추가되었습니다.

select
    m1_0.member_id, m1_0.age, m1_0.team_id, m1_0.username, t1_0.team_id, t1_0.name 
from
    member m1_0 
left join
    team t1_0 
on m1_0.username=t1_0.name

기존에는 leftJoin(member.team, team) 을 사용했는데 이렇게 하면 조인의 on 절에 id 값이 들어가게 됩니다.

하지만 이번에는 leftJoin(team) 하나 밖에 없는 것을 볼 수 있습니다. 이렇게 하면 id 매칭이 없어지기 때문에 on 절에 적힌 것처럼 username 와 name 만으로 매칭됩니다.

4-4. 패치 조인

@Test
void fetchJoin() {
    Member findMember = queryFactory
            .selectFrom(member)
            .join(member.team, team)
            .fetchJoin()
            .where(member.username.eq("member1"))
            .fetchOne();
}

기존과 동일하게 join 을 사용하고, 뒤에 fetchJoin() 을 사용하면 연관된 엔티티까지 한 번에 조회할 수 있습니다.

5. 서브쿼리

5-1. where 절 서브쿼리

@Test
void subQuery_where() {
    QMember memberSub = new QMember("memberSub");

    List<Member> result = queryFactory
                .selectFrom(member)
                .where(member.age.eq(
                        JPAExpressions
                            .select(memberSub.age.max())
                            .from(memberSub)
                ))
                .fetch();
}

QueryDSL 에서 서브쿼리를 사용하려면 JPAExpressions 를 사용합니다. 이때 서브쿼리와 메인쿼리의 alias 가 겹치면 안되기 때문에 Q 객체를 새로 생성해서 사용해야 합니다. 일반적인 SQL 에서 별칭을 다르게 하는 것과 동일한 원리입니다.

eq 외에도 앞에서 보았던 in, goe 와 같은 것들도 사용할 수 있습니다.

5-2. select 절 서브쿼리

@Test
void subQuery_select() {
    QMember memberSub = new QMember("memberSub");

    List<Tuple> result = queryFactory
                .select(member.username,
                        JPAExpressions
                                .select(memberSub.age.avg())
                                .from(memberSub))
                .from(member)
                .fetch();
}

하이버네이트 구현체를 사용하면 select 절의 서브쿼리를 지원합니다. 따라서 Querydsl도 하이버네이트 구현체를 사용하면 select 절의 서브쿼리를 지원합니다.

JPA JPQL 서브쿼리의 한계점으로 from 절의 서브쿼리는 지원하지 않는데 Hibernate 6 부터 from 절에서의 서브쿼리를 지원합니다. 하지만 QueryDSL 에서는 아직 지원하지 않는 것 같다고 합니다.

6. 기타 문법

6-1. Case 문

case 문은 select, where, order by 에서 사용할 수 있습니다.

@Test
void queryDSLCase() {
    // 단순 조건
    List<String> result1 = queryFactory
                .select(member.age
                        .when(10).then("열살")
                        .when(20).then("스무살")
                        .otherwise("기타"))
                .from(member)
                .fetch();

    // 복잡한 조건
    List<String> result1 = queryFactory
                .select(new CaseBuilder()
                        .when(member.age.between(0, 20)).then("0 ~ 20살")
                        .when(member.age.between(21, 30)).then("21 ~ 30살")
                        .otherwise("기타"))
                .from(member)
                .fetch();
}

복잡한 조건을 사용할 때는 CaseBuilder 를 사용해서 case 조건을 줄 수 있습니다. then 에서 문자가 아닌 숫자를 반환한다면 CaseBuilder 의 반환형을 따로 뽑아 정렬 기준으로 사용할 수 있습니다.

6-2. 상수

Tuple result = queryFactory
        .select(member.username, Expressions.constant("A"))
        .from(member)
        .fetchFirst();

상수가 필요한 경우 Expressions.constant() 를 사용합니다.

6-3. 문자

String result = queryFactory
        .select(member.username.concat("_").concat(member.age.stringValue()))
        .from(member)
        .where(member.username.eq("member1"))
        .fetchOne();

문자를 더할 때는 concat() 을 사용합니다. 또 문자가 아닌 다른 타입을 문자로 변환할 때는 stringValue() 를 사용하는데 특히 ENUM 을 사용할 때 주로 사용됩니다.

김영한 님의 실전! 스프링 데이터 JPA 강의를 보고 작성한 내용입니다.

1. Spring Data JPA 구현체 분석

IDE 를 통해 JpaRepository 에서 찾아보면 보면 SimpleJpaRepository 가 나오는데 바로 이것이 Spring Data JPA 의 구현체입니다.

@Repository
@Transactional(readOnly = true)
public class SimpleJpaRepository<T, ID> implements JpaRepositoryImplementation<T, ID> {

    private final JpaEntityInformation<T, ?> entityInformation;
    private final EntityManager entityManager;
    private final PersistenceProvider provider;
    ...
    public SimpleJpaRepository(Class<T> domainClass, EntityManager entityManager) {
        this(JpaEntityInformationSupport.getEntityInformation(domainClass, entityManager), entityManager);
    }
    ...
    @Override
    public Optional<T> findById(ID id) {
        ...
        if (metadata == null) {
            return Optional.ofNullable(entityManager.find(domainType, id));
        }
        ...
        return Optional.ofNullable(type == null ? entityManager.find(domainType, id, hints) : entityManager.find(domainType, id, type, hints));
    }
    ...
}

[ EntityManager ]

해당 클래스를 살펴보면 내부적으로 EntityManager 를 가지고 있는 것을 볼 수 있으며, findById() 를 실행할 때도 em.find() 를 실행해서 가져오는 것을 볼 수 있습니다. 결국 Spring Data JPA 는 JPA 내부 기능들을 활용해서 동작하는 것입니다.

[ @Repository ]

또 @Repository 가 붙어있는 것을 볼 수 있는데 이로 인해 스프링 빈의 컴포넌트 스캔 대상이 되며, JDBC 나 JPA 는 다른 예외들이 발생하게 되는데 해당 어노테이션을 사용함으로써 예외가 발생했을 때 스프링에서 사용할 수 있는 예외로 변환됩니다.

그래서 스프링에서 제공하는 예외가 전달되기 때문에 JDBC, JPA 와 같은 하부 기술을 변경해도 Service 계층에서 예외를 처리하는 로직은 변경하지 않아도 됩니다.

[ @Transactional ]

그 다음에 @Transational 이 붙어있는데 Service 계층에서 @Transactional 을 사용했다면 해당 트랜잭션을 이어 받아서 동작하지만, 트랜잭션이 없어도 Spring Data JPA 는 자기 리포지토리 계층에서 트랜잭션을 시작합니다.

트랜잭션에 readOnly=true 로 되어 있는데, save 와 같은 메서드를 보면 별도로 readOnly 옵션 없이 트랜잭션 어노테이션이 사용되고 있습니다. 그래서 @Transactional 을 걸지 않아도 Spring Data JPA 가 트랜잭션을 걸고 시작하기 때문에 정상적으로 동작합니다.

하지만 save 를 하고 나오는 순간 영속성 컨텍스트가 사라지기 때문에 영속성 컨텍스트로 인해 사용할 수 있는 기능들을 사용할 수 없게 됩니다.

참고로 데이터를 단순히 조회만 하고 변경하지 않는 트랜잭션에서 readOnly=true 옵션을 사용하면 플러시를 생략해서( 변경감지가 일어나지 않음 ) 약간의 성능 향상을 얻을 수 있다고 합니다.

2. 새로운 엔티티를 구별하는 방법

2-1. save 메서드

SimpleJpaRepository 의 save 메서드를 보면 아래와 같습니다.

@Transactional
@Override
public <S extends T> S save(S entity) {
    Assert.notNull(entity, "Entity must not be null");

    if (entityInformation.isNew(entity)) {
        entityManager.persist(entity);
        return entity;
    } else {
        return entityManager.merge(entity);
    }
}

전달 받은 엔티티가 새로운 엔티티라면 persist() 를 호출하고, 새로운 엔티티가 아니면 merge() 를 호출합니다. merge 에 대한 내용은 이전 게시글에서 확인할 수 있습니다.

그렇다면 새로운 엔티티인지를 판단하는 기준은 무엇일까요?

2-2. 새로운 엔티티인지 판단하는 기준

새로운 엔티티를 판단하는 기본 전략은 아래와 같습니다. 참고로 식별자는 persist() 를 하면 엔티티 안에 들어가게 됩니다.

1. 식별자가 Long 과 같은 객체일 때 null 로 판단

2. 식별자가 int 와 같은 기본 타입일 때 0 으로 판단

3. Persistable 인터페이스를 구현해서 판단 로직 변경 가능

[ @GeneratedValue 사용 ]

public class Member {
    @Id @GeneratedValue
    private Long id;
}

예를 들면 Member 엔티티의 @Id 에 @GeneratedValue 를 사용하고 save 호출하면 아래처럼 동작합니다.

save 에 break point 를 찍고, repository.save() 를 호출하도록 한 뒤 디버깅을 돌리면 나오는 모습입니다. Member entity 의 id 값이 null 인 것을 볼 수 있습니다. 그래서 persist() 가 호출됩니다.

그 후 한 단계 더 실행하고 나면 Member 의 id 에 1 이라는 값이 들어간 것을 확인할 수 있습니다. 즉, 위에서 언급한 것첢 식별자는 persist() 이후에 엔티티에 들어가게 됩니다.

[ @GeneratedValue 미사용 ]

public class Item {
    @Id
    private String id;
}
// ----------------------------
@Test
void save() {
    Item item = new Item("1");
    itemRepository.save(item);
}

만약 위처럼 Id 값을 직접 지정하고 save() 를 호출한다면 결과는 아래와 같습니다.

동일하게 save 임에도 불구하고 이전과는 다르게 persist() 가 아닌 merge() 를 호출합니다. 왜냐하면 이미 Item 은 객체이고, 이미 객체에 id 값이 들어있기 때문에 새로운 객체라고 판단하지 않은 것입니다.

merge()는 우선 DB를 호출해서 값을 확인하고, DB에 값이 없으면 새로운 엔티티로 인지하므로 매우 비효율적입니다. 따라서 Persistable 을 사용해서 새로운 엔티티 확인 여부를 직접 구현하게는 좋습니다.

2-3. Persistable

@Entity
@EntityListeners(AuditingEntityListener.class)
@NoArgsConstructor(access = AccessLevel.PROTECTED)
public class Item implements Persistable<String> {
    @Id
    private String id;

    @CreatedDate
     private LocalDateTime createdDate;

    public Item(String id) {
        this.id = id;
    }

    @Override
    public String getId() {
        return id;
    }

    @Override
    public boolean isNew() {
        return createdDate == null;
    }
}

Persistable 에는 PK 의 타입을 지정합니다. 그리고 getId 와 isNew 를 오버라이딩 해야 하는데 isNew() 메서드에 어떤 기준으로 새로운 객체인지 판단할 것인지를 작성하면 됩니다.

강사님이 자주 사용하는 방식은 @CreatedDate 를 사용하는 것이라고 합니다. @CreatedDate 도 JPA 의 이벤트인데, persist 되기 전에 호출됩니다. 그래서 이 값이 null 인지를 기준으로 새로운 객체인지를 판단할 수 있게 됩니다.

그래서 아까와 동일한 테스트를 실행시켰을 때 createdDate 가 null 이기 때문에 새로운 객체라고 판단해서 persist 가 실행됩니다.

persist 이후에 값을 확인해보면 createdDate 에 값이 정상적으로 들어있는 것을 확인할 수 있습니다.

김영한 님의 실전! 스프링 데이터 JPA 강의를 보고 작성한 내용입니다.

1. 사용자 정의 인터페이스 구현

Spring Data JPA 는 인터페이스만 정의하면 구현체는 스프링이 자동으로 생성해줍니다. 인터페이스를 직접 구현하면 개발자가 구현해야 하는 기능이 너무 많습니다.

인터페이스 메서드를 직접 구현하기 위해 JPA 를 직접 사용하거나 MyBatis 를 사용할 수 있도록 사용자 정의 리포지토리라는 기능을 제공합니다.

이 기능은 인터페이스만으로 해결되지 않을 때, 예를 들어 NamedQuery 나 @Query 로 해결할 수 있는 경우가 아니고 복잡한 동적 쿼리를 작성해야 할 때 사용합니다. 대표적으로 QueryDSL 을 사용할 때 사용한다고 합니다.

[ 1. 인터페이스 생성 ]

public interface MemberRepositoryCustom {
    List<Member> findMemberCustom();
}

먼저 인터페이스를 생성하고, 사용할 메서드를 정의합니다.

[ 2. 구현체 생성 ]

@RequiredArgsConstructor
public class MemberRepositoryImpl implements MemberRepositoryCustom {

    private final EntityManager em;

    @Override
    public List<Member> findMemberCustom() {
        return em.createQuery("select m from Member m", Member.class).getResultList();
    }
}

1번에서 구현한 인터페이스를 상속 받아, JPA 를 사용하여 실행할 메서드를 구현합니다.

여기서 중요한 점은 1번의 인터페이스 이름은 아무거나 지정해도 되지만, 구현체의 이름은 JpaRepository 를 상속 받는 인터페이스명 + Impl 형태로 작성해야 합니다.

Spring Data 2.x 부터는 1번에서 구현한 인터페이스명 + Impl ( MemberRepositoryCustomImpl ) 형태도 가능합니다. 강사님은 새롭게 변경된 이 방식이 더 직관적이기 때문에 권장한다고 하십니다.

[ 3. 인터페이스 상속 ]

public interface MemberRepository extends JpaRepository<Member, Long>, MemberRepositoryCustom {
    ...
}

Spring Data JPA 인터페이스에 1번에서 만든 인터페이스를 상속 받도록 합니다.

결과적으로 MemberRepository 에서 findMemberCustom() 을 호출하면 2번에서 구현한 메서드가 실행되는데 이 기능은 자바에서 되는건 아니고 Spring Data JPA 가 이렇게 동작하도록 엮어주는 것입니다.

[ 참고 ]

MemberRepositoryCustom 을 인터페이스가 아닌 클래스로 만들고 스프링 빈으로 등록해서 그냥 직접 사용해도 된다고 합니다. 물론 이 경우 스프링 데이터 JPA와는 아무런 관계 없이 별도로 동작한다고 합니다.

2. Auditing

엔티티를 생성, 변경할 때 등록일, 등록시간, 수정일, 수정시간과 같이 변경한 사람와 시간을 추적하고 싶을 때 사용합니다.

2-1. 순수 JPA 사용

@MappedSuperclass
public class JpaBaseEntity {
    @Column(updatable = false)
    private LocalDateTime createdDate;
    private LocalDateTime updatedDate;

    @PrePersist
    public void prePersist() {
        LocalDateTime now = LocalDateTime.now();
        createdDate = now;
        updatedDate = now;
    }

    @PreUpdate
    public void preUpdate() {
        updatedDate = LocalDateTime.now();
    }
}

생성된 시간에는 updatable = false 라는 옵션을 주었습니다. 이렇게 하면 실수로 생성시간을 변경해도 값이 업데이트 되지 않습니다.

@PrePersist 는 persist 하기 전에 이벤트가 발생하는 것이고, @PreUpdate 는 업데이트 하기 전에 이벤트가 발생하는 것입니다.

JPA 에서 진짜 상속 관계가 있고, 속성만 받는 상속 관계가 존재하는데 지금 같은 경우에는 속성만 받는 상속관계이며, 이런 경우에는 @MappedSuperclass 를 사용합니다.

해당 속성들을 사용할 엔티티에서 extends JpaBaseEntity 를 작성하면 테이블이 실행될 때 createdDate, updateDate 컬럼이 함께 생성됩니다.

create table member (
    age integer not null,
    member_id bigint not null,
    team_id bigint,
    username varchar(255),
    primary key (member_id)
)

만약 JpaBaseEntity 에 @MappedSuperclass 어노테이션이 없다면 위처럼 등록날짜, 수정날짜가 빠진 채로 테이블이 생성됩니다.

2-2. Spring Data JPA 사용

[ 1. 엔티티 생성 ]

@EntityListeners(AuditingEntityListener.class)
@MappedSuperclass
public class BaseEntity {
    // 등록일, 수정일
    @CreatedDate
    @Column(updatable = false)
    private LocalDateTime createdDate;

    @LastModifiedDate
    private LocalDateTime lastModifiedDate;

    // 등록자, 수정자
    @CreatedBy
    @Column(updatable = false)
    private String createdBy;

    @LastModifiedBy
    private String lastModifiedBy;
}

이벤트를 기반으로 동작한다는 것을 넣어주어야 하기 때문에 @EntityListeners(AuditingEntityListener.class) 를 추가합니다.

해당 어노테이션을 추가하지 않고 동작하도록 할 수 있는데 이것은 강의 자료를 참고하시길 바랍니다.

순수 JPA 에서 추가된 점은 등록자, 수정자를 넣은 것인데 @CreatedBy, @LastModifiedBy 를 사용하며, 그냥 두면 값이 들어가지 않고 이에 대한 처리가 필요합니다.

[ 2. Application 세팅 ]

@EnableJpaAuditing
@SpringBootApplication
public class DataJpaApplication {
    public static void main(String[] args) {
        SpringApplication.run(DataJpaApplication.class, args);
    }

    @Bean
    public AuditorAware<String> auditorProvider() {
        return () -> Optional.of(UUID.randomUUID().toString());
    }
}

Spring Data JPA 에서 등록시, 수정시를 넣으려면 xxxApplication 에 @EnableJpaAuditing 어노테이션을 넣어야 합니다.

해당 어노테이션을 붙이면 createdDate, lastModifiedDate 에 값이 채워지게 됩니다. 만약 등록할 때 수정시간을 넣고 싶지 않다면 modifyOnCreate = false 옵션을 넣으면 됩니다.

또 등록자, 수정자에 이름을 넣으려면 AuditorAware 를 스프링 빈으로 등록하고, createdBy, lastModifiedBy 에 채워넣을 값을 반환하면 됩니다.

위처럼 세팅해놓으면 데이터가 등록되거나 수정될 때마다 위에서 생성한 빈을 호출하고 반환하는 값을 꺼내서 createdBy, lastModifiedBy 에 값이 채워지게 됩니다.

예시에서는 간단하게 UUID 를 사용했는데, 저렇게 구현하지 않고 SecurityContextHolder 에서 인증 객체를 가져와 사용해야 한다고 하셨습니다.

3. 도메인 클래스 컨버터

[ 기존 방식 ]

public class MemberController {
    @GetMapping("/members/{id}")
    public String findMember(@PathVariable("id") Long memberId) {
        Member member = memberRepository.findById(memberId).get();
        return member.getUsername();
    }
}

기존에는 id 값을 받아서 memberRepository 를 통해 조회하는 방식을 거쳐 Member 엔티티를 가져왔습니다. 하지만 이 과정을 도메인 클래스 컨버터를 통해 간편하게 줄일 수 있습니다.

[ 새로운 방식 ]

public class MemberController {
    @GetMapping("/members/{id}")
    public String findMember(@PathVariable("id") Member member) {
        return member.getUsername();
    }
}

HTTP 요청은 회원 id 를 받지만 도메인 클래스 컨버터가 중간에 리파지토리를 사용해서 엔티티를 찾고, 회원 엔티티 객체를 반환합니다.

만약 id 값이 존재하지 않는다면 MissingPathVariableException 예외가 발생하게 됩니다.

도메인 클래스 컨버터로 엔티티를 파라미터로 받으면, 이 엔티티는 단순 조회용으로만 사용해야 합니다. 트랜잭션이 없는 범위에서 엔티티를 조회했으므로, 엔티티를 변경해도 DB에 반영되지 않습니다.

4. 페이징과 정렬

4-1. Pageable

public class MemberController {
    @GetMapping("/members")
    public Page<Member> list(Pageable pageable) {
        return memberRepository.findAll(pageable);
    }
}

findAll() 에 pageable 을 넘기게 되면 PagingAndSortingRepository 의 findAll() 메서드가 실행되며, 이 메서드는 pageable 을 파라미터로 받습니다.

findAll(pageable) 은 파라미터로 받은 pageable 객체가 제공한 페이징 제한을 충족하는 엔티티들의 page 를 반환합니다.

Pageable 을 파라미터로 설정하면 쿼리 파라미터로 page, size, sort 와 같은 key 값들을 받을 수 있습니다.

ex> /members?page=0&size=3&sort=id,desc&sort=username,desc

쿼리 파라미터들이 Controller 에서 바인딩될 때 pageable 이 있으면 PageRequest 라는 객체를 생성해서 값을 채워넣고 인젝션해줍니다. Pageable 은 인터페이스이고, PageRequest 는 구현체입니다

4-2. 디폴트 설정

만약 쿼리 파라미터로 page 나 size 와 같은 것들을 지정하지 않았다면 기본 디폴트값들이 들어가게 되는데 이 디폴드 값들을 변경할 수 있습니다.

# 글로벌 설정
spring:
  data:
    web:
      pageable:
        default-page-size: 10 # 기본 페이지 사이즈
        max-page-size: 1000   # 최대 페이지 사이즈

// 개별 설정
public class MemberController {
    @GetMapping("/members")
    public Page<Member> list(@PageableDefault(size = 12, sort = "username"
                            direction = Sort.Direction.DESC) Pageable pageable) {
        return memberRepository.findAll(pageable);
    }
}

@PageableDefault 어노테이션을 사용해서 개별적으로 설정할 수 있습니다.

4-3. 페이징 정보가 둘 이상인 경우

public class MemberController {
    @GetMapping("/members")
    public Page<Member> list(@Qualifier("member") Pageable memberPageable,
                             @Qualifier("order") Pageable orderPageable) {
        return memberRepository.findAll(pageable);
    }
}

페이징 정보가 둘 이상인 경우 @Qualifier 에 접두사를 추가하여 접두사_xxx 를 통해 구분할 수 있습니다.

ex> /members?member_page=0&order_page=1

5. Query By Example

JpaRepository 를 보면 QueryByExampleExecutor 를 상속 받는 것을 알 수 있는데 이 인터페이스가 Example 을 파라미터로 받아 쿼리를 수행할 수 있도록 해줍니다.

Query By Example 을 사용하기 위해서 아래 3가지를 알아야 합니다.

Probe : 필드에 데이터가 있는 실제 도메인 객체

ExampleMatcher : 특정 필드를 일치시키는 상세한 정보 제공, 재사용 가능

Example : Probe와 ExampleMatcher로 구성, 쿼리를 생성하는데 사용

5-1. Example

[ 사용 예시 ]

@Test
void test() {
    Member member = new Member("m1");
    Example<Member> example = Example.of(member);

    List<Member> result = memberRepository.findAll(example);

    assertThat(result.get(0).getUsername()).isEqualTo("m1");
}

Query By Example 은 도메인 자체가 검색 조건이 됩니다. 도메인으로 Example 객체를 생성한 후 이를 repository 에 넘겨주면 도메인 객체를 가지고 검색 조건을 만들게 됩니다.

[ 쿼리 로그 ]

select ...
from member m1_0 
where m1_0.username='m1' and m1_0.age=0;

근데 위에서 분명 username 만 사용했는데 where 조건을 보면 age = 0 이라는 조건이 들어있는 것을 볼 수 있습니다.

생성한 member 의 PK 는 null 이기 때문에 무시되는데, age 는 기본 타입이기 때문에 0 이 들어갔기 때문에 무시하지 않은 것입니다.

5-2. ExampleMatcher

[ 사용 예시 및 쿼리 로그 ]

ExampleMatcher 를 사용하여 age 조건을 사용하지 않도록 할 수 있습니다.

@Test
void test() {
    Member member = new Member("m1");
    ExampleMatcher matcher = ExampleMatcher.matching().withIgnorePaths("age");
    Example<Member> example = Example.of(member, matcher);

    List<Member> result = memberRepository.findAll(example);

    assertThat(result.get(0).getUsername()).isEqualTo("m1");
}

select ...
from member m1_0 
where m1_0.username='m1';

위의 코드는 age 라는 속성을 무시한다는 의미이고, Example 객체를 생성할 때 도메인 객체와 함께 넘겨줍니다. 이때 수행되는 쿼리를 보면 age 가 조건에 없는 것을 확인할 수 있습니다.

5-3. 조인 사용하기

[ 사용 예시 및 쿼리 로그 ]

@Test
void test() {
    // 조인 사용을 위해 연관관계 설정
    Member member = new Member("m1");
    Team team = new Team("teamA");
    member.setTeam(team);

    ExampleMatcher matcher = ExampleMatcher.matching().withIgnorePaths("age");
    Example<Member> example = Example.of(member, matcher);

    List<Member> result = memberRepository.findAll(example);

    assertThat(result.get(0).getUsername()).isEqualTo("m1");
}

select ...
from member m1_0 
join team t1_0 on t1_0.team_id=m1_0.team_id 
where t1_0.name='teamA' and m1_0.username='m1';

위처럼 연관관계를 설정하고 쿼리를 수행하면 쿼리를 수행할 때 member 와 team 의 조인이 이루어지고, team 의 이름이 검색조건으로 함께 들어가게 됩니다.

단, 위와 같은 내부 조인( INNER JOIN) 만 가능하고 외부 조인( LEFT JOIN ) 은 불가능합니다. 또 AND 나 OR 를 사용한 중접 제약조건이 불가하며 문자를 제외하면 = 비교밖에 안됩니다.

6. Projections

Spring Data JPA Projections( 프로젝션 )은 JPA 엔터티의 일부 속성만을 선택적으로 조회하고, 이를 DTO 나 인터페이스 등의 특정 타입으로 매핑하는 기능을 말합니다. Projections 을 사용하면 필요한 데이터만을 가져와서 성능을 최적화하거나 데이터 전송 양을 최소화할 수 있습니다.

Spring Data JPA Projections은 인터페이스 기반의 프로젝션과 클래스 기반의 프로젝션 두 가지 유형이 있습니다.

[ 1. 인터페이스 기반 프로젝션 ]

인터페이스를 정의하고, 해당 인터페이스의 메소드들을 이용하여 필요한 속성을 지정합니다. 인터페이스의 메소드 이름은 엔티티의 필드나 그에 상응하는 getter 메소드와 일치해야 합니다.

[ 2. 클래스 기반 프로젝션 ]

특정 클래스를 정의하고, 해당 클래스의 생성자를 통해 필요한 속성을 전달합니다. 이 경우, 생성자 매개변수의 이름은 엔티티의 필드와 일치해야 합니다.

6-1. 인터페이스 기반 Closed Projections

[ 1. 반환하고자 하는 컬럼을 가진 인터페이스 생성 ]

public interface UserNameOnly {
    String getUsername();   // getter 형식
}

조회할 엔티티의 필드를 getter 형식으로 지정하면 해당 필드만 선택해서 조회합니다.

[ 2. 인터페이스를 반환하는 메서드 생성 ]

public interface MemberRepository extends JpaRepository<Member, Long> {
    List<UserNameOnly> findProjectionsByUsername(@Param("username") String username);
}

반환타입에 1번에서 생성한 인터페이스를 지정합니다. 이렇게 하면 UserNameOnly 인터페이스에 프록시 객체가 담겨서 반환됩니다.

[ 3. 테스트 코드 ]

@Test
void projections() {
    List<UserNameOnly> result = memberRepository.findProjectionsByUsername("m1");

    for (UserNameOnly userNameOnly : result) {
        System.out.println("userNameOnly = " + userNameOnly);
    }
}

select
    m1_0.username 
from
    member m1_0 
where
    m1_0.username=?

위의 코드를 실행했을 때 동작하는 쿼리를 보면 위와 같습니다. select 절을 보면 딱 username 만 가져온 것을 볼 수 있습니다. 또 출력된 결과를 보면 아래와 같습니다.

userNameOnly = org.springframework.data.jpa.repository.query.AbstractJpaQuery$TupleConverter$TupleBackedMap@4936dca9

인터페이스만 구현하면 구현 클래스는 Spring Data JPA 가 프록시 기술을 가지고 가짜 객체를 만들고, gerUsername() 을 확인한 후 구현체에 데이터를 담아서 반환해줍니다.

6-2. 인터페이스 기반 Open Projections

public interface UserNameOnly {
    @Value("#{target.username + ' ' + target.age + ' ' + target.team.name}")
    String getUsername();   // getter 형식
}

인터페이스에 정의할 때 @Value 에 스프링의 SpEL 문법을 사용해서 지정할 수 있습니다. 이렇게 하면 지정한 형식에 맞게 반환됩니다.

이렇게 되면 이전처럼 username 만 select 를 하는 것이 아니라 DB에서 엔티티 필드를 다 조회해온 다음에 위의 형식에 맞게 데이터를 집어넣고 반환하게 됩니다. 따라서 JPQL select 절 최적화가 이루어지지 않습니다.

6-3. 클래스 기반 프로젝션

public class UsernameOnlyDTO {

    private final String username;

    public UsernameOnlyDTO(String username) {
        this.username = username;
    }

    public String getUsername() {
        return username;
    }
}

인터페이스 말고 클래스 기반으로도 프로젝션이 가능한데 생성자의 파라미터 이름으로 매칭해서 해당 하는 컬럼만을 프로젝션합니다.

인터페이스와는 다르게 구체적인 클래스를 명시하기 때문에 프록시가 아닌 구체적인 클래스의 객체의 생성자에 값을 넣어서 반환합니다.

userNameOnly = study.datajpa.example.UsernameOnlyDTO@22f3b213

6-4. 동적 Projections

public interface MemberRepository extends JpaRepository<Member, Long> {
    <T> List<T> findProjectionsByUsername(String username, Class<T> type);
}

제네릭 타입을 주게 되면 조금 더 동적으로 데이터를 가져올 수 있습니다. 예를 들어, 어떤 경우에는 유저의 이름을 가져온다던지, 어떤 경우에는 나이를 가져온다던지 할 때 사용하면 편리합니다.

[ 사용 예시 ]

List<UsernameOnlyDTO> result = 
    memberRepository.findProjectionsByUsername("m1", UsernameOnlyDTO.class);

6-5. 중첩 구조

[ 1. 인터페이스 정의 ]

public interface NestedClosedProjections {
    String getUsername();
    TeamInfo getTeam();

    interface TeamInfo {
        String getName();
    }
}

[ 2. 사용 예시 및 쿼리 ]

List<NestedClosedProjections> result = 
    memberRepository.findProjectionsByUsername("m1", NestedClosedProjections.class);

select
    m1_0.username,
    t1_0.team_id,
    t1_0.name 
from
    member m1_0 
left join team t1_0 
    on t1_0.team_id=m1_0.team_id 
where
    m1_0.username=?

쿼리 로그를 보면 member 는 username 만 가져왔는데 team 은 모든 컬럼들을 조회한 것을 볼 수 있습니다.

프로젝션 대상이 root 엔티티면, JPQL SELECT 절 최적화 가능하지만 root 가 아니면 left outer join 을 처리하고, 모든 필드를 select 해서 엔티티로 조회한 다음에 계산하게 됩니다.

즉, 하나의 엔티티를 넘어가는 순간( 프로젝션 대상이 root 엔티티를 넘어가면 ) JPQL select 최적화가 불가능합니다.

7. Native Query

네이티브 쿼리는 JPA 가 제공하는 기능입니다. 하지만 가급적 네이티브 쿼리를 사용하지 않는게 좋다고 합니다.

7-1. JPA 네이티브 쿼리

public interface MemberRepository extends JpaRepository<Member, Long> {
    @Query(value = "select * from member where username = ?", nativeQuery = true)
    Member findByNativeQuery(String username);
}

네이티브 쿼리는 반환형이 굉장히 애매합니다. 예를 들어 username 을 가져온다고 했을 때 이는 Member 타입이 아닙니다.

스프링 데이터 JPA 기반 네이티브 쿼리에서 제공하는 반환형은 Object[], Tuple, DTO( Projections 포함 ) 세 가지 입니다.

또 Sort 파라미터를 통한 정렬이 정상 동작하지 않을 수 있으며, 동적 쿼리도 불가하고, @Query 에 작성함에도 불구하고 애플리케이션 로딩 시점에 문법 확인이 불가능합니다.

7-2. Projections 활용

@Query(value = "SELECT m.member_id as id, m.username, t.name as teamName " +
                "FROM member m left join team t ON m.team_id = t.team_id",
        countQuery = "SELECT count(*) from member",
        nativeQuery = true)
Page<MemberProjection> findByNativeProjection(Pageable pageable);

6번의 Projections 를 사용할 수 있으며, 페이징 처리도 가능합니다. 페이징 처리 시에는 네이티브 쿼리이기 때문에 countQuery 를 직접 작성해주어야 합니다.

과거에는 Object[] 배열로 받았어야 했는데 Projections 기능이 등장하며 반환형으로 인한 문제가 해결되었습니다.

7-3. 동적 네이티브 쿼리

String sql = "select m.username as username from member m";
List<MemberDto> result = em.createNativeQuery(sql)
        .setFirstResult(0)
        .setMaxResults(10)
        .unwrap(NativeQuery.class)
        .addScalar("username")
        .setResultTransformer(Transformers.aliasToBean(MemberDto.class))
        .getResultList();

하이버네이트를 직접 활용해서 동적 네이티브 쿼리를 사용할 수 있습니다.

김영한 님의 실전! 스프링 데이터 JPA 강의를 보고 작성한 내용입니다.

1. 쿼리 메소드

Spring Data JPA 는 쿼리 메소드 기능을 제공하는데 쿼리를 어떤 방식으로 작성할 것인지 3가지 방식을 제공합니다.

1. 메소드 이름으로 쿼리 생성

2. 메소드 이름으로 JPA NamedQuery 호출

3. @Query 어노테이션을 사용해서 Repository 인터페이스에 직접 정의

1-1. 메서드 이름으로 쿼리 생성

만약 특정 이름을 가진 유저 중에 n 살 이상인 회원을 조회하고 싶다면 JPA 의 경우 아래처럼 작성해야 합니다.

public List<Member> findByUsernameAndAgeGreaterThan(String username, int age) {
    return em.createQuery(
                "select m from Member m where m.username=:username and m.age>:age", 
                    Member.class)
                .setParameter("username", username)
                .setParameter("age", age)
                .getResultList();
}

하지만 Spring Data JPA 는 아래처럼 메서드만 정의해도 정상적으로 실행됩니다.

public interface MemberRepository extends JpaRepository<Member, Long> {
    List<Member> findByUsernameAndAgeGreaterThan(String username, int age);
}

이것이 가능한 이유는 Spring Data JPA 가 메서드 이름을 분석해서 JPQL 을 실행하기 때문입니다. 이때 몇 가지 규칙들이 존재하는데 위의 예시로 살펴보면 다음과 같습니다.

1. UsernameAndAge : where 절에서 and 조건으로 묶인다

2. Age 뒤에 GreaterThan 이 붙었기 때문에 > 로 들어간다

3. Username 은 다른거 없이 Username 만 사용해서 = 로 들어간다

그래서 결과적으로 실행된 쿼리 로그는 아래와 같습니다. 사용할 수 있는 규칙들은 공식문서에서 확인하실 수 있습니다.

select
    m1_0.member_id,
    m1_0.age,
    m1_0.team_id,
     m1_0.username 
from
    member m1_0 
where
    m1_0.username=? 
    and m1_0.age>?

1-2. 메소드 이름으로 JPA NamedQuery 호출

JPA 강의에서 NamedQuery 에 대해서 알아보았습니다. 이 NamedQuery 를 JPA 에서도, Spring Data JPA 에서도 호출할 수 있는데 이를 알아보도록 하겠습니다.

[ NamedQuery ]

@Entity
@NamedQuery(
    name="Member.findByUsername",
    query="select m from Member m where m.username = :username")
public class Member {
    ...
}

[ JPA 에서 호출 ]

public List<Member> findByUsername(String username) {
    return em.createNamedQuery("Member.findByUsername", Member.class)
                        .setParameter("username", username)
                        .getResultList();
}

createNamedQuery() 를 통해 NamedQuery 를 호출할 수 있습니다.

[ Spring Data JPA 에서 호출 ]

public interface MemberRepository extends JpaRepository<Member, Long> {
    @Query(name = "Member.findByUsername")
    List<Member> findByUsername(@Param("username") String username);
}

@Query 어노테이션을 사용하고, name 속성 내부에 NamedQuery 의 이름을 작성하면 됩니다.

Spring Data JPA 는 선언한 도메인 클래스 + . + 메서드 이름으로 NamedQuery 를 찾아서 실행합니다.

만약 실행할 NamedQuery 가 없다면 메서드 이름으로 쿼리 생성 전략을 사용합니다.

실무에서 Named Query를 직접 등록해서 사용하는 일은 드물고 @Query 를 사용해서 리파지토리 메소드에 쿼리를 직접 정의한다고 합니다.

1-3. @Query 를 사용해서 인터페이스에 직접 정의

public interface MemberRepository extends JpaRepository<Member, Long> {
    @Query("select m from Member m where m.username= :username and m.age = :age")
    List<Member> findUser(@Param("username") String username, @Param("age") int age);
}

@Query 어노테이션을 이용하는 방법으로 실행할 메서드에 JPQL 을 이용해 정적 쿼리를 직접 작성합니다.

createQuery 에서 JPQL 을 작성하는 것은 문자이기 때문에 오타가 있어도 오류가 발생하지 않는데 @Query 는 JPA Named 쿼리처럼 애플리케이션 실행 시점에 문법 오류를 발견할 수 있다는 장점이 있습니다.

2. @Query

2-1. 조회하기

[ 값 조회하기 ]

public interface MemberRepository extends JpaRepository<Member, Long> {
    @Query("select m.username from Member m")
    List<String> findUsernameList();
}

엔티티에서 특정한 값만을 가져오고 싶을 때 사용합니다.

[ DTO 조회하기 ]

public interface MemberRepository extends JpaRepository<Member, Long> {
    @Query("select new study.datajpa.dto.MemberDto(m.id, m.username, t.name) " +
            "from Member m join m.team t")
    List<MemberDto> findMemberDto();
}

DTO 를 바로 조회할 수 있는데 이때는 반드시 new 키워드를 사용해야 하고, 패키지경로까지 함께 적어주어야 합니다. 또한 DTO 에는 전달 받을 컬럼들을 가진 생성자가 필요합니다.

2-2. 파라미터 바인딩

파라미터 바인딩은 JPA 강의에서 나온 것처럼 위치 기반과 이름 기반이 있는데 코드 가독성과 유지보수를 위해 이름 기반 파라미터 바인딩을 사용하는 것이 좋다고 합니다.

public interface MemberRepository extends JpaRepository<Member, Long> {
    @Query("select m from Member m where m.username in :names")
    List<Member> findByNames(@Param("names") List<String> names);
}

Spring Data JPA 에서는 @Param 을 이용해서 파라미터 바인딩을 할 수 있습니다. 또 컬렉션을 넘겨주어 IN 연산자를 사용할 수 있습니다.

3. 반환타입

Member findByUsername(String name); // 엔티티
Optional<Member> findByUsername(String name); // 엔티티 Optional
List<Member> findByUsername(String name); // 엔티티 컬렉션

Spring Data JPA 는 여러 가지 반환 타입을 사용할 수 있습니다. 컬렉션을 반환하는 경우 결과가 없다면 빈 컬렉션이 반환됩니다.

하지만 하나만 조회하는 경우, JPQL 의 getSingleResult() 를 호출하는데, 이 메서드는 조회 결과가 없을 때 NoResultException 이 발생하는데 이를 null 로 반환해줍니다.

2개 이상이라면 NonUniqueResultException 예외가 발생합니다. 이때 Spring Data JPA 가 Spring 의 IncorrectResultSizeDataAccessException 으로 변환해서 반환합니다.

Repository 에 사용하는 기술은 JPA 나 몽고DB 와 같은 기술들을 사용할 수 있는데, 서비스 계층에서 해당 기술에 의존하는게 아니라 스프링이 추상화한 예외에 의존하면 스프링은 동일하게 데이터가 맞지 않으면 Repository 에 사용하는 기술을 변경해도 해당 예외를 발생시키기 때문에 서비스 코드를 변경하지 않아도 된다는 장점이 있습니다.

4. Spring Data JPA 페이징과 정렬

[ JPA ]

// Repository
public List<Member> findByPage(int age, int offset, int limit) {
    return em.createQuery(
        "select m from Member m where m.age = :age order by m.username desc", Member.class)
            .setParameter("age", age)
            .setFirstResult(offset)
            .setMaxResults(limit)
            .getResultList();
}

public long totalCount(int age) {
        return em.createQuery(
            "select count(m) from Member m where m.age = :age", Long.class)
                .setParameter("age", age)
                .getSingleResult();
    }

JPA 에서는 페이징을 할 때 offset 과 limit 를 사용하는데 이는 어디서부터 시작해서( offset ) 몇 개를 가져올지( limit )를 나타냅니다.

이렇게 JPQL 을 작성해놓으면 JPA 는 방언을 기반으로 동작하기 때문에 현재 DB 에 맞는 SQL 을 생성하고 실행하여 DB 에서 페이징 처리를 한 데이터를 가져옵니다.

또 페이징 처리에는 총 몇 개의 데이터가 있는지도 필요한데 이를 count 쿼리를 통해 구할 수 있는데 Spring Data JPA 는 이러한 것들을 편리하게 사용할 수 있도록 제공해줍니다.

4-1. 파라미터와 반환 타입

[ 페이징과 정렬 파라미터 ]

org.springframework.data.domain.Sort : 정렬 기능 org.springframework.data.domain.Pageable : 페이징 기능 ( 내부에 Sort 포함 )

패키지를 보면 springframework.data 인 것을 볼 수 있는데 이것은 DB 에 관계없이 페이징을 공통화 시켰다는 의미입니다.

[ 반환 타입 ]

org.springframework.data.domain.Page : 추가 count 쿼리 결과를 포함하는 페이징 org.springframework.data.domain.Slice : 추가 count 쿼리 없이 다음 페이지만 확인 가능 List : 추가 count 쿼리 없이 결과만 반환

Page 는 totalCount 와 같이 페이징 처리에 필요한 데이터를 가지고 있습니다. 데이터를 가져오는 쿼리와 count 쿼리가 함께 실행됩니다.

Slice 는 TotalCount 가 필요 없는 페이징 처리할 때 사용하는데 무한 스크롤 같은 곳에서 활용할 수 있는 것 같습니다.

List 를 반환타입으로 사용하면 페이징 처리와 관련된 함수들은 사용할 수 없고 페이징 처리된 데이터만 가져오게 됩니다.

4-2. Page 반환

[ Repository ]

public interface MemberRepository extends JpaRepository<Member, Long> {
    Page<Member> findByAge(int age, Pageable pageable);
}

Pageable 을 파라미터로 전달 받게 되는데 내부에 몇 번 페이지인지와 같은 정보가 들어있고, 반환 타입은 Page 로 작성합니다.

[ 테스트 코드 ]

@Test
void paging() {
    // Pageable 구현체
    PageRequest pageRequest = PageRequest
                                .of(0, 3, Sort.by(Sort.Direction.DESC, "username"));

    Page<Member> page = memberRepository.findByAge(10, pageRequest);    // 쿼리 실행 결과

    List<Member> content = page.getContent(); // 조회된 데이터

    assertThat(content.size()).isEqualTo(3); // 조회된 데이터 수
    assertThat(page.getTotalElements()).isEqualTo(5); // 전체 데이터 수
    assertThat(page.getNumber()).isEqualTo(0); // 페이지 번호
    assertThat(page.getTotalPages()).isEqualTo(2); // 전체 페이지 번호
    assertThat(page.isFirst()).isTrue(); // 첫번째 항목인가?
    assertThat(page.hasNext()).isTrue(); // 다음 페이지가 있는가?
}

Spring Data JPA 에서 페이징은 페이지 번호가 0부터 시작합니다. PageRequest 를 만들어 넘겨주었는데 이를 따라가보면 Pageable 인터페이스를 구현한 것임을 알 수 있습니다.

이렇게 Pageable 인터페이스만 전달하면 페이징 처리에 필요한 모든 데이터가 담겨서 들어오게 됩니다.

[ 쿼리 로그 ]

select m1_0.member_id,m1_0.age,m1_0.team_id,m1_0.username 
from member m1_0 
where m1_0.age=10 
order by m1_0.username desc 
offset 0 rows fetch first 3 rows only;
----------------------------------
select
    count(m1_0.member_id) 
from
    member m1_0 
where
    m1_0.age=10

데이터를 가져오는 쿼리를 수행하고 난 후에 자동으로 count 쿼리가 실행된 것을 확인할 수 있습니다.

위에서 언급한 것처럼 Page 를 반환할 때는 count 쿼리가 추가로 실행되고, 실행 결과 데이터가 Page 에 담기게 됩니다.

4-3. Slice 반환

Slice 는 totalCount 를 가지고 오지 않기 때문에 count 쿼리가 추가로 실행되지 않습니다.

또 slice 는 쿼리를 수행할 때 만약 3개를 요청했으면 1개를 더해서 4개를 요청하게 됩니다.

[ 쿼리 로그 ]

select m1_0.member_id,m1_0.age,m1_0.team_id,m1_0.username 
from member m1_0 
where m1_0.age=10 
order by m1_0.username desc 
offset 0 rows fetch first 4 rows only;

위의 코드에서 Page 를 반환하지 않고 Slice 를 반환하면 쿼리가 위처럼 실행됩니다. 3개를 요청했는데 4개의 데이터를 가져오는 것을 확인할 수 있습니다.

또 count 쿼리가 나가지 않기 때문에 getTotalElements(), getTotalPages() 를 사용할 수 없게 됩니다.

4-4. count 쿼리 분리

@Query(value = "select m from Member m left join m.team t")
Page<Member> findByAge(int age, Pageable pageable);

쿼리에 조인이 걸려있고, 이를 Page 로 반환하면 총 데이터 개수를 가져오기 위해 count 쿼리를 수행할 때도 조인을 수행하게 됩니다.

하지만 하이버네이트 6 부터는 이렇게 의미없는 left join을 최적화 해버리기 때문에 조인을 수행하지 않습니다.

[ 쿼리 로그 ]

select m1_0.member_id,m1_0.age,m1_0.team_id,m1_0.username 
from member m1_0 
order by m1_0.username desc 
offset 0 rows fetch first 3 rows only;
--------------------------------------------------------------
select count(m1_0.member_id) 
from member m1_0;

쿼리 로그를 살펴보면 join 을 통해 조회하는데 join 이 실행되지 않은 것을 볼 수 있습니다. 왜냐하면 JPQL 을 보았을 때 Team 과 조인을 하지만 전혀 사용하지 않고 있기 때문입니다.

만약 select 나 where 절에서 team 에 대한 조건을 사용하거나 left join fetch 를 사용하면 join 되는 쿼리가 수행됩니다.

[ join fetch 쿼리 로그 ]

select m1_0.member_id,m1_0.age,t1_0.team_id,t1_0.name,m1_0.username 
from member m1_0 
left join team t1_0 on t1_0.team_id=m1_0.team_id 
order by m1_0.username desc 
offset 0 rows fetch first 3 rows only;
--------------------------------------------------------------
select count(m1_0.member_id) 
from member m1_0;

하지만 left join fetch 를 사용해도 count 쿼리를 수행할 때 join 을 하지 않는 것은 동일합니다. 이유는 앞서 말했듯이 하이버네이트 6 부터는 이렇게 의미없는 left join을 최적화 해버리기 때문입니다.

[ countQuery 별도 지정 방법 ]

@Query(value = "select m from Member m left join m.team t", 
        countQuery = "select count(m.username) from Member m")
Page<Member> findByAge(int age, Pageable pageable);

Page 를 반환하면서 @Query 어노테이션을 사용해서 countQuery 속성에 count 쿼리를 분리해서 사용할 수 있습니다.

4-5. 페이징을 유지하면서 DTO 로 변환하기

Page<Member> page = memberRepository.findByAge(10, pageRequest);
Page<MemberDto> dtoPage = page.map(m -> new MemberDto());

page 내부에는 member 가 있기 때문에 map() 을 통해 member 를 MemberDto 로 변환할 수 있습니다.

[ 사이드 프로젝트에 적용 ]

// 변경 전 코드
Page<Comment> pagingData = commentRepository.findAllByParticipationId(participationId, pageable);
List<Comment> entityList = pagingData.getContent();
List<CommentResponseDTO> dtoList = entityList.stream().map(CommentResponseDTO::new).toList();

// 변경 후 코드
Page<Comment> pagingData = commentRepository.findAllByParticipationId(participationId, pageable);
List<CommentResponseDTO> dtoList1 = pagingData.map(CommentResponseDTO::new).stream().toList();

위 코드는 제가 사이드 프로젝트를 진행하면서 작성한 코드인데 이 방법을 몰라서 getContent() 로 데이터를 가져오고, 이를 반복하며 DTO 로 변환해주는 과정을 했었습니다.

저는 DTO 내부에 세팅해야 하는 데이터가 있어서 List 로 변환했는데 page.map() 을 통해 변환하고, 반환할 때 getContent() 를 쓰는 것도 좋을 것 같습니다. 데이터 말고 Page 자체를 반환해도 됩니다.

5. 벌크성 수정 쿼리

JPA 에서는 변경 감지 기능이 있어서 엔티티의 데이터를 변경하면 트랜잭션 커밋 시점에 update 쿼리가 수행됩니다.

이 방식은 하나씩 하는 방법이고, 여러 건의 데이터를 한 번에 변경하고 싶을 때는 벌크 연산을 사용합니다.

JPA 기본편에서 다루었는데 createQuery() 로 JPQL 을 작성하고, executeUpdate() 를 통해 수행합니다.

[ Repository ]

public interface MemberRepository extends JpaRepository<Member, Long> {
    @Modifying
    @Query("update Member m set m.age = m.age + 1 where m.age >= :age")
    int bulkAgePlus(@Param("age") int age);
}

반환되는 데이터는 영향을 받은 로우 수이며, 타입은 int 로 설정합니다.

벌크성 수정, 삭제 쿼리는 반드시 @Modifying 어노테이션을 사용해야 하며, 사용하지 않는다면 QueryExecutionRequestException 이 발생하게 됩니다. 왜냐하면 해당 어노테이션이 없다면 executeUpdate() 를 호출하는 것이 아닌 getResultList() 나 getSingleResult() 를 호출하기 때문입니다.

벌크 연산은 영속성 컨텍스트를 무시하고 DB 에 직접 쿼리가 날라가게 되는데 기존에 영속성 컨텍스트에 존재하던 엔티티의 데이터는 변경되지 않습니다. 그래서 벌크 연산 수행 후에는 반드시 영속성 컨텍스트를 초기화해야 하는데 이때 사용하는 옵션이 clearAutomatically 입니다.

@Modifying(clearAutomatically = true) 로 설정하면 벌크성 쿼리를 실행한 후에 영속성 컨텍스트를 초기화합니다. 디폴트는 false 입니다.

6. @EntityGraph

6-1. 지연로딩과 fetch join

연관관계를 지연로딩으로 설정하면 처음 조회할 때는 지연 로딩이 걸린 엔티티에 대해서는 쿼리가 실행되지 않고 실제 사용되는 시점에 쿼리가 수행됩니다. 이 경우 N + 1 문제가 발생합니다.

fetch join 을 사용하면 연관된 엔티티까지 한 번의 쿼리로 가져오는데 이때는 프록시 객체를 가져오는 것이 아닌 진짜 엔티티를 가져오게 됩니다. ( 이전 게시글 참고 )

Spring Data JPA 에서 @Query 내부에 join fetch 를 사용해서 패치조인을 수행할 수 있지만, 이 방법 외에도 연관된 엔티티를 한 번에 조회할 수 있는 기능을 제공합니다.

6-2. @EntityGraph 사용

1. 공통 메서드 오버라이드

public interface MemberRepository extends JpaRepository<Member, Long> {
    @Override
    @EntityGraph(attributePaths = {"team"})
    List<Member> findAll();
}

JpaRepository 의 findAll() 메서드를 오버라이딩하면서 @EntityGraph 를 사용하는 방법입니다. attributePaths 에는 연관관계가 설정된 이름을 지정하면 됩니다.

위의 메서드를 실행하면 Member 를 조회하면서 연관된 Team 까지 함께 조회하게 됩니다.

2. JPQL과 함께 사용

public interface MemberRepository extends JpaRepository<Member, Long> {
    @EntityGraph(attributePaths = {"team"})
    @Query("select m from Member m")
    List<Member> findMemberEntityGraph();
}

@Query 에 JPQL 을 작성하고, @EntityGraph 를 적용하는 방법도 가능합니다.

3. 메서드 이름으로 쿼리 생성 시 사용

public interface MemberRepository extends JpaRepository<Member, Long> {
    @EntityGraph(attributePaths = {"team"})
    List<Member> findByUsername(String username)
}

메서드 이름으로 쿼리가 자동으로 생성되게 설정한 후에 @EntityGraph 를 적용하는 방법도 가능합니다.

6-3. @NamedEntityGraph

@EntityGraph 는 JPA 에서 제공하는 기능입니다. JPA 에서 이 방법 외에도 @NamedEntityGraph 도 제공합니다.

@NamedEntityGraph(name = "Member.all", 
                attributeNodes = @NamedAttributeNode("team"))
@Entity
public class Member {
    ...
}

@NamedEntityGraph 에 이름을 지정하고, @NamedAttributeNode 에 연관관계가 설정된 필드명을 지정합니다.

public interface MemberRepository extends JpaRepository<Member, Long> {
    @EntityGraph("Member.all")
    @Query("select m from Member m")
    List<Member> findMemberEntityGraph();
}

그 후 Repository 에서 @NamedEntityaGraph 에서 지정한 이름으로 EntityGraph 기능을 사용할 수 있습니다.

7. JPA Hint & Lock

7-1. JPA 쿼리 힌트

JPA 쿼리 힌트는 SQL 힌트가 아닌 JPA 구현체( 하이버네이트 )에게 제공하는 힌트를 의미합니다. 힌트가 무엇인지는 예제를 통해 살펴보겠습니다.

[ Repository ]

public interface MemberRepository extends JpaRepository<Member, Long> {
    @QueryHints(value = @QueryHint(name = "org.hibernate.readOnly", value = "true"))
    Member findReadOnlyByUsername(String username);
}

하이버네이트는 readOnly 라는 기능을 제공하는데 이를 true 로 설정했을 때 테스트와 쿼리 실행 로그를 살펴보겠습니다.

[ 테스트 코드 ]

@Test
public void queryHint() throws Exception {
    memberRepository.save(new Member("member1", 10));
    em.flush();
    em.clear();

    Member member = memberRepository.findReadOnlyByUsername("member1");
    member.setUsername("member2");
    em.flush(); // Update Query 실행 X
}

select m1_0.member_id,m1_0.age,m1_0.team_id,m1_0.username 
from member m1_0 
where m1_0.username='member1';

Member 를 저장하고, 영속성 컨텍스트를 초기화시킨 후에 조회합니다. 그 후 Member 를 변경하는데 수행되는 쿼리를 보면 select 쿼리만 수행되고, update 쿼리를 수행되지 않는 것을 볼 수 있습니다.

findById() 를 사용해서 조회한 후에 변경을 하면 당연히 update 쿼리가 수행됩니다. 이때 변경감지가 일어나는데 변경 감지 기능을 수행하기 위해서는 결국 비교할 대상이 되는 객체도 가지고 있어야 합니다. 내부적으로 최적화가 되어 있어도 결국 사용하는 객체와 기준이 되는 객체 2가지를 관리해야 하기 때문에 결국 메모리를 사용하게 됩니다.

하지만 위처럼 readOnly 를 설정한 메서드로 가지고 오게 되면 변경 감지를 하지 않기 때문에 변경 감지에 사용하는 스냅샷을 만들지 않게 되고, 성능 최적화가 이루어지게 되는 것입니다.

7-2. Lock

public interface MemberRepository extends JpaRepository<Member, Long> {
    @Lock(LockModeType.PESSIMISTIC_WRITE)
    List<Member> findLockByUsername(String name);
}

JPA 가 Lock 을 지원하고, Spring Data JPA 에서 편리하게 사용할 수 있도록 어노테이션을 지원합니다.

select m1_0.member_id, m1_0.age, m1_0.team_id, m1_0.username 
from member m1_0 
where m1_0.username=? for update

쿼리 로그를 보면 자동으로 뒤에 for update 라는 키워드가 붙은 것을 확인할 수 있습니다. select 를 하는 중에 다른 사람들이 손댈 수 없도록 lock 을 걸어놓은 것입니다. 방언에 따라서 동작 방식은 달라지게 됩니다.

김영한 님의 실전! 스프링 데이터 JPA 강의를 보고 작성한 내용입니다.

1. 공통 인터페이스

1-1. 인터페이스

public interface MemberRepository extends JpaRepository<Member, Long> { }

Spring Data JPA 를 사용할 때는 위처럼 JpaRepository 인터페이스를 상속받는 인터페이스를 만들어 사용합니다. 이 인터페이스를 사용하면 이전에 JPA 를 이용한 구현체가 하던 작업들을 수행할 수 있습니다.

인터페이스만 만들고, 구현체는 만들지 않았는데 테스트 코드에서 MemberRepository 를 주입 받고, 출력해보면 아래처럼 결과가 나오게 됩니다.

memberRepository = class jdk.proxy3.$Proxy122

구현체를 만들지 않았는데 프록시 객체가 출력됩니다. 이것은 Spring Data JPA 가 인터페이스를 보고 구현 클래스를 만들어서 넣어준 것입니다.

이를 그림으로 보면 위와 같은데 애플리케이션 로딩 시점에 Spring Data JPA 관련 인터페이스를 가지고 있으면 구현 클래스를 만들게 됩니다.

@Repository 은 컴포넌트 스캔의 대상이 되도록 하고, JPA 예외를 스프링 예외로 변환해주는데 Spring Data JPA 가 컴포넌트 스캔까지 자동으로 처리해주기 때문에 @Repository 를 생략할 수 있고, 예외 변환도 자동으로 처리해줍니다.

1-2. 인터페이스 분석

package org.springframework.data.jpa.repository;

@NoRepositoryBean
public interface JpaRepository<T, ID> extends ListCrudRepository<T, ID>, 
                                            ListPagingAndSortingRepository<T, ID>, 
                                            QueryByExampleExecutor<T> {
    ...
}

Repositroy 인터페이스를 생성할 때 상속 받는 JpaRepository 를 살펴보면 위와 같습니다. T 는 엔티티 타입을 의미하고, ID 는 식별자 타입을 의미합니다.

패키지를 보면 springframework.data.jpa 인 것을 볼 수 있는데 Spring data 프로젝트는 기본적으로 공통의 CRUD 를 제공하는데 그 중에서 JPA 특화된 기능들이 있는 곳이 JpaRepository 입니다.

JpaRepository 가 상속 받는 ListPagingAndSortingRepository 를 보면 springframework.data.repository 패키지에 속해있는 것을 확인할 수 있는데 paging 과 sorting 은 어떤 RDB 에서도 제공하는 기본 기능이기 때문에 공통 인터페이스가 제공됩니다.

또 ListCrudRepository 를 들어가보면 CrudRepository 를 상속 받는 것을 확인할 수 있는데 바로 여기에 save(), findById(), count() 와 같은 기본 CRUD 메서드들이 존재합니다.

delete(), findById() 같은 메서드들은 내부에서 EntityManager.remove(), EntityManger.find() 와 같은 메서드들을 호출해서 삭제, 조회 기능을 제공해줍니다.

김영한 님의 자바 ORM 표준 JPA 프로그래밍 - 기본편 강의를 보고 작성한 내용입니다.

1. 경로 표현식

1-1. 상태필드, 연관필드

select m.username   -- 상태 필드
from Member m
join m.team t       -- 단일 값 연관 필드
join m.orders o     -- 컬렉션 값 연관 필드

경로 표현식이란 . 으로 객체 그래프를 탐색하는 것을 의미하고, 어떤 필드로 가느냐에 따라서 내부의 동작이 달라지게 됩니다.

상태 필드란 단순히 값을 저장하기 위한 필드를 의미합니다. 상태 필드는 이후에 . 을 통해 탐색할 수 있는 것이 없기 때문에 경로 탐색의 끝이며, 이후 탐색이 발생하지 않습니다.

연관 필드란 연관관계를 위한 필드를 의미하는데 단일 값 연관 필드, 컬렉션 값 연관 필드로 나뉩니다.

1-2. 단일 값 연관 필드

select m.team.name
from Member m

단일 값 연관 필드는 @xToOne 처럼 대상이 엔티티인 것을 의미합니다. 그래서 select 절에 m.team.name 과 같이 m.team 이후에 . 을 통해 탐색을 더 할 수 있습니다. 이러한 경우 묵시적 내부 조인이 발생합니다. ( 내부 조인만 가능 )

String jpql = "select m.team from Member m";
List<Team> resultList = em.createQuery(jpql, Team.class).getResultList();

select
    t1_0.id,
    t1_0.name 
from
    Member m1_0 
join 
    Team t1_0 
        on t1_0.id=m1_0.TEAM_ID

JPQL 에서 m.team 을 통해 Team 을 가져오려 했는데, 실행되는 로그를 보면 Member 와 Team 을 join 을 하고, 프로젝션에 team 의 필드들을 나열합니다.

객체 입장에서는 . 을 통해 갈 수 있지만, DB 에서는 이처럼 사용하려면 조인이 필요하기 때문에 조인이 발생하고, 이러한 것을 묵시적 내부 조인이라고 합니다.

묵시적 조인이 되면 어디서 조인이 발생했는지 모르기 때문에 join 키워드를 직접 사용하는 명시적 조인을 사용하는 것이 좋습니다.

1-3. 컬렉션 값 연관 필드

String jpql = "select t.members from Team t";
List<Collection> result = em.createQuery(jpql, Collection.class).getResultList();

컬렉션 값 연관 필드는 @xToMany 처럼 대상이 컬렉션인 것을 의미합니다. 단일 값 연관 필드처럼 묵시적 내부 조인이 발생하지만, 이후 탐색은 불가능합니다.

@OneToMany 와 같은 것은 컬렉션이여서 데이터가 여러 개 존재합니다. 그렇게 때문에 어떤 데이터의 어떤 필드를 가져올지 선택할 수 없기 때문에 이후 탐색은 불가능합니다.

String jpql = "select m.username from Team t join t.members m";

위처럼 명시적 조인을 통해 별칭을 얻으면 이후 탐색이 가능합니다.

2. 엔티티 패치 조인

패치조인이란 SQL 의 조인이 아닌 JPQL 에서 성능 최적화를 위해 제공하는 기능으로 연관된 엔티티나 컬렉션을 SQL 한 번에 함께 조회하는 기능이며 join fetch 명령어를 사용합니다.

엔티티 패치 조인은 @ManyToOne 으로 이루어진 연관관계를 조인하는 것입니다.

2-1. 일반 조인

List<Member> members = em.createQuery(
                        "select m from Member m join m.team", Member.class)
                        .getResultList();

for (Member findMember : members) {
    System.out.println("---------------findMember.getUsername() = " 
                        + findMember.getUsername());
    System.out.println("---------------findMember.getTeam().getName() = " 
                        + findMember.getTeam().getName());
}

select
    m1_0.id,
    m1_0.age,
    m1_0.TEAM_ID,
    m1_0.username 
from Member m1_0 
join Team t1_0 
    on t1_0.id=m1_0.TEAM_ID
---------------findMember.getUsername() = memberA
select
    t1_0.id,
    t1_0.name 
from Team t1_0 
where
    t1_0.id=?
---------------findMember.getTeam().getName() = teamA

join 키워드만 사용했을 때는 Team 과 조인하지만 Member 에 관한 컬럼들만 가져옵니다. 그래서 Team 의 이름을 출력할 때 지연로딩에 의해 다시 Team 에 대한 쿼리가 실행됩니다.

만약 Memebr 의 Team 이 전부 다른 데이터라면 Team 을 조회하는 쿼리가 계속 실행되고, N + 1 문제가 발생합니다.

쉽게 말해서 일반 조인 실행 시, 지연 로딩에 의해 연관된 엔티티를 함께 조회하지 않습니다.

2-2. 패치 조인

List<Member> members = em.createQuery(
                        "select m from Member m join fetch m.team", Member.class)
                        .getResultList();
for (Member findMember : members) {
    System.out.println("---------------findMember.getUsername() = " 
                        + findMember.getUsername());
    System.out.println("---------------findMember.getTeam().getName() = " 
                        + findMember.getTeam().getName());
}                        

select
    m1_0.id,
    m1_0.age,
    t1_0.id,
    t1_0.name,
    m1_0.username 
from Member m1_0 
join Team t1_0 
    on t1_0.id=m1_0.TEAM_ID
---------------findMember.getUsername() = memberA
---------------findMember.getTeam().getName() = teamA

패치조인은 Member 와 Team 의 컬럼들을 모두 가져오게 됩니다. 그래서 Team 의 이름을 출력할 때 다시 쿼리가 나가지 않고 바로 출력됩니다. 즉, 패치조인으로 Member 와 Team 을 함께 조회해서 지연 로딩이 이루어지지 않았습니다.

해당 로그는 즉시로딩으로 가져오는 것과 비슷하게 출력되는데 즉시로딩은 연관된 모든 것을 여러 번의 쿼리로 가져옵니다.

하지만 패치조인은 원하는 것만을 한 번의 쿼리로 가져오도록 설정할 수 있습니다. 그래서 일반조인과 달리 N + 1 문제가 발생하지 않습니다.

지연로딩보다 패치조인이 우선이기 때문에 패치조인이 이루어지고, 이 시점에 지연로딩과는 다르게 Team 은 프록시가 아닌 실제 엔티티입니다.

2-3. 참고> 즉시로딩

-- MEMBER
select
    m1_0.id,
    m1_0.age,
    m1_0.TEAM_ID,
    m1_0.username 
from Member m1_0 
join Team t1_0 
    on t1_0.id=m1_0.TEAM_ID
-- TEAM    
select
    t1_0.id,
    t1_0.name 
from Team t1_0 
where t1_0.id=?
---------------findMember.getUsername() = memberA
---------------findMember.getTeam().getName() = teamA

연관된 엔티티를 모두 가져온 다음에 실행됩니다. 이때 조인은 join 키워드만 사용합니다.

3. 컬렉션 패치 조인

컬렉션 패치조인은 @OneToMany 의 관계를 패치조인 하는 것을 말합니다. 현재 데이터는 member1 과 member2 가 teamA 에 속해있는 상태입니다.

List<Team> teams = em.createQuery(
                    "select t from Team t join fetch t.members tm", Team.class)
                    .getResultList();

for (Team team : teams) {
    System.out.println("-----------------------team.getName() = " + 
                        team.getName());
    System.out.println("-----------------------team.getMembers().size() = " + 
                        team.getMembers().size());
}                    

select
    t1_0.id,
    m1_0.Team_id,
    m1_1.id,
    m1_1.age,
    m1_1.TEAM_ID,
    m1_1.username,
    t1_0.name 
from Team t1_0 
join Team_Member m1_0 
    on t1_0.id=m1_0.Team_id 
join Member m1_1 
    on m1_1.id=m1_0.members_id 
where t1_0.name='teamA'
-----------------------team.getName() = teamA
-----------------------team.getMembers().size() = 2

일대다 조인의 경우, 데이터가 늘어나서 teamA 가 두 번 출력되어야 하는데 한 번만 출력됩니다. 이것은 Hibernate 6 부터 distinct 를 자동으로 해주기 때문입니다.

JPQL 의 distinct 는 SQL 에 distinct 를 추가함과 동시에 애플리케이션에서 같은 식별자를 가진 엔티티의 중복을 제거합니다.

SQL 의 distinct 는 완전히 데이터가 동일해야 제거되는데 Member 의 PK 가 다르기 때문에 SQL 의 distinct 로는 제거가 안되고, 애플리케이션의 중복 제거를 통해 제거됩니다.

4. 패치조인 정리

4-1. 일반조인 vs 패치조인

JPQL 은 결과를 반환할 때 연관관계 고려하지 않고 SELECT 절에 지정한 엔티티만 조회합니다. 그래서 일반조인은 실행 시 연관된 엔티티를 함께 조회하지 않게 됩니다.

패치조인을 사용할 때만 연관된 엔티티도 함께 조회하게 됩니다. 즉, 패치조인은 객체 그래프를 SQL 한 번에 조회하는 개념입니다.

4-2. 패치조인 한계

1. 패치조인 대상에는 별칭을 줄 수 없습니다. ( 하이버네이트는 가능, 권장 X )

왜냐하면 패치조인은 연관된 모든 것들을 가지고 오는 것입니다. 중간에 가져오고 싶지 않은 것들을 위해 사용한다면 차라리 따로 조회를 하는 것이 더 좋습니다. from 절에 있는 엔티티에 대해 조건을 거는 것은 가능합니다.

2. 둘 이상의 컬렉션은 패치조인할 수 없습니다.

만약 Team 에 List 로 members 와 orders 가 있다고 했을 때 둘 중 하나만 패치조인을 할 수 있습니다.

3. 컬렉션을 패치조인하면 페이징을 사용할 수 없습니다.

@xToOne 과 같은 연관관계는 패치조인해도 페이징이 가능합니다. 다대일과 같은 관계는 조인을 해도 데이터가 늘어나지 않기 때문입니다.

하지만 @xToMany 와 같은 관계의 컬렉션 패치조인은 페이징이 불가능합니다. 이를 해결할 수 있는 방법이 있는데 API 2편 게시글에 설명되어 있습니다.

4-3. 패치조인 특징

1. 연관된 엔티티들을 SQL 한 번으로 조회하기 때문에 성능 최적화에 좋습니다.

2. 엔티티에 직접 적용하는 지연 로딩과 같은 글로벌 로딩 전략보다 우선 시 됩니다.

3. 모든 것을 패치조인으로 해결할 수는 없고 패치조인은 객체 그래프를 유지해서 .을 통해 찾아가는 것이 필요할 때 사용하면 효과적입니다.

4. 여러 테이블을 조인해서 엔티티가 가진 모양이 아닌 전혀 다른 결과를 내야 하면, 패치조인 보다는 일반 조인을 사용하고 필요한 데이터들만 조회해서 DTO 로 반환하는 것이 효과적입니다.

5. NamedQuery

Named Query 는 미리 정의해서 이름을 부여해두고 사용하는 JPQL 로, 정적 쿼리만 가능합니다.

어노테이션이나 XML 에 정의해서 사용할 수 있는데 애플리케이션 로딩 시점에 JPA 나 Hibernate 가 쿼리를 SQL 로 파싱하고 캐싱합니다.

JPQL 은 SQL 로 파싱돼서 실행되어야 하는데 미리 파싱하고 캐싱을 하기 때문에 실행할 때마다 파싱하는 코스트를 줄일 수 있습니다.

또 JPQL 을 문자로 작성하면 쿼리가 실행되는 런타임에 오류가 발생할 수 있는데 Named Query 를 사용하면 애플리케이션 로딩 시점에 쿼리를 검증할 수 있습니다.

[ 사용 예시 ]

@Entity
@NamedQuery(name = "Member.findByUsername",
            query="select m from Member m where m.username = :username")
public class Member {
    ...
}
// ----------------------------------------------------------------------
List<Member> result = 
em.createNamedQuery("Member.findByUsername", Member.class)
    .setParameter("username", "회원1")
    .getResultList();

@NamedQuery 어노테이션을 통해 쿼리를 생성하면서 이름을 부여하고, 사용할 때도 이름으로 쿼리를 사용할 수 있습니다. 이름을 작성할 때 관례로 엔티티명.쿼리명 으로 많이 사용합니다.

6. 벌크 연산

영속성 컨텍스트에 의해 엔티티가 변경되면 자동으로 update 쿼리가 나간다고 했습니다. 하지만 이런 변경 감지 기능으로는 대량의 데이터를 수정하기도 어렵고 많은 SQL 이 실행되어야 합니다. 이때 사용할 수 있는게 벌크 연산입니다.

executeUpdate() 로 UPDATE, DELETE 를 수행할 수 있으며, 쿼리 한 번으로 여러 엔티티를 변경할 수 있습니다. 실행 결과로 영향 받은 엔티티 수가 반환됩니다.

참고로 하이버네이트는 INSERT INTO ... SELECT 문도 지원합니다.

[ 사용 예시 ]

String qlString = "update Product p " + 
                  "set p.price = p.price * 1.1 " +  
                  "where p.stockAmount < :stockAmount";  

int resultCount = em.createQuery(qlString) 
                    .setParameter("stockAmount", 10)  
                    .executeUpdate();  

[ 주의점 ]

commit 을 하거나, query 가 나가거나, 강제로 flush 를 호출하면 FLUSH 되는데 벌크 연산은 영속성 컨텍스트를 무시하고 DB 에 직접 쿼리가 날라가게 됩니다.

셋 중에 벌크 연산은 Query 를 날리는거에 해당하므로 FLUSH 후에 벌크 연산이 실행되기 때문에 영속성 컨텍스트에 있는 엔티티들은 걱정하지 않아도 됩니다.

Member member = new Member();
member.setAge(10);
em.persist(member);

String qlString = "update Product p " + 
                  "set p.price = p.price * 1.1 " +  
                  "where p.stockAmount < :stockAmount";  
// FLUSH -> DB 에 반영                  
int resultCount = em.createQuery(qlString) 
                    .setParameter("stockAmount", 10)  
                    .executeUpdate();  

Member findMember = em.find(Member.class, member.getId());
System.out.println("member age = " + findMember.getAge());   // 10

하지만 위의 경우 문제가 생기는데 executeUpdate() 로 인해 DB 에서 Member 의 나이는 20살이지만, 위의 출력 결과는 10 이 됩니다.

왜냐하면 FLUSH 를 한다고 영속성 컨텍스트가 지워지는 것이 아닌 em.clear() 를 해야 지워지기 때문입니다. 그래서 영속성 컨텍스트에 존재하는 10 이 출력되는 것입니다.

이로 인한 문제를 방지하기 위해 벌크 연산을 먼저 수행하거나, 벌크 연산 수행 후에 em.clear() 를 통해 영속성 컨텍스트를 초기화해야 합니다.

김영한 님의 자바 ORM 표준 JPA 프로그래밍 - 기본편 강의를 보고 작성한 내용입니다.

1. JPA 가 지원하는 쿼리

1-1. JPQL

JPA 를 사용하면 엔티티 객체를 중심으로 개발을 하기 때문에, 검색할 때 테이블이 아닌 엔티티 객체를 대상으로 검색해야 합니다.

그래서 JPA 는 SQL 을 추상화한 JPQL 이라는 객체 지향 쿼리 언어를 지원하는데 SQL을 추상화했기 때문에 특정 데이터베이스 SQL 에 의존하지 않습니다.

또 JPQL 을 작성하면 SQL 로 번역되어 실행되는데 ANSI 표준 SQL 이 지원하는 모든 문법을 지원하며 엔티티 객체를 대상으로 쿼리합니다. ( SQL 은 테이블 대상 )

1-2. JPA Criteria

JPQL 은 문자로 작성해야 하기 때문에 동적 쿼리를 작성하기 어렵고, 쿼리가 실행되는 런타임에 오류가 발생할 수도 있습니다.

Criteria 는 쿼리를 코드로 작성할 수 있어 컴파일 시점에 오류를 파악할 수 있고, JPQL 보다 동적쿼리를 작성하기 편리합니다. 하지만 코드가 복잡하고 가독성이 좋지 않습니다.

1-3. QueryDSL

Criteria 와 동일하게 JPQL 빌더 역할을 하며, 코드로 작성할 수 있어 컴파일 시점에 오류를 파악할 수 있습니다. 무엇보다 단순하고 쉬우며 동적 쿼리 작성도 편리합니다.

1-4. 네이티브 SQL

JPA 에서 SQL 을 직접 사용하는 기능인데 createNativeQuery() 를 사용하며, JPQL 로 해결할 수 없는 특정 데이터베이스에 의존적인 기능이 필요할 때 사용합니다.

1-5. JDBC API 직접 사용

JPA 를 사용하면서 JDBC API 를 직접 사용하거나, Spring JdbcTemplate, MyBatis 를 함께 사용할 수 있습니다.

이때 SQL 을 실행하기 직전에 영속성 컨텍스트를 수동으로 플러시하는 것처럼 영속성 컨텍스트를 적절한 시점에 강제로 플러시 하는게 필요합니다.

2. JPQL 기본 문법

2-1. JPQL 형태

select m from Member m where m.age > 20
select COUNT(m), SUM(m.age), MAX(m.age) from Member m

JPQL 에서 select, from 과 같은 키워드는 대소문자를 구분하지 않지만 엔티티를 표현할 때는 대문자를 사용하고, 속성을 표현할 때는 소문자를 사용합니다.

select 절에 위와 같은 집계 함수 사용이 가능합니다.

from 절에는 엔티티 이름을 사용하며, 별칭은 필수이나 as 는 생략할 수 있습니다. 엔티티 이름이란 클래스명이 아닌 @Entity 에 지정된 이름이며, 기본은 클래스명과 동일합니다.

2-2. TypedQuery, Query

createQuery() 를 사용했을 때 반환되는 타입은 TypedQuery 와 Query 가 있습니다.

[ TypedQuery ]

TypedQuery<Member> query = em.createQuery("select m from Member m", Member.class);
TypedQuery<String> str = em.createQuery("select m.name from Member m", String.class);

createQuery() 의 두 번째 파라미터로 응답 클래스에 대한 타입 정보를 넘겨줄 수 있는데 이때 반환되는 것이 TypedQuery 이며 반환 타입이 명확할 때 사용됩니다.

첫 번째 예시는 Member 엔티티를 반환하기 때문에 Member 를 가지고, 두 번째 m.name 은 String 이기 때문에 String 타입을 주었고 제네릭에 String 이 있는 것을 확인할 수 있습니다.

[ Query ]

Query query = em.createQuery("select m from Member m");
Query query2 = em.createQuery("select m.name, m.age from Member m");

반대로 Query 는 두 번째 파라미터로 엔티티 정보를 넘겨주지 않았을 때, 반환 타입이 명확하지 않을 때 사용됩니다.

두 번째 예시를 보면 m.name 과 m.age 를 사용했는데 name 은 String 이고, age 는 int 입니다. 두 개의 타입이 다르기 때문에 타입 정보를 넘겨줄 수 없고, 이때 Query 가 반환됩니다.

2-3. 결과 조회 API

TypedQuery<Member> query = em.createQuery("select m from Member m",Member.class);
List<Member> members = query.getResultList();
Member resultMember = query.getSingleResult();

getResultList() 는 결과가 하나 이상일 때 사용하며, 리스트를 반환합니다. 결과가 없으면 빈 리스트가 반환됩니다.

getSingleResult() 는 결과가 정확히 하나일 때 사용하며, 단일 객체를 반환합니다. 만약 결과가 없거나 둘 이상이면 예외가 발생합니다.

2-4. 파라미터 바인딩

em.createQuery("select m from Member m where m.name = :username" ,Member.class)
                .setParameter("username", "kim");

em.createQuery("select m from Member m where m.username = ?1", Member.class)
                .setParameter(1, "kim");

파라미터 바인딩하는 첫 번째 방법은 이름을 기준으로 하는 방법입니다. 파라미터 이름 앞에 : 를 붙여서 나타내며 setParameter() 를 통해 지정할 수 있습니다.

두 번째 방법은 위치를 기준으로 하는 방법인데 ?위치 로 JPQL 을 작성하면 되는데 이 방법은 추천하지 않습니다.

2-5. 프로젝션

프로젝션이란 select 절에 조회할 대상을 지정하는 것인데 엔티티, 연관관계 엔티티, 임베디드 타입 숫자와 문자 같은 스칼라 타입을 지정할 수 있습니다.

[ 엔티티 프로젝션 ]

em.createQuery("select m from Member m", Member.class);
em.createQuery("select m.team from Member m", Team.class);
em.createQuery("select t from Member m join m.team t", Team.class);

엔티티 프로젝션의 경우, 조회되는 데이터 모두 영속성 컨텍스트에서 관리됩니다.

m.team 을 조회하는 경우, createQuery() 의 두 번째 파라미터로 Team.class 를 넘겨주어야 합니다. 그렇게 되면 Member 와 Team 이 조인되는 쿼리가 실행됩니다.

참고로 두 번째 예시와 세 번째 예시는 동일한 SQL 이 실행되는데, 두 번쨰의 경우 JOIN 예측이 안되기 때문에 세 번째처럼 사용하는 것이 좋습니다.

[ 임베디드, 스칼라 ]

em.createQuery("select o.address from Order o", Address.class); // 임베디드
em.createQuery("select a from Address a", Address.class); // 불가능한 예시
em.createQuery("select m.name from Member m", Member.class);  // 스칼라

Order 내부에 임베디드 타입을 조회하려면 응답 타입을 임베디드 타입으로 지정해야 합니다. 임베디드 타입은 하나의 테이블에 컬럼이 있는 형태이기 때문에 문제가 없습니다.

임베디드 타입은 특정 테이블에 소속되어 있기 때문에 두 번째 예시처럼 사용할 수 없습니다.

2-6. 여러 타입 조회

여러 개의 타입을 조회해야 하는 경우가 있는데 이때 3가지 방법이 존재합니다.

[ Query ]

List resultList = em.createQuery("select m.username, m.age from Member m")
                    .getResultList();
Object obj = resultList.get(0);
Object[] result = (Object[]) obj;
System.out.println("username = " + result[0]);
System.out.println("age = " + result[1]);

첫 번째는 Query 를 사용하는 방법입니다. 위의 List 안에는 Object 가 들어 있습니다. 조회 결과로 반환되는 것은 두 개이기 때문에 이를 Object[] 로 캐스팅하고, 배열 내부에서 조회 결과를 가져올 수 있습니다.

[ Object[] ]

List<Object[]> resultList = em.createQuery(
                    "select m.username, m.age from Member m")
                    .getResultList();
Object[] result = resultList.get(0);
System.out.println("username = " + objects[0]);
System.out.println("age = " + objects[1]);

두 번째는 Object[] 를 사용하는 방법입니다. 반환되는 List 의 제네릭을 Object[] 로 지정하면 캐스팅 작업 없이 바로 Object[] 를 받을 수 있습니다.

[ new ]

List<MemberDTO> dto = em.createQuery(
                        "SELECT new jpabook.jpql.MemberDTO(m.username, m.age) " +
                        "FROM Member m", MemberDTO.class)
                    .getResultList();

엔티티가 아닌 다른 타입으로 조회를 하는 경우 반드시 new 키워드를 사용해서 생성해야 합니다. 생성할 때는 패키지명을 포함한 전체 클래스명을 입력해야 하며, 순서와 타입이 일치하는 생성자가 필수로 필요합니다.

2-7. 페이징

em.createQuery("select m from Member m order by m.age desc", Member.class)
   .setFirstResult(10)
   .setMaxResults(20)
   .getResultRest();

setFirstResult() 로 조회 시작 위치를 지정할 수 있으며, 0 부터 시작합니다.

setMaxResults() 로 조회할 데이터의 수를 지정할 수 있습니다.

위의 함수를 작성하면 JPA 가 각 데이터베이스 방언에 맞게 쿼리를 작성해서 실행하게 됩니다.

3. 조인

JPQL 은 엔티티를 중심으로 동작하기 때문에 객체 스타일로 조인 문법을 작성해야 합니다.

3-1. 내부조인, 외부조인

// 내부조인
String jpql = "select m from Member m inner join m.team t";
em.createQuery(jpql, Member.class);
// 외부조인
String jpql = "select m from Member m left outer join m.team t";
em.createQuery(jpql, Member.class);

inner 와 outer 는 생략할 수 있습니다.

3-2. 세타조인

세타조인은 전혀 연관관계가 없는 엔티티를 조인하는 것입니다. 아래 예시들은 Member 가 4명, Team 이 2개가 저장되어 있고, 둘의 연관관계는 없는 상태입니다.

[ 조건 X ]

String jpql = "select m, t from Member m, Team t";
List resultList = em.createQuery(jpql).getResultList();
System.out.println("resultList.size() = " + resultList.size());   // 결과 : 8

위의 예시에서는 조인 조건이 없으므로 카테시안 곱으로 인한 모든 데이터가 함께 나오게 되기 때문에 8이 출력됩니다.

[ 조건 O ]

String jpql = "select m, t from Member m, Team t where m.username = t.name";
List resultList = em.createQuery(jpql).getResultList();
System.out.println("resultList.size() = " + resultList.size());   // 결과 : 2

만약 여기서 조건을 추가해서 실행하면 2가 출력됩니다. 왜냐하면 세타조인은 내부조인만 가능하기 때문입니다. 전체 8개 중에 Member 와 Team 이 동일한 것은 최대 Team 의 데이터 수만큼 가능하기 때문에 결과가 2가 나오게 됩니다.

3-3. ON 절

[ 조인 대상 필터링 ]

String jpql = "select m, t from Member m left join m.team t on t.name = 'A'";

JPA 는 조인할 때 조인 대상을 필터링 할 수 있는 ON 절을 지원합니다. 위의 예시는 회원과 팀을 조인할 때 팀의 이름이 A 인 팀만 조인하는 JPQL 입니다.

[ 연관관계 없는 외부조인 ]

String jpql = "select m, t from Member m left join m.team t on m.name = t.name";

위의 세타조인에서는 내부조인만 가능했는데 연관관계 없는 엔티티 외부 조인도 가능합니다.

4. JPA 지원 함수

4-1. 서브쿼리

• [NOT] EXISTS : 서브쿼리에 결과가 존재하면 참

• [NOT] IN : 서브쿼리의 결과 중 하나라도 같은 것이 있으면 참

• { ALL | ANY | SOME }

  • ALL 은 조건을 모두 만족해야 참

  • ANY 와 SOME 은 조건을 하나라도 만족하면 참

원래는 select 절, where 절, having 절에서만 서브쿼리를 사용할 수 있었는데 하이버네이트 6 부터는 FROM 절 서브쿼리도 지원합니다.

4-2. 타입

[ ENUM ]

// JPQL 에 직접 사용
String jpql = "select m from Member m where m.type = jpabook.MemberType.ADMIN";

// 파라미터 바인딩 사용
String jpql = "select m from Member m where m.type = :userType";
em.createQuery(jpql, Member.class)
    .setParameter("userType", MemberType.ADMIN);

jpql 에 ENUM 타입을 사용할 수 있는데 JPQL 자체에 작성할 때는 패키지명을 포함해서 적어주어야 합니다. 파라미터 바인딩을 사용해서 ENUM 타입을 사용할 수 있습니다.

[ 엔티티 타입 ]

String jpql = "select i from Item i where type(i) = Book";
em.createQuery(jpql, Item.class);

이전 예시에서 Item 를 상속 받는 엔티티가 Book, Album, Movie 가 있었는데 그 중에 Book 만 가지고 오고 싶을 때 위처럼 type() 을 사용할 수 있습니다.

Item 에는 자식들을 구분하기 위한 DTYPE 컬럼이 추가되는데 위의 쿼리가 실행되면 where 절에 item.DTYPE = 'BOOK' 이 추가됩니다.

4-3. 조건식 Case

[ 기본 Case 식 ]

String jpql =
        "select " +
        "case when m.age < 8 then '어린이' " +
        "     when m.age < 20 then '학생' " +
        "     else '성인' " +
        "end " +
        "from Member m";
List<String> resultList = em.createQuery(jpql, String.class).getResultList();

[ 단순 Case 식 ]

String jpql =
        "select " +
        "case t.name " +
        "     when 'teamA' then '인센티브110%' " +
        "     when 'teamB' then '인센티브120%' " +
        "     else '인센티브105%' " +
        "end " +
        "from Team t";
List<String> resultList = em.createQuery(jpql, String.class).getResultList();

[ COALESCE ]

select coalesce(m.username,'이름 없는 회원') from Member m

COALESCE 는 하나씩 조회해서 NULL 이 아니면 반환합니다. 위의 예시는 사용자 이름이 없으면 "이름 없는 회원" 을 반환합니다.

[ NULLIF ]

select NULLIF(m.username, '관리자') from Member m

NULLIF 는 두 값이 같으면 null 을 반환하고, 다르면 첫 번째 값을 반환합니다. 위의 예시는 사용자 이름이 "관리자"면 null 을 반환하고, 나머지는 본인의 이름을 반환합니다.

4-4. 기타 함수들

IN, AND, OR, NOT, BETWEEN, LIKE, IS NULL, CONCAT, SUBSTRING, TRIM, LOWER, UPPER, LENGTH, LOCATE, ABS, SQRT, MOD, SIZE, INDEX 와 같은 기본 표현과 함수들도 다 사용할 수 있습니다.

DB 내부에 존재하는 사용자 정의 함수를 사용할 때는 함수 등록이 필요한데 Hibernate 6 버전 부터는 방식이 변경되었다고 한다 ( 참고 )

김영한 님의 자바 ORM 표준 JPA 프로그래밍 - 기본편 강의를 보고 작성한 내용입니다.

1. JPA 의 데이터 타입 분류

[ 엔티티 타입 ]

@Entity 로 정의하는 객체이며, 데이터가 변해도 식별자로 지속해서 추척이 가능합니다. 예를 들어, 회원 엔티티의 이름을 변경해도 식별자로 인식이 가능합니다.

[ 값 타입 ]

int, String 처럼 단순히 값으로 사용하는 자바 기본 타입이나 객체를 의미합니다. 식별자가 없고 값만 있기 때문에 변경했을 때 추척이 불가능합니다.

값 타입은 또 다시 기본값 타입, 임베디드 타입, 컬렉션 값 타입으로 분류할 수 있으며, 모든 값 타입은 값 타입을 소유한 엔티티의 생명주기에 의존합니다.

[ 기본값 타입 ]

String 이나 자바 기본 타입인 int 나 double, 래퍼 클래스인 Integer 나 Long 등이 기본값 타입에 해당합니다.

기본값 타입은 생명주기를 엔티티에 의존합니다. 예를 들어 회원을 삭제하면 내부의 이름과 나이 필드도 함께 삭제됩니다.

또 값타입은 공유를 하면 안되는데 회원 이름을 변경한다고 해서 다른 회원의 이름이 변경되면 안됩니다.

int, double 과 같은 기본 타입은 항상 값을 복사하기 때문에 a = b 이후에 a 를 변경해도 b 는 변경되지 않습니다.

Integer 나 String 과 같은 클래스는 레퍼런스를 사용하기 때문에 공유는 가능하지만 변경은 불가능합니다.

2. 임베디드 타입

새로운 값 타입을 직접 정의해서 사용할 수 있는데, JPA 에서는 이를 임베디드 타입이라고 합니다. 임베디드 타입은 int, String 과 같은 엔티티 내부의 값 타입입니다.

위의 그림은 값 타입을 사용하기 전과 후를 나타낸 그림입니다. startData, endDate 를 Period 라는 임베디드 타입을 만들고, 이를 Member 내부에서 사용하는 방식입니다.

JPA 에서 값 타입을 정의하는 곳에 표시하는 @Embeddable 과 값 타입을 사용하는 곳에 표시하는 @Embedded 를 사용하는데 임베디드 타입 내부에 기본 생성자는 필수입니다.

임베디드 타입은 재사용이 가능하고 응집도가 높아 Period.isWork() 처럼 해당 값 타입만 사용하는 의미있는 메서드를 만들 수 있습니다.

임베디드 타입을 사용할 때 매핑만 해주면 임베디드 타입을 사용하지 않을 때와 테이블의 구조는 동일합니다.

[ @AttributeOverrides ]

한 엔티티에서 같은 값 타입을 사용하면 컬럼명이 중복되는데 @AttributeOverrids 와 @AttributeOverride 를 사용해서 컬러명 속성을 재정의 할 수 있습니다.

public class Member {
    @Embedded
    private Address homeAddress;

    @Embedded
    @AttributeOverrides({
        @AttributeOverride(name="city", column = @Column(name="WORK_CITY")),
        @AttributeOverride(name="street", column = @Column(name="WORK_STREET")),
        @AttributeOverride(name="zipcode", column = @Column(name="WORK_ZIPCODE"))
    })
    private Address workAddress;
}

[ 임베디드 타입과 연관관계 ]

임베디드 타입은 값 타입을 포함하거나, 엔티티를 참조할 수 있습니다.

@Embeddable
public class Address {
    ...
    @Embedded
    private Zipcode zipcode;    // 임베디드 타입 포함
}

@Embeddable
public class Zipcode {
    private String area;
    ...
}
// ------------------------------------------
@Embeddable
public class PhoneNumber {
    ...
    @ManyToOne
    private PhoneEntity phoneEntity;    // 엔티티 참조
}

@Entity
public class PhoneEntity {
    @Id @GeneratedValue
    private Long id;
    ...
}

[ null ]

임베디드 타입에 null 을 넣게되면 임베디드 타입에 해당하는 모든 컬럼들은 null 로 저장되게 됩니다.

public class Member {
    ...
    @Embedded
    private Address homeAddress = null;
}

3. 값 타입과 불변 객체

3-1. 값 타입

임베디드 타입 같은 값 타입을 여러 엔티티에서 공유하면 side effect 가 발생할 수 있어 위험합니다.

[ 값 타입 공유 ]

Address address = new Address("city", "street", "10000");

Member member1 = new Member();
member1.setName("member1");
member1.setAddress(address);
em.persist(member1);

Member member2 = new Member();
member2.setName("member2");
member2.setAddress(address);
em.persist(member2);

member1.getAddress().setCity("newCity");

member1 과 member2 가 같은 address 를 공유하는 상황에서 member1 을 통해 address 를 변경하면 insert 이후에 member1 과 memebr2 모두에게 update 쿼리가 날라가게 됩니다. 그래서 결국 member1 의 주소를 변경했지만 member2 의 주소도 newCity 로 변경됩니다.

[ 값 타입 복사 ]

Address address = new Address("city", "street", "10000");

Member member1 = new Member();
member1.setName("member1");
member1.setAddress(address);
em.persist(member1);

Address copyAddress = new Address(address.getCity(), address.getStreet(), address.getZipcode());

Member member2 = new Member();
member2.setName("member2");
member2.setAddress(copyAddress);
em.persist(member2);

member1.getAddress().setCity("newCity");

값 타입 자체를 공유하는 것이 아닌 값을 복사해서 위처럼 사용하는 것이 올바른 방법입니다.

3-2. 불변객체

자바 기본 타입은 값을 대입하면 값을 복사합니다. 하지만 임베디드 타입처럼 직접 정의한 값 타입은 자바 기본 타입이 아닌 객체 타입이고, 객체 타입은 참조 값을 복사해서 넣게 됩니다.

객체 타입을 수정할 수 없게 만들면 함께 수정되는 부작용을 원천 차단시킬 수 있습니다. 그래서 값 타입은 불변 객체로 설계해야 합니다.

불변 객체란 생성 시점 이후 절대 값을 변경할 수 없는 객체입니다. 생성자로만 값을 생성하고 setter 를 만들지 않으면 됩니다. ( Integer, String 이 대표적인 불변객체입니다. ) 만약 값을 수정하고 싶다면 new 키워드를 통해 새로운 객체를 만들어 사용해야 합니다.

3-3. 값 타입 비교

예를 들어, int 형 a 와 b 가 동일한 값을 가졌다면 == 비교를 했을 때 동일하다고 판단됩니다. 하지만 Address 의 경우 동일한 값을 가져도 == 비교를 했을 때 false 가 나오게 됩니다.

== 비교는 인스턴스의 참조 값을 비교하는 동일성 비교이기 때문에 인스턴스의 값을 비교하는 equals() 를 이용한 동등성 비교를 해야합니다.

즉, 값 타입은 a.equals(b)를 사용해서 동등성 비교를 해야하며, equals() 는 기본이 == 비교이기 때문에 값 타입의 equals() 메소드를 모든 필드를 사용하도록 재정의하는 것이 필요합니다.

@Override
public boolean equals(Object o) {
    if (this == o) return true;
    if (o == null || getClass() != o.getClass()) return false;
    Address address = (Address) o;
    return Objects.equals(city, address.city) 
            && Objects.equals(street, address.street) 
            && Objects.equals(zipcode, address.zipcode);
}

@Override
public int hashCode() {
    return Objects.hash(city, street, zipcode);
}

equals() 와 hashCode() 눈 기본적으로 생성해주는 것을 사용하는 것이 좋습니다.

4. 값 타입 컬렉션

4-1. 개념

값 타입 컬렉션이란 값 타입을 컬렉션에 담아서 사용하는 것을 말하는데 값 타입을 하나 이상 저장할 때 사용하며, @ElementCollection, @CollectionTable 을 사용합니다.

값 타입이 하나만 있을 때는 엔티티의 필드로 넣으면 구현할 수 있었는데, 컬렉션을 사용하면 일대다 개념이기 때문에 RDB 에서 테이블 안에 컬렉션을 담을 수 없습니다.

그래서 값 타입 컬렉션에 대해서 별도의 테이블을 사용해야 합니다. 값 타입 테이블에 id 같은 개념을 넣어서 PK 로 쓰면 엔티티가 되어 버리기 때문에 값들을 묶어서 PK 로 사용해야 합니다.

public class Member {
    ...
    @Embedded
    private Address homeAddress;

    @ElementCollection
    @CollectionTable(name = "ADDRESS", joinColumns = @JoinColumn(name = "MEMBER_ID"))
    private List<Address> addressHistory = new ArrayList<>();
}

@CollectionTable 은 생성될 테이블명을 지정합니다. 또 외래키를 지정할 수 있는데 위에서는 MEMBER_ID 를 외래키로 지정하였습니다.

4-2. 사용 예시

[ 저장 ]

Member member = new Member();
member.setName("member1");
member.setHomeAddress(new Address("city", "street", "10000"));

member.getAddressHistory().add(new Address("old1", "street", "10000"));
member.getAddressHistory().add(new Address("old2", "street", "10000"));

em.persist(member);

4-1 에서 지정한 것처럼 ADDRESS 라는 이름으로 테이블이 하나 생성되었고, 값 타입 컬렉션에 담긴 정보들은 ADDRESS 테이블에 저장된 것을 확인할 수 있습니다.

또 member 만 persist() 했는데 값 타입 컬렉션은 자동으로 저장되었습니다. 왜냐하면 값 타입 컬렉션도 스스로 라이프 사이클을 가지지 않기 때문에 라이프 사이클이 member 에 소속되어 다른 테이블임에도 함께 저장된 것입니다.

[ 조회 ]

Member findMember = em.find(Member.class, member.getId());
System.out.println("----------------------------findMember 반환");
for (Address ad : findMember.getAddressHistory()) {
    System.out.println("history = " + ad.getCity() + ", " 
                                    + ad.getStreet() + ", " 
                                    + ad.getZipcode());
}

select
    m1_0.MEMBER_ID,
    m1_0.city,
    m1_0.street,
    m1_0.zipcode,
    m1_0.name 
from
    Member m1_0 
where
    m1_0.MEMBER_ID=?
----------------------------findMember 반환
select
    ah1_0.MEMBER_ID,
    ah1_0.city,
    ah1_0.street,
    ah1_0.zipcode 
from
    ADDRESS ah1_0 
where
    ah1_0.MEMBER_ID=?

member 에 소속된 homeAddress 에 해당하는 값 타입은 함께 조회되었지만, 값 타입 컬렉션은 조회되지 않았습니다. 이 말은 값 타입 컬렉션은 지연로딩이라는 뜻입니다. 그래서 findMember 이후에 값을 사용할 때 쿼리가 나가는 것을 확인할 수 있습니다.

[ 수정 ]

Member findMember = em.find(Member.class, member.getId());
List<Address> addressHistory = findMember.getAddressHistory();
addressHistory.remove(new Address("old1", "street", "10000"));
addressHistory.add(new Address("newCity1", "street", "10000"));

remove() 를 통해 제거할 때 equals() 를 사용하기 때문에 이전에 했던 것처럼 equals() 와 hashCode() 를 제대로 구현해야 합니다.

또 값 타입은 불변 객체여야 하기 때문에 수정할 때 set 을 사용할 수 없으므로 새로운 값 타입 객체를 생성해서 사용합니다.

컬렉션의 값만 변경해도 JPA 가 DB 에 쿼리를 날려줍니다. 그래서 값 타입 컬렉션은 영속성 전이와 고아 객체 제거 기능을 가진다고 볼 수 있습니다.

4-3. 값 타입 컬렉션 제약 사항

값 타입 컬렉션에 변경 사항이 발생하면 주인 엔티티와 연관된 모든 데이터를 삭제하고, 값 타입 컬렉션에 있는 현재 값을 모두 다시 저장합니다.

Hibernate: 
    delete from
        ADDRESS 
    where
        MEMBER_ID=?
Hibernate: 
    insert into
        ADDRESS (MEMBER_ID, city, street, zipcode) 
    values (?, ?, ?, ?)
Hibernate: 
    insert into
        ADDRESS (MEMBER_ID, city, street, zipcode) 
    values (?, ?, ?, ?)

위의 수정 코드의 SQL 로그인데 delete 를 보면 해당 member 에 해당하는 모든 값을 지우는 것을 확인할 수 있고, 하나의 address 만 추가했는데 두 개의 insert 문이 실행되었습니다.

기존 데이터 2개 중 하나만 지웠기 때문에 하나가 남아있게 되고, 신규 insert 와 함께 기존 insert 1번이 실행된 것입니다.

저장할 때도 주의해야 할 점이 있는데 값 타입 컬렉션을 매핑하는 테이블은 모든 컬럼을 묶어서 기본키를 구성해야 합니다. null 도 안되고, 중복 저장도 안됩니다.

@Entity
public class AddressEntity {
    @Id @GeneratedValue
    private Long id;
    private Address address;
}
// -----------------------------
@Entity
public class Member {
    ...
    // 일대다 단방향 매핑
    @OneToMany(cascade = CascadeType.ALL, orphanRemoval = true)
    @JoinColumn(name = "MEMBER_ID")
    private List<AddressEntity> addressHistory = new ArrayList<>();
}

그래서 실무에서는 상황에 따라 값 타입 컬렉션 대신 일대다 관계를 고려해서 엔티티를 만들고, 여기서 값 타입을 사용하는 것이 좋습니다. 영속성 전이와 고아 객체 제거 기능을 사용해서 값 타입 컬렉션처럼 사용하면 됩니다.

김영한 님의 자바 ORM 표준 JPA 프로그래밍 - 기본편 강의를 보고 작성한 내용입니다.

1. 프록시

1-1. 필요한 이유

현재 예제에서는 Member 와 Team 이 연관관계를 맺고 있습니다. 만약 JPA 가 Member 와 Team 을 한 번에 가져온다고 했을 때, 둘 다 비즈니스 로직에서 사용한다면 좋겠지만 실제로는 Member 만 사용할 수도 있습니다.

Member findMember = em.find(Member.class, member.getId());
System.out.println("findMember = " + findMember.getName());

select
    m1_0.MEMBER_ID,
    m1_0.city,
    m1_0.name,
    ...
from
    Member m1_0 
left join Team t1_0 
    on t1_0.id=m1_0.team_id 
where
    m1_0.MEMBER_ID=?

Member 의 이름을 조회하는 코드를 실행했을 때 나오는 쿼리입니다. Team 은 전혀 사용을 하지 않는 상황인데 조인을 통해 Team 까지 한 번에 가져오고 있습니다.

JPA 는 이러한 점을 지연로딩과 프록시라는 것으로 해결하는데 지연 로딩을 이해하기 위해서는 프록시부터 명확하게 이해해야 합니다.

1-2. 프록시

JPA 에는 em.find() 와 함께 em.getReference() 라는 참조를 가져오는 메서드가 존재합니다.

em.find() : 데이터베이스를 통해서 실제 엔티티 객체를 조회

em.getReference() : 데이터베이스 조회를 미루는 가짜( 프록시 )엔티티 객체 조회

가짜 엔티티를 조회한다는 말은 DB에 쿼리가 나가지 않는데 객체가 조회되는 것을 말합니다.

Member findMember = em.getReference(Member.class, member.getId());
System.out.println("---------------------findMember 반환됨");
System.out.println("findMember = " + findMember.getName());

---------------------findMember 반환됨
select
    m1_0.MEMBER_ID,
    m1_0.city,
    m1_0.name,
    ...
from
    Member m1_0 
left join Team t1_0 
    on t1_0.id=m1_0.team_id 
where
    m1_0.MEMBER_ID=?

위의 코드를 실행시킨 SQL 로그를 보았을 때 findMember 를 반환하는 코드에서 SELECT 쿼리가 나가지 않고 그 이후에 쿼리가 실행된 것을 확인할 수 있습니다.

즉, findMember 를 반환했는데 DB 에 쿼리가 나가지 않았다는 의미이고 getName() 으로 이름을 가져올 때 DB 에 쿼리가 나간 것입니다.

findMember.getClass() = Member$HibernateProxy$OFQX4JAg

findMember.getClass() 를 출력해보면 위처럼 출력되는데 반환된 findMember 는 Hibernate 가 강제로 만든 가짜 클래스라는 의미입니다. 그리고 이것이 프록시라는 것입니다.

1-3. 프록시와 실제 엔티티

getReference() 로 가져온 프록시 객체를 그림으로 표현하면 위와 같은데 프록시 객체는 실제 클래스를 상속 받아서 만들어져 겉모양이 실제 클래스와 동일합니다. 사용자 입장에서 진짜 객체인지 프록시 객체인지 구분하고 사용하면 됩니다.

프록시 객체는 실제 객체의 참조(target)를 보관하는데 target 이 바로 진짜 레퍼런스를 가리키며 프록시 객체를 호출하면 프록시 객체는 실제 객체의 메소드 호출합니다.

1-4. 프록시 초기화

Member member = em.getReference(Member.class, "id1"); 
member.getName();

위의 코드에서 member 는 실제 DB 에서 조회한 적이 없어 target 이 존재하지 않습니다. 그 후 getName() 호출을 하면 프록시 객체는 아래와 같은 초기화 과정을 거치게 됩니다.

1. 처음 getRefercnce() 로 가져온 Proxy 는 target 을 갖고 있지 않습니다.

2. target 이 비어있는데 getName() 을 호출하면 JPA 가 영속성 컨텍스트에 초기화를 요청합니다.

3. 영속성 컨텍스트는 DB 에서 조회를 해서 실제 Entity 객체를 생성합니다.

4. 실제 Entity 가 생성되면 프록시 객체의 target 에 실제 Entity 를 연결해줍니다.

5. target( 실제 Entity )의 getName() 을 통해 Member 의 이름이 반환됩니다.

6. 프록시가 초기화되었기( target 이 연결되었기 ) 때문에 이후에 또 getName() 을 호출해도 DB 에 쿼리가 날라가지 않습니다.

1-5. 프록시의 특징

1. 프록시 객체는 처음 사용할 때 한 번만 초기화되고, 한 번 초기화되면 초기화된 객체를 계속 사용하게 됩니다.( 실제 Entity 가 연결되었기 때문 )

2. 프록시 객체를 초기화할 때 프록시 객체가 실제 엔티티로 변하는 것은 아닙니다. 초기화되면 프록시 객체를 통해 실제 엔티티에 접근이 가능하게 되는 것입니다.

3. 프록시 객체는 원본 엔티티를 상속받는 것이기 때문에 타입 체크 시 주의해야 합니다 ( == 비교를 사용하면 실패합니다. instance of 를 사용해야 합니다. )

4. 영속성 컨텍스트에 찾는 엔티티가 이미 존재하면 getReference() 를 호출해도 실제 엔티티가 반환됩니다. ( 그 반대도 마찬가지 )

5. 영속성 컨텍스트의 도움을 받을 수 없는 준영속 상태일 때, 프록시를 초기화하면 예외가 발생합니다. ( 하이버네이트의 경우 LazyInitializationException 예외가 발생 )

[ 4번 추가 설명 ]

[ find vs getReference ]

Member m1 = em.find(Member.class, member1.getId());
System.out.println("m1 = " + m1.getClass());

Memebr m2 = em.getReference(Member.class, member1.getId());
System.out.println("m2 = " + m2.getClass());

위의 코드를 실행하면 m1 도 Proxy 가 아닌 Member 이고, m2 도 Proxy 가 아닌 Member 입니다. 이 결과가 나오는 것은 두 가지 이유가 존재합니다.

첫 번째는 이미 Member 가 영속성 컨텍스트에 있는데 굳이 프록시로 가져와도 아무 이점이 없기 때문입니다. 원본을 반환하는게 성능 최적화 입장에서도 훨씬 좋기 때문입니다.

두 번째 이유는 JPA 는 같은 영속성 컨텍스트 안에서, 같은 트랜잭션 레벨 안에서 == 비교를 하면 항상 true 로 출력되어야 하기 때문입니다.

m1 이 실제 엔티티든 프록시든 상관없이 JPA 에서는 마치 Java 컬렉션에서 가져온 것을 == 비교하듯이, 위의 m1 과 m2 가 한 영속성 컨텍스트에서 가져온 것이고 PK 가 동일하다면 JPA 는 항상 true 를 반환해야 합니다.

쉽게 말해서 == 비교를 할 때 true 로 만들어주기 위해서 영속성 컨텍스트에 있다면 프록시가 아닌 실제 엔티티를 반환하는 것입니다.

[ getReference vs getReference ]

Member m1 = em.getReference(Member.class, member1.getId());
System.out.println("m1 = " + m1.getClass());

Memebr m2 = em.getReference(Member.class, member1.getId());
System.out.println("m2 = " + m2.getClass());

위의 코드를 실행해서 출력하면 둘이 동일한 프록시가 출력됩니다. 왜냐하면 4번에 의해 == 비교를 했을 때 true 를 출력해주어야 하기 때문입니다.

[ getReference vs find ]

Member refMember = em.getReference(Member.class, member1.getId());
System.out.println("refMember = " + refMember.getClass());

Memebr findMember = em.find(Member.class, member1.getId());
System.out.println("findMember = " + findMember.getClass());

refMember 는 프록시 객체가 출력됩니다. 그 뒤에 findMember 는 find() 로 조회했기 때문에 실제 엔티티가 출력될 것이라고 생각할 수 있지만 findMember 역시 refMember 와 동일한 프록시 객체가 출력됩니다.

만약 refMember 가 프록시 객체이고 findMember 가 실제 엔티티라면 == 비교를 했을 때 false 가 출력될 것입니다. 하지만 4번에 의해 true 가 출력되어야 하고, 그래서 find() 의 결과가 프록시를 반환합니다.

[ 5번 추가 설명 ]

Member refMember = em.getReference(Member.class, member1.getId());
System.out.println("refMember = " + refMember.getClass());  // 프록시

em.close(); // or em.detach(refMember) or em.clear()

System.out.println("name = " + refMember.getName());    // 프록시 객체 초기화 ( 강제 호출 )

만약 위처럼 영속성 컨텍스트를 종료하거나 영속 상태 엔티티를 준영속 상태로 변경하고 프록시 객체를 초기화하면 어떻게 될까요?

위에서 언급한 것처럼 하이버네이트가 org.hibernate.LazyInitializationException 예외를 터트려버립니다.

왜냐하면 1-4번에서 프록시에 대한 초기화 요청은 영속성 컨텍스트를 통해 일어난다고 했는데 해당 객체를 영속성 컨텍스트에서 관리하고 있지 않기 때문입니다.

참고로 getName() 과 같은 메서드를 써서 프록시 객체를 초기화하는 것을 강제 초기화라고 하며, Hibernate.initalize(entity) 를 통해서도 강제로 초기화할 수 있습니다.

2. 지연로딩과 즉시로딩

2-1. 지연로딩

처음으로 돌아가서 Member 만 사용을 하는데 굳이 Team 까지 같이 가져오는 문제를 해결하는 것이 지연로딩이라고 했습니다. JPA 는 지연로딩 LAZY 를 사용해서 프록시로 조회합니다.

public class Member {
    ...
    @ManyToOne(fetch = FetchType.LAZY)
    private Team team;
}
//-------------------------------------
Member findMember = em.find(Member.class, member.getId());
System.out.println("---------------------------findMember 반환");
System.out.println(findMember.getTeam().getName());

Hibernate: 
    select
        m1_0.MEMBER_ID,
        m1_0.name,
    from
        Member m1_0 
    where
        m1_0.MEMBER_ID=?
---------------------------findMember 반환
Hibernate: 
    select
        t1_0.id,
        t1_0.name 
    from
        Team t1_0 
    where
        t1_0.id=?

위처럼 FetchType.LAZY 를 사용하면 Member 클래스만 DB 에서 조회하고, Team 은 프록시 객체로 조회합니다. 쿼리 로그를 보면 Member 만 조회하고 Team 에 대한 것은 아무것도 없는 것을 확인할 수 있습니다.

그 이후에 getTeam().getName() 을 하면 프록시 초기화가 이루어져야 하기 때문에 DB 에서 Team 을 조회하게 됩니다. 즉, 실제 Team 을 사용하는 시점에 DB 에 쿼리가 나가 프록시가 초기화됩니다.

2-2. 즉시로딩

만약 Member 와 Team 을 함께 사용하는 일이 많다면 즉시로딩을 사용합니다.

public class Member {
    ...
    @ManyToOne(fetch = FetchType.EAGER)
    private Team team;
}
//-------------------------------------
Member findMember = em.find(Member.class, member.getId());

Hibernate: 
    select
        m1_0.MEMBER_ID,
        m1_0.name,
    from
        Member m1_0 
    left join
        Team t1_0 
            on t1_0.id=m1_0.team_id 
    where
        m1_0.MEMBER_ID=?

쿼리 로그를 보면 Member 를 DB 에서 조회할 때 Team 을 조인해서 바로 가져오는 것을 확인할 수 있습니다. 한 번에 다 가져오기 때문에 프록시를 사용하지 않습니다.

하지만 실무에서는 즉시로딩이 아닌 지연로딩을 사용해야 합니다. 즉시로딩을 적용하면 예상하지 못한 SQL 이 발생하고, JPQL 에서 N + 1 문제를 일으키기 때문입니다.

@ManyToOne, @OneToOne은 기본이 즉시 로딩이고, @OneToMany, @ManyToMany는 기본이 지연 로딩입니다.

[ N + 1 문제 ]

List<Member> members = em.createQuery("select m from Member m", Member.class)
                        .getResultList();

Hibernate: 
    select
        m1_0.MEMBER_ID,
        m1_0.name,
    from
        Member m1_0
Hibernate: 
    select
        t1_0.id,
        t1_0.name 
    from
        Team t1_0 
    where
        t1_0.id=?

즉시로딩을 설정하고 위의 JPQL 을 실행하면 쿼리가 2번 나가게 됩니다. find() 는 PK 를 찍어서 가져오는 것이기 때문에 JPA 가 최적화할 수 있습니다.

하지만 JPQL 은 그대로 SQL 로 번역이 이루어지기 때문에 아래처럼 실행되게 됩니다.

1. JPQL 이 Member 를 조회하는 것이기 때문에 Member 에 대한 select 쿼리가 실행

2. Member 를 가지고 왔는데 Team 이 즉시로딩이 되어 있습니다.

3. 즉시로딩은 데이터를가져올 때 무조건 값이 다 들어있어야 하기 때문에 또 Team 을 조회하기 위한 쿼리가 실행됩니다.

지금은 Member 데이터가 1개만 저장되어 있어서 1번만 실행되었지만 10개의 데이터가 있다면 Team 을 조회하기 위해 10번의 쿼리가 나가게 됩니다.

이것이 N + 1 문제인데 처음의 쿼리를 1 이라고 하고, 처음 쿼리로 인해 추가 쿼리가 N 개가 나간다고 해서 N + 1 이라고 합니다.

LAZY 로 설정하고 실행하면 쿼리는 Member 만 조회하고, Team 에는 프록시가 들어갑니다. 하지만 member 를 반복하면서 team 을 사용했을 때 쿼리가 반복해서 나가는 것은 동일합니다.

[ N + 1 문제 해결 ]

우선 모든 연관관계를 지연로딩으로 설정하고 fetch join 을 사용합니다.

패치조인은 런타임에 동적으로 원하는 객체들을 선택해서 한 번에 가져오는 전략입니다. join fetch m.team 을 하면 둘을 조인해서 한 번에 가져옵니다. ( 즉시 로딩처럼 )

이외에도 @EntityGraph 나 batch_size 를 사용하는 방법도 존재합니다.

3. 영속성 전이( CASCADE )

영속성 전이는 특정 엔티티를 영속 상태로 만들 때 연관된 엔티티도 함께 영속 상태로 만들고 싶을 때 사용합니다.

@Entity
public class Parent {
    @OneToMany(mappedBy = "parent", cascade = CascadeType.PERSIST)
    private List<Child> childList = new ArrayList<>();

    public void addChile(Child child) {
        childList.add(child);
        child.setParent(this);
    }
}
//------------------------------------------------------------------
@Entity
public class Child {
    @ManyToOne
    @JoinColumn(name = "PARENT_ID")
    private Parent parent;
}
//------------------------------------------------------------------
Parent parent = new Parent();
Child child1 = new Child();
Child child2 = new Child();

parent.addChile(child1);
parent.addChile(child2);

em.persist(parent);

위처럼 Parent 와 Child 가 있다고 가정했을 때 cascade = CascadeType.PERSIST 이 없다면 parent 와 child 를 저장하려면 각각 persist() 를 호출해야 저장됩니다.

하지만 해당 속성을 사용함으로써 parent 만 저장하면 자동적으로 child 도 저장되게 됩니다.

CASCADE 를 사용할 때 주의해야 할 점은 소유자가 하나일 때 사용해야 한다는 점입니다. 현재 예시에서는 child 의 소유자가 parent 가 있는데 만약 다른 엔티티에서 child 와 연관관계가 있다면 사용하면 안됩니다.

[ CASCADE 종류 ]

• ALL : 모두 적용
• PERSIST : 영속
• REMOVE : 삭제
• MERGE : 병합
• REFRESH : REFRESH
• DETACH : DETACH

4. 고아객체

부모 엔티티와 연관관계가 끊어진 자식 엔티티를 자동으로 삭제할 때 사용하는 orphanRemoval 옵션이 있는데 이를 true 로 설정하면 자동으로 제거됩니다.

public class Parent {
    ...
    @OneToMany(mappedBy = "parent", cascade = CascadeType.PERSIST, orphanRemoval = true)
    private List<Child> childList = new ArrayList<>();
}
//-----------------------------------------------------------------------------------
Parent parent = em.find(Parent.class, id);
parent.getChildren().remove(0);

위처럼 옵션을 추가한뒤, 자식 엔티티를 컬렉션에서 제거하면 둘의 연관관계가 끊기게 되는데 그렇게 되면 DELETE 쿼리가 수행됩니다.

이 옵션도 CASCADE 와 마찬가지로 참조하는 곳이 하나일 때만 사용해야 하며, @OneToOne, @OneToMany 만 가능합니다.

참고로 고아 객체 제거 기능을 활성화 하면, 부모를 제거할 때 자식도 함께 제거되는데 이는 CascadeType.REMOVE 처럼 동작합니다.

스스로 생명주기를 관리하는 엔티티는 em.persist() 로 영속화, em.remove() 로 제거합니다.

CascadeType.ALL 과 orphanRemoval = true 옵션을 모두 활성화 하면 부모 엔티티를 통해서 자식의 생명주기를 관리할 수 있습니다.

김영한 님의 자바 ORM 표준 JPA 프로그래밍 - 기본편 강의를 보고 작성한 내용입니다.

1. 상속관계 매핑

관계형 데이터베이스에 상속관계는 없습니다. 슈퍼타입 서브타입 관계라는 모델링 기법이 객체의 상속과 유사합니다. 그래서 상속관계를 매핑할 때는 객체의 상속 구조와 DB의 슈퍼타입, 서브타입 관계를 매핑합니다.

위와 같은 구조가 있다고 가정했을 떄, 슈퍼타입 서브타입 논리 모델을 실제 물리 모델로 구현하는 3가지 방법이 존재합니다. 객체 입장에서는 상속관계를 지원하기 때문에 하나의 구조가 나오게 되므로 어떤 전략을 사용해도 JPA 에서 매핑이 가능합니다.

1-1. 조인전략

조인전략은 각각 테이블로 변환하는 방식인데 모든 테이블을 생성해 데이터를 나누고 조인으로 구성하는 것입니다. 필요 시 데이터를 같이 가져올 때 조인으로 가져오면 됩니다.

예를 들어 Album 이 저장될 때 Item 테이블과 Album 테이블에 데이터를 나누어 저장하는 방식입니다. 데이터를 가져올 때는 ITEM_ID 를 통해 가져옵니다.

Item 테이블만 보았을 때 Album 인지, Movie 인지, Book 인지 구분이 안되기 때문에 Item 테이블 안에 이들을 구별하는 컬럼을 생성합니다.

[ 구현 코드 ]

@Entity
@Inheritance(strategy = InheritanceType.JOINED)
@DiscriminatorColumn
public class Item {
    @Id @GeneratedValue
    private Long id;
    private String name;
    private int price;
}
// -----------------------
@Entity
public class Movie extends Item {
    @Id @GeneratedValue
    private Long id;
    private String actor;
    private String director;
}

@Inheritance(strategy = InheritanceType.JOINED) 라고 선언하면 위의 그림처럼 설계한 것과 동일하게 테이블이 생성됩니다.

@DiscriminatorColumn 은 상위 클래스에 지정하고, name 속성을 지정하지 않으면 DTYPE 이라는 이름의 컬럼이 생성됩니다.

@DiscriminatorValue 는 하위 클래스에 지정하고 저장하고 싶은 데이터를 지정할 수 있는데, 어노테이션 자체를 선언하지 않거나 지정하지 않으면 엔티티명이 들어갑니다.

[ 실행 코드 ]

Movie movie = new Movie();
movie.setActor("actorA");
movie.setDirector("directorA");
movie.setName("nameA");
movie.setPrice(10000);

em.persist(movie);
// -----------------------
Movie findMovie = em.find(Movie.class, movie.getId());

위위 코드를 실행하면 Item 테이블과 Movie 테이블에 각각 Insert 쿼리가 나가게 되고 Item 테이블에 name, price 가, Movie 테이블에 actor, director,ITEM_ID 가 저장됩니다.

저장된 것을 보면 ITEM 의 ID 와 MOVIE 의 ID 가 동일한 것을 확인할 수 있으며, ITEM 에 DTYPE 이라는 컬럼이 생성되고, Movie 라는 값이 들어있는 것을 확인할 수 있습니다. 만약 Movie 에 @DiscriminatorValue("M") 을 선언하면 Movie 가 아닌 M 이라는 값으로 들어가게 됩니다.

-- 조회 SQL 로그
Hibernate: 
    select
        m1_0.id,
        m1_1.name,
        m1_1.price,
        m1_0.actor,
        m1_0.director 
    from
        Movie m1_0 
    join
        Item m1_1 
            on m1_0.id=m1_1.id 
    where
        m1_0.id=?

em.find() 를 할 때는 Movie 와 Item 을 inner 조인해서 데이터를 가져오게 됩니다.

1-2. 단일 테이블 전략

단일 테이블 전략이란 논리 모델을 하나의 테이블로 다 합치는 방법입니다. 조인전략과 마찬가지로 Album 인지, Movie 인지, Book 인지 구분하기 위해 이들을 구별하는 컬럼을 생성합니다.

조인전략에서 어노테이션을 @Inheritance(strategy = InheritanceType.SINGLE_TABLE) 로 변경하면 됩니다. 아래 테이블 생성 쿼리를 보면 Movie 에 있는 컬럼들도 Item 에 생성되는 것을 확인할 수 있습니다.

조인전략에서는 @DiscriminatorColumn 가 필수로 필요했지만, 단일 테이블 전략에서는 생략해도 자동으로 생성됩니다.

Hibernate: 
create table Item (
    price integer not null,
    id bigint not null,
    DTYPE varchar(31) not null,
    actor varchar(255),
    director varchar(255),
    name varchar(255),
    primary key (id)
)

단일 테이블 전략은 Insert 도 한 번에 되고, select 도 조인 필요없이 한 테이블에서만 조회하면 되기 때문에 성능상 훨씬 좋습니다.

1-3. 구현 클래스별 테이블 전략

쓰면 안되는 전략이라고 하셨습니다

테이블을 생성할 때 각각의 테이블을 생성하고, 모든 테이블이 Item 에 해당하는 name, price 와 같은 컬럼들을 가지게 하는 전략입니다.

@Inheritance(strategy = InheritanceType.TABLE_PER_CLASS) 로 선언하면 됩니다. 이때 Item 은 추상 클래스로 선언해야 하고, 코드 실행 결과, movie 테이블에 name 과 price 컬럼이 들어있는 것을 확인할 수 있습니다.

조회할 때 문제가 발생하는데 em.find(Item.class, movie.getId()) 를 실행하면 모든 자식들을 UNION 을 걸어서 전부 확인하게 됩니다.

2. 매핑정보 상속

@MappedSuperclass 라는 어노테이션이 있는데 공통 매핑 정보가 필요할 때 사용합니다.

예를 들어, 객체 입장에서 Member 와 Seller 에 id 와 name 이라는 필드가 공통적으로 있을 때 이를 부모를 만들어 속성만 상속해서 사용하고 싶을 때 사용합니다. 속성만 상속하고 DB 테이블은 따로 사용하게 됩니다.

@MappedSuperclass
public class BaseEntity {
    private String createdBy;
    private String createdData;
    ...
}
// --------------------------------------
public class Member extends BaseEntity {
    ...
}

@MappedSuperclass 가 선언된 클래스가 매핑 정보만 받는 슈퍼 클래스라고 생각하면 됩니다. BaseEntity 는 테이블이 생성되지 않고 Member 테이블이 생성될 때 속성들이 추가되어 생성됩니다.

상속 받는 자식 클래스에 매핑 정보만 제공할 뿐 엔티티가 아니기 때문에 테이블과 매핑되지 않고, 조회나 검색도 불가능합니다. 이를 구현할 때는 추상 클래스를 권장합니다.

참고로 JPA 에서 extends 를 사용할 때는 @Entity 나 @MappedSuperclass 가 붙은 클래스들만 상속 받을 수 있습니다.

김영한 님의 자바 ORM 표준 JPA 프로그래밍 - 기본편 강의를 보고 작성한 내용입니다.

1. 연관관계 매핑 시 고려사항

1. 다중성

2. 단방향, 양방향

테이블은 외래키 하나로 양쪽 조인이 가능하므로 사실상 방향 이라는 개념은 없습니다.

반대로 객체는 참조용 필드가 있는 쪽으로만 참조가 가능합니다. 한쪽만 참조하면 단방향, 양쪽이 서로 참조하면 양방향입니다.

3. 연관관계의 주인

테이블은 외래키 하나로 두 테이블이 연관관계를 맺습니다. 객체에서 양방향 관계는 두 개의 참조를 사용해야 하는데, 이 둘 중에서 어느 참조가 외래키를 관리할 것인지를 지정해야합니다.

외래키를 관리하는 참조를 연관관계의 주인이라고 하며, 주인의 반대편은 외래키에 영향을 주지 않고 단순 조회만 가능합니다.

2. 다대일

데이터베이스 테이블의 일(1), 다(N) 관계에서 외래 키는 항상 N 쪽에 있습니다. 따라서 객체 양방향 관계에서 연관관계의 주인은 항상 N 쪽입니다.

단방향에서 양방향으로 만들기 위해 반대쪽 사이드에 참조를 추가한다고 해서 테이블에 전혀 영향을 주지 않습니다. 왜냐하면 연관관계의 주인이 이미 외래키를 관리하고 있기 때문입니다.

3. 일대다

3-1. 일대다 단방향

일대다 단방향은 다대일의 반대로, 일대다(1 : N)에서 일(1)이 연관관계의 주인입니다.

위의 예시로 살펴보면 Team 은 Member 를 알고 싶은데, Member 는 Team 을 알고 싶지 않은 경우입니다. 하지만 테이블 일대다 관계는 항상 다(N) 쪽에 외래 키가 존재합니다.

그래서 위의 설계를 구현하게 되면 Team 의 List memebrs 값을 변경했을 때 Member 테이블이 가진 TEAM_ID 외래키가 업데이트됩니다.

public class Team {
    ...
    @OneToMany
    @JoinColumn(name = "TEAM_ID")   // 외래키를 관리
    private List<Member> members = new ArrayList<>();
}
// ---------------------------------------------------
Member member = new Member();
member.setUsername("memebr1");
em.persist(member);

Team team = new Team();
team.setName("teamA");
team.getMembers().add(member);

em.persist();

일대다 단방향의 경우, @OneToMany 와 함께 @JoinColumn 을 사용해서 외래키를 관리합니다. 일대다에서 @JoinColumn 은 필수이기 때문에 사용하지 않으면 중간에 테이블을 하나 추가하는 조인 테이블 방식을 사용하게 됩니다.

위의 코드에서 team.getMembers().add(member)가 수행될 때 Member 테이블의 외래키를 업데이트하는 쿼리가 날라가게됩니다. 그래서 Member 저장 1번, Team 저장 1번, Member 업데이트 1번해서 총 3번의 쿼리가 실행됩니다.

해당 관계는 엔티티가 관리하는 외래키가 다른 테이블에 존재하며, 연관관계 관리를 위해 추가로 Update 쿼리가 실행된다는 단점때문에, 다(N)측이 일(1)로 갈 일이 없어도 일대다 단방향보다는 다대일 양방향을 사용하는 것이 좋습니다.

3-2. 일대다 양방향

public class Member {
    ...
    @ManyToOne
    @JoinColum(name = "TEAM_ID", insertable = false, updatable = false)
    private Team team;
}

일대다 양방향은 다(N)측에 해당하는 Member 의 @JoinColumn 에서 insertable, updatable 속성을 사용해서 읽기 전용으로 만들어 구현할 수는 있습니다.

JPA 에서 일대다 양방향은 공식적으로 존재하지 않고, 다대일 양방향을 사용하는 것이 좋습니다.

4. 일대일

일대일 관계는 그 반대도 일대일 관계이며, 주 테이블이나 대상 테이블 중에서 외래키를 어느 테이블에 넣을지 선택할 수 있습니다. 외래키에 DB 유니크 제약조건을 추가해야 일대일 관계가 됩니다.

회원은 하나의 사물함만 사용하고, 사물함도 하나의 회원에 의해서만 사용된다는 가정과 함께 아래 예시들을 살펴보겠습니다.

4-1. 주 테이블

주 테이블에 외래키 단방향의 경우 Member 에 LOCKER_ID 라는 외래키를 넣고 유니크 제약조건을 걸었을 때, Member 에 Locker 라는 참조를 선언하고 외래키를 매핑하면 됩니다.

양방향으로 만드려면 반대쪽에도 @OneToOne 어노테이션을 사용하고, mappedBy 속성을 사용하면 됩니다. 다대일 양방향 매핑 처럼 외래키가 있는 곳이 연관관계의 주인이 됩니다.

주 테이블에 외래키가 있을 때 단점은 값이 없으면 외래키에 null 을 허용해야 한다는 점입니다.

4-2. 대상 테이블

대상 테이블에 외래키가 있다는 의미는 예를 들어, Member 의 Locker 참조가 외래키를 관리하고 싶은데 외래키가 Locker 테이블에 있는 것을 의미하는데 대상 테이블 단방향의 경우는 JPA 에서 지원하지 않습니다.

대상 테이블 양방향은 지원이 가능하며, 일대일 주 테이블 외래키 양방향과 매핑 방법은 같은데 단순하게 생각해서 일대일 관계는 내 엔티티에 있는 외래키는 내가 직접 관리해야 한다고 생각하면 됩니다.

대상 테이블에 외래키가 있을 때 단점은 프록시 기능의 한계로 지연 로딩으로 설정해도 항상 즉시로딩 된다는 점입니다.

주 테이블에 외래키 단방향 그림을 보았을 때 JPA 가 Member 를 로딩할 때 LOCKER_ID 에 값이 있으면 프록시를 넣고, 없으면 null 을 집어넣으면 됩니다. 그래서 Member 만 쿼리하면 됩니다.

하지만 대상 테이블에 양방향 그림을 보면 Member 를 조회할 때 Locker 의 값이 있는지 없는지 알려면 Member 테이블만 조회해서는 알 수 없기 때문에 Locker 에 Member 의 ID 가 있는지 확인해야 합니다.

그래서 어차피 두 테이블 모두에서 조회를 해야 프록시를 넣을지, null 을 넣을지 알게 되기 때문에 일대일에서 대상 테이블에 외래키가 있으면 지연로딩으로 설정해도 즉시로딩이 됩니다.

5. 다대다

관계형 데이터베이스는 정규화된 테이블 2개로 다대다 관계를 표현할 수 없습니다. 그래서 연결 테이블을 추가해서 일대다, 다대일 관계로 풀어내야 합니다.

예를 들어, 회원이 여러 개의 상품을 선택할 수 있고 하나의 상품은 여러 명의 회원들에게 선택될 수 있습니다. 이런 다대다 관계를 MEMBER_PRODUCT 는 중간 테이블을 만들어 일대다, 다대일로 풀어야 합니다.

하지만 객체는 컬렉션을 이용해서 객체 2개로 다대다 관계를 만들 수 있습니다. @ManyToMany 를 사용하고 @JoinTable 로 연결 테이블을 지정하면 됩니다.

// 하나의 엔티티에만 지정하면 단방향, 둘 다 지정하면 양방향
public class Member {
    ...
    @ManyToMany
    @JoinTable(name = "MEMBER_PRODUCT")
    private List<Product> products = new ArrayList<>();
}
// -------------------------------------------------------
public class Product {
    ...
    @ManyToMany
    @JoinTable(mappedBy = "products")
    private List<Member> members = new ArrayList<>();
}

[ 다대다 매핑의 한계 ]

위의 그림에서 연결 테이블인 MEMBER_PRODUCT 에는 두 개의 외래키만 가지고 있으며 추가적인 정보를 넣는게 불가능한데, 실제로 연결 테이블은 연결만 하고 끝나지 않고 주문시간이나 수량과 같은 데이터가 들어갈 수 있습니다.

[ 다대다 한계 극복 ]

연결 테이블용 엔티티를 추가( 연결 테이블을 엔티티로 승격 )해서 위처럼 @ManyToMany 를 @OneToMany 와 @ManyToOne 으로 사용하면 됩니다.

6. 어노테이션 속성

[ @JoinColumn ]

[ @ManyToOne ]

[ @OneToMany ]

김영한 님의 자바 ORM 표준 JPA 프로그래밍 - 기본편 강의를 보고 작성한 내용입니다.

1. 연관관계가 필요한 이유

객체는 참조로 연관관계를 표현하고, 테이블은 외래키로 연관관계를 표현합니다. 그래서 객체의 참조와 테이블의 외래키를 매핑하는 방법을 알아야 합니다.

예를 들어 아래와 같은 관계가 있다고 가정해보겠습니다.

회원과 팀이 있다 회원은 하나의 팀에만 소속될 수 있다 하나의 팀에는 여러 명의 회원이 존재한다 ➜ 회원과 팀은 다대일 관계이다

해당 관계에서 객체를 테이블에 맞추어 모델링하면 아래와 같고 이는 연관관계가 없는 객체가 됩니다.

@Entity
public class Member {
  @Id @GeneratedValue
  private Long id;
  private String name;
  @Column(name = "TEAM_ID")
  private Long teamId;
  ...
}
// ------------------------
@Entity
public class Team {
  @Id @GeneratedValue
  private Long id;
  private String name;
  ...
}

테이블에 맞추어 모델링을 했기 때문에 Member 가 Team 에 대한 참조를 가진 것이 아닌 Team 의 ID 를 FK 로 가지게 됩니다.

만약 회원의 팀을 저장하고 조회하려면 서로 연관관계가 없기 때문에 아래처럼 해야 합니다.

// 저장
Team team = new Team();
team.setName("teamA"); 
em.persist(team);

Member member = new Member();
member.setName("memberA");
member.setTeamId(team.getId());
em.persist(member);
// ------------------------------------------------------
// 조회
Member findMember = em.find(Member.class, member.getId());

Long findTeamId = findMember.getId();
Team findTeam = em.find(Team.class, findTeamId);

연관관계가 없기 때문에 member 를 저장할 때 Team 의 참조가 아닌 ID 를 사용합니다. 또한 회원의 팀을 조회할 때도 member 에서 Team 의 id 를 조회하고, team 의 id 로 다시 Team 을 조회해야 합니다.

이렇게 객체를 테이블에 맞추어 데이터 중심으로 모델링하면 협력 관계를 만들 수 없습니다.

2. 단방향 연관관계

위에서 보았던 예제를 객체지향적으로 모델링하면 아래와 같습니다.

@Entity
public class Member {
  @Id @GeneratedValue
  private Long id;
  private String name;
  @ManyToOne
  @JoinColumn(name = "TEAM_ID")
  private Team team;
  ...
}
// ------------------------
@Entity
public class Team {
  @Id @GeneratedValue
  private Long id;
  private String name;
  ...
}

Member 를 보면 Team 의 ID 가 아닌 Team 의 참조를 그대로 들고 있습니다. 참조를 사용하면 아래 두 가지를 명시해주어야 합니다.

1. JPA 에게 현재 엔티티와 참조 엔티티가 어떤 관계인지

2. 현재 엔티티에서 참조가 어떤 FK 와 매핑되는지

1번의 경우 회원과 팀은 다대일 관계이기 때문에 @ManyToOne 을 사용합니다.

2번의 경우 Member 가 가진 Team 의 참조와 테이블 관점에서 보았을 때 Member 가 가진 FK 를 매핑해주어야 하기 때문에 @JoinColumn 을 사용해서 이를 지정해줍니다.

위처럼 모델링 했을 때 저장과 조회를 하는 코드는 아래처럼 변하게 됩니다.

// 저장
Team team = new Team();
team.setName("teamA");  // 단방향 연관관계 설정, 참조 저장
em.persist(team);

Member member = new Member();
member.setName("memberA");
member.setTeam(team);
em.persist(member);
// ------------------------------------------------------
// 조회
Member findMember = em.find(Member.class, member.getId());
Team findTeam = findMember.getTeam();   // 참조를 사용해서 연관관계 조회 ( 객체 그래프 탐색 )

저장할 때는 Team 의 참조를 넣어주면 되고, 조회할 때는 Member 에서 바로 Team 을 꺼내면 됩니다. 변경할 때도 setTeam() 에 Team 에 대한 참조만 넣어주면 됩니다.

3. 양방향 연관관계

위에서 단방향 관계로 설정했기 때문에 Member ➜ Team 은 가능하지만 Team ➜ Member 는 불가능합니다. 이를 양방향 연관관계로 변경하면 아래와 같습니다.

테이블 연관관계를 보면 이전과 동일합니다. 왜냐하면 회원이 속한 팀을 알고 싶을 때도 TEAM_ID 로 조인하면 되고, 팀에 속한 회원을 알고 싶을 때도 TEAM_ID 로 조인하면 되기 때문입니다.

즉, 테이블의 연관관계는 외래키 하나에 양방향이 다 있다는 것이고, 테이블에서는 외래키 하나 만으로 양쪽의 데이터를 가져올 수 있게 됩니다.

하지만 객체 연관관계에서 Team 을 보면 List Member 가 추가된 것을 볼 수 있는데 이렇게 해야 Team 에서 Member 로 갈 수 있기 때문에 추가된 것입니다.

이것이 객체 참조와 테이블의 외래키의 가장 큰 차이점인데 참조를 통한 객체 연관관계는 단방향, 외래키를 통한 테이블 연관관계는 양방향입니다.

@Entity
public class Member {
  @Id
  @Column(name = "MEMBER_ID")
  private String id;
  private String username;

  @ManyToOne
  @JoinColumn(name="TEAM_ID")
  private Team team;
  ...
}
// ------------------------
@Entity
public class Team {
  @Id
  @Column(name = "TEAM_ID")
  private String id;
  private String name;

  @OneToMany(mappedBy = "team")
  private List<Member> members = new ArrayList<Member>();
  ...
}

Team 에 입장에서 일대다 관계이기 때문에 @OneToMany 를 사용하고 이를 List 로 묶습니다. 이때 미리 초기화 시켜야 add() 를 호출했을 때 NullPointerException 이 발생하지 않습니다.

@OneToMany 를 보면 mappedBy 라는 속성이 사용된 것을 볼 수 있는데, team 이라는 변수명에 연결되어 있음을 표시함과 동시에 연관관계의 주인이 아님을 명시합니다.

이렇게 하면 Member ➜ Team, Team ➜ Member 가 둘 다 가능한 양방향 연관관계가 완성됩니다.

4. 양방향 연관관계의 주인

4-1. 객체와 테이블이 관계를 맺는 차이

객체의 양방향 관계는 사실 양방향 관계가 아니라 서로 다른 단뱡향 관계 2개입니다. 그래서 객체를 양방향으로 참조하려면 단방향 연관관계를 2개 만들어야 합니다.

하지만 테이블은 외래키 하나로 두 테이블의 연관관계를 관리하고, 외래키 하나로 양방향 연관관계를 가져 양쪽으로 조인할 수 있습니다.

결국 엔티티와 테이블의 차이점은 엔티티를 양방향 연관관계로 설정하면 객체의 참조는 둘인데 테이블에서는 외래키 하나라는 점입니다.

2번에서 객체에서 연관관계를 표현하기 위해 참조에 FK 를 매핑해주었습니다. 단방향일 때는 참조가 1개였지만, 양방향일 때는 참조가 2개입니다. 그래서 어떤 참조에 외래키를 매핑해야 할 지 문제가 발생하는데 이때 등장하는 개념이 연관관계의 주인입니다.

4-2. 연관관계의 주인

정리하자면 위의 그림처럼 양방향 관계일 때는 Member 에 있는 Team 참조에 FK 를 매핑할 것인지, Team 에 있는 Member 참조에 FK 를 매핑할 것인지를 결정해야 합니다.

연관관계의 주인을 정할 때는 외래키가 있는 곳을 주인으로 정하면 됩니다. 위의 예시에서는 Member.team 이 연관관계의 주인이 됩니다.

그래서 연관관계의 주인이 아닌 Team 에 mappedBy 가 붙었으며, Member 의 team 필드와 매핑되어 있다고 표시합니다.

[ 양방향 매핑 규칙 ]

1. 객체의 두 관계 중 하나를 연관관계의 주인으로 지정합니다.

2. 연관관계의 주인만이 외래키를 관리합니다. ( 등록, 수정이 가능합니다 )

3. 주인이 아닌 쪽은 읽기만 가능합니다.

4. 주인은 mappedBy 속성을 사용하지 않습니다.

5. 주인이 아니면 mappedBy 속성으로 주인을 지정합니다.

4-3. 양방향 매핑 시 주의점

1. 연관관계 주인에 값을 입력하지 않음

[ 잘못된 코드 ]

Team team = new Team();
team.setName("teamA");
em.persist(team);

Member member = new Member();
member.setUsername("memebrA");

team.getMembers().add(member);  // 연관관계의 주인이 아닌 값만 설정
em.persist(member);

위의 코드를 실행하고 Member 와 Team 을 조회하면 아래와 같습니다. Member 테이블의 TEAM_ID 를 보면 NULL 인 것을 알 수 있습니다.

Member 를 보면 Team 참조가 연관관계의 주인이고, Team 의 List Member 는 mappedBy 로 설정되어 읽기 전용입니다. 그래서 JPA 는 Insert 나 Update 를 할 때 mappedBy 가 붙은 부분은 확인하지 않습니다.

하지만 위의 코드에서는 연관관계의 주인인 Member.team 에 값을 세팅하지 않았기 때문에 MEMBER 의 TEAM_ID 값이 null 이 됩니다. 올바르게 하려면 양방향 매핑 시, 연관관계의 주인에 값을 입력하는 것이 맞습니다.

[ 올바른 코드 ]

Team team = new Team();
team.setName("teamA");
em.persist(team);

Member member = new Member();
member.setUsername("memebrA");

member.setTeam(team); // 연관관계 주인
em.persist(member);

2. 순수 객체 관계를 고려해서 항상 양쪽에 값을 세팅해야 한다

순수한 객체 관계를 고려하면 연관관계의 주인에도 세팅을 해주고, 주인이 아닌 쪽에도 값을 세팅해주는 것이 맞는 방법입니다. 아래 예시를 보겠습니다.

Team team = new Team();
team.setName("teamA");
em.persist(team);

Member member = new Member();
member.setUsername("memebrA");
member.setTeam(team); // 연관관계 주인
em.persist(member);

Team findTeam = em.find(Team.class, team.getId());
List<Member> members = findTeam.getMembers();

for(Member m : members) {
  System.out.println("m = " + m.getName());
}

tx.commit();

위의 코드를 실행시키면 아무것도 출력되지 않습니다. 왜냐하면 Member 와 Team 이 지연로딩이 설정되어 있어, 조회를 하려면 DB 에 select 쿼리가 나가야 하는데 1차 캐시에 있는 값을 가져왔기 때문입니다.

persist() 로 인해 Team 이 영속성 컨텍스트에 존재하게 되고, find() 를 실행할 때 1차 캐시에서 가지고 오게 됩니다. 그래서 DB에 쿼리가 나가지 않아 가져온 Team 의 List 에는 값이 존재하지 않게 됩니다. 그래서 아래처럼 양쪽 모두에 값을 세팅하는 것이 올바른 방법입니다.

Team team = new Team();
team.setName("teamA");

Member member = new Member();
member.setUsername("memebrA");

member.setTeam(team); // 연관관계 주인
team.getMembers().add(member);  // 주인이 아닌 관계
em.persist(team);
em.persist(member);

영한님이 추천하는 방식

public class Member {
  ...
  public void setTeam(Team team) {
    this.team = team;
    team.getMember().add(this);
  }
}

연관관계의 주인에 값을 세팅하는 것과, 연관관계의 주인이 아닌 곳에 값을 세팅하는 코드 두 개를 작성해야 하는데 이를 연관관계 편의 메서드를 생성해서 하나로 묶는 방식을 추천하셨습니다.

4-4. 양방향 매핑 정리

단방향 매핑만으로도 이미 연관관계 매핑은 완료된 것입니다. 양방향 매핑은 반대 방향으로 조회(객체 그래프 탐색)기능이 추가된 것 뿐입니다.

그래서 단방향 매핑을 잘 하고, 양방향은 필요할 때 추가해도 테이블에 영향을 주지 않기 때문에 상관없습니다.

김영한 님의 자바 ORM 표준 JPA 프로그래밍 - 기본편 강의를 보고 작성한 내용입니다.

1. 엔티티 매핑

엔티티 매핑에 필요한 어노테이션들은 아래와 같습니다.

1. 객체와 테이블 매핑 : @Entity, @Table

2. 필드와 컬럼 매핑 : @Column

3. 기본 키 매핑 : @Id

4. 연관관계 매핑 : @ManyToOne, @JoinColumn

2. 객체와 테이블 매핑

2-1. @Entity

@Entity 가 붙은 클래스는 JPA 가 관리하게 되며, 엔티티라고 합니다. JPA 를 사용해서 테이블과 매핑할 클래스는 @Entity 가 필수적으로 붙어야 합니다.

JPA 는 객체를 프록싱하는 등의 기능이 있기 때문에 파라미터가 없는 public 이나 protected 기본 생성자가 필수로 필요합니다.

final 클래스, inner 클래스, interface, enum 에는 사용할 수 없고, DB 에 저장하고 싶은 필드에 final 키워드를 사용하면 안됩니다.

2-2. @Table

@Table 은 엔티티와 매핑할 테이블 지정합니다.

[ 사용 예시 ]

@Table(uniqueConstraints = 
    {@UniqueConstraint( 
        name = "NAME_AGE_UNIQUE",
        columnNames = {"NAME", "AGE"} )
    }
) 

3. 데이터베이스 스키마 자동 생성

JPA 는 매핑 정보만 보면 어떤 테이블인지, 어떤 쿼리를 만들어야 하는지 다 알 수 있습니다. 그래서 JPA 는 객체를 만들고 매핑을 하면 애플리케이션 로딩 시점에 DB 테이블을 생성하는 기능을 지원해줍니다.

이떄 JPA 는 데이터베이스 방언을 활용해서 DB 에 맞는 적절한 DDL 을 생성합니다. 예를 들어, hibernate.dialect 를 Oracle 로 설정하면 String 을 varchar2 로 생성하고, MySQL 로 지정하면 varchar 로 생성합니다.

이렇게 생성된 DDL 은 꼭 개발에서만 사용해야 하는데, 운영에서 create, create-drop, update 를 사용하면 안됩니다.

[ hibernate.hbm2ddl.auto ]

4. 필드와 컬럼 매핑

컬럼 매핑에 사용되는 어노테이션들은 아래와 같습니다.

1. 컬럼 매핑 : @Column

2. 날짜 타입 매핑 : @Temporal ( 스프링에서 LocalDateTime 타입을 사용하면 자동으로 날짜 타입이 됩니다 )

3. enum 타입 매핑 : @Enumrated

4. BLOB, CLOB 매핑 : @Lob

5. 특정 필드를 컬럼에 매핑하지 않음( 매핑 무시 ) : @Transient

4-1. 컬럼 매핑

• name : 필드와 매핑할 테이블의 컬럼 이름 ( 기본값 : 객체의 필드 이름 )

• length : 문자 길이 제약 조건으로 String 타입에만 사용합니다.

• nullable : null 값의 허용 여부를 설정합니다. false 로 설정하면 DDL 생성 시에 not null 제약 조건이 붙습니다. ( 기본값 : true )

• insertable / updatable : 컬럼 값을 수정했을 때, DB 에 저장, 혹은 수정할 것인지에 대한 여부를 지정합니다. ( 기본값 : true )

• unique

  • @Table의 uniqueConstraints와 같지만 한 컬럼에 간단히 유니크 제약조건을 걸 때 사용합니다.

  • 복잡적으로 사용할 수 없고 하나의 컬럼에만 사용할 수 있습니다.

  • 제약조건의 이름이 알아볼 수 없게 저장되기 때문에 잘 사용하지 않습니다. ( @Table 에서 지정하면 이름 지정과 복잡 지정이 가능 )

• columnDefinition

  • 데이터베이스 컬럼 정보를 직접 줄 수 있습니다.

  • ex> columnDefinition = "varchar(100) default 'EMPTY'"

• percision / scale

  • BigDecimal, BigInteger 타입에서 사용합니다. (double, float 에는 적용되지 않습니다)

  • percision 은 소수점을 포함한 전체 자리수를 나타냅니다

  • scale 은 소수의 자리수를 나타냅니다.

4-2. 타입에 따른 매핑

[ 날짜 타입 ]

@Temporal 은 Calendar 와 같은 날짜 타입을 매핑할 때 사용합니다. 만약 LocalDate, LocalDateTime 을 사용하면 어노테이션 자체를 생략할 수 있습니다. 속성은 value 가 있습니다.

[ Enum 타입 ]

자바 Enum 타입을 매핑할 때 @Enumrated 를 사용합니다. 속성은 value 가 있습니다.

[ 큰 타입 ]

varchar 를 넘어가는 큰 컨텐츠를 넣고 싶은 경우에 @Lob를 사용합니다. 속성은 존재하지 않습니다. 매핑하는 필드 타입이 String, char[] 와 같은 문자이면 CLOB 매핑, 나머지는 BLOB 를 매핑합니다.

[ 임시 타입 ]

DB 랑 관계없이 메모리에서 계산하고 싶은 필드에 @Transient 를 사용합니다. 해당 어노테이션을 붙이면 필드가 매핑되지 않아 DB 에 저장되지 않습니다.

5. 기본 키 매핑

5-1. 기본 키 매핑 어노테이션

JPA가 제공하는 데이터베이스 기본 키 매핑 어노테이션은 아래와 같습니다.

• 직접 할당 : 기본 키를 애플리케이션에서 직접 할당할 때 @Id 를 사용합니다.

• 자동 생성 : 데이터베이스가 값을 자동으로 할당해줄 때는 @GeneratedValue 를 사용합니다.

  • IDENTITY : 데이터베이스에 위임 ( MySQL )

  • SEQUENCE : 데이터베이스 시퀀스 오브젝트 사용, @SequenceGenerator 지정 가능 ( Oracle )

  • TABLE : 키 생성용 테이블 사용, 모든 DB 에서 사용하며 @TableGenerator 지정 가능

  • AUTO : 데이터베이스 방언에 따라 자동으로 지정하며, 기본값입니다.

5-2. IDENTITY 전략

기본키 생성을 데이터베이스에 위임하는 전략입니다. 주로 MySQL, PostgreSQL, MS SQL Server 에서 사용합니다. MySQL 에서는 AUTO_INCREMENT 가 있는데 null 로 집어넣으면 DB가 알아서 순차적으로 올라가도록 값을 세팅해줍니다.

JPA는 보통 트랜잭션 커밋 시점에 INSERT SQL 실행하는데 IDENTITY 는 데이터베이스에 INSERT SQL을 실행한 이후에 ID 값을 알 수 있습니다.

엔티티가 영속 상태가 되려면( 1차 캐시에 저장되려면 ) 식별자가 필요하기 때문에 IDENTITY 전략은 em.persist() 시점에 즉시 INSERT SQL 실행하고 DB에서 식별자를 조회합니다.

[ SEQUENCE 사용 ]

========= persist member1 이전 호출
Hibernate: 
    select 
        next value for MEMBER_SEQ
========= persist member1 이후 호출
========= transaction commit
Hibernate: 
    insert into
        Member (name, id) 
    values
        (?, ?)

SEQUENCE 를 사용하면 persist() 를 호출해도 Insert 쿼리가 수행되지 않고, 트랜잭션이 커밋될 때 INSERT 쿼리가 수행되는 것을 확인할 수 있습니다.

[ IDENTITY 사용 ]

========= persist member1 이전 호출
Hibernate: 
    insert into
        Member (name, id) 
    values
        (?, default)
========= persist member1 이후 호출
========= transaction commit

하지만 IDENTITY 는 트랜잭션이 커밋되지 않아도 persist() 를 호출하면 바로 INSERT 쿼리가 수행되는 것을 확인할 수 있습니다.

5-3. SEQUENCE 전략

데이터베이스 시퀀스는 유일한 값을 순서대로 생성하는 특별한 데이터베이스 오브젝트입니다. 주로 Oracle, PostgreSQL, H2 에서 사용합니다.

create sequence Member_SEQ start with 1 increment by 50

웹 애플리케이션을 실행시키면 위와 같은 로그가 출력되는데 create sequence 를 통해 시퀀스를 만들어내는 것을 확인할 수 있습니다.

[ @SequenceGenerator ]

@Entity
@SequenceGenerator(
        name = "MEMBER_SEQ_GENERATOR",
        sequenceName = "MEMBER_SEQ",
        initialValue = 1,
        allocationSize = 1
)
public class Member {
    @Id
    @GeneratedValue(strategy = GenerationType.SEQUENCE,
                    generator = "MEMBER_SEQ_GENERATOR")
    private Long id;
    ...
}

테이블마다 다른 시퀀스를 사용하고 싶은 경우, @SequenceGenerator 를 통해서 시퀀스를 생성하고, @GeneratedValue 에 generator 속성에 매핑해서 사용할 수 있습니다.

참고로 위처럼 지정하고 실행하면 allocationSize 에 의해 로그가 아래처럼 변하게 됩니다.

create sequence MEMBER_SEQ start with 1 increment by 1

[ 동작 확인 ]

Member member = new Member();
member.setName("HelloA");
System.out.println("========= persist member1");
em.persist(member);
System.out.println("========= member1 id = " + member.getId());

Member member2 = new Member();
member2.setName("HelloB");
System.out.println("========= persist member2");
em.persist(member2);
System.out.println("========= member2 id = " + member2.getId());

System.out.println("========= transaction commit");
tx.commit();

========= persist member1
Hibernate: 
    select
        next value for MEMBER_SEQ
========= member1 id = 1

========= persist member2
Hibernate: 
    select
        next value for MEMBER_SEQ
========= member1 id = 2

========= transaction commit
Hibernate: 
    insert into Member (name, id) values (?, ?)
Hibernate: 
    insert into Member (name, id) values (?, ?)

위의 로그를 보면 persist() 를 호출하면 데이터베이스 시퀀스를 사용해서 식별자를 먼저 조회하는 것을 확인할 수 있습니다.

그리고 조회한 식별자를 엔티티에 할당한 후에 엔티티를 영속성 컨텍스트에 저장하기 때문에 persist() 호출 후에 id 값을 확인해보면 정상적으로 출력되는 것을 확인할 수 있습니다.

Insert 쿼리는 트랜잭션 커밋이 호출되었을 때 실행되게 됩니다.

5-4. TABLE 전략

TABLE 전략은 키 생성 전용 테이블을 하나 만들어서 데이터베이스 시퀀스를 흉내내는 전략입니다. 모든 데이터베이스에 적용 가능하다는 장점이 있지만 락이 걸릴 수도 있는 등 성능이 좋지 않습니다.

@TableGenerator(
        name = "MEMBER_SEQ_GENERATOR",
        table = "MY_SEQUENCES",
        pkColumnValue = "MEMBER_SEQ", allocationSize = 1)
public class Member {
    @Id
    @GeneratedValue(strategy = GenerationType.TABLE,
                    generator = "MEMBER_SEQ_GENERATOR")
    private Long id;
    ...
}

시퀀스와 동일하게 어노테이션으로 generator 를 지정하고, @GeneratedValue 에 매핑하는 방식을 사용합니다.

Hibernate: 
    create table MY_SEQUENCES (
        next_val bigint,
        sequence_name varchar(255) not null,
        primary key (sequence_name)
    )
Hibernate: 
    insert into MY_SEQUENCES(sequence_name, next_val) values ('MEMBER_SEQ', 0)

애플리케이션을 실행하면 JPA 가 테이블을 생성해주면서 0 값을 넣어주게 됩니다. 그 뒤에 데이터를 INSERT 하게 되면 1부터 시작되는 PK 를 갖게 됩니다.

5-5. AUTO 전략

AUTO 전략이 기본값입니다. 데이터베이스 방언에 맞춰서 자동으로 생성되는 전략입니다. 위의 3개 중에 선택되어 사용됩니다.

Oracle 의 경우에는 SEQUENCE 전략을 사용하는데 DB 가 자동으로 숫자값을 생성해줍니다.

5-6. allocationSize

========= persist member1
Hibernate: 
    select
        next value for MEMBER_SEQ

========= persist member2
Hibernate: 
    select
        next value for MEMBER_SEQ

========= transaction commit
Hibernate: 
    insert into Member (name, id) values (?, ?)
Hibernate: 
    insert into Member (name, id) values (?, ?)

SEQUENCE 를 보면 위와 같은 로그가 있습니다. SEQUENCE 전략은 persist() 를 호출하면 데이터베이스 시퀀스를 조회해서 영속성 컨텍스트에 저장합니다.

여기서 데이터베이스 시퀀스를 조회하기 위해서 데이터베이스와 통신을 해야하고, 트랜잭션이 커밋될 때도 데이터베이스와 통신을 해야 하기 때문에 2번의 통신이 이루어져야 합니다. 이러한 것을 방지하고 성능을 높이기 위해 JPA 는 allocationSize 라는 속성을 제공합니다.

현재 시퀀스가 1이고, allocationSize 가 50이면 시퀀스를 조회할 때 DB의 시퀀스를 51로 높이게 됩니다. 그리고 메모리에서 1씩 사용하게 되면서 데이터베이스에 시퀀스 조회 쿼리가 날라가지 않게 됩니다.

시퀀스를 모두 소진하기 전에 어플리케이션이 종료될 경우, 나머지 시퀀스는 사라지며 다시 사용할 수 없는 상태가 됩니다. 만약 1-50번까지의 시퀀스 중 10번까지 사용하고 11-50번은 사용하지 않은 상태로 어플리케이션을 종료하고 다시 시작하면, 51번부터 시작하게 됩니다.