📖 자바 ORM 표준 JPA 프로그래밍

2023-01-16

자바 ORM 표준 JPA 프로그래밍 책을 읽고 내용을 아주 간단하게 정리한 글입니다. 책에는 자세한 설명과 예제가 많으니 꼭 구입해서 읽는것을 추천합니다~👍

1. JPA 소개

1.1 SQL을 직접 다룰 때 발생하는 문제점

자바로 개발하는 애플리케이션은 대부분 관계형 데이터베이스를 데이터 저장소로 사용한다.
JDBC API를 사용해 SQL을 전달한다.

1.1.1 반복, 반복 그리고 반복

객체를 데이터베이스에 CURD 하려면 너무많은 SQL과 JDBC API를 코드로 작성해야 한다. 테이블이 여러개라면 무수히 많은 SQL을 작성해야 한다.

1.1.2 SQL에 의존적인 개발

애플리케이션에서 SQL을 직접 다룰 때 발생하는 문제점

진정한 의미의 계층 분할이 어렵다.
엔티티를 신뢰할 수 없다.
SQL에 의존적인 개발을 피하기 어렵다.

1.1.3 JPA와 문제 해결

JPA를 사용하면 객체를 데이터베이스에 저장하고 관리할 때, 개발자가 직접 SQL을 작성하는 것이 아니라 JPA가 제공하는 API를 사용하면 된다.

// 저장
jpa.persist(member);

// 조회
String memberId = "helloId"
Member member = jpa.find(Member.class, memberId);

// 수정
Member member = jpa.find(Member.class, memberId);
member.setName("이름변경"); // jpa는 update 메소드가 따로 없다.

// 연관된 객체 조회
Member member = jpa.find(Member.class, memberId);
Team team = member.getTeam();

1.2 패러다임 불일치

객체와 관계형 데이터베이스는 지향하는 목적이 서로 다르다.
기능과 표현 방법도 다르다.
객체 구조를 테이블 구조에 저장하는 데는 한계가 있다.

1.2.1 상속

객체는 상속이라는 기능을 가지고 있지만 테이블은 상속이라는 기능이 없다.(일부 데이터베이스는 상속 기능을 지원하지만 객체의 상속과는 약간 다르다.)

데이터베이스 모델링에서는 슈퍼타입 서브타입 관계를 사용하면 유사하게 만들 수 있다.

위의 구조를 JDBC API를 사용해서 구현하려면 작성해야 할 코드량이 만만치 않다.

INSERT INTO ITEM…
INSERT INTO ALBUM…

JPA와 상속
JPA는 상속과 관련된 패러다임 불일치 문제를 개발자 대신 해결해 준다.

// 저장
jpa.persist(album);

// JPA에서 실행 해주는 SQL
INSERT INTO ITEM...
INSERT INTO ALBUM...

1.2.2 연관관계

객체는 참조를 사용해 다른 객체와 연관관계를 가진다. 참조에 접근해서 연관된 객체를 조회한다.
테이블은 외래 키를 사용해 다른 테이블과 연관관계를 가진다. 조인을 사용해서 연관된 테이블을 조회한다.
객체는 참조가 있는 방향으로만 조회할 수 있다.

객체를 테이블에 맞추어 모델링

// 관계형 데이터베이스가 사용하는 방식에 맞추면 객체 참조를 통해 조회할 수 없다.
class Member {
    String id;   // MEMBER_ID 컬럼 사용
    Long teamId; // TEAM_ID FK 컬럼 사용
}

객체지향 모델링

// 패러다임 불일치를 해결하려고 소모하는 코드가 많다.
class Member {
    String id;   // MEMBER_ID 컬럼 사용
    Team team; // 참조로 연관관계를 맺는다.
}

// 데이터베이스에 저장
member.getId();
member.getTeam.getId(); // TEAM_ID FK를 직접 구해야 함
...생략...

// 조회
SQL 실행
Member member = new Member ();
Team team = new Team();
...생략...
member.setTeam(team); // 직접 회원과 팀 관계 설정

JPA와 연관관계

// JPA는 연관관계와 관련된 패러다임 불일치 문제를 해결해준다.

// 저장
member.setTeam(team);
jpa.persist(member); // TEAM_ID FK를 직접 지정할 필요 없음

// 조회
Member member = jpa.find(Member.class, memberId);
Team team = member.getTeam(); // 바로 사용 가능

1.2.3 객체 그래프 탐색

객체에서 회원에 소속된 팀을 조회할 때는 다음처럼 참조를 사용해서 연관된 팀을 찾으면 되는데, 이것을 객체 그래프 탐색이라 한다.

// 객체 그래프 탐색
member.getOrder().getOrderItem()...

// 문제 발생
member.getOrder(); // 만약 null이라면?

SQL을 직접 다루면 처음 실행하는 SQL에 따라 객체 그래프를 어디까지 탐색할 수 있는지 정해진다. 이는 객체 그래프가 언제 끊어질지 모르기 때문에 함부로 탐색할 수 없다.

JPA와 객체 그래프 탐색
JPA는 연관된 객체를 사용하는 시점에 적절한 SELECT SQL을 실행한다(지연로딩). 따라서 JPA를 사용하면 연관된 객체를 신뢰하고 조회할 수 있다.

1.2.4 비교

데이터베이스는 기본 키의 값으로 각 row를 구분
객체는 동일성, 동등성 비교.
- 동일성은 == 비교. 객체 인스턴스의 주소 값을 비교한다.
- 동등성은 equals() 비교. 객체 내부의 값을 비교한다.

JDBC API 비교

String memberId = "100";
Member member1 = memberDAO.getMember(memberID);
Member member2 = memberDAO.getMember(memberID);

// false
member1 == member2;

JPA 비교

String memberId = "100";
Member member1 = jpa.find(memberID);
Member member2 = jpa.find(memberID);

// true
member1 == member2;

1.2.5 정리

객체 모델과 관계형 데이터베이스 모델은 지향하는 패러다임이 서로 다르다.
이 패러다임 차이를 극복하려고 개발자가 너무 많은 시간과 코드를 소비한다.
결국, 객체 모델링은 힘을 잃고 점점 데이터 중심의 모델로 변해간다.
JPA는 패러다임 불일치 문제를 해결하고, 정교한 객체 모델링을 유지하게 도와준다.

1.3 JPA란 무엇인가?

JPA란?

JPA(java persistence API)는 자바진영 ORM 기술 표준이다. 애플리케이션과 JDBC 사이에서 동작한다.

ORM이란?

ORM(Object-Relational Mapping)은 객체와 관계형 데이터베이스를 매핑한다는 뜻이다.
다양한 ORM 프레임워크들이 있는데 자바 진영에서는 하이버네이트 프레임워크가 가장 많이 사용된다.

1.3.1 JPA 소개

JPA는 자바 ORM 기술에 대한 API 표준 명세다.
쉽게 이야기해서 인터페이스를 모아둔 것이다.
따라서 JPA를 사용하려면 JPA를 구현한 ORM 프레임워크를 선택해야 한다.
ORM 프레임워크 중 하이버네이트가 가장 대중적이다.

1.3.2 왜 JPA를 사용해야 하는가?

생산성
유지보수
패러다임 불일치 해결
성능 (캐시)
데이터 접근 추상화와 벤더 독립성
- 데이터베이스마다 사용법이 다르다 (예: 페이징 쿼리)
- JPA에게 데이터베이스만 알려주면 자동으로 해결된다
표준
- 자바 진영 ORM 기술 표준
- 표준을 사용하면 다른 구현 기술로 손쉽게 변경 가능

1.4 정리

SQL을 직접 다룰 때 발생하는 다양한 문제
객체지향 언어와 관계형 데이터베이스 사이의 패러다임 불일치 문제
JPA가 각 문제를 어떻게 해결하는지
JPA가 무엇인지
JPA 장점

2. JPA 시작

2.1 이클립스 설치와 프로젝트 불러오기

2.2 H2 데이터베이스 설치

2.3 라이브러리와 프로젝트 구조

2.4 객체 매핑 시작

// 객체 매핑 예
@Entity
@Table(name="MEMBER")
public class Member {

    @Id
    @Column(name = "ID")
    private String id;

    @Column(name = "NAME")
    private String username;

    private Integer age;
    ...
}

어노테이션	설명
@Entity	이 클래스를 테이블과 매핑한다고 JPA에게 알려준다. @Entity가 사용된 클래스를 엔티티 클래스라 한다.
@Table	엔티티 클래스에 매핑할 테이블 정보를 알려준다. 이 어노테이션을 생략하면 클래스 이름을 테이블 이름으로 매핑한다. (정확히는 엔티티 이름을 사용함)
@Id	엔티티 클래스의 필드를 테이블 기본키(primary key)에 매핑한다. @Id가 사용된 필드를 식별자 필드라 한다.
@Column	필드를 컬럼에 매핑한다.
매핑 정보가 없는 필드	필드명을 사용해서 컬럼명으로 매핑한다. 대소문자를 구분하는 데이터베이스를 사용하면 @Column(name=”AGE”)처럼 명시적으로 매핑해야 한다.

2.5 객체 매핑 시작

2.5.1 데이터베이스 방언

데이터베이스마다 SQL 문법과 함수가 조금씩 다르다는 문제점이 있다.

데이터 타입: 가변 문자 타입으로 MySQL은 VARCHAR, 오라클은 VARCHAR2 사용
다른 함수명: 문자열을 자르는 함수로 SQL 표준은 SUBSTRING(), 오라클은 SUBSTR()
페이징 처리: MySQL은 LIMIT, 오라클은 ROWNUM

데이터베이스만의 고유한 기능을 JPA에서는 방언(Dialect)이라 한다. 하이버네이트를 포함한 대부분의 JPA 구현체들은 위와 같은 문제점을 해결하려고 다양한 데이터베이스 방언 클래스를 제공한다. 방언만 교체하면 데이터베이스에 맞는 SQL이 알아서 실행된다.

<!-- 필수 속성 -->
<property name="javax.persistence.jdbc.driver" value="org.h2.Driver"/>
<property name="javax.persistence.jdbc.user" value="sa"/>
<property name="javax.persistence.jdbc.password" value=""/>
<property name="javax.persistence.jdbc.url" value="jdbc:h2:tcp://localhost/~/test"/>
<property name="hibernate.dialect" value="org.hibernate.dialect.H2Dialect" /> <!-- 방언 설정 -->

<!-- 옵션 -->
<property name="hibernate.show_sql" value="true" /> <!-- 하이버네이트가 실행한 SQL을 출력한다 -->
<property name="hibernate.format_sql" value="true" /> <!-- 하이버네이트가 실행한 SQL을 보기 쉽게 정렬한다 -->
<property name="hibernate.use_sql_comments" value="true" /> <!-- 쿼리를 출력할 때 주석도 함께 출력한다 -->
<property name="hibernate.id.new_generator_mappings" value="true" /> <!-- JPA 표준에 맞춘 새로운 키 생성 전략을 사용한다. -->

2.6 애플리케이션 개발

시작코드를 살펴보자

public class JpaMain {

    public static void main(String[] args) {

        //엔티티 매니저 팩토리 생성
        EntityManagerFactory emf = Persistence.createEntityManagerFactory("jpabook");
        EntityManager em = emf.createEntityManager(); //엔티티 매니저 생성

        EntityTransaction tx = em.getTransaction(); //트랜잭션 기능 획득

        try {
            tx.begin(); //트랜잭션 시작
            logic(em);  //비즈니스 로직
            tx.commit();//트랜잭션 커밋

        } catch (Exception e) {
            e.printStackTrace();
            tx.rollback(); //트랜잭션 롤백
        } finally {
            em.close(); //엔티티 매니저 종료
        }

        emf.close(); //엔티티 매니저 팩토리 종료
    }

    // 비즈니스 로직
    public static void logic(EntityManager em) {...}
}

코드는 크게 3부분으로 나뉘어 있다

엔티티 매니저 생성
트랜잭션 관리
비즈니스 로직

2.6.1 엔티티 매니저 설정

엔티티 매니저 팩토리 생성
JPA를 시작하려면 우선 엔티티 매니저 팩토리를 생성해야 한다.

EntityManagerFactory emf = Persistence.createEntityManagerFactory("jpabook");

엔티티 매니저 팩토리는 JPA를 동작시키기 위한 기반 객체를 만들고 데이터베이스 커넥션 풀도 생성하므로 생성 비용은 아주 크다. 따라서 엔티티 매니저 팩토리는 애플리케이션 전체에 딱 한 번만 생성하고 공유해서 사용해야 한다.

엔티티 매니저 생성

EntityManager em = emf.createEntityManager();

JPA의 기능 대부분은 엔티티 매니저가 제공한다. 대표적으로 엔티티를 데이터베이스에 등록,수정,삭제,조회할 수 있다. 엔티티 매니저는 데이터베이스 커넥션과 밀접한 관계가 있으므로 스레드간에 공유하거나 재사용하면 안된다.

종료
사용이 끝난 엔티티 매니저, 엔티티 매니저 팩토리는 반드시 종료해야한다.

em.close(); // 엔티티 매니저 종료
emf.close() // 엔티티 매니저 팩토리 종료

2.6.2 트랜잭션 관리

JPA를 사용하면 항상 트랜잭션 안에서 데이터를 변경해야 한다. 트랜잭션 없이 데이터를 변경하면 예외가 발생한다.

EntityTransaction tx = em.getTransaction(); //트랜잭션 기능 획득
try {
    tx.begin(); //트랜잭션 시작
    logic(em);  //비즈니스 로직
    tx.commit();//트랜잭션 커밋

} catch (Exception e) {
    e.printStackTrace();
    tx.rollback(); //트랜잭션 롤백
} finally {
    em.close(); //엔티티 매니저 종료
}

emf.close(); //엔티티 매니저 팩토리 종료

2.6.3 비즈니스 로직

JPA를 이용한 등록, 수정, 조회, 삭제 예는 아래와 같다.

public static void logic(EntityManager em) {

        String id = "id1";
        Member member = new Member();
        member.setId(id);
        member.setUsername("지한");
        member.setAge(2);

        //등록
        // INSERT INTO MEMBER ...
        em.persist(member);

        //수정
        // JPA는 엔티티 변경 추적 기능이 있어 엔티티의 값만 변경하면 수정됨
        // UPDATE MEMBER SET AGE=20, NAME='지한' WHERE ID = 'id1';
        member.setAge(20);

        //한 건 조회
        // SELECT * FROM MEMBER WHERE ID = 'id1';
        Member findMember = em.find(Member.class, id);
        System.out.println("findMember=" + findMember.getUsername() + ", age=" + findMember.getAge());

        //목록 조회
        List<Member> members = em.createQuery("select m from Member m", Member.class).getResultList();
        System.out.println("members.size=" + members.size());

        //삭제
        // DELETE FROM MEMBER WHERE ID = 'id1';
        em.remove(member);
    }

2.6.4 JPQL

JPA는 SQL을 추상화한 JPQL이라는 객체 지향 쿼리 언어를 제공한다.

//목록 조회
List<Member> members = em.createQuery("select m from Member m", Member.class).getResultList();
System.out.println("members.size=" + members.size());

JPQL과 SQL의 가장 큰 차이점

JPQL은 엔티티 객체를 대상으로 쿼리한다.
SQL은 데이터베이스 테이블을 대상으로 쿼리한다.

JPQL은 데이터베이스 테이블을 전혀 알지 못한다.

2.7 정리

JPA를 사용하기 위한 개발 환경 설정
JPA를 사용
JPQL 설명

3. 영속성 관리

3.1 엔티티 매니저 팩토리와 엔티티 매니저

엔티티 매니저 팩토리를 만드는 비용은 상당히 크다.
따라서 애플리케이션 전체에서 공유하도록 설계되어 있다. (그래서 일반적으로 하나만 생성 한다)
엔티티 매니저 팩토리는 여러 스레드가 동시에 접근해도 안전하다.
엔티티 매니저는 여러 스레드가 동시에 접근하면 동시성 문제가 발생한다.

3.2 영속성 컨텍스트란?

영속성 컨텍스트(persistence context)란 해석하자면 엔티티를 영구 저장하는 환경이란 뜻이다.

// 이 메소드는 정확히 표현하자면 '엔티티 매니저를 사용해서 회원 엔티티를 영속성 컨텍스트에 저장한다' 이다.
em.persist(memeber);

영속성 컨텍스트는

엔티티 매니저를 생성할 때 하나 만들어진다.
엔티티 매니저를 통해서 접근할 수 있다.
엔티티 매니저를 통해 관리받는다.
여러 엔티티 매니저가 접근할 수도 있다.

3.3 엔티티의 생명주기

엔티티에는 4가지 상태가 존재한다.

비영속(new / transient): 영속성 컨텍스트와 전혀 관계가 없는 상태
영속(managed): 영속성 컨텍스트에 저장된 상태
준영속(detached): 영속성 컨텍스트에 저장되었다가 분리된 상태
삭제(removed): 삭제된 상태

3.4 영속성 컨텍스트의 특징

영속성 컨텍스트의 특징은 다음과 같다.

영속성 컨텍스트는 엔티티를 식별자값(@Id)으로 구분한다. 영속 상태는 식별자 값이 반드시 있어야 한다.
JPA는 보통 트랜잭션을 커밋하는 순간 영속성 컨텍스트에 새로 저장된 엔티티를 데이터베이스에 반영하는데 이것을 플러시(flush)라 한다.

영속성 컨텍스트가 엔티티를 관리할 때 장점

1차 캐시
동일성 보장
트랜잭션을 지원하는 쓰기 지연
변경 감지
지연로딩

3.4.1 엔티티 조회

영속성 컨텍스트는 내부에 캐시를 가지고 있는데 이것을 1차 캐시라 한다. 영속 상태의 엔티티는 모두 이곳에 저장된다.

1차 캐시에서 조회

1차 캐시의 키는 식별자(@Id) 값.
식별자 값은 데이터베이스 기본 키와 매핑.
1차 캐시에서 엔티티를 찾고 엔티티가 없으면 데이터베이스에서 조회한다.

// 비영속 상태
Member member = new Member();
member.setId("member1");
member.setUsername("회원1");

// 영속 상태 (1차 캐시에 저장됨)
em.persist(member);

// 1차 캐시에서 조회
Member findMember = em.find(Member.class, "member1");

데이터베이스에서 조회

조회시 엔티티가 1차 캐시에 없으면 엔티티 매니저는 데이터베이스를 조회해서 엔티티를 생성.
1차 캐시에 저장한 후에 영속 상태의 엔티티를 반환한다.

영속 엔티티의 동일성 보장
영속성 컨텍스트는 성능상 이점과 엔티티의 동일성을 보장한다.

Member a = em.find(Member.class, "member1");
Member b = em.find(Member.class, "member1");

System.out.println(a == b);

동일성과 동등성

동일성(identity): 실제 인스턴스가 같다. 따라서 참조 값을 비교하는 == 비교의 값이 같다.
동등성(equality): 실제 인스턴스는 다를 수 있지만 인스턴스가 가지고 있는 값이 같다.

3.4.2 엔티티 등록

EntityManager em = emf.createEntityManager(); 
EntityTransaction tx = em.getTransaction();
// 엔티티 매니저는 데이터 변경 시 트랜잭션을 시작해야 한다.
tx.begin(); //트랜잭션 시작

em.persist(memberA);
em.persist(memberB);
// 여기까지 INSERT SQL을 데이터베이스에 보내지 않는다.

// 커밋하는 순간 데이터베이스에 INSERT SQL을 보낸다.
tx.commit();

엔티티 매니저는 트랜잭션을 커밋하기 직전까지 데이터베이스에 저장하지 않고 내부 쿼리 저장소에 INSERT SQL을 모아둔다.
트랜잭션을 커밋할 때 모아둔 쿼리를 데이터베이스에 보낸다. 이를 트랜잭션을 지원하는 쓰기 지연이라 한다.

플러시

플러시는 영속성 컨텍스트의 변경 내용을 데이터베이스에 동기화 하는 작업
구체적으로 이야기하면 쓰기 지연 SQL을 데이터베이스에 보내는 작업이다.

트랜잭션을 지원하는 쓰기 지연이 가능한 이유

등록 쿼리를 그때 그때 데이터베이스에 전달해도 트랜잭션을 커밋하지 않으면 아무 소용 없다.
결국 데이터베이스에 SQL을 그때 그때 전달하나, 커밋 직전에만 전달하나 결과는 같다.

3.4.3 엔티티 수정

SQL 수정 쿼리의 문제점

수정 쿼리가 많아진다.
비즈니스 로직을 분석하기 위해 SQL을 계속 확인해야한다.
결국 직간접적으로 비즈니스 로직이 SQL에 의존한다.

JPA의 수정: 변경감지

JPA에서 엔티티 수정은 단순히 엔티티를 조회해서 데이터만 변경하면 된다.
이렇게 엔티티의 변경사항을 데이터베이스에 자동으로 반영하는 기능을 변경 감지라 한다.
변경 감지는 영속성 컨텍스트가 관리하는 영속 상태의 엔티티에만 적용된다.

EntityManager em = emf.createEntityManager(); 
EntityTransaction tx = em.getTransaction();

// 트랜잭션 시작
tx.begin();

// 영속 엔티티 조회
Member memberA = em.find(Member.class, "memberA");

// 영속 엔티티 데이터 수정
memberA.setUserName("hi");
memberA.setAge(10);

// 트랜잭션 커밋
tx.commit();

JPA의 수정 기본전략은 엔티티의 모든 필드를 업데이트 한다.
필드가 너무 많거나 저장되는 내용이 너무 크면 수정된 데이터만 사용해서 동적으로 UPDATE SQL을 생성하는 전략을 선택할 수 있다.

@Entity
@org.hibernate.annotations.DynamicUpdate
public class Member{...}

참고
상황에 따라 다르겠지만 컬럼이 대략 30개 정도가 아니라면 기본 전략의 수정 쿼리가 빠르다.
추가로 INSERT SQL을 동적으로 생성하는 @DynamicInsert도 있다.

3.4.4 엔티티 삭제

// 영속 엔티티 조회
Member memberA = em.find(Member.class, "memberA");
em.remove(memberA);

em.remove(); 호출
호출 순간 영속성 컨텍스트에서 엔티티 제거
쓰기 지연 SQL 저장소에 삭제 쿼리 등록
트랜잭션 커밋시 플러시 (실제 데이터베이스에 삭제 쿼리 전달)
데이터베이스 트랜잭션 커밋

3.5 플러시

플러시는(flush())는 영속성 컨텍스트의 변경 내용을 데이터베이스에 반영한다. 동작 순서는 다음과 같다.

변경 감지가 영속성 컨텍스트에 있는 모든 엔티티를 스냅샷과 비교해서 수정된 엔티티를 찾는다.
수정된 엔티티는 수정 쿼리를 만들어 쓰기 지연 SQL 저장소에 등록한다.
쓰기 지연 SQL 저장소의 쿼리를 데이터베이스에 전송한다.(등록,수정,삭제 쿼리)

영속성 컨텍스트를 플러시하는 방법 3가지

직접 호출 (em.flush())
트랜잭션 커밋
JPQL 쿼리 실행
- JPQL은 SQL로 변환되어 데이터베이스에서 엔티티 조회
- 만약 엔티티가 데이터베이스에 없으면 조회 불가
- 따라서 플러시를 통해 변경 내용을 데이터베이스에 반영해야 함

참고
식별자를 기준으로 조회하는 find() 메소드를 호출할 때는 플러시가 실행되지 않는다.

3.5.1 플러시 모드 옵션

FlushModeType.AUTO: 커밋이나 쿼리를 실행할 때 플러시(기본값)
FlushModeType.COMMIT: 커밋할 때만 플러시

em.setFlushMode(FlushModeType.COMMIT); // 플러시 모드 직접 설정

3.6 준영속

영속성 컨텍스트가 관리하는 영속 상태의 엔티티가 영속성 컨텍스트에서 분리된 것을 준영속 상태라 한다.
준영속 상태의 엔티티는 영속성 컨텍스트가 제공하는 기능을 사용할 수 없다.

영속 상태의 엔티티를 준영속 상태로 만드는 방법

em.detach(entity): 특정 엔티티만 준영속 상태로 전환
em.clear(): 영속성 컨텍스트를 완전히 초기화
em.close(): 영속성 컨텍스트를 종료

3.6.1 엔티티를 준영속 상태로 전환: detach()

특정 엔티티만 준영속 상태로 전환

3.6.2 영속성 컨텍스트 초기화: clear()

영속성 컨텍스트를 초기화해서 해당 영속성 컨텍스트의 모든 엔티티를 준영속 상태로 만듬

3.6.3 영속성 컨텍스트 종료: close()

영속성 컨텍스트를 종료하면 해당 영속성 컨텍스트가 관리하던 영속 상태의 엔티티가 모둔 준영속 상태가 된다.

3.6.4 준영속 상태의 특징

거의 비영속 상태에 가깝다.
식별자 값을 가지고 있다. (준영속 상태는 이미 한 번 영속 상태였으므로 식별자 값을 가지고 있다)
지연 로딩을 할 수 없다.

3.6.5 병합: merge()

준영속 상태의 엔티티를 다시 영속 상태로 변경하려면 병합을 사용한다. merge() 메소드는 준영속 상태의 엔티티를 받아서 그 정보로 새로운 영속 상태의 엔티티를 반환한다.

Member mergeMember = em.merge(member);

준영속 병합
준영속 상태인 member엔티티와 영속 상태인 mergeMember 엔티티는 서로 다른 인스턴스다. 따라서 다음과 같이 참조하도록 사용하는 것이 안전하다.

// Member mergeMember = em.merge(member); // 이 코드는 위험
member = em2.merge(member); // 이렇게 사용

비영속 병합
병합은 비영속 엔티티도 영속 상태로 만들 수 있다.

Member member = new Member();
Mmeber newMember = em.merge(member); // 비영속 병합
tx.commit();

병합 동작 순서

파라미터로 넘어온 엔티티의 식별자 값으로 영속성 컨텍스트 조회
찾는 엔티티가 없으면 데이터베이스 조회
데이터베이스에서도 없으면 엔티티 생성해서 병합

3.7 정리

엔티티 매니저는 앤티티 매니저 팩토리에서 생성한다.
영속성 컨텍스트는 엔티티 매니저를 통해서 접근할 수 있다.
영속성 컨텍스트는 애플리케이션과 데이터베이스 사이에서 객체를 보관하는 가상의 데이터베이스 같은 역할을 한다.
영속성 컨텍스트 덕분에 1차 캐시, 동일성 보장, 트랜잭션을 지원하는 쓰기지연, 변경 감지, 지연 로딩 기능을 사용할 수 있다.
영속성 컨텍스트에 저장한 엔티티는 플러시 시점에 데이터베이스에 반영된다.
플러시는 일반적으로 트랜잭션을 커밋할 때 동작한다.
영속 상태: 영속성 컨텍스트가 관리하는 엔티티
준영속 상태: 영속 상태의 엔티티가 영속성 컨텍스트에서 분리된 것을 준영속 상태

4. 엔티티 매핑

객체와 테이블 매핑: @Entity, @Table
기본 키 매핑: @Id
필드와 컬럼 매핑: @Column
연관관계 매핑: @ManyToOne, @JoinColumn

4.1 @Entity

JPA를 사용해서 테이블과 매핑할 클래스

속성	기능	기본값
name	JPA에서 사용할 엔티티 이름을 지정한다. 기본값은 클래스 이름이다. 만약 다른 패키지에 이름이 같은 엔티티 클래스가 있다면 출돌한다.	클래스이름 (예: Member)

주의사항

기본 생성자는 필수 (public 또는 protected)
final, enum, interface, inner 클래스에는 사용할 수 없다.
저장할 필드에 final을 사용하면 안된다.

4.2 @Table

엔티티와 매핑할 테이블을 지정. 생략하면 매핑한 엔티티 이름을 테이블 이름으로 사용한다.

속성	기능	기본값
name	매핑할 테이블 이름	엔티티 이름을 사용한다.
catalog	catalog 기능이 있는 데이터베이스에서 catalog를 매핑한다.
schema	schema 기능이 있는 데이터베이스에서 schema를 매핑한다.
uniqueConstraints	DDL 생성 시 유니크 제약조건을 만든다. 2개 이상의 복합 유니크 제약조건도 만들 수 있다. 이 기능은 스키마 자동 생성 기능을 사용해서 DDL을 만들 때만 사용된다.

4.3 다양한 매핑 사용

@Entity
@Table(name="MEMBER",
    uniqueConstraints = {@UniqueConstraint(
        name = "NAME_AGE_UNIQUE",
        columnNames = {"NAME", "AGE"} 
    )}
)
public class Member {
    ...생략...

    // enum을 사용하려면 @Enumerated 어노테이션으로 매핑
    @Enumerated(EnumType.STRING)
    private RoleType roleType;

    // 자바의 날짜 타입은 @Temporal 어노테이션으로 매핑
    @Temporal(TemporalType.TIMESTAMP)
    private Date createdDate;

    // CLOB, BLOB타입은 @Lob 어노테이션으로 매핑
    @Lob
    private String description;

    ...생략...
}

4.4 데이터베이스 스키마 자동 생성

JPA는 데이터베이스 스키마를 자동으로 생성하는 기능을 지원한다.

<!-- 스키마 자동 생성 -->
<property name="hibernate.hbm2ddl.auto" value="create" />

<!-- 콘솔에 테이블 생성 DDL 출력 -->
<property name="hibernate.show_sql" value="true" />

hibernate.hbm2ddl.auto 속성

옵션	설명
create	기존 테이블을 삭제하고 새로 생성한다. DROP + CREATE
create-drop	create 속성에 추가로 애플리케이션을 종료할 때 생성한 DDL을 제거한다. DROP + CREATE + DROP
update	데이터베이스 테이블과 엔티티 매핑정보를 비교해서 변경 사항만 수정한다.
validate	데이터베이스 테이블과 엔티티 매핑정보를 비교해서 차이가 있으면 경고를 남기고 애플리케이션을 실행하지 않는다.
none	자동 생성 기능을 사용하지 않으려면 hibernate.hbm2ddl.auto 속성 자체를 삭제하거나 유효하지 않은 옵션 값을 주면 된다.

hibernate.hbm2ddl.auto 주의사항
운영 서버에서는 DDL을 수정하는 옵션은 절대 사용하면 안된다.

개발 초기 단계: create, update
초기화 상태로 테스트, CI서버: create, create-drop
테스트 서버: update, validate
스테이징, 운영 서버: validate, none

기본 이름 매핑 전략 변경하기
테이블 명이나 컬럼 명이 생략되면 자바의 카멜 표기법을 데이터베이스 테이블의 언더스코어 표기법으로 매핑한다.

<property name="hibernate.ejb.naming_strategy" value="org.hibernate.cfg.ImprovedNamingStrategy" />

4.5 DDL 생성 기능

제약 조건 추가
스키마 자동 생성하기를 통해 DDL에 제약조건을 추가할 수 있다. 다만 DDL을 자동 생성할 때만 사용되고 JPA의 실행 로직에는 영향을 주지 않는다.

@Entity
@Table(name="MEMBER", 
    /** 
     *  유니크 제약조건 추가
     *  ALET TABLE MEMBER
     *      ADD CONSTRAINT NAME_AGE_UNIQUE UNIQUE (NAME, AGE)
     */
    uniqueConstraints = {@UniqueConstraint(
        name = "NAME_AGE_UNIQUE",
        columnNames = {"NAME", "AGE"} 
    )}
)
public class Member {
    ...생략...

    // 컬럼명 NAME, not null, 문자크기 10
    @Column(name = "NAME", nullable = false, length = 10)
    private String username;

    ...생략...
}

4.6 DDL 생성 기능

JPA가 제공하는 데이터베이스 기본 키 생성 전략은 다음과 같다.

직접 할당: 애플리케이션에서 직접 할당
자동 생성: 대리 키 사용 방식
- IDENTITY: 기본 키 생성을 데이터베이스에 위임
- SEQUENCE: 데이터베이스 시퀀스를 사용
- TABLE: 키 생성 테이블을 사용

자동 생성 전략이 다양한 이유는 데이터베이스 벤더마다 지원하는 방식이 다르기 때문이다. 키 생성 전략을 사용하려면 다음 속성을 추가한다.

<property name="hibernate.id.new_generator_mappings" value="true" />

4.6.1 기본 키 직접 할당 전략

@Id
@Column(name = "ID")
private String id;

Board board = new Board();
board.setId("id"); // 기본 키 직접 할당
em.persist(board);

4.6.2 IDENTITY 전략

IDENTITY는 기본 키 생성을 데이터베이스에 위임하는 전략이다.
IDENTITY 식별자 생성 전략은 엔티티를 데이터베이스에 저장해야 식별자를 구할 수 있다.
em.persist()를 호출하는 즉시 INSERT SQL이 데이터베이스에 전달된다.
따라서 트랜잭션을 지원하는 쓰기 지연이 동작하지 않는다.

@Id
@GeneratedValue(strategy = GenerationType.IDENTITY)
private Long id;

Board board = new Board();
em.persist(board);
board.getId(); // 1

참고
IDENTITY 전략은 데이터를 데이터베이스에 INSERT한 후에 기본 키값을 조회할 수있다. 따라서 엔티티에 식별자 값을 할당하려면 JPA는 추가로 데이터베이스를 조회해야 한다. 하지만 하이버네이트는 JDBC3에 추가된 Statement.getGeneratedKeys() 메소드를 사용해서 데이터베이스와 한번만 통신한다.

4.6.3 SEQUENCE 전략

SEQUENCE 전략은 데이터베이스 시퀀스를 이용해 기본 키를 생성한다.

-- 데이터베이스 시퀀스 생성
CREATE SEQUENCE BOARD_SEQ START WITH 1 INCREMENT BY 1;

@Entity
@SequenceGenerator(
    name = "BOARD_SEQ_GENERATOR",
    sequenceName = "BOARD_SEQ", // 매핑할 데이터베이스 시퀀스 이름
    initialValue = 1,
    allocationsSize = 1
)
public class BOARD {

    @Id
    @GeneratedValue(
        strategy = GenerationType.SEQUENCE,
        generator = "BOARD_SEQ_GENERATOR"
    )
    private Long id;
}

@SequenceGenerator

속성	기능	기본값
name	식별자 생성기 이름	필수
sequenceName	데이터베이스에 등록되어 있는 시퀀스 이름	hibernate_sequence
initialValue	DDL 생성 시에만 사용됨. 시퀀스 DDL을 생성할 때 처음 시작하는 수를 지정한다.	1
allocationsSize	시퀀스 한 번 호출에 증가하는 수 (성능 최적화에 사용됨)	50
catalog, schema	데이터베이스 catalog, schema 이름

SEQUENCE 전략과 최적화
SEQUENCE 전략은 데이터베이스와 2번 통신한다.

식별자 구하기 (SELECT BOARD_SEQ.NEXTVAL FROM DUAL)
조회한 시퀀스를 기본 키 값으로 사용해 데이터베이스에 저장 (INSERT INTO BOARD …)

JPA는 시퀀스 접근하는 횟수를 줄이기 위해 @SequenceGenerator.allocationsSize를 사용한다. 여기에 설정한 값만큼 한 번에 시퀀스 값을 증가시키고, 그만큼 메모리에 시퀀스 값을 할당한다. 이 방법은 시퀀스 값을 선점하므로 여러 JVM이 동시에 동작해도 기본 키 값이 충돌하지 않는다. 반면에 시퀀스 값을 한 번에 많이 증가시킨다. 이런 상황이 부담스럽고 INSERT 성능이 중요하지 않으면 allocationsSize값을 1로 설정한다.

4.6.4 TABLE 전략

TABLE 전략은 키 생성 전용 테이블을 하나 만들고 여기에 이름과 값으로 사용할 컬럼을 만들어 데이터베이스 시퀀스를 흉내내는 전략이다.

-- 데이터베이스 키 생성 용도 테이블 생성
create table MY_SEQUENCES (
    sequence_name varchar(255) not null,
    next_val bigint,
    primary key (sequence_name)
)

@Entity
@TableGenerator(
    name = "BOARD_SEQ_GENERATOR",
    table = "MY_SEQUENCES",
    pkColumnValue = "BOARD_SEQ",
    allocationsSize = 1
)
public class BOARD {

    @Id
    @GeneratedValue(
        strategy = GenerationType.TABLE,
        generator = "BOARD_SEQ_GENERATOR"
    )
    private Long id;
}

@TableGenerator

속성	기능	기본값
name	식별자 생성기 이름	필수
table	키생성 테이블명	hibernate_sequences
pkColumnName	시퀀스 컬럼명	sequence_name
valueColumnName	시퀀스 값 컬럼명	next_val
pkColumnValue	키로 사용할 값 이름	엔티티 이름
initialValue	초기 값, 마지막으로 생성된 값이 기준이다.	0
allocationsSize	시퀀스 한 번 호출에 증가하는 수 (성능 최적화에 사용됨)	50
catalog, schema	데이터베이스 catalog, schema 이름
uniqueConstraints(DDL)	유니크 제약 조건을 지정할 수 있다.

TABLE 전략과 최적화
TABLE 전략은 값을 조회하면서 SELECT 쿼리를 사용하고, 다음 값으로 증가시키기 위해 UPDATE 쿼리를 사용한다. SEQUENCE 전략과 비교해서 데이터베이스와 한 번 더 통신하는 단점이 있다.

4.6.5 AUTO 전략

데이터베이스의 방언에 따라 IDENTITY, SEQUENCE, TABLE 전략 중 하나를 자동으로 선택한다. @GeneratedValue.strategy의 기본값은 AUTO다.

@Id @GeneratedValue
private Long id;

4.6.6 기본 키 매핑 정리

직접 할당: 애플리케이션에서 직접 식별자 값을 할당
SEQUENCE: 데이터베이스 시퀀스에서 식별자 값을 획득 후 영속성 컨텍스트에 저장
TABLE: 데이터베이스 시퀀스 생성용 테이블에서 식별자 값을 획등 후 영속성 컨텍스트에 저장
IDENTITY: 데이터베이스에 엔티티를 저장해서 식별자 값을 획득한 후 영속성 컨텍스트에 저장

식별자 선택 전략
테이블의 기본 키를 선택하는 전략은 크게 2가지가 있다.

자연 키(natural key)
- 비즈니스에 의미가 있는 키
- 예) 주민등록번호, 이메일, 전화번호
대리 키(surrogate key)
- 비즈니스와 관련이 없는 임의로 만들어진 키, 대체 키로도 불린다
- 예) 오라클 시퀀스, auto_increment, 키 생성 테이블 사용

권장하는 식별자 선택 전략
자연 키보다는 대리 키를 권장한다.

자연 키는 변경될 수 있다.
비즈니스 환경은 언젠가 변한다.
테이블은 한 번 정의하면 변경하기 어렵다.

4.7 필드와 컬럼 매핑: 레퍼런스

분류	매핑 어노테이션	설명
필드와 컬럼 매핑	@Column	컬럼을 매핑한다.
	@Enumerated	자바의 enum 타입을 매핑한다.
	@Temporal	날짜 타입을 매핑한다.
	@Lob	BLOB, CLOB 타입을 매핑한다.
	@Transient	특정 필드를 데이터베이스에 매핑하지 않는다.
기타	@Access	JPA가 엔티티에 접근하는 방식을 지정한다.

4.7.1 @Column

@Column은 객체 필드를 테이블 컬럼에 매핑한다.

속성	기능	기본값
name	필드와 매핑할 테이블의 컬럼 이름	객체의 필드 이름
insertable (거의 사용하지 않음)	엔티티 저장 시 이 필드도 같이 저장한다. false로 설정하면 이 필드는 데이터베이스에 저장하지 않는다.	true
updatable (거의 사용하지 않음)	엔티티 수정 시 이 필드도 같이 수정한다. false로 설정하면 이 필드는 데이터베이스에 수정하지 않는다.	true
table (거의 사용하지 않음)	하나의 엔티티를 두 개 이상의 테이블에 매핑할 때 사용한다. 지정한 필드를 다른 테이블에 매핑할 수 있다.	현재 클래스가 매핑된 테이블
nullable (DDL)	null 값의 허용 여부 설정.	true
unique (DDL)	@Table의 uniqueConstraints와 같지만 한 컬럼에 간단히 유니크 제약조건을 걸 때 사용한다. 만약 두 컬럼 이상을 사용해서 유니크 제약조건을 사용하려면 @Table.uniqueConstraints를 사용해야 한다.
length (DDL)	문자 길이 제약조건, String 타입에만 사용한다.	255
precision, scale (DDL)	BigDecimal 타입에서 사용한다. precision은 소수점을 포함한 전체 자릿수, scale은 소수의 자릿수다. double, float타입에는 적용되지 않는다.	precision = 19, scale=2
columnDefinition	데이터베이스 컬럼 정보를 직접 줄 수 있다.	필드의 자바 타입과 방언 정보를 사용해서 적절한 컬럼 타입을 생성한다.

4.7.2 @Enumerated

자바의 enum 타입을 매핑할 때 사용한다.

속성	기능	기본값
value	EnumType.ORDINAL: enum 순서를 데이터베이스에 저장 EnumType.STRING: enum 이름을 데이터베이스에 저장	EnumType.ORDINAL

4.7.3 @Temporal

날짜 타입(java.util.Date, java.util.Calendar)을 매핑할 때 사용한다.

속성	기능	기본값
value	- TemporalType.DATE: 날짜, 데이터베이스 date 타입과 매핑 (예: 2013-10-11) - TemporalType.TIME: 시간, 데이터베이스 time 타입과 매핑 (예: 11:11:11) - TemporalType.TIMESTAMP: 날짜와 시간, 데이터베이스 timestamp 타입과 매핑 (예: 2013-10-11 11:11:11)	TemporalType은 필수 지정

4.7.4 @Lob

데이터베이스 BLOB, CLOB 타입과 매핑한다. 매핑하는 필드 타입에 따라 매핑을 달리한다.

CLOB: String, char[], java.sql.CLOB
BLOB: byte[], java.sql.BLOB

4.7.5 @Transient

이 필드는 매핑하지 않는다. 따라서 데이터베이스에 저장하지 않고 조회하지 않는다.

4.7.6 @Access

JPA가 엔티티 데이터에 접근하는 방식을 지정한다.

AccessType.FIELD: 필드 접근
AccessType.PROPERTY: 프로퍼티 접근, 접근자(Getter) 사용

@Entity
@Access(AccessType.FIELD)
public class Member {...}

@Entity
@Access(AccessType.PROPERTY)
public class Member {...}

/**
 * 두 접근 방식을 함께 사용할 수도 있다.
 *
 * @Id는 필드 접근 방식
 * getFullName()는 프로퍼티 접근 방식
 * Member 엔티티를 저장하면 테이블의 FULLNAME 컬럼에
 * firstName + lastName의 결과가 저장된다.
 */
@Entity
public class Member {
    
    @Id
    private String id;

    @Transient
    private String firstName;

    @Transient
    private String lastName;

    @Access(AccessType.PROPERTY)
    public String getFullName() {
        return firstName + lastName;
    }
    ...
}

5. 연관관계 매핑 기초

연관관계 매핑 키워드 정리

방향(Direction): [단방향, 양방향]이 있다. 방향은 객체관계에서만 존재하고 테이블 관계는 항상 양방향이다.
다중성(Multiplcity): [다대일(N:1), 일대다(1:N), 일대일(1:1), 다대다(N:M)] 다중성이 있다.
연관관계 주인(Owner): 객체를 양방향 연관관계로 만들면 연관관계 주인을 정해야 한다.

5.1 단방향 연관관계

객체 연관관계와 테이블 연관관계의 차이

객체
- 참조(주소)로 연관관계를 맺는다.
- 언제나 단방향
- 양방향을 하려면 서로다른 단방향 관계 2개로 구현
테이블
- 외래 키로 연관관계를 맺는다.
- 외래 키 하나로 양방향 조인 가능

5.1.1 순수한 객체 연관관계

객체 참조를 사용해서 연관관계를 탐색할 수 있는데 이것을 객체 그래프 탐색이라 한다.

public static void main(String[] args) {
    Member member1 = new Memeber("member1", "회원1");
    Member member2 = new Memeber("member2", "회원1");
    Team team = new Team("team", "팀");

    member1.setTeam(team);
    member2.setTeam(team);

    // 객체 그래프 탐색
    Team findTeam = member1.getTeam();
}

5.1.2 테이블 연관관계

외래 키를 사용해서 연관관계를 탐색할 수 잇는데 이것을 조인이라 한다.

SELECT T.*
FROM MEMBER M
    JOIN TEAM T ON M.TEAM_ID = T.ID
WHERE M.MEMBER_ID = 'member1'

5.1.3 객체 관계 매핑

@Entity
public class Member {

    @Id
    @Column(name = "MEMBER_ID")
    private Long id;

    private String username;

    //연관 관계 매핑
    @ManyToOne
    @JoinColumn(name="TEAM_ID")
    private Team team;

    //연관관계 설정
    public void setTeam(Team team) {
        this.team = team;
    }
    ...생략...
}

@Entity
public class Team {
    
    @Id
    @Column(name = "TEAM_ID")
    private String id;
    ...생략...
}

@ManyToOne

다대일(N:1) 관계라는 매핑 정보
연관관계 매핑할 때 다중성을 나타내는 어노테이션 필수로 사용해야 한다.

@JoinColumn(name=”TEAM_ID”)

조인컬럼은 외래 키를 매핑할 때 사용한다.
name 속성에 매핑할 외래 키 이름을 지정한다. (여기선 팀 테이블의 TEAM_ID)
생략할 수 있다.

5.1.4 @JoinColumn

@JoinColumn은 외래 키를 매핑할 때 사용한다.

속성	기능	기본값
name	매핑할 외래 키 이름	필드명 + _ + 참조하는 테이블의 컬러명
referencedColumnName	외래 키가 참조하는 대상 테이블의 컬럼명	참조하는 테이블의 기본 키 컬럼명
foreignKey (DDL)	외래 키 제약조건을 직접 지정할 수 있다. 이 속성은 테이블을 생성할 때만 사용한다.
unique, nullable, insertable, updatable, columnDefinition, table	@Column의 속성과 같다.

5.1.5 @ManyToOne

@ManyToOne 어노테이션은 다대일 관계에서 사용한다.

속성	기능	기본값
optional	false로 설정하면 연관된 엔티티가 항상 있어야 한다.	true
fetch	글로벌 페치 전략을 설정한다.	@ManyToOne=FetchType.EAGER @OneToMany=FetchType.LAZY
cascade	영속성 전이 기능을 사용한다.
targetEntity (거의 사용하지 않음)	연관된 엔티티의 타입 정보를 설정한다. 이 기능을 사용하지 않고 컬렉션을 사용해도 제네릭으로 타입 정보를 알 수 있다.

5.2 연관관계 사용

연관관계를 등록, 수정, 삭제, 조회하는 예제를 통해 연관관계를 어떻게 사용하는지 알아본다.

5.2.1 저장

JPA에서 엔티티를 저장할때 연관된 모든 엔티티는 영속 상태여야 한다.

public void testSave() {

    // 팀1 저장
    Team team1 = new Team("team1", "팀1");
    em.persist(team1);

    // 회원1 저장
    Member member1 = new Member("member1", "회원1");
    member1.setTeam(team1); //연관관계 설정 member1 -> team1
    em.persist(member1);

    // 회원2 저장
    Member member2 = new Member("member2", "회원2");
    member2.setTeam(team1); //연관관계 설정 member2 -> team1
    em.persist(member2);
}

5.2.2 조회

연관관계가 있는 엔티티 조회 방법은 크게 2가지다.

객체 그래프 탐색(객체 연관관계를 사용한 조회)
객체지향 쿼리 사용(JPQL)

객체 그래프 탐색

Member member = em.find(Member.class, "member1");
Team team = member.getTeam(); // 객체 그래프 탐색
System.out.println("팀 이름 = " + team.getName());

객체 지향 쿼리 사용

public static void testJPQL(EntityManager em) {
    String jpql1 = "select m from Member m join m.team t where t.name=:teamName";

    List<Member> resultList = em.createQuery(jpql1, Member.class)
        .setParameter("teamName", "팀1")
        .getResultList();

    for (Member member : resultList) {
        System.out.println("[query] member.username = " + member.getUsername());
    }
}

/*
* 결과
* [query] member.username=회원1
* [query] member.username=회원2
*/

실행되는 SQL은 다음과 같다.

SELECT M.* FROM MEMBER MEMBER 
INNER JOIN 
    TEAM TEAM ON MEMBER.TEAM_ID = TEAM1_.ID 
WHERE
    TEAM1_.NAME='팀1'

실행된 SQL과 JPQL을 비교하면 JPQL은 객체(엔티티)를 대상으로 하고 SQL보다 간결하다.

5.2.3 수정

private static void updateRelation(EntityManager em) {

    // 새로운 팀2
    Team team2 = new Team("team2", "팀2");
    em.persist(team2);

    //회원1에 새로운 팀2 설정
    Member member = em.find(Member.class, "member1");
    member.setTeam(team2);
}

실행되는 수정 SQL은 다음과 같다.

UPDATE MEMBER
SET
    TEAM_ID='team2', ...
WHERE ID = 'member1' 

5.2.4 연관관계 제거

private static void deleteRelation(EntityManager em) {

    Member member1 = em.find(Member.class, "member1");
    member1.setTeam(null); //연관관계 제거
}

실행되는 연관관계 제거 SQL은 다음과 같다.

UPDATE MEMBER
SET
    TEAM_ID=null, ...
WHERE ID = 'member1' 

5.2.5 연관관계 삭제

연관된 엔티티를 삭제하려면 기존에 있던 연관관계를 먼저 제거하고 삭제해야 한다. 그렇지 않으면 외래 키 제약조건으로 인해, 데이터베이스에서 오류가 발생한다.

member1.setTeam(null); // 회원1 연관관계 제거
member2.setTeam(null); // 회원2 연관관계 제거
em.remove(team);       // 팀 삭제

5.3 양방향 연관관계

객체

회원과 팀은 다대일 관계
팀에서 회원의 관계는 일대다 관계

데이터베이스 테이블

데이터베이스 테이블은 외래 키 하나로 양방향 조회

5.3.1 양방항 연관관계 매핑

@Entity
public class Member {
    ...생략...

    // 연관 관계 매핑
    @ManyToOne
    @JoinColumn(name="TEAM_ID")
    private Team team;

    ...생략...
}

@Entity
public class Team {
    ...생략...

    // @OneToMany 매핑 정보를 사용했다.
    // mappedBy 속성은 양방향 매핑일 때 사용하는데 반대쪽 매핑의 필드 이름을 값으로 주면 된다.
    @OneToMany(mappedBy = "team")
    private List<Member> members = new ArrayList<Member>();
    
    ...생략...  
}

5.4 연관관계 주인

객체에는 양방향 연관관계라는 것이 없다.
서로 다른 단방향 연관관계 2개를 양방향인 것처럼 보이게 할 뿐이다.
엔티티를 양방향 연관관계로 설정하면 객체의 참조는 둘인데 왜래 키는 하나다.
JPA에서는 두 객체 연관관계 중 하나를 정해서 테이블의 외래 키를 관리해야 하는데 이것을 연관관계의 주인이라 한다.

5.4.1 양방향 매핑의 규칙: 연관관계의 주인

두 연관관계 중 하나를 연관관계 주인으로 정해야 한다.
연관관계의 주인만이 데이터베이스 연관관계와 매핑되고 왜래 키를 관리(등록,수정,삭제)할 수 있다.
주인이 아닌 쪽은 읽기만 할 수 있다.

mappedBy

주인은 mappedBy 속성을 사용하지 않는다.
주인이 아니면 mappedBy 속성을 사용해서 속성의 값으로 연관관계 주인을 지정한다. (‘내가 상대에게 매핑되었다’라고 생각하면 편함)
연관관계 주인을 정한다는 것은 외래 키 관리자를 선택하는 것이다.

5.4.2 연관관계의 주인은 외래 키가 있는 곳

연관관계의 주인은 테이블에 외래 키가 있는 곳으로 정해야 한다.
다대일, 일대다 관계에서는 항상 다 쪽이 외래 키를 가진다.
다 쪽인 @ManyToOne은 항상 연관관계의 주인이 되므로 mappedBy를 설정할 수 없다.
따라서 @ManyToOne에는 mappedBy 속성이 없다.

5.5 양방향 연관관계 저장

public void testSave() {

    // 팀1 저장
    Team team1 = new Team("team1", "팀1");
    em.persist(team1);

    // 회원1 저장
    Member member1 = new Member("member1", "회원1");
    member1.setTeam(team1); //연관관계 설정 member1 -> team1
    em.persist(member1);

    // 회원2 저장
    Member member2 = new Member("member2", "회원2");
    member2.setTeam(team1); //연관관계 설정 member2 -> team1
    em.persist(member2);
}

// 주인이 아닌 곳에 입력된 값은 외래 키에 영향을 주지 않는다. 
team1.getMembers().add(member1); //무시(연관관계의 주인이 아님)
team1.getMembers().add(member2); //무시(연관관계의 주인이 아님)

// Member.team은 연관관계의 주인이다.
// 엔티티 매니저는 이곳에 입력된 값을 사용해 외래 키 관리한다.
member1.setTeam(team1); //연관관계 설정(연관관계의 주인)
member2.setTeam(team1); //연관관계 설정(연관관계의 주인)

5.6 양방향 연관관계의 주의점

가장 흔한 실수는 연관관계 주인에는 값을 입력하지 않고, 주인이 아닌 곳에만 값을 입력하는 것이다.

public void testSaveNonOwner() {

    // 회원1 저장
    Member member1 = new Member("member1", "회원1");
    em.persist(member1);

    // 회원2 저장
    Member member2 = new Member("member2", "회원2");
    em.persist(member2);

    Team team1 = new Team("team1", "팀1");

    // 주인이 아닌 곳에 연관관계 설정
    team1.getMembers().add(member1);
    team2.getMembers().add(member2);

    em.persist(team1);
}

조회 결과는 다음과 같다.

MEMBER_ID	USERNAME	TEAM_ID
member1	회원1	null
member2	회원2	null

5.6.1 순수한 객체까지 고려한 양방향 연관관계

그렇다면 정말 연관관계의 주인에만 값을 저장하고 주인이 아닌 곳에는 값을 저장하지 않아도 될까? 객체 관점에서는 양쪽 방향 모두 값을 입력해주는 것이 가장 안전하다.

member1.setTeam(team1); // 회원 -> 팀
team1.getMembers().add(member1); // 팀 -> 회원

5.6.2 연관관계 편의 메소드

한 번에 양방향 관계를 설정하는 메소드를 연관관계 편의 메소드라 한다. 이렇게 하면 실수도 줄어들고 좀 더 편하게 양방향 연관관계를 설정할 수 있다.

public class Member {

    private Team team;

    public void setTeam(Team team) {
        this.team = team;
        team.getMembers().add(this);
    }
}

5.6.3 연관관계 편의 메소드 작성 시 주의사항

연관관계를 변경할 때는 기존 팀이 있으면 기존 팀과 회원의 연관관계를 삭제하는 코드를 추가해야 한다.

member1.setTeam(teamA); // 1
member1.setTeam(teamB); // 2
Member findMember = teamA.getMember(); // member1이 여전히 조회된다.

public void setTeam(Team team) {

    // 기존 팀과 관계를 제거
    if (this.team != null) {
        this.team.getMembers().remove(this);
    }    
    this.team = team;
    team.getMembers().add(this);
}

5.7 정리

단방향 매핑은 언제나 연관관계 주인이다.
양방향은 단방향에 주인이 아닌 연관관계를 하나 추가했을 뿐이다.
양방향의 장점은 반대방향으로 객체 그래프 탐색 기능이 추가된 것 뿐이다.
주인의 반대편은 mappedBy로 주인을 지정해야 한다.
주인의 반대편은 단순히 보여주는 일만 할 수 있다.
연관관계 주인은 외래 키의 위치와 관련해서 정해야지 비즈니스 중요도로 접근하면 안된다.

6. 다양한 연관관계 매핑

엔티티 연관관계를 매핑할 때 고려사항

다중성
- 다대일(@ManyToOne)
- 일대다(@OneToMany)
- 일대일(@OneToOne)
- 다대다(@ManyToMany)
단방향, 양방향
- 단방향: 한쪽만 참조하는 것
- 양방향: 양쪽이 서로 참조하는 것
연관관계 주인

6.1 다대일

데이터베이스 테이블의 일대다 관계에서 외래 키는 항상 다쪽에 있다. 따라서 객체 양방향 관계에서 연관관계의 주인은 항상 다쪽이다.

6.1.1 다대일 단방향 [N:1]

@ManyToOne 어노테이션을 사용해서 다대일 관계를 매핑한다.
@JoinColumn은 필드를 외래 키와 매핑할 때 사용한다.

public class Member {
    ...생략...
    @ManyToOne
    @JoinCoulmn(name="TEAM_ID")
    private Team team;
    ...생략...
}

6.1.2 다대일 양방향 [N:1, 1:N]

public class Member {
    ...생략...
    @ManyToOne
    @JoinCoulmn(name="TEAM_ID")
    private Team team;

    public void setTeam(Team team) {
        this.team = team;

        // 무한루프에 빠지지 않도록 체크
        if(!team.getMembers().contains(this)) {
            team.getMembers().add(this);
        }
    }
    ...생략...
}

public class Team {
    ...생략...
    @OneToMany(mappedBy = "team")
    private List<Member> members = new ArrayList<>();

    public void addMember(Member member) {
        this.members.add(member);

        // 무한루프에 빠지지 않도록 체크
        if (member.getTeam() != this) {
            member.setTeam(this);
        }
    }
    ...생략...
}

양방향은 외래 키가 있는 쪽이 연관관계 주인이다.
양방향 연관관계는 항상 서로를 참조해야 한다.

6.2 일대다

일대다 관계는 엔티티를 하나 이상 참조할 수 있으므로 자바 컬렉션인 Collection, List, Set, Map 중에 하나를 사용해야 한다.

6.2.1 일대다 단방향 [1:N]

public class Team {
    ...생략...
    @OneToMany
    @JoinColumn(name = "TEAM_ID") // MEMBER 테이블의 TEAM_ID (FK)
    private List<Member> members = new ArrayList<>();
    ...생략...
}

일대다 관계에서는 일이 연관관계의 주인이다.
일 쪽에서 외래키를 관리하겠다는 의미가 된다.
일대 다 단방향 관계를 매핑할 때는 @JoinColumn을 명시해야 한다.
그렇지 않으면 JPA는 연결 테이블을 중간에 두고 연관관계를 관리하는 조인 테이블 전략을 기본으로 사용한다.

일대다 문제점

엔티티를 매핑한 테이블이 아닌 다을 테이블의 외래 키를 관리해야 한다.
성능 문제

Member member1 = new Memeber("member1");
Member member2 = new Memeber("member2");

Team team1 = new Team("team1");
team1.getMembers().add(member1);
team1.getMembers().add(member2);

em.persist(member1); // INSERT MEMBER1
em.persist(member2); // INSERT MEMBER2
em.persist(team1); // INSERT TEAM, UPDATE MEMBER1, UPDATE MEMBER2

tx.commit();

-- 업데이트 쿼리가 추가된다.
insert into Member (MEMBER_ID, username) values (null, ?);
insert into Team (TEAM_ID, name) values (null, ?);
update Member set TEAM_ID=? where MEMBER_ID=?

일대다 단방향 매핑보다는 다대일 양방향 매핑을 사용하자

6.2.2 일대다 양방향 [1:N, N:1]

public class Team {
    ...생략...
    @OneToMany
    @JoinColumn(name = "TEAM_ID")
    private List<Member> members = new ArrayList<>();
    ...생략...
}

public class Member {
    ...생략...
    @ManyToOne
    @JoinCoulmn(name = "TEAM_ID",
        insertable = false, updatable = false) // 읽기 전용 매핑
    private Team team;
    ...생략...
}

일대다 단방향 매핑이 가지는 단점을 그대로 가진다.

6.3 일대일 [1:1]

일대일 관계 특징

일대일 관계는 그 반대도 일대일 관계다.
테이블 관계에서 일대다, 다대일은 항상 다(N)쪽이 외래 키를 가진다. 반면 일대일 관계는 주 테이블이나 대상 테이블 둘 중 어느 곳이나 외래 키를 가질 수 있다.

6.3.1 주 테이블에 외래 키

주 테이블에 외래 키가 있는 단방향 관계를 먼저 살펴보고, 양방향 관계도 살펴 보자.

단방향

@Entity
public class Member {

    @Id @GeneratedValue
    @Column(name = "MEMBER_ID")
    private Long id;

    // @OneToOne을 사용해 일대일 매핑한다.
    @OneToOne
    @JoinColumn(name = "LOCKER_ID")
    private Locker locker;
    ...생략...
}

@Entity
public class Locker {
    @Id @GeneratedValue
    @Column(name = "LOCKER_ID")
    private Long id;

    ...생략...
}

양방향

@Entity
public class Member {

    @Id @GeneratedValue
    @Column(name = "MEMBER_ID")
    private Long id;

    @OneToOne
    @JoinColumn(name = "LOCKER_ID")
    private Locker locker;
    ...생략...
}

@Entity
public class Locker {
    @Id @GeneratedValue
    @Column(name = "LOCKER_ID")
    private Long id;

    @OneToOne(mappedBy = "locker") // 연관관계 주인 필드명을 선언
    private Member member;

    ...생략...
}

6.3.2 대상 테이블에 외래 키

대상 테이블에 외래 키가 있는 일대일 관계를 알아본다.

단방향

일대일 단방향은 이런 매핑을 허용하지 않는다.

양방향

@Entity
public class Member {

    @Id @GeneratedValue
    @Column(name = "MEMBER_ID")
    private Long id;

    @OneToOne(mappedBy = "member")
    private Locker locker;
    ...생략...
}

@Entity
public class Locker {
    @Id @GeneratedValue
    @Column(name = "LOCKER_ID")
    private Long id;

    @OneToOne
    @JoinColumn(name = "MEMBER_ID")
    private Member member;

    ...생략...
}

일대일 매핑에서 대상 테이블에 외래 키를 두고 싶으면 이렇게 양방향으로 매핑한다.

6.4 다대다 [N:N]

테이블 2개로는 다대다 관계를 표현할 수 없다.

중간에 연결 테이블을 추가해야 한다.

6.4.1 다대다: 단방향

@Entity
public class Member {

    @Id @GeneratedValue
    @Column(name = "MEMBER_ID")
    private Long id;

    @ManyToMany
    @JoinTable(
        name = "MEMBER_PRODUCT", // 연결 테이블 지정
        joinColumn = @JoinColumn(name = "MEMBER_ID"), // 현재 엔티티와 매핑할 연결 테이블의 조인 컬럼
        inverseJoinColumns = @JoinColumn(name = "PRODUCT_ID") // 상대 엔티티와 매핑할 연결 테이블의 조인 컬럼
    )
    private List<Product> products = new ArrayList<Product>();
    ...생략...
}

@Entity
public class Product {
    @Id @Column(name = "PRODUCT_ID")
    private Long id;
    ...생략...
}

6.4.2 다대다: 양방향

@Entity
public class Member {

    @Id @GeneratedValue
    @Column(name = "MEMBER_ID")
    private Long id;

    @ManyToMany
    @JoinTable(
        name = "MEMBER_PRODUCT", // 연결 테이블 지정
        joinColumn = @JoinColumn(name = "MEMBER_ID"), // 현재 엔티티와 매핑할 연결 테이블의 조인 컬럼
        inverseJoinColumns = @JoinColumn(name = "PRODUCT_ID") // 상대 엔티티와 매핑할 연결 테이블의 조인 컬럼
    )
    private List<Product> products = new ArrayList<Product>();
    ...생략...
}

@Entity
public class Product {
    @Id @Column(name = "PRODUCT_ID")
    private Long id;

    @ManyToMany(mappedBy = "products") // 역방향 추가
    private List<Member> members;
    ...생략...
}

6.4.3 다대다: 매핑의 한계와 극복, 연결 엔티티 사용

연결테이블의 기본 키를 @IdClass 사용한 복합 키 사용 예제라서 넘김.

6.4.4 다대다: 새로운 기본 키 사용

@ManyToMany는 편리하지만, 실무에서 사용하기에는 한계가 있다.
보통은 연결 테이블에 새로운 컬럼이 추가되기 마련이다.
결국 연결 테이블을 매핑하는 연결 엔티티를 만들고 일대다, 다대일 관계로 풀어야 한다.

@Entity
public class Member {

    @Id @GeneratedValue
    @Column(name = "MEMBER_ID")
    private Long id;

    @OneToMany(mappedBy = "member")
    private List<MemberProduct> memberProducts;
    ...생략...
}

@Entity
public class Product {
    @Id @Column(name = "PRODUCT_ID")
    private Long id;

    // 상품 엔티티에서 회원상품 엔티티로 객체 그래프 탐색 기능이 필요 없다 판단.
    // 연관관계를 만들지 않았다.
    // @OneToMany(mappedBy = "product")
    // private List<MemberProduct> memberProducts = new ArrayList<>();
}

@Entity
public class MemberProduct {

    @Id @GeneratedValue
    private Long id;

    @ManyToOne
    @JoinColumn(name = "MEMBER_ID")
    private Member member;

    @ManyToOne
    @JoinColumn(name = "PRODUCT_ID")
    private Product product;
}

6.4.5 다대다 연관관계 정리

다대다 관계를 일대다, 다대일 관계로 풀어낸다.
연결 테이블을 만들 때 식별자를 어떻게 구성할지 선택한다.
- 식별 관계: 받아온 식별자를 기본 키 + 외래 키로 사용한다.
- 비식별 관계: 받아온 식별자는 외래 키로만 사용하고 새로운 식별자를 추가한다. 추천 👍

7. 고급 매핑

다룰 내용은 다음과 같다.

상속 관계 매핑: 객체의 상속 관계를 데이터베이스에 어떻게 매핑하는지
@MappedSuperclass: 등록일, 수정일 같이 여러 엔티티에서 공통으로 사용하는 매핑 정보만 상속받고 싶을 때
복합 키와 식별 관계 매핑: 데이터베이스의 식별자가 하나 이상일 때 매핑하는 방법
조인 테이블: 연결 테이블을 매핑하는 방법
엔티티 하나에 여러 테이블 매핑하는 방법

7.1 상속 관계 매핑

슈퍼타입 서브타입 논리 모델을 테이블로 구현하는 3가지 방법

각각의 테이블로 변환: JPA에서는 조인 전략이라 한다.
통합 테이블로 변환: JPA에서는 단일 테이블 전략이라 한다.
서브타입 테이블로 변환: JPA에서는 구현 클래스마다 테이블 전략이라 한다.

7.1.1 조인 전략

엔티티 각각을 모두 테이블로 만들고 자식 테이블이 부모 테이블의 기본 키를 받아서 기본 키 + 외래 키로 사용하는 전략

@Entity
@Inheritance(strategy = InheritanceType.JOIN) // 부모 클래스에 상속 매핑, 전략 지정
@DiscriminatorColumn(name = "DTYPE") // 부모 클래스에 구분 컬럼 지정
public abstract class Item {

    @Id @GeneratedValue
    @Column(name = "ITEM_ID")
    private Long id;

    private String name; //이름
    private int price;   //가격
}

@Entity
@DiscriminatorValue("A") // 엔티티를 저장할 때 구분 컬럼에 입력할 값을 지정
public class Album extends Item {

    private String artist;
}

@Entity
@DiscriminatorValue("M")
public class Movie extends Item {

    private String director;
    private String actor;
}

@Entity
@DiscriminatorValue("B")
@PrimaryKeyJoinColumn(name = "BOOK_ID") // 기본 키 컬럼명 변경, 기본값은 부모 테이블 ID 컬럼명
public class Book extends Item {

    private String author;
    private String isbn;
}

장점

테이블이 정규화된다.
외래 키 참조 무결성 제약조건을 활용할 수 있다.
저장공간을 효율적으로 사용한다.

단점

조회할 때 조인이 많이 사용되어 성능이 저하될 수 있다.
조회 쿼리가 복잡하다.
데이터를 등록할 때 INSERT SQL이 두 번 실행된다.

특징

@DiscriminatorColumn 없이도 동작할 수 있다.

관련 어노테이션

@PrimaryKeyJoinColumn, @DiscriminatorColumn, @DiscriminatorValue

7.1.2 단일 테이블 전략

@Entity
@Inheritance(strategy = InheritanceType.SINGLE_TABLE) // 부모 클래스에 상속 매핑, 전략 지정
@DiscriminatorColumn(name = "DTYPE") // 부모 클래스에 구분 컬럼 지정
public abstract class Item {

    @Id @GeneratedValue
    @Column(name = "ITEM_ID")
    private Long id;

    private String name;
    private int price;
}

@Entity
@DiscriminatorValue("A")
public class Album extends Item {...}

@Entity
@DiscriminatorValue("M")
public class Movie extends Item {...}

@Entity
@DiscriminatorValue("B")
public class Book extends Item {...}

장점

조인이 필요 없으므로 조회 성능이 빠르다.
조회 쿼리가 단순하다.

단점

자식 엔티티가 매핑한 컬럼은 모두 null을 허용해야 한다.
단일 테이블에 모든 것을 저장하므로 테이블이 커질 수 있다. 그러므로 상황에 따라서는 조회 성능이 오히려 느려질 수 있다.

특징

@DiscriminatorColumn을 꼭 설정해야 한다.
@DiscriminatorValue를 지정하지 않으면 기본으로 엔티티 이름을 사용한다.

7.1.3 구현 클래스마다 테이블 전략

@Entity
@Inheritance(strategy = InheritanceType.TABLE_PER_CLASS)
@DiscriminatorColumn(name = "DTYPE")
public abstract class Item {

    @Id @GeneratedValue
    @Column(name = "ITEM_ID")
    private Long id;

    private String name;
    private int price;
}

@Entity
@DiscriminatorValue("A")
public class Album extends Item {...}

@Entity
@DiscriminatorValue("M")
public class Movie extends Item {...}

@Entity
@DiscriminatorValue("B")
public class Book extends Item {...}

일반적으로 추천하지 않는 전략이다.

장점

서브 타입을 구분해서 처리할 때 효과적이다.
not null 제약 조건을 사용할 수 있다.

단점

여러 자식 테이블을 함께 조회할 때 성능이 느리다. (UNION을 사용해야 한다)
자식 테이블을 통합해서 쿼리하기 어렵다.

특징

구분 컬럼을 사용하지 않는다.

7.2 @MappedSuperclass

부모 클래스는 테이블과 매핑하지 않고 자식 클래스에게 매핑 정보만 제공하고 싶으면 @MappedSuperclass을 사용한다.

// 공통 매핑 정보 정의
@MappedSuperclass
public abstract class BaseEntity {

    @Id @GeneratedValue
    private Long id;
    private String name;
}

@Entity
public class Member extends BaseEntity {
    private String email;
}
@Entity
public class Seller extends BaseEntity {
    private String shopName;
}

연관관계를 재정의 하려면 @AssociationOverrides, @AssociationOverride 사용한다.
부모로부터 물려받은 매핑 정보를 재정의 하려면 @AttributeOverrides, @AttributeOverride 사용한다.

// 매핑 정보 재정의
// 부모에게 상속받은 id 속성의 컬럼명을 MEMBER_ID로 재정의
@Entity
@AttributeOverride(name = "id", column = @Column(name = "MEMBER_ID"))
public class Member extends BaseEntity {
    private String email;
}

// 둘 이상의 매핑 정보 재정의
@Entity
@AttributeOverrides({
    @AttributeOverride(name = "id", column = @Column(name = "MEMBER_ID")),
    @AttributeOverride(name = "name", column = @Column(name = "MEMBER_NAME"))
})
public class Member extends BaseEntity {
    private String email;
}

@MappedSuperclass 특징

테이블과 매핑되지 않는다.
자식 클래스에게 엔티티의 매핑 정보를 상속하기 위해 사용한다.
엔티티가 아니므로 em.find(), JPQL에서 사용할 수 없다.
직접 생성해서 사용할 일이 거의 없으므로 추상 클래스로 만드는 것을 권장한다.
등록일자, 수정일자, 등록자, 수정자 같은 곹오 속성을 효과적으로 관리할 수 있다.

7.3 복합 키와 식별 관계 매핑

복합 키를 매핑하는 방법과 식별 관계, 비식별 관계를 매핑하는 방법을 알아본다.

7.3.1 식별 관계 vs 비식별 관계

식별 관계
부모 테이블의 기본 키를 내려받아서 자식 테이블의 기본 키 + 외래 키로 사용하는 관계다.

비식별 관계
부모 테이블의 기본 키를 받아서 자식 테이블의 외래 키로만 사용하는 관계다.

필수적 비식별 관계(Mandatory): 외래 키에 null을 허용하지 않는다. 연관관계를 필수적으로 맺어야 한다.
선택적 비식별 관계(Optional): 외래 키에 null을 허용한다. 연관관계를 맺을지 말지 선택할 수 있다.

참고
최근에는 비식별 관계를 주로 사용하고 꼭 필요한 곳에만 식별 관계를 사용하는 추세

7.3.2 복합 키: 비식별 관계 매핑

JPA는 복합 키를 지원하기 위해 다음 2가지 방법을 제공한다.

@IdClass: 관계형 데이터베이스에 가까운 방법
@EmbeddedId: 객체지향에 가까운 방법

@IdClass

@Entity
@IdClass(ParentId.class)
public class Parent {

    @Id
    @Column(name = "PARENT_ID1")
    private String id1;

    @Id
    @Column(name = "PARENT_ID2")
    private String id1;
}

public class ParentId implements Serializable {
    private String id1;
    private String id2;

    public ParentId() {}

    ...

    @Override
    public boolean equals (Object o) {...}

    @Override
    public int hashCode() {...}
}

@IdClass를 사용할 때 식별자 클래스는 다음 조건을 만족해야 한다.

식별자 클래스의 속성명과 엔티티에서 사용하는 식별자의 속성명이 같아야 한다.
Serializable 인터페이스를 구현해야 한다.
equals, hashCode를 구현해야 한다.
기본 생성자가 있어야 한다.
식별자 클래스는 public이어야 한다.

사용방법

// 저장
Parent parent = new Parent();
parent.setId1("1");
parent.setId2("2");

em.persist(parent);

// 조회
ParentId parentId = new ParentId("1","2");
Parent parent = em.find(Parent.class, parentId);

자식 클래스
자식 테이블에서 외래 키 매핑 방법

@Entity
public class Child {

    @Id
    private String id;

    @ManyToOne
    @JoinColumns({
        @JoinColumn(name = "PARENT_ID1", referencedColumnName = "PARENT_ID1"),
        @JoinColumn(name = "PARENT_ID2", referencedColumnName = "PARENT_ID2")
    })
    private Parent parent;
}

@EmbeddedId

@Entity
public class Parent {

    @EmbeddedId
    private ParentId id;
}

@Embeddable
public class ParentId implements Serializable {

    @Column(name = "PARENT_ID1")
    private String id1;
    @Column(name = "PARENT_ID2")
    private String id2;

    public ParentId() {}

    ...

    @Override
    public boolean equals (Object o) {...}

    @Override
    public int hashCode() {...}
}

@EmbeddedId를 사용할 때 식별자 클래스는 다음 조건을 만족해야 한다.

@Embeddable 어노테이션을 붙여주어야 한다.
Serializable 인터페이스를 구현해야 한다.
equals, hashCode를 구현해야 한다.
기본 생성자가 있어야 한다.
식별자 클래스는 public이어야 한다.

사용방법

// 저장
Parent parent = new Parent();
ParentId parentId = new ParentId("1","2");
parent.setId(parentId);

em.persist(parent);

// 조회
ParentId parentId = new ParentId("1","2");
Parent parent = em.find(Parent.class, parentId);

@IdClass vs @EmbeddedId

@IdClass: 관계형 데이터베이스에 가까운 방법
@EmbeddedId: 객체지향에 가까운 방법

// JPQL
em.createQuery("select p.id.id1, p.id.id2 from Parent p"); // @EmbeddedId
em.createQuery("select p.id1, p.id2 from Parent p"); // @IdClass

참고
복합 키에는 @GenerateValue를 사용할 수 없다. 복합 키를 구성하는 여러 컬럼중 하나에도 사용할 수 없다.

7.3.3 복합 키: 식별 관계 매핑

// 부모
@Entity
public class Parent {

    @Id
    @Column(name = "PARENT_ID")
    private String id;
}

// 자식
@Entity
@IdClass(ChildId.class)
public class Child {

    @Id
    @ManyToOne
    @JoinColumn(name = "PARENT_ID")
    private Parent parent;

    @Id @Column(name = "CHILD_ID")
    private String childId;
}

// 자식 ID
public class ChildId implements Serializable {
    
    private String parent;
    private String childId;
    ...생략...
}

// 손자
@Entity
@IdClass(GrandChildId.class)
public class GrandChild {

    @Id
    @ManyToOne
    @JoinColumns({
        @JoinColumn(name = "PARENT_ID"),
        @JoinColumn(name = "CHILD_ID")
    })
    private Child child;

    @Id @Column(name = "GRANDCHILD_ID")
    private String id;
}

// 손자 ID
public class GrandChildId implements Serializable {
    
    private ChildId child;
    private String id;
    ...생략...
}

@EmbeddedId와 식별 관계

// 부모
@Entity
public class Parent {

    @Id
    @Column(name = "PARENT_ID")
    private String id;
}

// 자식
@Entity
public class Child {

    @EmbeddedId
    private ChildId id;

    @MapsId("parentId")
    @ManyToOne
    @JoinColumn(name = "PARENT_ID")
    private Parent parent;
}

// 자식 ID
@Embeddable
public class ChildId implements Serializable {
    
    private String parentId; // @MapsId("parentId")로 매핑
    
    @Column(name = "CHILD_ID")
    private String id;
    ...생략...
}

// 손자
@Entity
public class GrandChild {

    @EmbeddedId
    private GrandChildId id;

    @MapsId("childId")
    @ManyToOne
    @JoinColumns({
        @JoinColumn(name = "PARENT_ID"),
        @JoinColumn(name = "CHILD_ID")
    })
    private Child child;
}

// 손자 ID
@Embeddable
public class GrandChildId implements Serializable {
    
    private ChildId childId; // @MapsId("childId")로 매핑
    
    @Column(name = "GRANDCHILD_ID")
    private String id;
    ...생략...
}

7.3.4 비식별 관계로 구현

// 부모
@Entity
public class Parent {

    @Id @GeneratedValue
    @Column(name = "PARENT_ID")
    private Long id;
}

// 자식
@Entity
public class Child {

    @Id @GeneratedValue
    @Column(name = "CHILD_ID")
    private Long id;

    @ManyToOne
    @JoinColumn(name = "PARENT_ID")
    private Parent parent;
}

// 손자
@Entity
public class GrandChild {

    @Id @GeneratedValue
    @Column(name = "GRANDCHILD_ID")
    private Long id;

    @ManyToOne
    @JoinColumn(name = "CHILD_ID")
    private Child child;
}

식별 관계의 복합 키를 사용한 코드와 비교하면 매핑도 쉽고 코드도 단순하다.

7.3.5 일대일 식별 관계

일대일 식별 관계는 자식 테이블의 기본 키 값으로 부모 테이블의 기본 키 값만 사용한다.

// 부모
@Entity
public class Board {

    @Id @GeneratedValue
    @Column(name = "BOARD_ID")
    private Long id;

    @OneToOne(mappedBy = "board")
    private BoardDetail boardDetail;
}

@Entity
public class BoardDetail {

    @Id
    private Long boardId;

    // 식별자가 단순히 컬럼 하나면 @MapsId를 사용하고 속성 값은 비워두면 된다.
    @MapsId // BoardDetail.boardId 매핑
    @OneToOne
    @JoinColumn(name = "BOARD_ID")
    private Board board;
}

사용방법

Board board = new Board();
em.persist(board);

BoardDetail boardDetail = new BoardDetail();
boardDetail.setBoard(board);
em.persist(boardDetail);

7.3.6 식별, 비식별 관계의 장단점

식별 관계 장점

특정 상황에서 조인 없이 하위 테이블만으로 검색할 수 있다.

식별 관계 단점

식별 관계는 부모 테이블의 기본 키를 자식 테이블로 전파하면서 자식 테이블의 기본 키 컬럼이 점점 늘어난다.
- SQL복잡, 기본 키 인덱스가 커짐
식별 관계는 복합 기본 키를 만들어야 하는 경우가 많다.
식별 관계를 사용할 때 기본 키로 비즈니스 의미가 있는 자연 키 컬럼을 조합 하는 경우가 많다.
- 비즈니스 요구사항은 언제나 변할 수 있다.
식별 관계는 테이블 구조가 유연하지 못하다.
식별 관계는 일대일 관계를 제외하고 별도의 복합 키 클래스를 사용한다.
- 기본 키 매핑에 많은 노력이 필요하다.

비식별 관계 장점

@GenerateValue처럼 편리한 대리 키 생성 방법 사용 가능
식별자 컬럼이 하나여서 매핑이 쉽다.

비식별 관계 단점

JPQL 조회시 길어질 수 있다.

결론
비식별 관계를 사용하고 기본 키는 Long 타입의 대리 키를 사용한다.

7.4 조인 테이블

데이터베이스 테이블의 연관관계를 설계하는 방법은 크게 2가지다.

조인 컬럼

조인 테이블

추천 방법
기본은 조인 컬럼을 사용하고 필요하다고 판단되면 조인 테이블을 사용하자.

7.4.1 일대일 조인 테이블

// 부모
@Entity
public class Parent {

    @Id @GeneratedValue
    @Column(name = "PARENT_ID")
    private Long id;


    @OneToOne
    @JoinTable(
        name = "PARENT_CHILD",
        joinColumn = @JoinColumn(name = "PARENT_ID"),
        inverseJoinColumns = @JoinColumn(name = "CHILD_ID")
    )
    private Child child;
}

// 자식
@Entity
public class Child {

    @Id @GeneratedValue
    @Column(name = "CHILD_ID")
    private Long id;

    // 양방향으로 매핑하려면 다음 코드를 추가한다.
    // @OneToOne(mappedBy = "child")
    // private Parent parent;
}

7.4.2 일대다 조인 테이블

// 부모
@Entity
public class Parent {

    @Id @GeneratedValue
    @Column(name = "PARENT_ID")
    private Long id;

    @OneToMany
    @JoinTable(
        name = "PARENT_CHILD",
        joinColumn = @JoinColumn(name = "PARENT_ID"),
        inverseJoinColumns = @JoinColumn(name = "CHILD_ID")
    )
    private List<Child> child = new ArrayList<Child>();
}

// 자식
@Entity
public class Child {

    @Id @GeneratedValue
    @Column(name = "CHILD_ID")
    private Long id;
}

7.4.2 다대일 조인 테이블

// 부모
@Entity
public class Parent {

    @Id @GeneratedValue
    @Column(name = "PARENT_ID")
    private Long id;

    @OneToMany(mappedBy = "parent")
    private List<Child> child = new ArrayList<Child>();
}

// 자식
@Entity
public class Child {

    @Id @GeneratedValue
    @Column(name = "CHILD_ID")
    private Long id;

    @ManyToOne
    @JoinTable(
        name = "PARENT_CHILD",
        joinColumn = @JoinColumn(name = "CHILD_ID"),
        inverseJoinColumns = @JoinColumn(name = "PARENT_ID")
    )
    private Parent parent;
}

7.4.4 다대다 조인 테이블

// 부모
@Entity
public class Parent {

    @Id @GeneratedValue
    @Column(name = "PARENT_ID")
    private Long id;

    @ManyToMany
    @JoinTable(
        name = "PARENT_CHILD",
        joinColumn = @JoinColumn(name = "PARENT_ID"),
        inverseJoinColumns = @JoinColumn(name = "CHILD_ID")
    )
    private List<Child> child = new ArrayList<Child>();
}

// 자식
@Entity
public class Child {

    @Id @GeneratedValue
    @Column(name = "CHILD_ID")
    private Long id;
}

7.5 엔티티 하나에 여러 테이블 매핑

@SecondaryTable을 사용하면 한 엔티티에 여러 테이블을 매핑할 수 있다.

@Entity
@Table(name="BOARD")
@SecondaryTable( 
    name = "BOARD_DETAIL",
    pkJoinColumns = @PrimaryKeyJoinColumn(name = "BOARD_DETAIL_ID")
)
public class Board {
    
    @Id @GeneratedValue
    @Column(name = "BOARD_ID")
    private Long id;

    private String title;

    @Column(name = "BOARD_DETAIL")
    private String content;
}

@SecondaryTable.name: 매핑할 다른 테이블 이름
@SecondaryTable.pkJoinColumns: 매핑할 다른 테이블의 기본 키 컬럼 속성

// 여러개 가능
@SecondaryTables({
    @SecondaryTable(name="BOARD_DETAIL"),
    @SecondaryTable(name="BOARD_FILE")
})

@SecondaryTable을 사용하는 것보단 테이블당 엔티티를 각각 만들어서 사용하는 것을 권장한다.

8. 프록시와 연관관계 관리

프록시와 즉시로딩, 지연로딩
영속성 전이와 고아 객체

8.1 프록시

엔티티를 조회할 때 연관된 엔티티들이 항상 사용되는 것은 아니다.
사용하지 않는 엔티티를 함께 조회해 두는 것은 효율적이지 않다.
JPA는 이런 문제를 해결하려고 지연 로딩을 제공한다.
지연 로딩이란 실제 사용하는 시점에 데이터베이스를 조회하는 것이다.
지연 로딩 기능을 사용하려면 실제 엔티티 객체 대신에 가짜 객체가 필요한데 이것을 프록시 객체라 한다.

8.1.1 프록시 기초

프록시의 특징

프록시 클래스는 실제 클래스를 상속 받아서 만들어진다.
따라서 사용하는 입장에서는 이것이 진짜 객체인지 프록시 객체인지 구분하지 않고 사용하면 된다.
프록시 객체는 실제 객체에 대한 참조를 보관한다.
프록시 객체의 메소드를 호출하면, 프록시 객체는 실제 객체의 메소드를 호출한다.
프록시 객체는 처음 사용할 때 한 번만 초기화 한다.

프록시 객체의 초기화

프록시 객체는 실제 사용될 때 데이터베이스를 조회해서 실제 엔티티 객체를 생성한다.
이를 프록시 객체의 초기화라 한다.

준영속 상태와 초기화

// em.getReference()를 호출하면 엔티티를 실제 사용하는 시점까지 데이터베이스 조회를 미룬다.
// MemberProxy 반환
Member member = em.getReference(Member.class, "id1");

tx.commit();
em.close(); // 영속성 컨텍스트 종료
member.getName(); // 준영속 상태에서 초기화 시도
                  // org.hibernate.LazyInitializationException 발생

8.1.2 프록시와 식별자

엔티티를 프록시로 조회할 때 식별자(PK) 값을 파라미터로 전달하는데 프록시 객체는 이 식별자 값을 보관한다.

Team team = em.getReference(Team.class, "team1"); // 식별자 보관
team.getId(); // 초기화되지 않음

단 @Access(AccessType.PROPERTY)일 때만 위처럼 동작하고, @Access(AccessType.FIELD)로 설정하면 프록시 객체를 초기화 한다.

8.1.3 프록시 확인

JPA가 제공하는 PersistenceUnitUtil.isLoaded(Object entity) 메소드를 사용하면 프록시 인스턴스의 초기화 여부를 확인할 수 있다.

boolean isLoad = em.getEntityManagerFactory()
                .getPersistenceUnitUtil().isLoaded(entity);

8.2 즉시 로딩과 지연 로딩

JPA는 개발자가 연관된 엔티티의 조회 시점을 선택할 수 있도록 다음 두 가지 방법을 제공한다.

즉시 로딩: 엔티티를 조회할 때 연관된 엔티티도 함께 조회한다.
- 설정 방법: @ManyToOne(fetch = FetchType.EAGER)
지연 로딩: 연관된 엔티티를 실제 사용할 때 조회한다.
- 설정 방법: @ManyToOne(fetch = FetchType.LAZY)

8.2.1 즉시 로딩

즉시 로딩을 사용하려면 @ManyToOne(fetch = FetchType.EAGER)로 지정한다.

@Entity
public class Member {
    ...생략...
    @ManyToOne(fetch = FetchType.EAGER)
    @JoinColumn(name = "TEAM_ID")
    private Team team;
    ...생략...
}

8.2.2 지연 로딩

지연 로딩을 사용하려면 @ManyToOne(fetch = FetchType.LAZY)로 지정한다. 지연 로딩은 프록시 객체를 이용한다.

@Entity
public class Member {
    ...생략...
    @ManyToOne(fetch = FetchType.LAZY)
    @JoinColumn(name = "TEAM_ID")
    private Team team;
    ...생략...
}

참고
조회 대상이 영속성 컨텍스트에 이미 있으면 프록시 객체를 사용할 이유가 없다. 따라서 실제 객체를 사용한다.

8.2.3 즉시 로딩, 지연 로딩 정리

지연 로딩: 연관된 엔티티를 프록시로 조회한다. 프록시를 실제 사용할 때 초기화하면서 데이터베이스를 조회한다.
즉시 로딩: 연관된 엔티티를 즉시 조회한다. 하이버네이트는 가능하면 SQL 조인을 사용해서 한 번에 조회한다.

8.3 지연 로딩 활용

연관된 엔티티가 자주 함께 사용되는지 아닌지에 따라 즉시 로딩, 지연 로딩을 결정한다.

8.3.1 프록시와 컬렉션 래퍼

컬렉션의 지연 로딩

Member member = em.find(Member.class, "member1");
List<Order> = member.getOrders();
System.out.println(orders.getClass().getName()); 

// 출력
// org.hibernate.collection.internal.PersistenBag

8.3.2 JPA 기본 페치 전략

@ManyToOne, @OneToOne: 즉시 로딩(FetchType.EAGER)
@OneToMany, @ManyToMany: 지연 로딩(FetchType.LAZY)

추천하는 방법은 모든 연관관계에 지연 로딩을 사용하는 것이다. 그리고 꼭 필요한 곳에만 즉시 로딩을 사용하도록 한다.

8.3.3 컬렉션에 FetchType.EAGER 사용 시 주의점

컬렉션에 FetchType.EAGER를 사용할 경우 주의할 점은 다음과 같다.

컬렉션을 즉시 로딩하는 것은 권장하지 않는다.
- 너무 많은 데이터를 반환할 수 있고, 결과적으로 성능이 저하될 수 있다.
컬렉션 즉시 로딩은 항상 OUTER JOIN을 사용한다.
@ManyToOne, @OneToOne
- (optional = false): 내부 조인
- (optional = true): 외부 조인
@OneToMany, @ManyToMany
- (optional = false): 외부 조인
- (optional = true): 내부 조인

8.4 영속성 전이: CASCADE

특정 엔티티를 연속 상태로 만들 때 연관된 엔티티도 함께 영속 상태로 만들고 싶으면 영속성 전이 기능을 사용한다. JPA에서 엔티티를 저장할 때 연관된 모든 엔티티는 영속 상태여야 한다.

8.4.1 영속성 전이: 저장

@Entity
public class Parent {
    ...생략...
    @OneToMany(mappedBy = "parent", cascade = CascadeType.PERSIST)
    private List<Child> children = new ArrayList<Child>();
    ...생략...
}

Parent parent = new Parent();
Child child = new Child();

child.setParent(parent);
parent.getChildren().add(child);

// Parent만 저장했지만, 영속성 전이에 의해 Child도 저장됨
em.persist(parent);

영속성 전이는 연관관계를 매핑하는 것과는 아무 관련이 없다. 단지 엔티티를 영속화할 때 연관된 엔티티도 같이 영속화하는 편리함을 제공할 뿐이다.

8.4.2 영속성 전이: 삭제

@Entity
public class Parent {
    ...생략...
    @OneToMany(mappedBy = "parent", cascade = CascadeType.REMOVE)
    private List<Child> children = new ArrayList<Child>();
    ...생략...
}

Parent parent = em.find(Parent.class, 1L);

// Parent만 삭제했지만, 영속성 전이에 의해 Child도 삭제됨
em.remove(parent);

8.4.3 CASCADE의 종류

public enum CascadeType {
    ALL,        // 모두 적용
    PERSIST,    // 영속
    MERGE,      // 병합
    REMOVE,     // 삭제
    REFRESH,
    DETACH
}

8.5 고아 객체

JPA는 부모 엔티티와 연관관계가 끊어진 자식 엔티티를 자동으로 삭제하는 기능을 제공하는데 이것을 고아 객체(ORPHAN) 제거라 한다. 부모 엔티티의 컬렉션에서 자식 엔티티의 참조만 제거하면 자식 엔티티가 자동으로 삭제된다.

@Entity
public class Parent {
    ...생략...
    @OneToMany(mapeedBy = "parent", orphanRemoval = true)
    private List<Child> children = new ArrayList<Child>();
    ...생략...
}

Parent parent = em.find(Parent.class, id);
parent.getChildren().remove(0); // 자식 엔티티를 컬렉션에서 삭제

// SQL
DELETE FROM CHILD WHERE ID=?

고아 객체 제거는 참조가 제거된 엔티티는 다른 곳에서 참조하지 않는 고아 객체로 보고 삭제하는 기능이다. 또, 부모를 제거하면 자식도 같이 제거된다.

8.6 영속성 전이 + 고아 객체, 생명 주기

CascadeType.All + orphanRemoval = true를 동시에 사용하면 어떻게 될까? 두 옵션을 모두 활성화 하면 부모 엔티티를 통해서 자식의 생명주기를 관리 할 수 있다.

자식을 저장하려면 부모에 등록하면 된다 (CASCADE)
자식을 삭제하려면 부모에서 제거하면 된다 (orphanRemoval)

9. 값 타입

JPA의 데이터 타입

엔티티 타입
- @Entity
값 타입
- 기본값 타입
  - 자바 기본 타입(예: int, double)
  - 래퍼 클래스(예: Integer)
  - String
- 임베디드 타입
  - embedded type
- 컬렉션 값 타입
  - collection value type

9.1 기본값 타입

private String name;
private int age;
...

9.2 임베디드 타입(복합 값 타입)

@Entity
public class Member {
    @Embedded Address homeAddress;
}

@Embeddable
public class Address {
    @Column(name="city")
    private String city;
    private String street;
    private String zipcode;
    ...
}

@Embeddable: 값 타입을 정의하는 곳에 표시
@Embedded: 값 타입을 사용하는 곳에 표시

9.2.1 임베디드 타입과 테이블 매핑

UML에서 임베디드 값 타입은 단순하게 표현하는 것이 편리하다.

9.2.2 임베디드 타입과 연관관계

@Entity
public class Member {
    @Embedded Address address;
    @Embedded PhoneNumber phoneNumber;
}

@Embeddable
public class Address {
    String city;
    String street;
    String state;
    @Embedded Zipcode zipcode;
}

@Embeddable
public class Zipcode {
    String zip;
    String plusFour;
}

@Embeddable
public class PhoneNumber {
    String areaCode;
    String localNumber;
    @ManyToOne PhoneServiceProvider provider;
}

@Entity
public class PhoneServiceProvider {
    @Id String name;
}

9.2.3 @AttributeOverride: 속성 재정의

임베디드 타입에 정의한 매핑정보를 재정의 하려면 엔티티에 @AttributeOverride를 사용한다.

@Entity
public class Member {
    @Embedded
    private Address address;

    @Embedded
    @AttributeOverrides({
        @AttributeOverride(ame="city", column=@Column(name="COMPANY_CITY")),
        @AttributeOverride(name="street", column=@Column(name="COMPANY_STREET")),
        @AttributeOverride(name="zipcode", column=@Column(name="COMPANY_ZIPCODE"))
    })
    private Address companyAddress;
}

9.2.4 임베디드 타입과 null

임베디드 타입이 null이면 매핑한 컬럼 값은 모두 null이 된다.

member.setAddress(null);
em.persist(member);
// 회원 테이블의 주소와 관련된 CITY,STREET,ZIPCODE 컬럼 값은 모두 null이 된다.

9.3 값 타입과 불변 객체

값 타입은 복잡한 객체를 조금이라도 단순화하려고 만든 개념이다. 따라서 값 타입은 단순하고 안전하게 다룰 수 있어야 한다.

9.3.1 값 타입 공유 참조

임베디드 타입 같은 값 타입을 여러 엔티티에서 공유하면 위함하다.

member1.setAddress(new Address("OldCity"));
Address address = member1.getAddress();

address.setCity("NewCity");
member2.setAddress(address);

// 회원2의 주소만 NewCity로 변경되기를 기대하지만 회원1의 주소도 NewCity로 변경되어 버린다.

9.3.2 값 타입 복사

값 타입의 실제 인스턴스인 값을 공유하는 것은 위험하다. 대신에 값(인스턴스)을 복사해서 사용해야 한다.

member1.setAddress(new Address("OldCity"));
Address address = member1.getAddress();

// 복사
Address newAddress = address.clone();
newAddress.setCity("NewCity");
member2.setAddress(newAddress);

9.3.3 불변 객체

값 타입은 부작용 걱정 없이 사용할 수 있어야 한다. 객체를 불변하게 만들면 값을 수정할 수 없으므로 부작용을 원천 차단할 수 있다.

// 주소 불변 객체
@Embeddable
public class Address {
    private String city;
    
    protected Address () {}

    public Address(String city) {
        this.city = city;
    }
    

    public String getCity() {
        return city;
    }

    // Setter는 만들지 않는다.
}

9.4 값 타입의 비교

동일성 비교: 인스턴스의 참조 값을 비교, == 사용
동등성 비교: 인스턴스의 값을 비교, equals() 사용
값 타입을 비교할 때는 equals()를 사용해서 동등성 비교를 해야 한다.
값 타입의 equals(), hashCode() 메소드를 재정의해야 한다.

9.5 값 타입 컬렉션

값 타입을 하나 이상 컬렉션에 보관하고 @ElementCollection, @CollectionTable 어노테이션을 사용하면 된다.

@Entity
public class Member {

    @Id @GeneratedValue
    private Long id;

    @ElementCollection
    @CollectionTable(
        name = "FAVORITE_FOODS",
        joinColumns = @JoinColumn(name = "MEMBER_ID")
    )
    @Column(name = "FOOD_NAME")
    private Set<String> favoriteFoods = new HashSet<String>();

    @ElementCollection
    @CollectionTable(
        name = "ADDRESS",
        joinColumns = @JoinColumn(name = "MEMBER_ID")
    )
    private List<Address> addressHistory = new ArrayList<Address>();
}

@Embeddable
public class Address {

    @Column
    private String city;
    private String street;
    private String zipcode;
}

9.5.1 값 타입 컬렉션 사용

값 타입 컬렉션은 영속성 전이(Cascade) + 고아 객체 제거(Orphan remove) 기능이 포함되어 있다.

// 값 타입 컬렉션도 조회할 때 페치 전략을 선택할 수 있다.
@ElementCollection(fetch = FetchType.LAZY) // 기본값 LAZY

9.5.2 값 타입 컬렉션의 제약사항

제약사항

값 타입 컬렉션에 보관된 값 타입들은 별도의 테이블에 보관한다.
따라서 여기에 보관된 값 타입의 값이 변경되면 데이터베이스에서 데이터를 찾기 어렵다.
이런 문제로 JPA 구현체들은 값 타입 변경 사항이 발생하면 값 타입 컬렉션이 매핑된 테이블의 연관된 모든 데이터를 삭제, 현재 값으로 저장한다.
성능 문제 발생
값 타입 컬렉션을 매핑하는 테이블은 모든 컬럼을 묶어서 기본 키를 구성 해야한다.
따라서 데이터베이스 기본 키 제약 조건으로 인해 컬럼에 null을 입력할 수 없고, 값은 값을 중복해서 저장할 수 없는 제약도 있다.

해결방법

따라서 실무에서는 값 타입 컬렉션이 매핑된 테이블에 데이터가 많다면 값 타입 컬렉션 대신에 일대다 관계를 고려해야 한다.
그리고 영속성 전이 + 고아 객체 제거 기능을 적용하면 값 타입 컬렉션 처럼 사용할 수 있다.

// 값 타입 컬렉션 대신에 일대다 관계 사용
@Entity
public class AddressEntity {

    @Id @GeneratedValue
    private Long id;

    @Embedded
    private Address address;
}

@Embeddable
public class Address {

    @Column
    private String city;
    private String street;
    private String zipcode;
}

// 설정 코드
@OneToMany(cascade = CascadeType.ALL, orphanRemoval = true)
@JoinColumn(name = "MEMBER_ID")
private List<AddressEntity> addressHistory = new ArrayList<AddressEntity>();

9.6 정리

엔티티 타입의 특징

식별자(@Id)가 있다.
생명 주기가 있다.
- 생성, 영속, 소멸
공유할 수 있다.
- 참조 값을 공유할 수 있다.
- 예를 들어 회원 엔티티가 있다면 다른 엔티티에서 회원 엔티티를 참조할 수 있다.

값 타입의 특징

식별자가 없다
생명 주기를 엔티티에 의존한다.
- 의존하는 엔티티를 제거하면 같이 제거된다.
공유하지 않는 것이 안전하다.
- 대신에 값을 복사해서 사용한다.
- 오직 하나의 주인만이 관리해야 한다.
- 불변 객체로 만드는 것이 안전하다.

10. 객체지향 쿼리 언어

10.1 객체지향 쿼리 소개

JPQL 이란?

테이블이 아닌 객체를 대상으로 검색하는 객체지향 쿼리다
SQL을 추상화해서 특정 데이터베이스 SQL에 의존하지 않는다.
SQL이 데이터베이스 테이블을 대상으로 하는 데이터 중심의 쿼리라면 JPQL은 엔티티 객체를 대상으로 하는 객체지향 쿼리다.

JPA는 JPQL뿐만 아니라 다양한 검색 방법을 제공한다.

공식 지원 기능

JPQL(Java Persistence Query Language)
Criteria 쿼리: JPA을 편하게 작성하도록 도와주는 API, 빌더 클래스 모음
네이티브 SQL: JPA에서 JPQL 대신 직접 SQL을 사용할 수 있다.

비 공식 기능

QueryDSL: Criteria 쿼리처럼 JPQL을 편하게 작성하도록 도와주는 빌더 클래스 모음, 비표준 오픈소스 프레임워크다.
JDBC 직접 사용
MyBatis 같은 SQL 매퍼 프레임워크 사용

10.1.1 JPQL 소개

JPQL은 엔티티 객체를 조회하는 객체지향 쿼리다.
JPQL은 SQL을 추상화해서 특정 데이터베이스에 의존하지 않는다.
- 방언만 변경하면 된다.
JPQL은 SQL보다 간결하다.
- 엔티티 직접 조회
- 묵시적 조인
- 다형성 지원

@Entity(name="Member")
public class Member {
    ...생략...
    @Column(name = "name")
    private String name;
    ...생략...
}

// JPQL 사용
String jpql = "select m from Member as m where m.username = 'kim'";
List<Member> resultList = em.createQuery(jpql, Member.class).getResultList();

-- 실제 실행된 SQL, 별칭은 너무 복잡해 임의 수정
select
    member.id as id,
    member.age as age,
    member.team_id as team,
    member.name as name
from
    Member member
where
    member.name='kim'

10.1.2 Criteria 소개

Criteria는 JPQL을 생성하는 빌더 클래스다. Criteria의 장점은 문자가 아닌 query.select(m).where(...)처럼 프로그래밍 코드로 JPQL을 작성할 수 있다는 점이다.

장점

컴파일 시점에 오류를 발견할 수 있다.
IDE를 사용하면 코드 자동완성을 지원한다.
동적 쿼리를 작성하기 편하다.

// Criteria 사용 준비
CriteriaBuilder cb = em.getCriteriaBuilder();
CriteriaQuery<Member> query = cb.createQuery(Member.class);

// 루트 클래스(조회를 시작할 클래스)
Root<Member> m = query.from(Member.class);

// 쿼리 생성
CriteriaQuery<Member> cq = query.select(m).where(cb.equal(m.get("username"), "kim"));
List<Member> resultList = em.createQuery(cq).getResultList();

Criteria가 가진 장점이 많지만 모든 장점을 상쇄할 정도로 복잡하고 장황하다.

10.1.3 QueryDSL 소개

QueryDSL도 Criteria처럼 JPQL 빌더 역할을 한다.
코드 기반이다
단순하고 사용하기 쉽다
작성한 코드도 JPQL과 비슷해서 한눈에 들어온다

// 준비
JPAQuery query = new JPAQuery(em);
QMember member = QMember.member;

// 쿼리, 결과조회
List<Member> members = query.from(member)
                    .where(member.username.eq("kim"))
                    .list(member);

10.1.4 네이티브 SQL 소개

JPA는 SQL을 직접 사용할 수 있는 기능을 지원하는데 이것을 네이티브 SQL이라 한다.

String sql = "SELECT ID, AGE, TEAM_ID, NAME FROM MEMBER WHERE NAME = 'kim'";
List<Member> resultList = em.createNativeQuery(sql, Member.class).getResultList();

네이티브 SQL의 단점은 특정 데이터베이스에 의존하는 SQL을 작성해야 한다는 것이다. 따라서 데이터베이스를 변경하면 네이티브 SQL도 수정해야 한다.

10.1.5 JDBC 직접 사용, 마이바티스 같은 SQL 매퍼 프레임워크 사용

다음은 하이버네이트에서 직접 JDBC Connection을 획득하는 방법이다.

Session session = entityManager.unwrap(Session.class);
session.doWork(new Work() {

    @Override
    public void execute(Connection connection) throw SQLException {...}
});

JDBC나 마이바티스를 JPA와 함께 사용하면 영속성 컨텍스트를 적절한 시점에 강제로 플러시해야 한다.
데이터베이스와 영속성 컨텍스트를 동기화 하기 위함이다.

10.2 JPQL

JPQL 특징

JPQL은 객체지향 쿼리 언어다. 따라서 테이블이 아닌 엔티티 객체를 대상으로 쿼리한다.
JPQL은 SQL을 추상화해서 특정 데이터베이스 SQL에 의존하지 않는다.
JPQL은 결국 SQL로 변환된다.

10.2.1 기본 문법과 쿼리 API

JPQL 문법

select_문 :: =
    select_절
    from_절
    [where_절]
    [groupby_절]
    [having_절]
    [orderby_절]

update_문 :: update_절 [where_절]
delete_문 :: delete_절 [where_절]

SELECT 문

SELECT m FROM Member AS m where m.username = 'Hello'

대소문자 구분
- 엔티티와 속성은 대소문자를 구분한다.
- JPQL 키워드(SELECT, FROM, AS..)는 대소문자를 구분하지 않는다.
엔티티 이름
- 테이블 명이 아니라 엔티티 명을 사용한다.
- @Entity(name=”xxx”)로 지정할 수 있다.
- 엔티티 명을 지정하지 않으면 클래스명을 기본값으로 사용한다.
별칭은 필수
- JPQL은 별칭을 필수로 사용해야 한다. (JPA 명세로 치면 정확히는 식별 변수)
- AS는 생략할 수 있다.

TypeQuery, Query
작성한 JPQL을 실행하려면 쿼리 객체를 만들어야 한다.

TypeQuery 객체: 반환 타입을 명확하게 지정할 수 있으면 사용
Query 객체: 반환 타입을 명확하게 지정할 수 없으면 사요

// TypeQuery 사용

TypeQuery<Member> query = em.createQuery("SELECT m FROM Member m", Member.class);

List<Member> resultList = query.getResultList();
for (Member member : resultList) {
    ...
}

// Query 사용

Query query = em.createQuery("SELECT m FROM Member m");

List resultList = query.getResultList();
for (Object o : resultList) {
    Object[] result = (Object[]) o; // 결과가 둘 이상이면 Object[] 반환
    System.out.println("username = " + result[0]);
    System.out.println("age = " + result[1]);
}

결과 조회
다음 메소드들을 호출하면 실제 쿼리를 실행해서 데이터베이스를 조회한다.

query.getResultList(): 결과를 반환. 만약 결과가 없으면 빈 컬렉션 반환
query.getSingleResult(): 결과가 정확히 하나일 때 사용한다.
- 결과가 없으면 javax.persistence.NoResultException 발생
- 결과가 1개보다 많으면 javax.persistence.NonUniqueResultException 발생

10.2.2 파라미터 바인딩

JDBC는 위치 기준 파라미터 바인딩만 지원하지만 JPQL은 이름 기준 파라미터 바인딩도 지원한다.

이름 기준 파라미터

String usernameParam = "user1";

// 파라미터 앞에 :을 붙인다.
TypeQuery<Member> query = em.createQuery("SELECT m FROM Member m where m.username = :username", Member.class);
query.setParameter("username", usernameParam);

List<Member> resultList = query.getResultList();

위치 기준 파라미터

String usernameParam = "user1";

// 파라미터는 ? 다음에 위치 값을 주면 된다.
List<Member> members = em.createQuery("SELECT m FROM Member m where m.username = ?1", Member.class);

query.setParameter(1, usernameParam);
List<Member> resultList = query.getResultList();

경고
파라미터 바인딩 방식을 사용하지 않고 직접 JPQL을 만들면 SQL 인젝션 공격을 당할 수 있다.

"SELECT m FROM Member m where m.username = '" + usernameParam + "'"

10.2.3 프로젝션

SELECT 절에 조회할 대상을 지정하는 것을 프로젝션이라고 한다. [SELECT {프로젝션 대상} FROM]으로 대상을 선택한다. 프로젝션 대상은 엔티티, 임베디드 타입, 스칼라 타입이 있다. 스칼라 타입은 숫자, 문자 등 기본 데이터 타입을 뜻한다.

엔티티 프로젝션

SELECT m FROM Member m      // 회원
SELECT m.team FROM Member m // 팀

조회한 엔티티는 영속성 컨텍스트에서 관리한다.

임베디드 타입 프로젝션
임베디드 타입은 조회의 시작점이 될 수 없다는 제약이 있다. 아래에 Address는 임베디드 타입이다.

// 잘못된 쿼리
String query = "SELECT a From Address a";

// 올바른 쿼리
String query = "SELECT o.address From Order o";
List<Address> addresses = em.createQuery(query, Address.class).getResultList();

실행된 쿼리는 다음과 같다.

select
    order.city,
    order.street,
    order.zipcode
from
    Orders order

임베디드 타입은 엔티티 타입이 아니다. 따라서 이렇게 직접 조회한 임베디드 타입은 영속성 컨텍스트에서 관리되지 않는다.

스칼라 타입 프로젝션
숫자, 문자, 날짜와 같은 기본 데이터 타입들은 스칼라 타입이라 한다.

String query = "SELECT username FROM Member m";
List<String> usernames = em.createQuery(query, String.class).getResultList();


// 중복 데이터를 제거하려면 DISTINCT를 사용한다.
SELECT DISTINCT username From Member m

// 통계
String query = "SELECT AVG(o.orderAmount) FROM Order o"
Double orderAmountAvg = em.createQuery(query, Double.class).getSingleResult();

여러 값 조회
꼭 필요한 데이터들만 선택해서 조회해야 할 때도 있다. 이 때는 TypeQuery를 사용할 수 없고 대신에 Query를 사용해야 한다.

Query query = em.createQuery("SELECT m.username, m.age FROM Member m");
List resultList = query.getResultList();

Iterator iterator = resultList.iterator();
while (iterator.hasNext()) {
    Object[] row = (Object[]) iterator.next();
    String username = (String) row[0];
    Integer age = (Integer) row[1];
}

Query query = em.createQuery("SELECT m.username, m.age FROM Member m");
List<Object[]> resultList = query.getResultList();

for (Object[] row : resultList) {
    String username = (String) row[0];
    Integer age = (Integer) row[1];
}

스칼라 타입뿐만 아니라 엔티티 타입도 여러 값을 함께 조회할 수 있다.

Query query = em.createQuery("SELECT o.member, o.product, o.orderAmount FROM Order o");
List<Object[]> resultList = query.getResultList();

for (Object[] row : resultList) {
    Member member = (Member) row[0];    // 엔티티
    Product product = (Product) row[1]; // 엔티티
    int orderAmount = (Integer) row[2]; // 스칼라
}

물론 이때도 조회한 엔티티는 영속성 컨텍스트에서 관리된다.

NEW 명령어
프로젝션을 UserDTO처럼 의미 있는 객체로 변환해서 사용할 수 있다.

public class UserDTO {
    private String username;
    private int age;

    public UserDTO(String username, int age) {
        this.username = username;
        this.age = age;
    }
    ...
}

TypeQuery<UserDTO> query = em.createQuery("SELECT new jpabook.jpql.UserDTO(m.username, m.age) FROM Member m", UserDTO.class);

List<UserDTO> resultList = query.getResultList();

NEW 명령어 사용시 주의 사항은 다음과 같다.

패키지 명을 포함한 전체 클래스 명을 입력해야 한다.
순서와 타입이 일치하는 생성자가 필요한다.

10.2.4 페이징 API

JPA 페이징

TypeQuery<Member> query = em.createQuery("SELECT m FROM Member m ORDER BY m.username DESC", Member.class);

query.setFirstResult(10); // 조회 시작 위치(0부터 시작)
query.setMaxResult(20);   // 조회할 데이터 수
query.getResultList();

HSQLDB 페이징

SELECT
    M.ID AS ID,
    M.AGE AS AGE,
    M.TEAM_ID AS TEAM_ID,
    M.NAME AS NAME
FROM
    MEMBER M
ORDER BY
    M.NAME DESC OFFSET ? LIMIT ?

MySQL 페이징

SELECT
    M.ID AS ID,
    M.AGE AS AGE,
    M.TEAM_ID AS TEAM_ID,
    M.NAME AS NAME
FROM
    MEMBER M
ORDER BY
    M.NAME DESC LIMIT ?, ?

PostgreSQL 페이징

SELECT
    M.ID AS ID,
    M.AGE AS AGE,
    M.TEAM_ID AS TEAM_ID,
    M.NAME AS NAME
FROM
    MEMBER M
ORDER BY
    M.NAME DESC LIMIT ? OFFSET ?

오라클 페이징

SELECT *
FROM
    (
        SELECT ROW_.*, ROWNUM ROWNUM_
            FROM
                (
                    SELECT
                        M.ID AS ID,
                        M.AGE AS AGE,
                        M.TEAM_ID AS TEAM_ID,
                        M.NAME AS NAME
                    FROM
                        MEMBER M
                    ORDER BY M.NAME
                ) ROW_
            WHERE ROWNUM <= ?
    )
WHERE ROWNUM_ > ?

SQLServer 페이징

WITH query AS (
    SELECT
    inner_query.*,
    ROW_NUMBER() OVER (ORDER BY CURRENT_TIMESTAMP) as
        __hibernate_row_nr__
    FROM
        (
            select
                TOP(?) m.id as id,
                m.age as age,
                m.team_id as team_id,
                m.name as name
            from Member m
            order by m.name DESC
        ) inner_query
)
SELECT id, age, team_id, name
FROM query
WHERE __hibernate_row_nr__ >= ? AND __hibernate_row_nr__ < ?

10.2.5 집합과 정렬

집합은 집합함수와 함께 통계 정보를 구할 때 사용한다.

집합 함수

함수	설명
COUNT	결과 수를 구한다. 반환 타입: Long
MAX, MIN	최대, 최소 값을 구한다. 문자, 숫자, 날짜 등에 사용한다.
AVG	평균값을 구한다. 숫자타입만 사용할 수 있다. 반환 타입: Double
SUM	합을 구한다. 숫자타입만 사용할 수 있다. 반환 타입: 정수합 Long, 소수합: Double, BigInteger합: BigInteger, BigDecimal합: BigDecimal

집합 함수 사용 시 참고사항

NULL 값은 무시하므로 통계에 잡히지 않는다. (DISTINCT가 정의되어 있어도 무시된다.)
만약 값이 없는데 SUM, AVG, MAX, MIN 합수를 사용하면 NULL 값이 된다. 단 COUNT는 0이 된다.
DISTINCT를 집합 함수 안에 사용해서 중복된 값을 제거하고 나서 집합을 구할 수 있다. 예: select COUNT( DISTINCT m.age ) from Member m
DISTINCT를 COUNT에서 사용할 때 임베디드 타입은 지원하지 않는다.

GROUP BY, HAVING
GROUP BY는 통계 데이터를 구할 때 특정 그룹끼리 묶어준다. HAVING은 GROUP BY와 함께 사용되는데 GROUP BY로 그룹화한 통계 데이터를 기준으로 필터링 한다.

select
    t.name,
    COUNT(m.age),
    SUM(m.age),
    AVG(m.age),
    MAX(m.age),
    MIN(m.age)
from Member m LEFT JOIN m.team t
GROUP BY t.name
HAVING AVG(m.age) >= 10

문법은 다음과 같다.

groupby_절 ::= GORUP BY {단일값 경로 | 별칭} +
having_절 ::= HAVING 조건식

정렬(ORDER BY)
결과를 정렬할 때 사용한다.

select m from Member m order by m.age DESC, m.username ASC

문법은 다음과 같다.

orderby_절 ::= ORDER BY {상태필드 경로 | 결과 변수 [ASC | DESC]}+

ASC: 오름차순(기본값)
DESC: 내림차순

10.2.6 JPQL 조인

JPQL도 조인을 지원하는데 SQL 조인과 기능은 같고 문법만 약간 다르다.

내부 조인
내부조인은 INNER JOIN을 사용한다. 참고로 INNER는 생략할 수 있다.

String teamName = "팀A";
String query = "SELECT m FROM Member m INNER JOIN m.team t WHERE t.name = :teamName";

List<Member> members = em.createQuery(query, Member.class)
                    .setParameter("teamName", teamName)
                    .getResultList();

주의사항
JPQL 조인은 연관 필드를 사용한다는 것이다. SQL 조인처럼 사용하면 문법 오류가 발생한다. 다음은 잘못된 예이다.

-- 잘못된 JPQL 조인
FROM Member m JOIN Team t 

외부 조인
JPQL의 외부 조인은 다음과 같이 사용한다.

SELECT m
FROM Member m LEFT [OUTER] JOIN m.team t

컬렉션 조인
일대다 관계나 다대다 관계처럼 컬렉션을 사용하는 곳에서 조인하는 것을 컬렉션 조인이라 한다.

[회원 -> 팀]으로의 조인은 다대일 조인, 단일 값 연관필드(m.team) 사용
[팀 -> 회원]으로의 조인은 일대다 조인, 컬렉션 값 연관필드(m.members) 사용

-- 팀과 회원목록을 컬렉션 값 연관 필드로 외부조인 했다.
SELECT t, m FROM Team t LEFT JOIN t.members m

세타 조인
WHERE 절을 사용해서 세타 조인을 할 수 있다. 세타 조인은 내부 조인만 지원한다. 세타 조인을 사용하면 전혀 관계없는 엔티티도 조인할 수 있다.

-- JPQL
select count(m) from Member m, Team t
where m.username = t.team

-- sql
select count(m.id)
from
    member m cross join team t
where
    m.username = t.name

JOIN ON 절(JPA 2.1)
JPA 2.1부터 조인할 때 ON 절을 지원한다. 참고로 내부 조인이 ON 절은 WHERE 절을 사용할 때와 결과가 같으므로 보통 ON 절은 외부 조인에서만 사용한다.

-- JPQL
select m, t
from Member m
    left join m.team t on t.name = 'A'

-- SQL
select m.*, t.*
from Member m
    left join Team t on m.team_id = t.id 
    and t.name = 'A'

10.2.7 페치 조인

페치(fetch) 조인은 JPQL에서 성능 최적화를 위해 제공하는 기능이다.
연관된 엔티티나 컬렉션을 한 번에 같이 조회하는 기능이다.
join fetch 명령어로 사용할 수 있다.

문법

페치 조인 ::= [ LEFT [OUTER] | INNER ] JOIN FETCH 조인경로

엔티티 페치 조인
다음은 페치 조인을 사용해서 회원 엔티티를 조회하면서 연관된 팀 엔티티도 함께 조회 하는 JPQL

-- 페치 조인 JPQL
select m
from Member m join fetch m.team


-- 실행된 SQL
SELECT
    M.*, T.*
FROM MEMBER T
INNER JOIN TEAM T ON M.TEAM_ID = T.ID

JPQL조인과는 다르게 m.team 다음에 별칭이 없는데 페치 조인은 별칭을 사용할 수 없다. (하지만 하이버네이트는 페치 조인에도 별칭을 허용한다.)

컬렉션 페치 조인
일대다 관계인 컬렉션을 페치 조인

-- 컬렉션 페치 조인 JPQL
select t
from Team t join fetch t.members
where t.name = '팀A'


-- 실행된 SQL
SELECT
    T.*, M.*
FROM TEAM T
INNER JOIN MEMBER M ON T.ID = M.TEAM_ID
WHERE T.NAME = '팀A'

문제는 TEAM 테이블에서 팀A는 하나지만 MEMBER테이블과 조인하면서 결과가 증가한다. 테이블의 데이터가 팀A, 회원1, 회원2 있다고 하면 결과는 아래와 같다.

teamname = 팀A, team = Team@0x100
    username = 회원1, member = Member@0x200
    username = 회원2, member = Member@0x300
teamname = 팀A, team = Team@0x100
    username = 회원1, member = Member@0x200
    username = 회원2, member = Member@0x300

페치 조인과 DISTINCT
위의 컬렉션 페치 조인은 팀A가 중복으로 조회된다. 이를 해결하기 위해 DISTINCT를 사용한다.

select distinct t
from Team t join fetch t.members
where t.name = '팀A'

위 상황의 데이터는 SQL에서 DISTINCT를 해도 효과가 없다.

로우 번호	팀	회원
1	팀A	회원1
2	팀A	회원2

하지만 JPQL의 select distinct t의 의미는 엔티티의 중복을 제거하라는 것이다. 따라서 팀A는 하나만 조회된다.

teamname = 팀A, team = Team@0x100
    username = 회원1, member = Member@0x200
    username = 회원2, member = Member@0x300

페치 조인과 일반 조인의 차이

일반 조인: JPQL의 결과를 반환할 때 연관관계까지 고려하지 않는다. 단지 SELECT 절에 지정한 엔티티만 조회할 뿐이다.
페치 조인: SELECT 절에 지정한 엔티티뿐만 아니라 지정하지 않았어도 연관된 엔티티도 함께 조회한다.

페치 조인의 특징과 한계

SQL 한번으로 연관된 엔티티들을 조회하여 SQL 호출 횟수를 줄여 성능을 최적화할 수 있다.
JPQL에서 페치 조인을 사용하면 글로벌 전략보다 우선 적용된다.
- 글로벌 전략 예: @OneToMany(fetch = FetchType.LAZY)
페치 조인을 하면 쿼리 시점에 조회하므로 준영속 상태에서도 객체 그래프를 탐색할 수 있다.
페치 조인 대상에는 별칭을 줄 수 없다.
- 따라서 SELECT, WHERE, 서비 쿼리에 페치 조인 대상을 사용할 수 없다.
- 하이버네이트에서는 페치 조인에 별칭을 지원한다. 하지만 잘못 사용하면 연관된 데이터 수가 달라져 무결성이 깨질 수 있다.
둘 이상의 컬렉션을 페치할 수 없다.
컬렉션을 페치 조인하면 페이징 API를 사용할 수 없다.
- 컬렉션(일대다)이 아닌 단일 값 연관 필드(일대일, 다대일)은 페치 조인 가능
- 하이버네이트는 컬렉션을 페치 조인하고 페이징 API를 사용하면 경고 로그를 남기고 메모리에서 페이징 처리한다. 하지만 성능 이슈가 발생할 수 있다.

추천은 글로벌 전략은 지연 로딩을 사용하고 최적화가 필요하면 그 때 페치 조인을 적용한다.

10.2.8 경로 표현식

경로 표현식이란 m.username, m.team 처럼 .(점)을 찍어 객체 그래프를 탐색하는 것이다.

경로 표현식의 용어 정리

상태 필드: 단순히 값을 저장하기 위한 필드
연관 필드: 연관관계를 위한 필드, 임베디드 타입 포함
- 단일 값 연관필드: @ManyToOne, @OneToOne, 대상이 엔티티
- 컬렉션 값 연관 필드: @OneToMany, @ManyToMany, 대상이 컬렉션

@Entity
public class Member {
    ...생략...
    @Column(name = "name")
    private String username;    // 상태 필드

    @ManyToOne(...)
    private Team team;          // 연관 필드 (단일 값)

    @OneToMany(...)
    private List<Order> orders; // 연관 필드 (컬렉션 값)
    ...생략...
}

경로 표현식 특징
JPQL에서 경로 표현식의 특징

상태 필드 경로: 경로 탐색의 끝이다. 더는 탐색할 수 없다.

  -- JPQL
  select m.username, m.age from Member m

  -- SQL 변환
  select m.name, m.age from Member m

단일 값 연관 경로: 묵시적으로 내부 조인이 일어난다. 단일 값 연관 경로는 계속 탐색할 수 있다.

  -- JPQL
  select o.member from Order o  -- 묵시적 조인
  -- where o.product.name = 'productA' 이렇게 계속 탐색 가능

  -- SQL 변환
  select m.*
  from Order o
      inner join Member m on o.member_id = m.id -- 묵시적으로 내부 조인이 일어났다

컬렉션 값 연관 경로: 묵시적으로 내부 조인이 일어난다. 더는 탐색할 수 없다. 단 FROM 절에서 조인을 통해 별칭을 얻으면 별칭으로 탐색할 수 있다.

  -- JPQL
  -- 성공
  select t.members from Team t 

  -- 실패, 컬렉션 값은 탐색이 불가 
  select t.members.username from Team t 
  -- 다음처럼 별칭을 얻어서 경로탐색을 해야 한다.
  select m.username from Team t join t.members m

  -- 컬렉션의 크기를 구할 수 있는 size기능 제공, 이를 사용하면 count함수를 사용하는 SQL로 변환된다.
  select t.members.size from Team t 

경로 탐색을 사용한 묵시적 조인 시 주의사항

항상 내부 조인이다.
컬렉션은 경로 탐색의 끝이다. 컬렉션에서 경로 탐색을 하려면 명시적으로 조인해서 별칭을 얻어야 한다.
경로 탐색은 주로 SELECT, WHERE 절(다른 곳에서도 사용됨)에서 사용하지만 묵시적 조인으로 인해 SQL의 FROM절에 영향을 준다.

단순하고 성능에 이슈가 없으면 문제가 안 되지만, 성능이 중요하면 분석하기 쉽도록 묵시적 조인보다는 명시적 조인을 사용하자.

10.2.9 서브 쿼리

JPQL도 SQL처럼 서브 쿼리를 지원한다.

사용가능: WHERE, HAVING 절
사용불가: SELECT, FROM 절
- 하이버네이트의 HQL은 SELECT 절의 서브 쿼리도 허용한다. 하지만 FROM 절의 서브 쿼리는 지원하지 않는다.

서브쿼리 예

-- 나이가 평균보다 많은 회원
select m from Member m
where m.age > (select avg(m2.age) from Member m2)

-- 한 건이라도 주문한 고객
select m from Member m
where (select count(o) from Order o where m = o.member) > 0

-- 한 건이라도 주문한 고객
-- size 이용, 위와 결과가 같다.(실행 SQL도 같다)
select m from Member m
where m.orders.size > 0

서브 쿼리 함수
서브 쿼리는 다음 함수들과 같이 사용할 수 있다.

EXISTS

문법: [NOT] EXISTS (subquery)

설명: 서브쿼리에 결과가 존재하면 참이다.

select m from Member m
where exists (select t from m.team t where t.name = '팀A')

{ALL | ANY | SOME}
- 문법: {ALL | ANY | SOME} (subquery)
- 설명: 비교 연산자와 같이 사용한다. {= | > | >= | < | <= | <>}
  - ALL: 조건을 모두 만족하면 참이다.
  - ANY 혹은 SOME: 둘은 같은 의미다. 조건을 하나라도 만족하면 참이다.
```
select o from Order o
where o.orderAmount > ALL (select p.stockAmount from Product p)

select m from Member m
where m.team = ANY (select t from Team t)
```
IN
- 문법: [NOT] IN (subquery)
- 설명: 서브쿼리의 결과 중 하나라도 같은 것이 있으면 참이다. 참고로 IN은 서브쿼리가 아닌곳에서도 사용한다.
```
select t from Team t
where t IN (select t2 From Team t2 JOIN t2.members m2 where m2.age >= 20)
```

10.2.10 조건식

타입 표현
JPQL에서 사용하는 타입은 다음과 같이 표시한다. 대소문자는 구분하지 않는다.

종류	설명	예제
문자	작은 따옴표 사이에 표현 작은 따옴표를 표현하고 싶으면 작은 따옴표 연속 두개('') 사용	'HELLO' 'She''s'
숫자	L(Long 타입 지정) D(Doublc 타입 지정) F(Float 타입 지정)	10L 10D 10F
날짜	DATE {d 'yyyy-mm-dd'} TIME {t 'hh-mm-ss'} DATETIME {ts 'yyyy-mm-dd hh-mm:ss.f'}	{d '2012-03-24'} {t '10-11-28'} {ts '2012-03-24 10-11-28.123'} m.createDate = {d '2012-03-24'}
Boolen	TRUE, FALSE
Enum	패키징명을 포함한 전체 이름을 사용해야 한다.	jpabook.MemberType.Admin
엔티티 타입	엔티티의 타입을 표현한다. 주로 상속과 관련해서 사용한다.	TYPE(m) = Member

연산자 우선 순위

경로 탐색 연산 (.)
수학 연산: +, -(단항 연산자), *, /, +, -
비교연산: =, >, >=, <, <=, <>
논리 연산: NOT, AND, OR

논리 연산과 비교식

논리 연산
- AND
- OR
- NOT
비교식
- =, >, >=, <, <=, <>

Between, IN, Like, NULL 비교

Between 식
- 문법: x [NOT] BETWEEN A AND B
- 설명: x는 A ~ B 사이의 값이면 참이다.(A, B값 포함)
IN 식
- 문법: x [NOT] IN
- 설명: X와 같은 값이 하나라도 있으면 참이다.
Like 식
- 문법: 문자표현식 [NOT] LIKE 패턴값 [ESCAPE 이스케이프문자]
- 설명: 문자표현식과 패텀값을 비교한다.
  - %(퍼센트): 아무 값들이 입력되어도 된다. 값이 없어도 된다.
  - _(언더라인): 한 글자는 아무 값이 입력되어도 되지만 값이 있어야 된다.
```
-- 회원A, 회원1..
where m.username like '회원_'

-- 회원3
where m.username like '__3'

-- 회원%
where m.username like '회원\%' ESCAPE '\'
```
NULL 비교식
- 문법: {단일값 경로 | 입력 파라미터} IS [NOT] NULL
- 설명: NULL인지 비교한다. NULL은 = 으로 비교하면 안 되고 꼭 IS NULL을 사용 해야 한다.
```
 where m.username is null
 where null = null -- 거짓
 where 1 = 1 -- 참
```

컬렉션 식
컬렉션에만 사용하는 특별한 기능이다. 컬렉션은 컬렉션 식 이외에 다른 식은 사용할 수 없다.

빈 컬렉션 비교 식

문법: {컬렉션 값 연관 경로} IS [NOT] EMPTY
설명: 컬렉션에 값이 비었으면 참

-- JPQL
select m from Member m
where m.orders is not empty

-- SQL 변환
select m.* from Member m
where exists (
  select o.id
  from Orders o
  where m.id = o.member_id
)

컬렉션의 멤버 식
- 문법: {엔티티나 값} [NOT] MEMBER [OF] {컬렉션 값 연관 경로}
- 설명: 엔티티마 값이 컬렉션에 포함되어 있으면 참
```
select t from Team t
where :memberParam member of t.members
```

스칼라 식
스칼라는 숫자, 문자, 날짜, case, 엔티티 타입같은 가장 기본적인 타입들을 말한다.

수학 식
- +, -: 단항 연산자 (양수, 음수)
- *, /, +, -: 사칙 연산
문자 함수

함수	설명	예제
CONCAT(문자1, 문자2, ...)	문자를 합한다.	CONCAT('A', 'B') = AB
SUBSTRING(문자, 위치, [길이])	위치부터 시작해 길이만큼 문자를 구한다. 길이 값이 없으면 나머지 전체 길이를 뜻한다.	SUBSTRING('ABCDEF', 2, 3) = BCD
TRIM([[LEADING \| TRAILING \| BOTH] [트림문자] FROM] 문자)	LEADING: 왼쪽만 트림 TRAILING: 오른쪽만 트림 BOTH: 양쪽 다 트림 기본값은 BOTH 트림 문자의 기본값은 공백(space)이다.	TRIM('ABC') = 'ABC'
LOWER(문자)	소문자로 변경	LOWER('ABC') = 'abc'
UPPER(문자)	대문자로 변경	UPPER('abc') = 'ABC'
LENGTH(문자)	문자 길이	LENGTH('ABC') = 3
LOCATE(찾을 문자, 원본 문자, [검색 시작 위치])	검색위치부터 문자를 검색한다. 1부터 시작, 못 찾으면 0 반환	LOCATE('DE', 'ABCDEFG') = 4

수학 함수

함수	설명	예제
ABS(수학식)	절대값을 구한다	ABS(-10) = 10
SQRT(수학식)	제곱근을 구한다.	SQRT(4) = 2.0
MOD(수학식, 나눌 수)	나머지를 구한다.	MOD(4, 3) = 1
SIZE(컬렉션 값 연관 경로식)	컬렉션의 크기를 구한다	SIZE(t.members)
INDEX(별칭)	LIST 타입 컬렉션의 위치값을 구함, 단 컬렉션이 @OrderColumn을 사용하는 LIST 타입일 때만 사용할 수 있다.	t.members m where INDEX(m) > 0

날짜 함수
날짜 함수는 데이터베이스의 현재 시간을 조회한다.
- CURRENT_DATE: 현재 날짜
- CURRENT_TIME: 현재 시간
- CURRENT_TIMESTAMP: 현재 날짜 시간

select CURRENT_DATE, CURRENT_TIME, CURRENT_TIMESTAMP from Team t

select e from Event e where e.endDate < CURRENT_DATE

하이버네이트는 날짜 타입에서 년, 월, 일, 시간, 분, 초 값을 구하는 기능을 지원한다.

-- YEAR, MONTH, DAY, HOUR, MINUTE, SECOND
select year(CURRENT_TIMESTAMP), month(CURRENT_TIMESTAMP) from Member

CASE 식
특정 조건에 따라 분기할 때 CASE 식을 사용한다.

기본 CASE

문법:

CASE
    {WHEN <조건식> THEN <스칼라식>}+
    ELSE <스칼라식>
END

select
    case when m.age <= 10 then '학생요금'
         when m.age >= 10 then '경로요금'
         else '일반요금'
    end
from Member m

심플 CASE

문법:

    CASE
        {WHEN <스칼라식1> THEN <스칼라식2>}+
        ELSE <스칼라식>
    END

select
    case t.name
        when '팀A' then '인센티브110%'
        when '팀B' then '인센티브120%'
        else '인센티브105%'
    end
from Team t

COALESCE

문법: COALESCE(<스칼라식> {, <스칼라식>}+)

설명: 스칼라식을 차례대로 조회해서 null이 아니면 반환한다.

-- m.username이 null이 아니면 '이름 없는 회원'을 반환한다.
select coalesce(m.username, '이름 없는 회원') from Member m

NULLIF
- 문법: NULLIF(<스칼라식>, <스칼라식>)
- 설명: 두 값이 같으면 null을 반환하고 다르면 첫 번째 값을 반환한다.
```
-- 관리자면 null을 반환하고 나머지는 본인 이름을 반환
select nullif(m.username, '관리자') from Member m
```

10.2.11 다형성 쿼리

JPQL로 부모 엔티티를 조회하면 그 자식 엔티티도 함께 조회된다.

@Entity
@Inheritance(strategy = InheritanceType.SINGLE_TABLE)
@DiscriminatorColumn(name = "DTYPE")
public abstract class Item {...}

@Entity
@DiscriminatorValue("B")
public class Book extends Item {
    private String author;
    ...
}

다음을 조회하면 Item의 자식도 함께 조회된다.

List resultList = em.createQuery("select t from Item i").getResultList();

-- 단일 테이블 전략(InheritanceType.SINGLE_TABLE) SQL
SELECT * FROM ITEM

-- 조인 전략(InheritanceType.JOINED) SQL
SELECT 
    i.ITEM_ID, i.DTYPE, i.name, i.price, i.stockQuantity,
    b.author, b.isbn,
    b.artist, a.ect,
    m.actor, m.director
FROM
    ITEM i
LEFT OUTER JOIN
    BOOK b on i.ITEM_ID = b.ITEM_ID
LEFT OUTER JOIN
    ALBUM a on i.ITEM_ID = a.ITEM_ID
LEFT OUTER JOIN
    MOVIE M on i.ITEM_ID = m.ITEM_ID

TYPE
TYPE은 엔티티의 상속 구조에서 조회 대상을 특정 자식 타입으로 한정할 때 주로 사용한다.

-- Item 중에 Book, Movie를 조회하라.
-- JPQL 
select i from Item i
where type(i) IN (Book, Movie)

-- SQL
SELECT i FROM Item i
WHERE i.DTYPE in ('B','M')

TREAT (JPA 2.1)
자바의 타입 캐스팅과 비슷한다. 상속 구조에서 부모 타입을 특정 자식 타입으로 다룰 때 사용한다.
JPA 표준은 FROM, WHERE 절에서 사용할 수 있지만, 하이버네이트는 SELECT 절에서도 사용할 수 있다.

-- JPQL
-- treat를 사용해서 부모 타입인 Item을 자식 타입인 Book으로 다룬다.
-- 따라서 Book의 author 필드에 접근 할 수 있다.
select i from Item i where treat(i as Book).author = 'kim'

10.2.12 사용자 정의 함수 호출 (JPA 2.1)

JPA 2.1부터 사용자 저의 함수를 지원한다.

문법

function_invocation::= FUNCTION(function_name {, function_arg}*)

예

select function('group_concat', i.name) from Item i

-- 하이버네이트 구현체는 축약 가능
select group_concat(i.name) from Item i

하이버네이트 구현체를 사용한다면 방언 클래스를 상속해서 구현하고, 사용할 데이터베이스 함수를 미리 등록해야 한다.

// 방언 클래스 상속
public class MyH2Dialect extends H2Dialect {
    public MyH2Dialect() {
        registerFunction(
            "group_concat",
            new StandardSQLFunction("group_concat", StandardBasicTypes.STRING)
        );
    }
}

<!-- 상속한 방언 클래스 등록 -->
<property name="hibernate.dialect" value="hello.MyH2Dialect">

10.2.13 기타 정리

enum은 = 비교 연산만 지원한다.
임베디드 타입은 비교를 지원하지 않는다.

EMPTY STRING

JPA 표준은 ‘‘을 길이 0인 Empty String으로 정했지만 데이터베이스에 따라 ‘‘를 NULL로 사용하는 데이터베이스도 있으므로 확인하고 사용해야 한다.

NULL 정의

조건을 만족하는 데이터가 하나도 없으면 NULL이다.
NULL은 알 수 없는 값(unknown value)이다. NULL과의 모든 수학적 계산 결과는 NULL이 된다.
NULL == NULL은 알 수 없는 값이다.
NULL is NULL은 참이다.

JPA 표준 명세 NULL(U), TRUE(T), FALSE(F)의 논리 계산 표

AND	T	F	U
T	T	F	U
F	F	F	F
U	U	F	U

OR	T	F	U
T	T	T	T
F	T	F	U
U	T	U	U

NOT
T	F
F	T
U	U

10.2.14 엔티티 직접 사용

기본 키 값
JPQL에서 엔티티 객체를 직접 사용하면 SQL에서는 해당 엔티티의 기본 키 값을 사용한다.

-- JPQL
-- 엔티티의 아이디를 사용
select count(m.id) from Member m

-- 엔티티를 직접 사용
select count(m) from Member m

// 엔티티를 파라미터로 직접 사용하는 방법
String sql = "select m from Member m where m = :member";
List resultList = em.createQuery(sql)
            .setParameter("member", member)
            .getResultList();


// 식별자 값을 직접 사용하는 방법
String sql = "select m from Member m where m.id = :memberId";
List resultList = em.createQuery(sql)
            .setParameter("memberId", 1L)
            .getResultList();

외래 키 값
외래 키 값도 엔티티 객체를 직접 사용할 수 있다.

// 엔티티를 파라미터로 직접 사용하는 방법
String sql = "select m from Member m where m.team = :team";
List resultList = em.createQuery(sql)
            .setParameter("team", team)
            .getResultList();


// 식별자 값을 직접 사용하는 방법
String sql = "select m from Member m where m.team.id = :teamId";
List resultList = em.createQuery(sql)
            .setParameter("teamId", 1L)
            .getResultList();

10.2.15 Named 쿼리: 정적 쿼리

Named 쿼리는 애플리케이션 로딩 시점에 JPQL 문법을 체크하고 미리 파싱해둔다. 따라서 에러 유무를 빨리 확인할 수 있고, 재사용하므로 성능상 이점도 있다.

Named 쿼리를 어노테이션에 정의

// @NamedQuery로 Named 쿼리 정의
@Entity
@NamedQuery(
    name = "Member.findByUsername",
    query = "select m from Member m where m.username = :username"
)
public class Member {
    ...
}

// @NamedQueries를 사용해 여러개의 @NamedQuery 지정
@Entity
@NamedQueries(
    @NamedQuery(
        name = "Member.findByUsername",
        query = "select m from Member m where m.username = :username"
    ),
    @NamedQuery(
        name = "Member.count",
        query = "select count(m) from Member m"
    )
)
public class Member {
    ...
}

// 사용
List<Member> resultList = em.createNamedQuery("Member.findByUsername", Member.class)
                        .setPrameter("username", "회원1")
                        .getResultList();

Named 쿼리에 Member.findByUsername 처럼 Member를 붙인 것은 기능적으로 특별한 의미가 있는 것이 아니다. 충동방지, 관리의 용이함을 위해 붙인 것이다.

10.3 Criteria

Criteria 쿼리는 JPQL을 자바 코드로 작성하도록 도와주는 빌더 클래스 API다. 문자가 아닌 코드로 JPQL을 작성하므로 문법 오류를 컴파일 단계에서 잡을 수 있다. 동적 쿼리를 안전하게 생성할 수 있다. 다만 코드가 복잡하고 장황해서 직관적으로 이해가 힘들다는 단점이 있다.

내용 생략 😅

10.4 QueryDSL

QueryDSL은 Criteria 처럼 JPQL 빌더 역할을 하는데 쉽고 간결하며, 그 모양도 쿼리와 비슷하게 개발할 수 있다.

QueryDSL은 오픈소스 프로젝트이다. 아래 사이트 참고

10.4.1 QueryDSL 설정

필요 라이브러리

<!-- QueryDSL JPA 라이브러리 -->
<dependency>
  <groupId>com.querydsl</groupId>
  <artifactId>querydsl-jpa</artifactId>
  <version>${querydsl.version}</version>
</dependency>

<!-- 쿼리 타입(Q)을 생성할 때 필요한 라이브러리 -->
<dependency>
  <groupId>com.querydsl</groupId>
  <artifactId>querydsl-apt</artifactId>
  <version>${querydsl.version}</version>
  <scope>provided</scope>
</dependency>

환경설정
QueryDSL을 사용하려면 엔티티를 기반으로 쿼리 타입 이라는 쿼리용 클래스를 생성해야 한다. 다음처럼 플러그인을 추가해야 한다.

<project>
  <build>
    <plugins>
        ...
        <plugin>
        <groupId>com.mysema.maven</groupId>
        <artifactId>apt-maven-plugin</artifactId>
        <version>1.1.3</version>
        <executions>
            <execution>
            <goals>
                <goal>process</goal>
            </goals>
            <configuration>
                <outputDirectory>target/generated-sources/java</outputDirectory>
                <processor>com.querydsl.apt.jpa.JPAAnnotationProcessor</processor>
            </configuration>
            </execution>
        </executions>
        </plugin>
        ...
    </plugins>
  </build>
</project>

이제 콘솔에서 mvc compile을 입력하면 outputDirectory에 지정한 target/generated-sources 위치에 QMember.java 처럼 Q로 시작하는 쿼리 타입들이 생성된다.

10.4.2 시작

간단 예제

public void queryDSL() {
    JPAQuery query = new JPAQuery(entityManager);
    QMember qMember = new QMember("m"); // 생성되는 JPQL의 별칭이 m
    List<Member> members = query.from(qMember)
                                .where(qMember.name.eq("회원1"))
                                .orderBy(qMember.name.desc)
                                .list(qMember);
}

기본 Q 생성
쿼리 타입(Q)는 사용하기 편리하도록 다음과 같이 기본 인스턴스를 보관하고 있다.

public class QMember extends EntityPathBase<Member> {
    public static final QMember member = new QMember("member1");
    ...
}

같은 엔티티를 조인하거나, 같은 엔티티를 서브쿼리에 사용하면 같은 별칭이 사용되므로 이때는 별징을 직접 지정해서 사용해야 한다.

QMember qMember = new QMember("m");  // 직접 지정
QMember qMember = QMember.member;    // 기본 인스턴스 사용

다음과 같이 import static을 활용하면 코드를 간결하게 작성 가능하다.

import static jpabook.jpashop.domain.QMember.member; // 기본 인스턴스

public void basic() {
    JPAQuery query = new JPAQuery(entityManager);
    List<Member> members = query.from(member)  // member 바로 사용
                        .where(member.name.eq("회원1"))
                        .orderBy(member.name.desc)
                        .list(member);
}

10.4.3 검색 조건 쿼리

// where and
query.from(customer)
    .where(customer.firstName.eq("Bob").and(customer.lastName.eq("Wilson")));

// where or
query.from(customer)
    .where(customer.firstName.eq("Bob").or(customer.lastName.eq("Wilson")));

// between
// 1800 ~ 2000 년도
doc.year.between("1800", "2000");

// contains
// sql의 like '%상품1%'
item.name.contains("상품1");

// startsWith
// sql의 like '오%'
person.firstName.startsWith("오");

10.4.4 결과 조회

쿼리 작성이 끝나고 결과 조회 메소드를 호출하면 실제 데이터베이스를 조회한다. 결과 조회 API는 com.mysema.query.Projectable에 정의되어 있다.

uniqueResult(): 조회 결과가 한 건일 때 사용. 조회 결과가 없으면 null을 반환하고 하나 이상이면 예외 발생
singleResult(): uniqueResult()와 같지만 결과가 하나 이상이면 처음 데이터를 반환
list(): 결과가 하나 이상일 때 사용. 결과가 없으면 빈 컬렉션 반환

10.4.5 페이징과 정렬

query.from(item)
    .where(item.price.gt(20000))
    .orderBy(item.price.desc(), item.stockQuantity.asc())
    .offset(10).limit(20)
    .list(item);

실제 페이징 처리를 하려면 검색된 전체 데이터 수를 알아야 한다. 이때는 list() 대신에 listResults()를 사용한다.

SearchResults<Item> result = query.from(item)
                .where(item.price.gt(20000))
                .orderBy(item.price.desc(), item.stockQuantity.asc())
                .offset(10).limit(20)
                .listResults(item);

long total = result.getTotal(); // 검색된 전체 데이터 수
List<Item> results = result.getResults(); // 조회된 데이터

10.4.6 그룹

query.from(item)
    .groupBy(item.price)
    .having(item.price.gt(1000))
    .list(item);

10.4.7 조인

조인은 innerJoin, leftJoin, rightJoin, fullJoin을 사용할 수 있다. 추가로 JPQL의 fetch조인도 사용할 수 있다.

조인의 기본 문법은 첫 번째 파라미터에 조인 대상을 지정하고, 두 번째 파라미터에 별칭으로 사용할 쿼리 타입을 지정한다.

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

// 기본 사용 방법
QCat cat = QCat.cat;
QCat mate = new QCat("mate");
QCate kitten = new QCat("kitten");
query.from(cat)
    .innerJoin(cat.mate, mate)
    .leftJoin(cat.kittens, kitten)
    .list(cat);


// 조인 on 사용
query.from(cat)
    .leftJoin(cat.kittens, kitten)
    .on(kitten.bodyWeight.gt(10.0))
    .list(cat);


// 페치 조인 사용
query.from(cat)
    .innerJoin(cat.mate, mate).fetch()
    .leftJoin(cat.kittens, kitten).fetch()
    .list(cat);

// 세타 조인 사용
query.from(cat, mate)
    .where(cat.mate.eq(mate))
    .list(cat);

10.4.8 서브 쿼리

서브 쿼리를 만들려면 com.mysema.query.jpa.JPASubQuery를 사용하면 된다.
서브 쿼리 결과가 하나면 unique(), 여러 건이면 list()를 사용한다.

// 서브 쿼리 한 건
QItem item = QItem.item;
QItem itemSub = new QItem("itemSub");

query.from(item)
    .where(item.price.eq(
        new JPASubQuery().from(itemSub).unique(itemSub.price.max())
    ))
    .list(item);



// 서브 쿼리 여러 건
QItem item = QItem.item;
QItem itemSub = new QItem("itemSub");

query.from(item)
    .where(item.in(
        new JPASubQuery().from(itemSub)
            .where(item.name.eq(itemSub.name))
            .list(itemSub)
    ))
    .list(item);

10.4.9 프로젝션과 결과 반환

select 절에 조회 대상을 지정하는 것을 프로젝션이라 한다.

프로젝션 대상이 하나
프로젝션 대상이 하나면 해당 타입으로 반환한다.

QItem item = QItem.item;
List<String> result = query.from(item).list(item.name);

여러 컬럼 반환고 튜플
프로젝션 대상이 여러 필드를 선택하면 QueryDSL은 기본적으로 com.mysema.query.Tuple이라는 내부 타입을 사용한다.

QItem item = QItem.item;
List<Tuple> result = query.from(item).list(item.name, item.price);

for (Tuple tuple : result) {
    tuple.get(item.name);   // name
    tuple.get(item.price);  // price
}

빈 생성
쿼리 결과를 엔티티가 아닌 특정 객체로 받고 싶으면 빈 생성 기능을 사용한다. QueryDSL은 다음을 사용해 객체를 생성한다.

프로퍼티 접근
필드 직접 접근
생성자 사용

public class ItemDTO {
    private String username;
    private String price;

    // 생성자 ...
    // Getter, Setter ...
}

프로퍼티 접근

QItem item = QItem.item;
List<ItemDTO> result = query.from(item)
.list(Projections.bean(ItemDTO.class, item.name.as("username"), item.price));

Projections.bean()메소드는 Setter를 사용해서 값을 채운다.

필드 직접 접근

QItem item = QItem.item;
List<ItemDTO> result = query.from(item)
.list(Projections.fields(ItemDTO.class, item.name.as("username"), item.price));

Projections.fields()메소드는 필드에 직접 접근해서 값을 채운다.

생성자 사용

QItem item = QItem.item;
List<ItemDTO> result = query.from(item)
.list(Projections.constructor(ItemDTO.class, item.name, item.price));

생성자를 사용하려면 지정한 프로젝션과 파라미터 순서가 같은 생성자가 필요하다.

DISTINCT distinct는 다음과 같이 사용한다.

query.distinct().from(item)...

10.4.10 수정, 삭제 배치 쿼리

QuertDSL도 수정, 삭제 같은 배치 쿼리를 지원한다. JPQL 배치 쿼리와 같이 영속성 컨텍스트를 무시하고 데이터베이스를 직접 쿼리한다는 점에 유의하자.

수정 배치 쿼리

QItem item = QItem.item;
JPAUpdateClause updateClause = new JPAUpdateClause(em, item);
long count = updateClause.where(item.name.eq("시골개발자의 JPA책"))
                    .set(item.price, item.price.add(100))
                    .execute();

삭제 배치 쿼리

QItem item = QItem.item;
JPADeleteClause deleteClause = new JPADeleteClause(em, item);
long count = deleteClause.where(item.name.eq("시골개발자의 JPA책")).execute();

10.4.11 동적 쿼리

com.mysema.query.BooleanBuilder를 사용하면 특정 조건에 따른 동적 쿼리를 편리하게 생성할 수 있다.

SearchParam param = new SearchParam();
param.setName("시골개발자");
param.setPrice(10000);

QItem item = QItem.item;

BooleanBuilder builder = new BooleanBuilder();
if (StringUtils.hasText(param.getName())) {
    builder.and(item.name.contains(param.getName()));
}

if (param.getPrice != null) {
    builder.and(item.price.gt(param.getPrice()));
}

List<Item> result = query.from(item).where(builder).list(item);

10.4.12 메소드 위임

메소드 위임 기능을 사용하면 쿼리 타입에 검색 조건을 직접 정의할 수 있다.

검색 조건 정의

public class ItemExpression {

    @QueryDelegate(Item.class)
    public static BooleanExpression isExpensive(QItem item, Integer price) {
        return item.price.gt(price);
    }
}

메소드 위임 기능을 사용하려면 정적(static) 메소드를 만들고 @QueryDelegate 어노테이션에 속성으로 이 기능을 적용할 엔티티를 지정한다.
정적 메소드의 첫 번째 파라미터에는 대상 엔티티의 쿼리 타입(Q)을 지정하고 나머지는 필요한 파라미터를 정의한다.

쿼리 타입(Q)에 생성된 결과
QItem에 생성된 결과는 다음과 같다.

public class QItem extends EntityPathBase<ITem> {
    ...
    public com.mysema.query.types.expr.BooleanExpression isExpensive(Integer price) {
        return ItemExpression.isExpensive(this, price);
    }
}

사용

query.from(item).where(item.isExpensive(30000)).list(item);

필요하다면 String, Date 같은 자바 기본 내장 타입에도 메소드 위임 기능을 사용할 수 있다.

@QueryDelegate(String.class)
    public static BooleanExpression isHelloStart(StringPath stringPath) {
        return stringPath.startsWith("Hello");
}

10.5 네이티브 SQL

JPQL은 표준 SQL이 지원하는 대부분의 문법과 SQL 함수들을 지원하지만 특정 데이터베이스에 종속적인 기능은 지원하지 않는다. 예를 들면 다음과 같은 것들이다.

특정 데이터베이스만 지원하는 함수, 문법, SQL쿼리 힌트
인라인뷰(From 절에서 사용하는 서브쿼리), UNION, INTERSECT
스토어드 프로시저

때로는 특정 데이터베이스에 종속적인 기능이 필요하다. JPA 구현체들은 JPA 표준보다 더 다양한 방법을 지원한다.

특정 데이터베이스만 사용하는 함수
- JPQL에서 네이티브 SQL 함수를 호출할 수 있다.(JPA 2.1)
- 하이버네이트는 데이터베이스 방언에 각 데이터베이스에 종속적인 함수들을 정의해두었다. 또한 직접 호출할 함수를 정의할 수도 있다.
특정 데이터베이스만 지원하는 SQL 쿼리 힌트
- 하이버네이트를 포함한 몇몇 JPA 구현체들이 지원한다.
인라인 뷰(From 절에서 사용하는 서브쿼리), UNION, INTERSECT
- 하이버네이트는 지원하지 않지만 몇몇 JPA 구현체들이 지원한다.
스토어 프로시저
- JPQL에서 스토어드 프로시저를 호출할 수 있다.(JPA 2.1)
특정 데이터베이스만 지원하는 문법
- 이때는 네이티브 SQL을 사용해야 한다.

다양한 이유로 JPQL을 사용할 수 없을 때 JPA는 SQL을 직접 사용할 수 있는 기능을 제공하는데 이를 네이티브 SQL이라 한다.

그렇다면 네이티브 SQL과 JDBC API를 직접 사용하는 것과의 차이점은 무엇일까? 네이티브 SQL을 사용하면 엔티티를 조회할 수 있고, JPA가 지원하는 영속성 컨텍스트의 기능을 그대로 사용할 수 있다.

10.5.1 네이티브 SQL 사용

// 결과 타입 정의
public Query createNativeQuery(String sqlString, Calss resultClass);

// 결과 타입을 정의할 수 없을 때
public Query createNativeQuery(String sqlString);

// 결과 매핑 사용
public Query createNativeQuery(String sqlString, String resultSetMapping);

내용 생략 😅

10.6 객체지향 쿼리 심화

10.6.1 벌크 연산

한 번에 수정하거나 삭제하는 벌크 연산을 사용할 수 있다.

UPDATE 벌크 연산

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

int count = em.createQuery(sqlString)
            .setParameter("stockAmount", 10)
            .executeUpdate();

DELETE 벌크 연산

String sqlString;
    "delete from Product p " +
    "where p.price < :price";

int count = em.createQuery(sqlString)
            .setParameter("price", 100)
            .executeUpdate();

벌크 연산의 주의점
벌크 연산을 사용할 때는 영속성 컨텍스트를 무시하고 데이터베이스에 직접 쿼리한다는 점에 주의해야 한다.

해결 방법

em.refresh() 사용
벌크 연산 먼저 실행
벌크 연산 수행 후 영속성 컨텍스트 초기화

10.6.2 영속성 컨텍스트와 JPQL

쿼리 후 영속 상태인 것과 아닌 것

영속 상태
- 엔티티
영속 상태 아닌 것
- 임베디드 타입
- 단순 필드 조회

em.find() 동작 순서

엔티티를 영속성 컨텍스트에서 먼저 찾고
없으면 데이터베이스에서 찾는다.

JPQL 동작 순서

최초 조회
- 데이터베이스에서 조회
- 엔티티를 영속성 컨텍스트에 등록
두 번째 조회
- 데이터베이스에서 조회
- 영속성 컨텍스트에 같은 엔티티 발견
- 새로 검색한 엔티티는 버리고 영속성 컨텍스트에 있는 기존 엔티티 반환

JPQL 특징 정리

JPQL은 항상 데이터베이스를 조회한다.
JPQL로 조회한 엔티티는 영속 상태다.
영속성 컨텍스트에 이미 존재하는 엔티티가 있으면 기존 엔티티를 반환한다.

10.6.3 JPQL과 플러시 모드

플러시 모드

em.setFlushMode(FlushModeType.AUTO);    // 커밋, 쿼리 실행 시 플러시 (기본값)
em.setFlushMode(FlushModeType.COMMIT);  // 커밋시에만 플러시

JPQL은 영속성 컨텍스트에 있는 데이터를 고려하지 않고 데이터베이스에서 데이터를 조회한다.
따라서 JPQL을 실행하기 전에 플러시를 통해 영속성 컨텍스트의 내용을 데이터베이스에 반영해야 한다.

10.7 정리

JPQL은 SQL을 추상화해서 특정 데이터베이스 기술에 의존하지 않는다.
Criteria나 QueryDSL은 JPQL을 만들어주는 빌더 역할을 할 뿐이므로 핵심은 JPQL을 잘 알아야 한다.
Criteria나 QueryDSL을 사용하면 동적으로 변하는 쿼리를 편리하게 작성할 수 있다.
Criteria는 JPA가 공식 지원하는 기능이지만 불편하다. QueryDSL은 JPA가 공식 지원하는 기능은 아니지만 편리하다.
JPA도 네이티브 SQL을 제공하므로 직접 SQL을 사용할 수 있다. 하지만 특정 데이터베이스에 종속적이 되므로 최대한 사용을 자제하자.
JPQL은 대량의 데이터를 수정하거나 삭제하는 벌크 연산을 지원한다.

11. 웹 애플리케이션 제작

내용 생략 😅

12. 스프링 데이터 JPA

12.1 스프링 데이터 JPA 소개

스프링 데이터 JPA 레퍼런스 문서

스프링 데이터 JPA는 스프링 프레임워크에서 JPA를 편리하게 사용할 수 있도록 지원하는 프로젝트다.
CURD를 처리하기 위한 공통 인터페이스를 제공한다.
인터페이스만 작성하면 실행 시점에 구현 객체를 동적으로 생성해서 주입해준다.
따라서 데이터 접근 계층을 개발할 때 구현 클래스 없이 인터페이스만 작성해도 개발을 완료할 수 있다.

12.2 스프링 데이터 JPA 설정

필요 라이브러리

<!-- 스프링 데이터 JPA -->
<dependency>
    <groupId>org.springframework.data</groupId>
    <artifactId>spring-data-jpa</artifactId>
    <version>${spring-data-jpa.version}</version>
</dependency>

환경 설정

<!-- xml -->
<!-- 리포지토리 인터페이스를 해당 패키지와 그 하위 패키지에서 검색한다. -->
<jpa:repositories base-package="jpabook.jpashop.repository" />

// java config class
@Configuration
@EnableJpaRepositories(basePackage = "jpabook.jpashop.repository")
public class AppConfig {}

12.3 공통 인터페이스 기능

스프링 데이터 JPA는 간단한 CRUD 기능을 공통으로 처리하는 JpaRepository 인터페이스를 제공한다.

// JpaRepository 인터페이스
public interface JpaRepository<T, ID extends Serializable> extends PagingAndSortingRepository<T, ID> {...}

// JpaRepository 인터페이스 사용
public interface MemberRepository extends JpaRepository<Member, Long> {}

12.4 쿼리 메소드 기능

스프링 데이터 JPA가 제공하는 쿼리 메소드 기능

메소드 이름으로 쿼리 생성
메소드 이름으로 JPA NamedQuery 호출
@Query 어노테이션을 사용해서 리포지터리 인터페이스에 쿼리 직접 정의

12.4.1 메소드 이름으로 쿼리 생성

// 이메일과 이름으로 회원을 조회 메소드를 정의
public interface MemberRepository extends JpaRepository<Member, Long> {
    List<Member> findByEmailAndName(String email, String name);
}

-- 스프링 데이터 JPA가 메소드를 분석해서 JPQL을 생성하고 실행한다.
select m from Member m where m.email =?1 and m.name = ?2

규칙
스프링 데이터 JPA 쿼리 생성 기능

키워드	예	JPQL 예
`Distinct`	`findDistinctByLastnameAndFirstname`	`select distinct … where x.lastname = ?1 and x.firstname = ?2`
`And`	`findByLastnameAndFirstname`	`… where x.lastname = ?1 and x.firstname = ?2`
`Or`	`findByLastnameOrFirstname`	`… where x.lastname = ?1 or x.firstname = ?2`
`Is`, `Equals`	`findByFirstname`,`findByFirstnameIs`,`findByFirstnameEquals`	`… where x.firstname = ?1`
`Between`	`findByStartDateBetween`	`… where x.startDate between ?1 and ?2`
`LessThan`	`findByAgeLessThan`	`… where x.age < ?1`
`LessThanEqual`	`findByAgeLessThanEqual`	`… where x.age <= ?1`
`GreaterThan`	`findByAgeGreaterThan`	`… where x.age > ?1`
`GreaterThanEqual`	`findByAgeGreaterThanEqual`	`… where x.age >= ?1`
`After`	`findByStartDateAfter`	`… where x.startDate > ?1`
`Before`	`findByStartDateBefore`	`… where x.startDate < ?1`
`IsNull`, `Null`	`findByAge(Is)Null`	`… where x.age is null`
`IsNotNull`, `NotNull`	`findByAge(Is)NotNull`	`… where x.age not null`
`Like`	`findByFirstnameLike`	`… where x.firstname like ?1`
`NotLike`	`findByFirstnameNotLike`	`… where x.firstname not like ?1`
`StartingWith`	`findByFirstnameStartingWith`	`… where x.firstname like ?1` (parameter bound with appended `%`)
`EndingWith`	`findByFirstnameEndingWith`	`… where x.firstname like ?1` (parameter bound with prepended `%`)
`Containing`	`findByFirstnameContaining`	`… where x.firstname like ?1` (parameter bound wrapped in `%`)
`OrderBy`	`findByAgeOrderByLastnameDesc`	`… where x.age = ?1 order by x.lastname desc`
`Not`	`findByLastnameNot`	`… where x.lastname <> ?1`
`In`	`findByAgeIn(Collection<Age> ages)`	`… where x.age in ?1`
`NotIn`	`findByAgeNotIn(Collection<Age> ages)`	`… where x.age not in ?1`
`True`	`findByActiveTrue()`	`… where x.active = true`
`False`	`findByActiveFalse()`	`… where x.active = false`
`IgnoreCase`	`findByFirstnameIgnoreCase`	`… where UPPER(x.firstname) = UPPER(?1)`

12.4.2 JPA NamedQuery

스프링 데이터 JPA는 메소드 이름으로 JPA Named 쿼리를 호출하는 기능을 제공한다.

// @NamedQuery로 Named 쿼리 정의
@Entity
@NamedQuery(
    name = "Member.findByUsername",
    query = "select m from Member m where m.username = :username"
)
public class Member {
    ...
}

// 도메인 클래스 + .(점) + 메소드 이름 으로 Named 쿼리를 찾아 실행한다.
// Named 쿼리가 없으면 메소드 이름으로 쿼리 생성 전략을 사용한다.
public interface MemberRepository extends JpaRepository<Member, Long> {
    List<Member> findByUsername(String username);
}

12.4.3 @Query, 리포지토리 메소드에 쿼리 정의

리포지토리 메소드에 직접 쿼리를 정의하려면 @Query 어노테이션을 사용한다.

// 메소드에 JPQL 쿼리 작성
public interface MemberRepository extends JpaRepository<Member, Long> {

    @Query("select m from Member m where m.username = ?1")
    Member findByUsername(String username);
}

// JPA 네이티브 SQL 지원
public interface MemberRepository extends JpaRepository<Member, Long> {

    @Query("SELECT * FROM MEMBER FROM WHERE USERNAME = ?0", nativeQuery = true)
    Member findByUsername(String username);
}

12.4.4 파라미터 바인딩

스프링 데이터 JPA는 위치 기반 파라미터 바인딩과 이름 기반 파라미터 바인딩을 지원한다. 기본값은 위치 기반이다.

-- 위치 기반, 기본값
select m from Member m where m.username = ?1

-- 이름 기반
select m from Member m where m.username = :name

public interface MemberRepository extends JpaRepository<Member, Long> {

    @Query("select m from Member m where m.username = :name")
    Member findByUsername(@Param("name") String username);
}

12.4.5 벌크성 수정 쿼리

스프링 데이터 JPA를 사용한 벌크성 수정, 삭제 쿼리는 @Modifying 어노테이션을 사용한다.

@Modifying
@Query("update Product p set p.price = price * 1.1 where p.stockAmount < :stockAmount")
int bulkPriceUp(@Param("stockAmount") String stockAmount);

벌크성 쿼리를 실행하고 나서 영속성 컨텍스트를 초기화하고 싶으면 @Modifying(clearAutomatically = true) 옵션을 준다.

12.4.6 반환 타입

스프링 데이터 JPA는 유연한 반환 타입을 지원한다. 한 건 이상이면 컬렉션을 사용하고, 단건이면 반환 타입을 지정한다.

List<Member> findByName(String name); // 컬렉션
Member findByEmail(String email);     // 단건

조회 결과가 없을 시

컬렉션: 빈 컬렉션 반환
단건: null 반환

조회 결과 1건

컬렉션: 1건의 데이터를 가진 컬렉션 반환
단건: 데이터 반환

조회 결과 2건 이상

컬렉션: 2건 이상 데이터를 가진 컬렉션 반환
단건: 예외 발생

12.4.7 페이징과 정렬

스프링 데이터 JPA는 쿼리 메소드에 페이징과 정렬 기능을 사용할 수 있도록 2가지 파라미터를 제공한다.

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

페이징과 정렬 사용 예

// count 쿼리 사용
Page<Member> findByName(String name, Pageable pageable);

// count 쿼리 사용 안 함
// total을 제외한 Page에서 제공하는 인터페이스 사용 가능
Slice<Member> findByName(String name, Pageable pageable);

// count 쿼리 사용 안 함
List<Member> findByName(String name, Pageable pageable);

// 정렬
List<Member> findByName(String name, Sort sort);

// 사용 방법
PageRequest pageRequest = new PageRequest(0, 10, new Sort(Direction.DESC, "name"));
Page<Member> result = memberRepository.findByName("김", pageRequest);

Slice 인터페이스

public interface Slice<T> extends Streamable<T> {
    int getNumber(); // 현재 페이지
    int getSize(); //페이지 크기
    int getNumberOfElements(); // 현재 페이지에 조회한 데이터 개수
    List<T> getContent(); // 현재 페이지에 조회한 데이터 
    boolean hasContent(); // 현재 페이지에 데이터가 있는지 여부 
    Sort getSort(); // 정렬 여부 
    boolean isFirst(); // 첫 번째 페이지인지 여부
    boolean isLast(); // 마지막 페이지인지 여부
    boolean hasNext(); // 다음 페이지가 있는지 여부
    boolean hasPrevious();  // 이전 페이지가 있는지 여부 
}

Page 인터페이스

public interface Page<T> extends Slice<T> {
    static <T> Page<T> empty() {
        return empty(Pageable.unpaged());
    }

    static <T> Page<T> empty(Pageable pageable) {
        return new PageImpl<>(Collections.emptyList(), pageable, 0);
    }

    int getTotalPages();     // 전체 페이지 개수
    long getTotalElements(); // 전체 데이터 개수
    <U> Page<U> map(Function<? super T, ? extends U> converter);
}

12.4.8 힌트

JPA 쿼리 힌트를 사용하려면 @QueryHint어노에티션을 사용한다. 이것은 SQL 힌트가 아니라 JPA구현체에게 제공하는 힌트다.

@QueryHints(value = {
    @QueryHint(name = "org.hibernate.readOnly", value = true)
})
Page<Member> findByName(String name, Pageable pageable);

12.5 명세

스프링 데이터 JPA는 JPA Criteria로 명세(SPECIFICATION)을 사용할 수 있도록 지원한다. 스프링 데이터 JPA를 이용한 조회 기능 참고

12.6 사용자 정의 리포지토리 구현

스프링 데이터 JPA로 리포지토리를 개발하면 인터페이스만 정의하고 구현체는 만들지 않는다. 하지만 메소드를 직접 구현해야 할 때도 있다.

사용자 정의 인터페이스 생성

// 인터페이스 이름은 자유롭게 작성 가능
public interface MemberRepositoryCustom {
    public List<Member> findMemberCustom();
}

사용자 정의 구현 클래스

/**
 * 클래스 이름은 리포지토리 인터페이스 이름 + Impl로 지어야 한다. 
 * 그러면 스프링 데이터 JPA가 사용자 정의 구현 클래스로 인식한다.
 */
public class MemberRepositoryImpl implements c {
    @Override
    public List<Member> findMemberCustom() {
        // 사용자 정의 구현...
    }
}

사용자 정의 인터페이스 상속

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

사용자 정의 구현 클래스 이름 규칙 변경

<jpa:repositories base-package="jpabook.jpashop.repository"
    repository-impl-postfix="Impl" />

@Configuration
@EnableJpaRepositories(
    basePackage = "jpabook.jpashop.repository",
    repositoryImplPostfix = "Impl"
)
public class AppConfig {}

12.7 Web 확장

스프링 데이터 프로젝트는 스프링 MVC에서 사용할 수 있는 편리한 기능을 제공한다.

12.7.1 설정

<bean class="org.springframework.data.web.config.SpringDataWebConfiguration">

@Configuration
@EnableWebMvc
@EnableSpringDataWebSupport // 추가
public class WebAppConfig {...}

12.7.2 도메인 클래스 컨버터 기능

도메인 클래스 컨버터는 HTTP 파라미터로 넘어온 엔티티의 아이디로 엔티티 객체를 찾아서 바인딩 해준다.

// URL: /member/memberUpdateForm?id=1

@Controller
public class MemberController {
    
    @RequestMepping("member/memberUpdateForm")
    public String memberUpdateForm(@RequestParam("id") Member member, Model model) {
        model.addAttribute("member", member);
        return "member/memberSaveForm";
    }
}

⚠주의
도메인 클래스 컨버터를 통해 넘어온 엔티티를 컨트롤러에서 직접 수정해도 실제 데이터베이스에는 반영되지 않는다. 이것은 영속성 컨텍스트의 동작 방식과 관련이 있다. 웹 애플리케이션에서 영속성 컨텍스트의 동작 방식과 OSIV에 관한 내용을 알아야 한다.

12.7.3 페이징과 정렬 기능

스프링 데이터가 제공하는 페이징과 정렬 기능을 스프링 MVC에서 편리하게 사용할 수 있다.

@Controller
public class MemberController {
    
    // 파라미터로 Pageable를 받는다
    @RequestMepping("members", method = RequestMethod.GET)
    public String list(Pageable pageable, Model model) {
        Page<Member> page = memberService.findMembers(pageable);
        model.addAttribute("member", page.getContent());
        return "member/memberList";
    }
}
// 예) /members?page=0&size=20&sort=name,desc&sort=address.city

요청 파라미터

page: 현재 페이지, 0부터 시작
size: 한 페이지에 노출할 데이터 건수
sort: 정렬 조건을 정의

참고
페이지를 1부터 시작하고 싶으면 PageableHandlerMethodArgumentResolver를 스프링 빈으로 직접 등록하고 setOneIndexedParameters를 true로 설정하면 된다.

접두사
사용해야 할 페이징 정보가 둘 이상이면 접두사를 사용해서 구분할 수 있다.

public String list(
    @Qualifier("member") pageable memberPageable,
    @Qualifier("order") pageable orderPageable.
    ...
)
// 예) /members?member_page=0&order_page=1

기본값
Pageable의 기본값은 page=0, size=20이다. 만약 기본값을 변경하고 싶으면 @PageableDefault 어노테이션을 사용한다.

@RequestMepping("members_page", method = RequestMethod.GET)
public String list(@PageableDefault(size = 12, sort = "name", 
    direction = Sort.Direction.DESC) Pageable pageable {
        ...
    }

12.8 스프링 데이터 JPA가 사용하는 구현체

내용 생략 😅

12.9 JPA 샵에 적용

내용 생략 😅

12.10 스프링 데이터 JPA와 QueryDSL 통합

스프링 데이터 JPA는 2가지 방법으로 QueryDSL을 지원한다.

12.10.1 QueryDslPredicateExecutor 사용

// 레포지토리에서 QueryDslPredicateExecutor 상속
public interface ItemRepository
    extends JpaRepository<Item, Long>, QueryDslPredicateExecutor<Item> {...}

// 사용
QItem item = QItem.item;
Iterable<Item> result = itemRepository.findAll(
    item.name.contains("장난감").and(item.price.between(10000, 20000))
);

⚠️경고
QueryDslPredicateExecutor는 기능의 한계가 있다. 예를 들어 join, fetch를 사용할 수 없다.

12.10.2 QueryDslRepositorySupport 사용

QueryDSL의 모든 기능을 사용하려면 JPAQuery 객체를 직접 생성해서 사용하면 된다. 스프링 데이터 JPA가 제공하는 QueryDslRepositorySupport를 상속 받아 사용하면 편리하게 QueryDSL을 사용할 수 있다.

// 사용자 정의 레포지토리
public interface CustomOrderRepository {
    public List<Order> search(OrderSearch orderSearch);
}

public class OrderRepositoryImpl extends QueryDslRepositorySupport
        implements CustomOrderRepository {
    public OrderRepositoryImpl() {
        super(Order.class);
    }

    @Override
    public List<Order> search(OrderSearch orderSearch) {
        QOrder order = QOrder.order;
        QMember member = QMember.member;

        JPAQuery query = from(order);
        // 검색 조건 쿼리...
        return query.list(order);
    }
}

13. 웹 애플리케이션과 영속성 관리

컨테이너 환경에서 JPA가 동작하는 방식을 이해하고, 컨테이너 환경에서 웹 애플리케이션을 개발할 때 발생할 수 있는 문제점과 해결방안을 알아본다.

13.1 트랜잭션 범위의 영속성 컨텍스트

스프링이나 J2EE 컨테이너 환경에서 JPA를 사용하면 컨테이너가 제공하는 전략을 따라야 한다.

13.1.1 스프링 컨테이너의 기본 전략

스프링 컨테이너는 트랜잭션 범위의 영속성 컨텍스트 전략을 기본으로 사용한다.

스프링 프레임워크를 사용하면 보통 비즈니스 로직을 시작하는 서비스 계층에 @Transactional 어노테이션을 선언해서 트랜잭션을 시작한다.

트렌잭션이 같으면 같은 영속성 컨텍스트를 사용한다.

트랜잭션이 다르면 다른 영속성 컨텍스트를 사용한다.

13.2 준영속 상태와 지연 로딩

컨테이너 환경의 기본 전략인 트랜잭션 범위의 영속성 컨텍스트 전략을 사용하면 트랜잭션이 없는 프리젠테이션 계층에서 엔티티는 준영속 상태다. 따라서 변경 감지와 지연 로딩이 동작하지 않는다.

준영속 상태에서 지연로딩을 시도하면 org.hibernate.LazyInitializationException 예외가 발생한다.

준영속 상태의 지연 로딩 해결 방법

뷰가 필요한 엔티티를 미리 로딩해두는 방법
- 글로벌 페치 전략 수정
- JPQL 페치 조인 (fetch join)
- 강제로 초기화
OSIV(open session in view)를 사용해서 엔티티를 영속 상태로 유지하는 방법

13.2.1 글로벌 페치 전략 수정

즉시 로딩 설정

@ManyToOne(fetch = FetchType.EAGER)

하지만 사용하지 않는 엔티티를 로딩하는 단점이 있다. 또 JPQL에서 N+1 문제가 발생한다.(페치 조인으로 해결 가능)

13.2.2 JPQL 페치 조인

-- JPQL fetch
select o from Order o join fetch o.member

무분별하게 사용하면 화면에 맞춘 리포지토리 메소드가 증가할 수 있다. 결국 프리젠테이션 계층이 알게 모르게 데이터 접근 계층을 침범하게 된다.

13.2.3 강제로 초기화

@Transactional
public Order findOrder(id) {
    Order order = orderRepository.findOrder(id);
    order.getMember().getName(); // 프록시 강제로 초기화
    return order;
}

하지만 프록시를 초기화하는 역할을 서비스 계층이 담당하면 뷰가 필요한 엔티티에 따라 서비스 계층의 로직을 변경해야 한다. 프리젠테이션 계층이 알게 모르게 서비스 계층을 침범하게 된다.

13.2.4 FACADE 계층 추가

FACADE 계층의 역할과 특징

프레젠테이션 계층과 도메인 모델 계층 간의 논리적 의존성을 분리해준다.
프리젠테이션 계층에서 필요한 프록시 객체를 초기화한다.
서비스 계층을 호출해서 비즈니스 로직을 실행한다.
리포지토리를 직접 호출해서 뷰가 요구하는 엔티티를 찾는다.

class OrderFacade {
    @Autowired
    OrderService orderService;

    public Order findOrder(id) {
        Order order = orderService.findOrder(id);
        order.getMember().getName(); // 프록시 강제로 초기화
        return order;
    }
}

class OrderService {

    public Order findOrder(id) {
        return orderRepository.findOrder(id);
    }
}

하지만 중간에 계층이 하나 더 끼어들게 되고, 결국 더 많은 코드를 작성해야 한다. 그리고 FACADE에는 단순히 서비스 계층을 호출만 하는 위임 코드가 상당히 많을 것이다.

13.2.5 준영속 상태와 지연 로딩의 문제점

결국 모든 문제는 엔티티가 프리젠테이션 계층에서 준영속 상태이기 때문에 발생한다.

13.3 OSIV

OSIV(Open Session In View)는 영속성 컨텍스트를 뷰까지 열어둔다는 뜻이다.

참고
OSIV는 하이버네이트에서 사용하는 용어다. JPA에서는 OEIV(Open EntityManager In View)라고 한다. 하지만 관례상 모두 OSIV로 부른다.

13.3.1 과거 OSIV: 요청 당 트랜잭션

클라이언트의 요청이 들어오자마자 서블릿 필터나 스프링 인터셉터에서 트랜잭션을 시작하고 요청이 끝날 때 트랜잭션도 끝내는 것을 요청 당 트랜잭션 방식의 OSIV라 한다.

요청 당 트랜잭션 방식의 OSIV 문제점

프리젠테이션 계층이 엔티티를 변경할 수도 있다.
엔티티를 변경하면 영속성 컨텍스트의 변경 감지 기능이 작동해 데이터베이스에 반영해 버린다.

프리젠테이션 계층에서 엔티티를 수정하지 못하게 막는 방법

엔티티를 읽기 전용 인터페이스로 제공
읽기 전용 메소드만 가지고 있도록 엔티티 래핑
DTO만 반환

하지만 코드량이 상당히 증가하는 단점이 있다.

13.3.2 스프링 OSIV: 비즈니스 계층 트랜잭션

스프링 프레임워크가 제공하는 OSIV는 비즈니스 계층에서 트랜잭션을 사용하는 OSIV다.

비즈니스 계층 트랜잭션 OSIV 특징

영속성 컨텍스트를 프리젠테이션 계층까지 유지한다.
프리젠테이션 계층에는 트랜잭션이 없으므로 엔티티를 수정할 수 없다.
프리젠테이션 계층에는 트랜잭션이 없지만 읽을 수는 있어서(트랜잭션 없이 읽기) 지연 로딩을 할 수 있다.

스프링 OSIV 주의사항
프리젠테이션 계층에서 엔티티를 수정한 직후에 트랜잭션을 시작하는 서비스 계층을 호출하면 영속성 컨텍스트를 플러시한다. 이 때 프리젠테이션 계층에서의 엔티티 수정 사항을 데이터베이스에 반영하는 문제가 발생한다.

class MemberController {
    
    public String viewMember(Long id) {
        Member member = memberService.getMember(id);
        member.setName("변경"); // 변경

        memberService.biz(); // 비스니스 로직 호출
        return "view";
    }
}

class MemberService {
    
    @Transactional
    public void biz() {
        // ...비즈니스 로직 실행
    }
}

해결방법
비즈니스 로직을 먼저 수행한다.

class MemberController {
    
    public String viewMember(Long id) {
        memberService.biz(); // 비스니스 로직 먼저 호출

        Member member = memberService.getMember(id);
        member.setName("변경"); // 변경을 나중에 수행
        return "view";
    }
}

13.3.3 OSIV 정리

스프링 OSIV의 특징

OSIV는 클라이언트의 요청이 들어올 때 영속성 컨텍스트를 생성해서 요청이 끝날 때까지 같은 영속성 컨텍스트를 유지한다.
엔티티 수정은 트랜잭션이 있는 계층에서만 동작한다.
트랜잭션이 없는 프리젠테이션 계층은 지연 로딩을 포함해서 조회만 할 수 있다.

스프링 OSIV의 단점

OSIV를 적용하면 같은 영속성 컨텍스트를 여러 트랜잭션이 공유할 수 있다는 점을 주의해야 한다. 특히 롤백 주의
프리젠테이션 계층에서 엔티티를 수정 후 비즈니스 로직을 수행하면 엔티티 수정사항이 반영될 수 있다.
지연 로딩에 의한 성능 튜닝시에 확인해야 할 부분이 넓다.

OSIV vs FACADE vs DTO
FACADE든 DTO든 OSIV를 사용하는 것과 비교해서 지루한 코드를 많이 작성해야 한다.

OSIV를 사용하는 방법이 만능은 아니다
복잡한 화면에서는 처음부터 화면에 맞는 JPQL로 필요한 데이터들만 조회해서 DTO로 반환하는 것이 더 나은 해결책일 수 있다.

OSIV는 같은 JVM을 벗어난 원격 상황에서는 사용할 수 없다
원격지에서 엔티티를 지연 로딩하는 것은 불가능하다. 그리고 엔티티는 생각보다 자주 변경된다. 따라서 외부 API는 엔티티를 직접 노출하기보다는 완충 역할을 할 수 있는 DTO로 변환해서 노출하는 것이 안전하다.

13.4 너무 엄격한 계층

OSIV를 사용하면 영속성 컨텍스트가 프리젠테이션 계층까지 살아있으므로 미리 초기화할 필요가 없다. 따라서 단순한 엔티티 조회는 컨트롤러에서 리포지토리를 직접 호출해도 문제가 없다.

14. 컬렉션과 부가 기능

이 장에서 다룰 내용

컬렉션: 다양한 컬렉션과 특징을 설명한다.
컨버터: 엔티티의 데이터를 변환해서 데이터베이스에 저장한다.
리스너: 엔티티에서 발생한 이벤트를 처리한다.
엔티티 그래프: 엔티티를 조회할 때 연관된 엔티티들을 선택해서 함께 조회한다.

14. 컬렉션

14.1.1 List + @OrderColumn

List 인터페이스에 @OrderColumn을 추가하면 순서가 있는 특수한 컬렉션으로 인식한다. 데이터베이스에 순서 값을 저장해서 조회할 때 사용한다.

@Entity
public class Board {
    ...
    @OneToMany(mappedBy = "board")
    @OrderColumn(name = "POSITION") // 추가
    private List<Comment> comments = new ArrayList<Comment>();
}


@Entity
public class Comment {
    private String comment;

    @ManyToOne
    @JoinColumn(name = "BOARD_ID")
    private Board board;
}

순서가 있는 컬렉션은 데이터베이스에 순서 값도 함께 관리한다.

@OrderColumn의 단점
@OrderColumn은 다음과 같은 단점들 때문에 실무에서 잘 사용하지 않는다.

@OrderColumn을 Board 엔티티에 매핑하므로 Comment는 POSITION의 값을 알 수 없다.
Comment를 INSERT할 때 Board.comments의 위치 값을 사용해서 POSITION의 값을 UPDATE 하는 SQL이 추가로 발생한다.
List를 변경하면 연관된 위치 값을 다 변경해야 한다. 예를 들어 댓글 2를 삭제하면 댓글 3, 댓글 4의 POSITION 값을 변경하는 UPDATE SQL이 2번 추가로 발생한다.
데이터베이스에서 강제로 삭제하고 다른 댓글 들의 POSITION 값을 수정하지 않으면 컬렉션을 순회할 때 NullPointException이 발생한다.

14.1.2 @OrderBy

@OrderBy는 데이터베이스의 ORDER BY절을 사용해서 컬렉션을 정렬한다.

@Entity
public class Team {
    ...
    @OneToMany(mappedBy = "team")
    @OrderBy("username desc, id asc")
    private Set<Member> members = new HashSet<Member>();
    ...
}

초기화할 때 실행된 SQL를 보면 ORDER BY가 사용된다.

SELECT M.* FROM MEMBER M
WHERE M.TEAM_ID = ?
ORDER BY M.MEMBER_NAME DESC, M.ID ASC

참고
하이버네이트는 Set에 @OrderBy를 적용해서 결과를 조회하면 순서를 유지하기 위해 LinkedHashSet을 내부에서 사용한다.

14.2 @Converter

컨버터를 사용하면 엔티티의 데이터를 변환해서 데이터베이스에 저장할 수 있다.

AttributeConverter를 이용한 밸류 매핑 처리 참고

14.3 리스너

JPA 리스너 기능을 사용하면 엔티티의 생명주기에 따른 이벤트를 처리할 수 있다.

리스너 참고

14.3.1 이벤트 종류

이벤트 종류와 발생 시점

14.3.2 이벤트 적용 위치

이벤트는 엔티티에서 직접 받거나 별도의 리스너를 등록해서 받을 수 있다.

엔티티에 직접 적용
@PrePersist, @PostLoad… 등을 이용한다.

@Entity
public class Duck {

    @Id @GeneratedValue
    private Long id;

    private String name;

    @PrePersist
    public void prePersist(){
        System.out.println("prePersist");
    }

    @PostPersist
    public void PostPersist (){
        System.out.println("PostPersist");
    }
    
    @PostLoad
    public void PostLoad(){
        System.out.println("PostLoad");
    }

    @PreRemove
    public void PreRemove (){
        System.out.println("PreRemove");
    }

    @PostRemove
    public void PostRemove(){
        System.out.println("PostRemove");
    }
    
    @PreUpdate
    public void PreUpdate(){
        System.out.println("PreUpdate");
    }
    
    @PostUpdate
    public void PostUpdate (){
        System.out.println("PostUpdate ");
    }    
}

별도의 리스너 등록
@EntityListeners를 사용한다.

@Entity
@EntityListeners(DuckListener.class)
public class Duck {...}

public class DuckListener {

    @PrePersist
    // 특정 타입이 확실하다면 특정 타입을 받을 수 있다.
    public void prePersist(Duck obj){
        System.out.println("prePersist");
    }

    @PostPersist
    public void PostPersist (Duck obj){
        System.out.println("PostPersist");
    }

    @PreRemove
    public void PreRemove (Object obj){
        System.out.println("PreRemove");
    }

    @PostRemove
    public void PostRemove(Object obj){
        System.out.println("PostRemove");
    }
}

리스너는 대상 엔티티를 파라미터로 받을 수 있다. 반환 타입은 void로 설정해야 한다.

기본 리스너 사용
모든 엔티티에서 이벤트를 처리하기위해 기본 리스너로 등록할 수 있다.

<?xml version="1.0" encoding="UTF-8"?>

<entity-mappings ...>
    <persistence-unit-metadata>
        <persistence-unit-defaults>
            <entity-listeners>
                <entity-listener class="jpabook.jpashop.domain.test.listener.DefaultListener">
                </entity-listener>
            </entity-listeners>
        </persistence-unit-defaults>
    </persistence-unit-metadata>
    
</entity-mappings>

더 세밀한 설정

javax.persistence.ExcludeDefaultListeners: 기본 리스너 무시
java.persistence.ExcludeSuperclassListners: 상위 클래스 이벤트 리스너 무시

@Entity
@EntityListeners(DuckListener.class)
@ExcludeDefaultListeners
@ExcludeSuperclassListners
public class Duck extends BaseEntity {...}

여러 리스너를 등록했을 때 이벤트 호출 순서

기본 리스너
부모 클래스 리스너
리스너
엔티티

14.4 엔티티 그래프

엔티티 그래프 기능은 엔티티 조회시점에 연관된 엔티티들을 함께 조회하는 기능이다.

정적으로 정의하는 Named 엔티티 그래프
동적으로 정의하는 엔티티 그래프

14.4.1 Named 엔티티 그래프 (정적)

// 주문을 조회할 때 연관된 회원도 함께 조회하는 엔티티 그래프
@NamedEntityGraph(
    name = "Order.withMember",
    attributeNodes = {@NamedAttributeNode("member")}
)
@Entity
@Table(name = "ORDERS")
public class Order {
 
    @Id
    @GeneratedValue
    @Column(name = "ORDER_ID")
    private Long id;
 
    @ManyToOne(fetch = FetchType.LAZY, optional = false)
    @JoinColumn(name = "MEMBER_ID")
    private Member member;  // 주문 회원
 
    ...
}

@NamedEntityGraph: Named 엔티티 그래프 정의한다.
name : 엔티티 그래프의 이름을 정의한다.
attributeNodes : 함께 조회할 속성을 선택한다. 이때 @NamedAttributeNode를 사용하고 그 값으로 함께 조회할 속성을 선택하면 된다.

Order.member가 지연 로딩으로 설정되어 있지만, 엔티티 그래프에서 함께 조회할 속성으로 member를 선택했으므로 이 엔티티 그래프를 사용하면 Order를 조회할 때 연관된 member도 함께 조회할 수 있다.

엔티티 그래프를 둘 이상 정의할 경우 @NamedEntityGraphs 사용한다.

14.4.2 em.find()에서 엔티티 그래프 사용

// 정의한 엔티티 그래프를 찾고
EntityGraph graph = em.getEntityGraph("Order.withMember");

// 엔티티 그래프는 JPA의 힌트 기능을 사용해서 동작
// 힌트의 값으로 찾아온 엔티티 그래프 사용
Map hints = new HashMap();
hints.put("javax.persistence.fetchgraph", graph);

// 조회할 때 힌트정보 포함
Order order = em.find(Order.class, orderId, hints);

14.4.3 subgraph

Order -> OrderItem -> Item 까지 함께 조회

@NamedEntityGraph(
    name = "Order.withAll",
    attributeNodes = {
        @NamedAttributeNode("member"),
        @NamedAttributeNode(value = "orderItems",subgraph = "orderItems")
    },
    subgraphs = @NamedSubgraph(
        name = "orderItems",
        attributeNodes = {@NamedAttributeNode("item")}
    )
)
@Entity
@Table(name = "ORDERS")
public class Order {
 
    @Id
    @GeneratedValue
    @Column(name = "ORDER_ID")
    private Long id;

    @ManyToOne(fetch = FetchType.LAZY, optional = false)
    @JoinColumn(name = "MEMBER_ID")
    private Member member;  // 주문 회원

    @OneToMany(mappedBy = "order", cascade = CascadeType.ALL)
    private List<OrderItem> orderItems = new ArrayList<OrderItem>();
    ...
}

@Entity
@Table(name = "ORDER_ITEM")
public class OrderItem {
 
    @Id
    @GeneratedValue
    @Column(name = "ORDER_ITEM_ID")
    private Long id;
 
    @ManyToOne(fetch = FetchType.LAZY)
    @JoinColumn(name = "ITEM_ID")
    private Item item;  // 주문 상품
    ...
}

Order.All이라는 Named 엔티티 그래프 정의했다. 이 엔티티 그래프는 다음과 같이 객체 그래프를 함께 조회한다.

Order -> Member
Order -> OrderItem
OrderItem -> Item (Order의 객체 그래프가 아니므로 subgraphs 속성에 정의)

JPQL에서 엔티티 그래프 사용

List<Order> resultList = 
    em.createQuery("select o from Order o where o.id = :orderId", Order.class)
    .setParameter("orderId", orderId)
    .setHint("javax.persistence.fetchgraph", em.getEntityGraph("Order.withAll"))
    .getResultList();

14.4.5 동적 엔티티 그래프

엔티티 그래프를 동적으로 구성하려면 createEntityGraph() 메소드 사용한다.

동적 엔티티 그래프

EntityGraph<Order> graph = em.createEntityGraph(Order.class);
graph.addAttributeNodes("member");

Map hints = new HashMap();
hints.put("javax.persistence.fetchgraph", graph);

Order order = em.find(Order.class, orderId, hints);

동적 엔티티 그래프 subgraph

EntityGraph<Order> graph = em.createEntityGraph(Order.class);
graph.addAttributeNodes("member");
Subgraph<OrderItem> orderItems = graph.addSubgraph("orderItems");
orderItems.addAttributeNodes("item");

Map hints = new HashMap();
hints.put("javax.persistence.fetchgraph", graph);

Order order = em.find(Order.class, orderId, hints);

14.4.6 엔티티 그래프 정리

ROOT에서 시작
엔티티 그래프틑 항상 조회하는 엔티티의 ROOT에서 시작해야 한다.

이미 로딩된 엔티티
영속성 컨텍스트에 해당 엔티티가 이미 로딩되어 있으면 엔티티 그래프가 적용되지 않는다.

Order order1 = em.find(Order.class, orderId); // 이미 조회
hints.put("javax.persistence.fetchgraph", em.getEntityGraph("Order.withMember"));

// 엔티티 그래프가 적용되지 않고 order1과 같은 인스턴스 반환
Order order2 = em.find(Order.class, orderId);

fetchgraph, loadgraph 차이

javax.persistence.fetchgraph: 엔티티 그래프에 선택한 속성만 함께 조회
javax.persistence.loadgraph: 엔티티 그래프에 선택한 속성 + FetchType.EAGER로 설정된 연관관계 조회

14.5 정리

JPA가 지원하는 컬렉션의 종류와 특징
컨버터를 사용하면 엔티티의 데이터를 변환해서 데이터베이스에 저장할 수 있다.
리스너를 사용하면 엔티티에서 발생한 이벤트를 받아서 처리할 수 있다.
페치 조인은 객체지향 쿼리를 사용해야 하지만 엔티티 그래프를 사용하면 객체 지향 쿼리를 사용하지 않아도 원하는 객체 그래프를 한 번에 조회할 수 있다.

15. 고급 주제와 성능 최적화

15.1 예외 처리

트랜잭션을 롤백하는 것은 데이터베이스의 반영사항만 롤백하는 것이지 수정한 자바 객체까지 원상태로 복구해주지 않는다.
엔티티 수정중 예외가 발생하면 데이터베이스의 데이터는 롤백되지만 객체는 수정된 상태로 엔티티 컨텍스트에 남아있다.
따라서 영속성 컨텍스트를 초기화한 다음에 사용해야 한다.
트랜잭션당 영속성 컨텍스트는 트랜잭션 종료 시점에 영속성 컨텍스트도 종료되므로 문제가 발생하지 않는다.
OSIV에서 스프링 프레임워크는 영속성 컨텍스트의 범위를 트랜잭션의 범위보다 넓게 설정하면 트랜잭션 롤백시 영속성 컨텍스트를 초기화해서 문제를 예방한다.

15.2 엔티티 비교

동일성 비교는 같은 영속성 컨텍스트의 관리를 받는 영속 상태의 엔티티에만 적용할 수 있다.
그 외에는 동등성 비교를 해야한다.
엔티티를 비교할 때는 @Id등과 같은 비즈니스키를 활용한 동등성 비교를 권장한다.

15.3 프록시 심화

15.3.1 영속성 컨텍스트와 프록시

영속성 컨텍스트는 자신이 관리하는 영속 엔티티의 동일성을 보장한다. 그럼 프록시로 조회한 엔티티의 동일성도 보장할까?

// 프록시 조회
Member refMember = em.getReference(Member.class, "member1");
// find 조회
Member findMember = em.find(Member.class, "member1");

출력 결과

refMember Type = 프록시 엔티티
findMember  Type = 프록시 엔티티

refMember는 프록시고 findMember는 원본 엔티티이므로 둘은 서로 다른 인스턴스로 생각할 수 있지만, 영속 엔티티의 동일성 보장을 위해 프록시로 조회된 엔티티에 대해서 같은 엔티티를 찾으면 프록시를 반환한다.

// find 조회
Member findMember = em.find(Member.class, "member1");
// 프록시 조회
Member refMember = em.getReference(Member.class, "member1");

출력 결과

findMember  Type = 원본 엔티티
refMember Type = 원본 엔티티

반대로 원본 엔티티를 먼저 조회하면 프록시를 반환할 이유가 없다. 따라서 refMember는 원본을 반환한다.

15.3.2 프록시 비교 타입

프록시는 원본 엔티티를 상속 받아서 만들어지므로 프록시로 조회한 엔티티의 타입을 비교할 때는 == 비교를 하면 안되고 대신에 instanceof를 사용해야한다.

Member refMember = em.getReference(Member.class, "member1");

Assert.assertFalse(Member.class == refMember.getClass()); // false
Assert.assertTrue(refMember instanceof Member); // true

15.3.3 프록시 동등성 비교

프로시 동등성 비교 주의사항

프록시의 타입 비교는 == 대신에 instanceof를 사용해야 한다.
프록시의 맴버변수에 직접 접근하면 안되고 접근자 메소드(Getter)를 사용해야 한다.

15.3.4 상속관계와 프록시

프록시를 부모 타입으로 조회하면 부모 타입을 기반으로 프록시가 생성된다.

Item proxyItem = em.getReference(Item.class, saveBook.getId());

// 예외발생 java.lang.ClassCastException
// Book book = (Book) proxyItem;

// 검증
Assert.assertFalse(proxyItem.getClass() == Book.class);
Assert.assertFalse(proxyItem instanceof Book);
Assert.assertTrue(proxyItem instanceof Item);

따라서 다음과 같은 문제가 있다.

instanceof 연산을 사용할 수 없다.
하위 타입으로 다운캐스팅을 할 수 없다.

몇 가지 해결방법
1. JPQL로 대상 직접 조회

Book jpqlBook = em.createQuery("select b from Book b where b.id=:bookId", Book.class);
            .setParameter("bookId", item.getId())
            .getSingleResult();

하지만 이 방법을 사용하면 다형성을 활용할 수 없다.

2. 기능을 위한 별도의 인터페이스 제공

// 특정 기능을 제공하는 인터페이스 생성
public interface TitleView {
    String getTitle();
}

@Entity
@Inheritance(strategy = InheritanceType.SINGLE_TABLE)
@DiscriminatorColumn(name = "DTYPE")
public abstract class Item implements TitleView {

    @Id @GeneratedValue
    @Column(name = "ITEM_ID")
    private Long id;

    private String name;
    private int price;
    
    ...
    // Getter, Setter
}

@Entity
@DiscriminatorValue("M")
public class Movie extends Item {

    private String director;
    private String actor;
    
    @Override
    public String getTitle() {
        return "[제목:" + getName() + " 감독:" + director + " 배우:" + actor + "]";
    }
}

@Entity
@DiscriminatorValue("B")
public class Book extends Item {
    
    private String author;
    private String isbn;

    @Override
    public String getTitle() {
        return "[제목:" + getName() + " 저자:" + author + "]";
    }
}

// 프록시 인터페이스 제공 사용
@Entity
public class OrderItem {
    @Id @GeneratedValue
    private Long id;

    @ManyToOne(fetch = FetchType.LAZY)
    @JoinColmn(name = "ITEM_ID")
    private Item item;

    ...

    public void printItem() {
        System.out.println("TITLE=" + item.getTitle());
    }
}

// Item의 구현체에 따라 각각 다른 getTitle() 메소드가 호출된다.
OrderItem orderItem = em.find(OrderItem.class, saveOrderItem.getId());
orderItem.printItem();

3. 비지터 패턴 사용
구현 내용 생략, 책 참고 😅

장점

프록시에 대한 걱정 없이 안전하게 원본 엔티티에 접근할 수 있다.
instanceof와 타입 캐스팅 없이 코드를 구현할 수 있다.
알고리즘과 객체 구조를 분리해서 구조를 수정하지 않고 새로운 동작을 추가할 수 있다.

단점

너무 복잡하고 이해하기 어렵다.
객체 구조가 변경되면 모든 Visitor를 수정해야 한다.

15.4 성능 최적화

15.4.1 N+1 문제

즉시 로딩은 JPQL을 실행할 때 N+1 문제가 발생할 수 있다.
지연 로딩은 연관된 컬렉션을 사용할 때 N+1 문제가 발생할 수 있다.

해결 방법
1. 페치 조인 사용

select distinct m from Member m join fetch m.orders

일대다 조인을 하면 결과가 늘어나서 중복된 결과가 나타날 수 있다. 따라서 distinct를 사용해서 중복을 제거하는 것이 좋다.

2. 하이버네이트 @BatchSize
하이버네이트가 제공하는 @BatchSize어노테이션을 사용하면 연관된 엔티티를 조회할 때 지정한 size만큼 SQL의 IN절을 사용해서 조회한다. 만약 조회한 회원이 10명인데 size=5로 지정하면 2번의 SQL만 추가로 실행한다.

@BatchSize
@OneToMany(mappedBy = "member", fetch = FetchType.EAGER)
private List<Order> orders = new ArrayList<Order>();

참고 hibernate.default_batch_fetch_size 속성을 사용하면 애플리케이션 전체에 기본으로 @BatchSize를 적용할 수 있다.

3. 하이버네이트 @Fetch(FetchMode.SUBSELECT)
하이버네이트가 제공하는 @Fetch어노테이션에 FetchMode.SUBSELECT로 사용하면 연관된 데이터를 조회할 때 서브 쿼리를 사용해서 N+1 문제를 해결한다.

@Fetch(FetchMode.SUBSELECT)
@OneToMany(mappedBy = "member", fetch = FetchType.EAGER)
private List<Order> orders = new ArrayList<Order>();

-- JPQL
select m from Member m where m.id > 10

-- 즉시 로딩으로 설정하면 조회 시점에
-- 지연 로딩으로 설정하면 지연로딩된 엔티티를 사용하는 시점에
-- SQL
SELECT O FROM ORDERS O
    WHERE O.MEMBER_ID IN (
        SELECT
            M.ID
        FROM
            MEMBER M
        WHERE M.ID > 10
    )

정리

즉시 로딩은 성능 최적화가 어렵다.
즉시 로딩은 사용하지 말고 지연 로딩만 사용하는 것을 추천한다.
성능 최적화가 꼭 필요한 곳에서만 JPQL 페치 조인 사용하자.

15.4.2 읽기 전용 쿼리의 성능 최적화

영속성 컨텍스트는 변경 감지를 위해 스냅샷 인스턴스를 보관하므로 더 많은 메모리를 사용하는 단점이 있다. 단순히 조회만 하고, 조회한 엔티티를 다시 조회할 일도 없고 수정할 일도 없다면 읽기 전용으로 엔티티를 조회하면 메모리 사용량을 최적화할 수 있다.

스칼라 타입으로 조회
스칼라 타입은 영속성 컨텍스트가 결과를 관리하지 않는다.

select o.id, o.name, o.price from Order p

읽기 전용 쿼리 힌트 사용
하이버네이트 전용 힌트인 org.hibernate.readOnly를 사용하면 엔티티를 읽기 전용으로 조회할 수 있다. 영속성 컨텍스트는 스냅샷을 보관하지 않는다.

TypedQuery<Order> query = em.createQuery("select o from Order o", Order.class);
query.setHint("org.hibernate.readOnly", true);

읽기 전용 트랜잭션 사용
스프링 프레임워크를 사용하면 트랜잭션을 읽기 전용 모드로 설정할 수 있다. 이 옵션은 트랜잭션을 커밋해도 영속성 컨텍스트를 플러시 하지 않는다. 스냅샷 비교와 같은 무거운 로직들을 수행하지 않으므로 성능이 향상된다.

@Transactional(readOnly = true)

추천 방법

읽기 전용 트랜잭션 사용: 플러시를 작동하지 않도록 해서 성능 향상
읽기 전용 엔티티 사용: 엔티티를 읽기 전용으로 조회해서 메모리 절약

15.4.3 배치 처리

영속성 컨텍스트에 너무 많은 엔티티가 저장되면 메모리 부족 오류가 발생할 수 있다.
따라서 이러한 배치 처리를 적절한 단위로 영속성 컨텍스트를 초기화해야 한다.
2차 캐시를 사용하고 있다면 2차 캐시에 엔티티를 보관하지 않도록 주의해야 한다.

JPA 등록 배치
많은 양의 엔티티를 한 번에 등록할 때 주의할 점은 영속성 컨텍스트에 엔티티가 계속 쌓이지 않도록 일정 단위마다 영속성 컨텍스트의 엔티티를 데이터베이스에 플러시하고 영속성 컨텍스트를 초기화해야 한다.

EntityManager em = entityManagerFactory.createEntityManager();
EntityTransaction tx = em.getTransaction();
tx.begin();

for(int i=0; i<100000; ++i){
    Product product = new Product("item"+ i, 10000);
    em.persist(product);

    //100건마다 플러시와 영속성 컨텍스트 초기화
    if( i % 100 == 0 ) {
        em.flush();
        em.clear();
    }
}

tx.commit();
em.close();​

JPA 수정 배치
배치 처리는 아주 많은 데이터를 조회해서 수정한다. 이때 수많은 데이터들을 한 번에 메모리에 올려둘 수 없어서 다음 방법을 주로 사용한다.

1. JPA 페이징 배치 처리

EntityManager em = entityManagerFactory.createEntityManager();
EntityTransaction tx = em.getTransaction();

tx.begin();
int pageSize = 100;

for (int i = 0; i < 10; ++i) {
    // 조회
    List < Product > resultList = em.createQuery("select p from Product p", Product.class)
        .setFirstResult(i * pageSize)
        .setMaxResults(pageSize)
        .getResultList();

    //비즈니스 로직 실행 
    for (Product product: resultList) {
        product.setPrice(product.getPrice + 100);
    }

    // 플러시, 초기화
    em.flush();
    em.clear();
}
tx.commit();
em.close();

2. 하이버네이트 scroll 사용
JPA는 JDBC 커서(CURSOR)를 지원하지 않는다. 따라서 커서를 사용하려면 하이버네이트 세션(SESSION)을 사용해야 한다. 하이버네이트는 scroll이라는 이름으로 JDBC 커서를 지원한다.

EntityTransaction tx = em.getTransaction();
Session session = em.unwrap(Session.class);

tx.begin();
ScrollableResults scroll = session.createQuery("select p from Product p")
    .setCacheMode(CacheMode.IGNORE) // 2차 캐시 기능을 끈다.
    .scroll(ScrollMode.FORWARD_ONLY);

int count = 0;
while (scroll.next()) {
    Product p = (Product) scroll.get(0);
    p.setPrice(p.getPrice() + 100);

    count++;
    if (count % 100 == 0) {
        session.flush(); //플러시
        session.clear(); //영속성 컨텍스트 초기화
    }
}
tx.commit();
session.close();

3. 하이버네이트 무상태 세션 사용

하이버네이트는 무상태 세션이라는 특별한 기능을 제공한다.
무상태 세션은 영속성 컨텍스트를 만들지 않고 심지어 2차 캐시도 사용하지 않는다.
엔티티를 수정하려면 무상태 세션이 제공하는 update() 메소드를 직접 호출해야 한다.

SessionFactory sessionFactory = entityManagerFactory.unwrap(SessionFactory.class);
StatelessSession session = sessionFactory.openStatelessSession();
Transaction tx = session.beginTransaction();
ScrollableResults scroll = session.createQuery("select p from Product p").scroll();

while (scroll.next()) {
    Product p = (Product) scroll.get(0);
    p.setPrice(p.getPrice() + 100);
    session.update(p); // 직접 update를 호출해야 한다.
}
tx.commit();
session.close();

15.4.4 SQL 쿼리 힌트 사용

JPA는 데이터베이스 SQL 힌트 기능을 제공하지 않는다. SQL 힌트를 사용하려면 하이버네이트를 직접 사용해야 한다. 여기서 말하는 SQL 힌트는 JPA 구현체에게 제공하는 힌트가 아니다. 데이터베이스 벤더에게 제공하는 힌트다.

SQL 쿼리 힌트 사용

Session session = em.unwrap(Session.class); // 하이버네이트 직접 사용

List<Member> list = session.creatQuery("select m from Member m")
            .addQueryHint("FULL (MEMBER)") // SQL 힌트 추가
            .list();

-- 실행된 SQL을 보면 추가한 힌트가 있다.
select
    /*+ FULL (MEMBER) */ m.id, m.name
from
    Member m

15.4.5 트랜잭션을 지원하는 쓰기 지연 성능 최적화

성능 최적화를 위해 SQL 배치를 이용한다. 하이버네이트에서 배치를 설정하면 데이터를 등록, 수정 삭제할 때 SQL 배치 기능을 사용한다

<property name="hibernate.jdbc.batch_size" value="50">

hibernate.jdbc.batch_size 속성의 속성 값을 50으로 주면 최대 50건씩 모아서 SQL 배치를 실행한다. 하지만 SQL 배치는 같은 SQL일 때만 유효하다.

em.persist(ner Member()); // 1
em.persist(ner Member()); // 2
em.persist(ner Member()); // 3
em.persist(ner Member()); // 4
em.persist(ner Child());  // 5, 다른 연산
em.persist(ner Member()); // 6
em.persist(ner Member()); // 7

이렇게 하면 1,2,3,4를 모아서 하나의 SQL 배치를 실행하고 5를 한 번 실행하고 6,7을 모아서 실행한다. 총 3번의 SQL 배치를 실행한다.

15.5 정리

JPA의 예외는 트랜잭션 롤백을 표시하는 예외와 표시하지 않는 예외로 나눈다. 트랜잭션을 롤백하는 예외는 심각한 예외이므로 트랜잭션을 강제로 커밋해도 커밋되지 않고 롤백된다.
영속성 컨텍스트의 엔티티는 비즈니스 키를 사용한 동등성 비교를 해야 한다.
프록시를 사용하는 클라이언트는 조회한 엔티티가 프록시인지 원본 엔티티인지 구분하지 않고 사용할 수 있어야 한다. 하지만 프록시는 기술적인 한계가 있으므로 한계점을 인식하고 사용해야 한다.
JPA를 사용할 때 N+1 문제를 가장 조심해야 한다. 주로 페치 조인으로 해결한다.
엔티티를 읽기 전용으로 조회하면 스냅샷을 유지할 필요가 없고 영속성 컨텍스트를 플러시하지 않아도 된다.
대량의 엔티티를 배치 처리하려면 적절한 시점에 꼭 플러시를 호출하고 영속성 컨텍스트도 초기화해야 한다.
JPA는 SQL 쿼리 힌트를 지원하지 않지만 하이버네이트 구현체를 사용하면 SQL 쿼리 힌트를 사용할 수 있다.

16. 트랜잭션과 락, 2차 캐시

16.1 트랜잭션과 락

트랜잭션 기초와 JPA가 제공하는 낙관적 락과 비관적 락에 대해 알아본다.

16.1.1 트랜잭션과 격리 수준

트랜잭션은 ACID라 하는 원자성(Atomicty), 일관성(Consistency), 격리성(Isolation), 지속성(Durability)을 보장해야 한다.

원자성: 트랜잭션 내에서 실행한 작업들은 마치 하나의 작업인 것처럼 모두 성공 하든가 모두 실패해야 한다.
일관성: 모든 트랜잭션은 일관성 있는 데이터베이스 상태를 유지해야 한다.
격리성: 동시에 실행되는 트랜잭션들이 서로에게 영향을 미치지 않도록 격리한다.
지속성: 트랜잭션을 성공적으로 끝내면 그 결과가 항상 기록되어야 한다.

ANSI 표준 트랜잭션의 격리 수준 4단계

READ UNCOMMITED
- 트랜잭션에서 변경하는 내용이 commit과 rollback여부에 관계 없이 다른 트랜잭션에게 노출된다.
READ COMMITTED
- 트랜잭션에서 변경한 레코드는 commit이 완료된 데이터만 조회할 수 있다.
- commit 전에 조회를 시도한다면 UNDO영역에 백업된 레코드를 조회할 수 있다.
REPEATABLE READ
- InnoDB 엔진에서 사용하는 기본 격리 수준.
- REPEATABLE READ란 하나의 트랜잭션 내부에서 같은 SELECT 문은 항상 같은 결과를 보여주는 것.
- MySQL InnoDB에서는 트랜잭션별로 식별자를 주고 트랜잭션에서 변경하는 데이터를 UNDO영역에 백업한다.
- 이 백업된 데이터와 트랜잭션 식별자로 동일 트랜잭션에서 동일 결과값을 보여줄 수 있도록 보장한다.
SERIALIZABLE
- 가장 높은 격리 수준.
- 레코드를 조회할 때 Shared Lock을 획득해야만 조회할 수 있다.
- 데이터를 변경할 때에는 Exclusive Lock을 획득해야만 변경할 수 있다.
- 즉 한 트랜잭션에서 사용하는 데이터는 다른 트랜잭션에서 접근할 수 없게 만든다.
- 데이터 정합성을 지키는 면은 가장 우수하지만 동시 처리 성능이 떨어진다.

격리 수준에 따른 문제점

DIRTY READ
- 트랜잭션에서 작업이 다 끝나지 않았지만 다른 트랜잭션에서 작업 내용을 볼 수 있는 것을 DIRTY READ라고 한다.
- 변경된 데이터가 롤백될지, 커밋될지 모르는 상황에서 작업 내용을 조회할 수 있기 때문에 데이터 정합성에 큰 문제를 유발할 수 있다.
NON REPEATABLE READ
- 하나의 트랜잭션에서 같은 SELECT문으로 조회할 때 마다 다른결과를 받을 수 있다면 이를 NON REPEATABLE READ상태라고 부른다.
PHANTOM READ
- 하나의 트랜잭션에서 같은 SELECT문으로 조회할 때 이전 SELECT에서는 존재하지 않던 값이 다음 SELECT에 조회되는 것을 의미한다.

트랜잭션 격리 수준과 문제점 정리

격리 수준	DIRTY READ	NON-REPEATABLE READ	PHANTOM READ
READ UNCOMMITED	O	O	O
READ COMMITTED		O	O
REPEATABLE READ			O
SERIALIZABLE

16.1.2 낙관적 락과 비관적 락 기초

JPA는 데이터베이스 트랜잭션 격리 수준을 READ COMMITED 정도로 가정한다. 만약 일부 로직에 더 높은 격리 수준이 필요하면 낙관적 락과 비관적 락 중 하나를 사용하면 된다.

낙관적 락
데이터베이스가 제공하는 락 기능을 사용하는 것이 아니라 JPA가 제공하는 버전 관리 기능을 사용한다. 트랜잭션을 커밋하기 전까지는 트랜잭션의 충돌을 알 수 없다는 특징이 있다.

비관적 락
트랜잭션의 충돌이 발생한다고 가정하고 우선 락을 걸고 보는 방법이다. 데이터베이스가 제공하는 락 기능을 사용한다. 대표적으로 select for update 구문이 있다.

두 번의 갱신 분실 문제
사용자 A가 수정하고 사용자 B가 1초 뒤에 수정 요청을 하게 되면 사용자 B의 수정사항만 남게 된다. 이것을 두 번의 갱신 분실 문제라 한다. 이를 해결하기 위한 3가지 선택 방법이 있다.

마지막 커밋만 인정하기: 사용자 A의 내용은 무시하고 마지막에 커밋한 사용자 B의 내용만 인정한다.
최초 커밋만 인정하기: 사용자 A가 이미 수정을 완료했으므로 사용자 B가 수정을 완료할 때 오류가 발생한다.
충돌하는 갱신 내용 병합하기: 사용자 A와 사용자 B의 수정사항을 병합한다.

16.1.3 @Version

JPA가 제공하는 낙관적 락을 사용하려면 @Version 어노테이션을 사용해서 버전 관리 기능을 추가해야 한다.

@Version 적용 가능 타입

Long (long)
Integer (int)
Shoort (short)
Timestamp

@Entity
public class Board {

	@Id
	private String id;
	private String title;

	@Version
	private Integer version;
}

이제부터 엔티티를 수정할 때 마다 버전이 하나씩 자동으로 증가한다. 그리고 엔티티를 수정할 때 조회 시점의 버전과 수정 시점의 버전이 다르면 예외가 발생한다.

// 트랜잭션 1 조회 title="제목A", version=1
Board board = em.find(Board.class, id);

// 트랜잭션 2에서 해당 게시물을 수정해서 title="제목C", version=2로 증가
board.setTitle("제목B"); // 트랜잭션 1 데이터 수정

save(board);
tx.commit(); //예외 발생, 데이터베이스 version=2, 엔티티 version=1

트랜잭션 1이 데이터를 제목 B로 변경하고 트랜잭션을 커밋하는 순간 엔티티를 조회할 때 버전과 데이터베이스의 현재 버전 정보가 다르므로 예외가 발생한다. 따라서 버전 정보를 사용하면 최초 커밋만 인정하기가 적용된다.

@Version으로 추가한 버전 관리 필드는 JPA가 직접 관리하므로 개발자가 임의로 수정하면 안 된다(벌크 연산 제외) 만약 버전 값을 강제로 증가 하려면 특별한 락 옵션을 선택하면 된다.

참고
벌크 연산은 버전을 무시한다. 벌크 연산에서 버전을 증가하려면 버전 필드를 강제로 증가시켜야 한다.
update Member m set m.name = '변경', m.version = m.version + 1

16.1.4 JPA 락 사용

참고
JPA를 사용할 때 추천하는 전략은 READ COMMITTED 트랜잭션 격리 수준 + 낙관적 버전 관리다. (두 번의 갱신 내역 분실 문제 예방)

락은 다음 위치에 적용할 수 있다.

EntityManager.lock(), EntityManager.find(), EntityManager.refresh()
Query.setLockMode() (TypeQuery 포함)
@NamedQuery

JPA가 제공하는 락 옵션은 javax.persistence.LockModeType에 정의되어 있다.

락 모드	타입	설명
낙관적 락	OPTIMISTIC	낙관적 락을 사용한다.
낙관적 락	OPTIMISTIC_FORCE_INCREMENT	낙관적 락 + 버전정보를 강제로 증가한다.
비관적 락	PESSIMISTIC_READ	비관적 락, 읽기 락을 사용한다.
비관적 락	PESSIMISTIC_WRITE	비관적 락, 쓰기 락을 사용한다.
비관적 락	PESSIMISTIC_FORCE_INCREMENT	비관적 락, 버전정보를 강제로 증가한다.
기타	NONE	락을 걸지 않는다.
기타	READ	JPA1.0 호환 기능이다. OPTIMISTIC과 같으므로 OPTIMISTIC을 사용하면 된다.
기타	WRITE	JPA1.0 호환 기능이다. OPTIMISTIC_FORCE_INCREMENT와 같다

16.1.5 JPA 낙관적 락

JPA가 제공하는 낙관적 락은 버전을 사용한다. 따라서 낙관적 락을 사용하려면 버전이 있어야 한다. 낙관적 락은 트랜잭션을 커밋하는 시점에 충돌을 알 수 있다는 특징이 있다. 낙관적 락의 옵션에 따른 효과를 알아보자.

NONE
락 옵션을 적용하지 않아도 엔티티에 @Version이 적용된 필드만 있으면 낙관적 락이 적용된다.

용도: 조회한 엔티티를 수정할 때 다른 트랜잭션에 의해 변경(삭제)되지 않아야 한다. 조회 시점부터 수정 시점까지를 보장한다.
동작: 엔티티를 수정할 때 버전을 체크하면서 버전을 증가한다.(UPDATE 쿼리 사용). 이때 데이터베이스의 버전 값이 현재 버전이 아니면 예외가 발생한다.
이점: 두 번의 갱신 분실 문제를 예방한다.

OPTIMISTIC
@Version만 적용했을 때는 엔티티를 수정해야 버전을 체크하지만 이 옵션을 추가하면 엔티티를 조회만 해도 버전을 체크한다. 한 번 조회한 엔티티는 트랜잭션을 종료할 때까지 다른 트랜잭션에서 변경되지 않음을 보장한다.

용도: 조회 시점부터 트랜잭션이 끝날 때까지 조회한 엔티티가 변경되지 않음을 보장한다.
동작: 트랜잭션을 커밋할 때 버전 정보를 조회해서 현재 엔티티의 버전과 같은지 검증한다. 만약 같지 않으면 예외가 발생한다.
이점: OPTIMISTIC 옵션은 DIRTY READ와 NON-REPEATABLE READ를 방지한다.

OPTIMISTIC_FORCE_INCREMENT
트랜잭션을 커밋할 때 UPDATE 쿼리를 사용해서 버전 정보를 강제로 증가시킨다.

용도: 논리적인 단위의 엔티티 묶음을 관리할 수 있다. 게시물과 첨부파일이 일대다, 다대일의 양방향 연관관계이고 첨부파일이 연관관계의 주인이다. 게시물을 수정하는 데 단순히 첨부파일만 추가하면 게시물의 버전은 증가하지 않는다. 이때 게시물의 버전도 강제로 증가하려면 OPTIMISTIC_FORCE_INCREMENT를 사용하면 된다.
동작: 트랜잭션을 커밋할 때 UPDATE 쿼리를 사용해서 버전 정보를 강제로 증가시킨다. 추가로 엔티티를 수정하면 수정 시 버전 UPDATE가 발생한다. 따라서 총 2번의 버전 증가가 나타날 수 있다.
이점: 강제로 버전을 증가해서 논리적인 단위의 엔티티 묶음을 버전 관리할 수 있다.

16.1.6 JPA 비관적 락

JPA가 제공하는 비관적 락은 데이터베이스 트랜잭션 락 메커니즘에 의존하는 방법이다. 주로 SQL 쿼리에 select for update 구문을 사용하면서 시작하고 버전 정보는 사용하지 않는다.

비관적 락의 특징

엔티티가 아닌 스칼라 타입을 조회할 때도 사용할 수 있다.
데이터를 수정하는 즉시 트랜잭션 충돌을 감지할 수 있다.

PESSIMISTIC_WRITE

용도: 데이터베이스에 쓰기 락을 건다
동작: 데이터베이스 select for update를 사용해서 락을 건다.
이점: NON-REPEATABLE READ를 방지한다. 락이 걸린 로우는 다른 트랜잭션이 수정할 수 없다.

PESSIMISTIC_READ
데이터를 반복 읽기만 하고 수정하지 않는 용도로 락을 걸 때 사용한다. 데이터베이스 대부분은 PESSIMISTIC_WRITE로 동작한다.

MySQL: lock in share mode
PostgreSQL: for share

PESSIMISTIC_FORCE_INCREMENT
비관적 락중 유일하게 버전 정보를 사용한다. 하이버네이트는 nowait를 지원하는 데이터베이스에 대해서 for update nowait 옵션을 적용한다.

오라클: for update nowait
PostreSQL: for update nowait
nowait를 지원하지 않으면 for update가 사용된다.

16.1.7 비관적 락과 타임아웃

비관적 락을 사용하면 락을 획득할 때까지 트랜잭션이 대기한다. 무한정 기다릴 수는 없으므로 타임아웃 시간을 줄 수 있다.

Map<String, Object> properties = new HashMap<String, Object>();

// 타임아웃 10초까지 대기 설정
properties.put("java.persistence.lock.timeout", 10000);

Board board = em.find(Board.class, "boardId", LockModeType.PESSIMISTIC_WRITE, properties);

16.2 2차 캐시

JPA가 제공하는 애플리케이션 범위의 캐시에 대해 알아보고 하이버네이트와 EHCACHE를 사용해서 실제 캐시를 적용해보자.

16.2.1 1차 캐시와 2차 캐시

영속성 컨텍스트로 얻을 수 있는 이점이 많지만, 일반적인 웹 애플리케이션 환경은 트랜잭션을 시작하고 종료할 때까지만 1차 캐시가 유효하다. OSIV를 사용해도 클라이언트의 요청이 들어올 때부터 끝날 때까지만 1차 캐시가 유효하다. 따라서 애플리케이션 전체로 보면 데이터베이스 접근 횟수를 획기적으로 줄이지는 못한다. 하이버네이트를 포함한 대부분의 JPA 구현체들은 애플리케이션 범위의 캐시를 지원하는데 이것을 공유 캐시 또는 2차 캐시라 한다.

1차 캐시
1차 캐시는 영속성 컨텍스트 내부에 있다. 엔티티 매니저로 조회하거나 변경하는 모든 엔티티는 1차 캐시에 저장된다. 트랜잭션을 커밋하거나 플러시를 호출하면 1차 캐시에 있는 엔티티의 변경 내역을 데이터베이스에 동기화 한다.

2차 캐시
2차 캐시는 애플리케이션 범위의 캐시다. 따라서 애플리케이션을 종료할 때까지 캐시가 유지된다. 분산 캐시나 클러스터링 환경의 캐시는 애플리케이션보다 더 오래 유지될 수도 있다. 2차 캐시를 적절히 활용하면 데이터베이스 조회 횟수를 획기적으로 줄일 수 있다.

2차 캐시의 특징

2차 캐시는 영속성 유닛 범위의 캐시다
2차 캐시는 조회한 객체를 그대로 반환하는 것이 아니라 복사본을 만들어서 반환한다.
2차 캐시는 데이터베이스 기본 키를 기준으로 캐시하지만 영속성 컨텍스트가 다르면 객체 동일성(a==b)을 보장하지 않는다.

16.2.2 JPA 2차 캐시 기능

캐시 모드 설정
2차 캐시를 사용하려면 javax.persistence.Cacheable 어노테이션을 사용하면 된다. @Cacheable은 @Cacheable(true), @Cacheable(false)를 설정할 수 있는데 기본값은 true다.

@Cacheable
@Entity
public class Member {

	@Id @GeneratedValue
	private Long id;
	...
}

shared-cache-mode를 설정해서 애플리케이션 전체(정확히는 영속성 유닛 단위)에 캐시를 어떻게 적용할지 옵션을 설정해야 한다.

<!-- 스프링 프레임워크 캐시 모드 설정 -->
<bean id="entityManagerFactory" class="org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean">
    <property name="sharedCacheMode" value="ENABLE_SELECTIVE">
    ...

캐시 모드는 javax.persistence.SharedCacheMode에 정의되어 있다.

캐시 모드	설명
ALL	모든 엔티티를 캐시한다.
NONE	캐시를 사용하지 않는다.
ENABLE_SELECTIVE	Cacheable(true)로 설정된 엔티티만 캐시를 적용한다.
DISABLE_SELECTIVE	모든 엔티티를 캐시하는데 Cacheable(false)로 명시된 엔티티는 캐시하지 않는다.
UNSPECIFIED	JPA 구현체가 정의한 설정을 따른다.

16.2.3 하이버네이트와 EHCACHE 적용

하이버네이트가 지원하는 캐시는 크게 3가지가 있다.

엔티티 캐시: 엔티티 단위로 캐시한다. 식별자로 엔티티를 조회하거나 컬렉션이 아닌 연관된 엔티티를 로딩할 때 사용한다.
컬렉션 캐시: 엔티티와 연관된 컬렉션을 캐시한다. 컬렉션이 엔티티를 담고 있으면 식별자 값만 캐시한다(하이버네이트 기능)
쿼리 캐시: 쿼리와 파라미터 정보를 키로 사용해서 캐시한다. 결과가 엔티티면 식별자 값만 캐시한다.(하이버네이트 기능)

환경설정
라이브러리 추가

<dependency>
    <groupId>org.hibernate</groupId>
    <artifactId>hibernate-ehcache</artifactId>
    <version>4.3.10.Final</version>
</dependency>

캐시 정책 설정

<!-- src/main/resources/ehcache.xml -->
<ehcache>
    <defaultCache
        maxElementsInMemory="10000"
        eternal="false"
        timeToIdleSeconds="1200"
        timeToLiveSeconds="1200"
        diskExpiryThreadIntervalSeconds="1200"
        memoryStoreEvictionPolicy="LRU"/>
</ehcache>

하이버네이트 캐시 사용 정보를 정의

# application.yml
spring:
  jpa:
    properties:
      hibernate:
        generate_statistics: true
        format_sql: true

        cache:
          use_second_level_cache: true
          region:
            factory_class: org.hibernate.cache.ehcache.EhCacheRegionFactory // EHCACHE

      javax:
        persistence:
          sharedCache:
            mode: ENABLE_SELECTIVE

hibernate.cache.use_second_level_cache: 2차 캐시를 활성화 한다. 엔티티 캐시와 컬렉션 캐시를 사용할 수 있다.
hibernate.cache.use_query_cach: 쿼리 캐시를 활성화 한다.
hibernate.cache.region.factory_class: 2차 캐시를 처리할 클래스를 지정한다.
hibernate.generate_statistics: 이 속성을 true로 설정하면 하이버네이트가 여러 통계정보를 출력해주는데 캐시 적용 여부를 확인할 수 있다.(성능에 영향을 주므로 개발 환경에서만 적용하는 것이 좋다)

@Cache
하이버네이트 전용인 @Cache 어노테이션을 사용하면 세밀한 캐시 설정이 가능하다.

@Cacheable // 엔티티 캐시
@Cache(usage = CacheConcurrencyStrategy.READ_WRITE) // 하이버네이트 전용, 캐시와 관련된 더 세밀할 설정 가능
@Entity
public class ParentMember {

	@Id @GeneratedValue
	private Long id;
	private String name;

	@Cache(usage = CacheConcurrencyStrategy.READ_WRITE) // 컬렉션도 캐시 적용 가능
	@OneToMany(mappedBy = "parentMember", cascade = CascadeType.ALL)
	private List<ChildMember> childMembers;
}

하이버네이트 @Cache 속성

속성	설명
usage	CacheConcurrencyStrategy를 사용해서 캐시 동시성 전략을 설정한다.
region	캐시 지역 설정
include	연관 객체를 캐시에 포함할지 선택한다. all, non-laze 옵션을 선택할 수 있다.(기본값 all)

CacheConcurrencyStrategy 속성

속성	설명
NONE	캐시를 설정하지 않는다.
READ_ONLY	읽기 전용으로 설정한다. 등록, 삭제는 가능하지만 수정은 불가능하다. 참고로 읽기 전용인 불변 객체는 수정되지 않으므로 하이버네이트는 2차 캐시를 조회할 때 객체를 복사하지 않고 원본 객체를 반환한다.
NONSTRICT_READ_WRITE	엄격하지 않은 읽고 쓰기 전략이다. 동시에 같은 엔티티를 수정하면 데이터 일관성이 깨질 수 있다. EHCACHE는 데이터를 수정하면 캐시 데이터를 무효화한다.
READ_WRITE	읽기 쓰기가 가능하고 READ COMMITTED 정도의 격리 수준을 보장한다.
TRANSACTIONAL	컨테이너 관리 환경에서 사용할 수 있다. 설정에 따라 REPEATABLE READ 정도의 격리 수준을 보장받을 수 있다.

캐시 동시성 전략 지원 여부

Cache	read-only	nonstrict-read-write	nonstrict-read-write	transactional
ConcurrentHashMap	yes	yes	yes
EHCache	yes	yes	yes	yes
Infinispan	yes			yes

캐시 영역
위에서 캐시를 적용한 코드(엔티티 코드)는 다음 캐시 영역에 저장된다.

엔티티 캐시 영역
- jpabook.jpashop.domain.test.cache.ParentMember
- 기본값으로 [패키지 명 + 클래스 명]을 사용
컬렉션 캐시 영역
- jpabook.jpashop.domain.test.cache.ParentMember.childMembers
- 엔티티 캐시 영역 이름 + 캐시한 컬렉션의 필드 명

필요하다면 @Cache(region = "customRegion", ...) 처럼 region 속성을 사용해서 캐시 영역을 직접 지정할 수 있다.

캐시 영역이 정해져 있으면 영역별로 세부 설정을 할 수 있다.

<ehcache>
    <defaultCache
        maxElementsInMemory="10000"
        eternal="false"
        timeToIdleSeconds="1200"
        timeToLiveSeconds="1200"
        diskExpiryThreadIntervalSeconds="1200"
        memoryStoreEvictionPolicy="LRU" />
    
    <!-- ParentMember를 600초 마다 캐시에서 제거 -->
    <cache
        name="jpabook.jpashop.domain.test.cache.ParentMember"
        maxElementsInMemory="10000"
        eternal="false"
        timeToIdleSeconds="600"
        timeToLiveSeconds="600"
        overflowToDisk="false" />
</ehcache>

쿼리 캐시

쿼리 캐시는 쿼리와 파라미터 정보를 키로 사용해서 쿼리 결과를 캐시하는 방법이다.
쿼리 캐시를 적용하려면 영속성 유닛 설정에 hibernate.cache.use_query_cache 옵션을 꼭 true로 설정해야 한다.
그리고 쿼리 캐시를 적용하려는 쿼리마다 org.hibernate.cacheable을 true로 설정하는 힌트를 주면 된다

// 쿼리 캐시 사용
em.createQuery("select i from Item i", Item.class)
    .setHint("org.hibernate.cacheable", true)
    .getResultList();
 
// @NamedQuery에 쿼리 캐시 적용
@Entity
@NamedQuery(
    hints = @QueryHint(name = "org.hibernate.cacheable", value = "true"),
    name = "Member.findByUsername",
    query = "select m.address from Member m where m.name = :username"
)
public class Member {...}

쿼리 캐시 영역
hibernate.cache.use_query_cache 옵션을 true로 설정해서 쿼리 캐시를 활성화 하면 다음 두 캐시 영역이 추가된다.

org.hibernate.cache.internal.StandardQueryCache: 쿼리 캐시를 저장하는 영역이다. 이곳에는 쿼리, 쿼리 결과 집합, 쿼리를 실행한 시점의 타임스탬프를 보관한다.
org.hibernate.cache.spi.UpdateTimestampsCache: 쿼리 캐시가 유효한지 확인하기 위해 쿼리 대상 테이블의 가장 최근 변경(등록, 수정, 삭제) 시간을 저장하는 영역이다. 이곳에는 테이블 명과 해당 테이블의 최근 변경된 타임스탬프를 보관한다.

쿼리 캐시는 캐시한 데이터 집합을 최신 데이터로 유지하려고 쿼리 캐시를 실행하는 시간과 쿼리 캐시가 사용하는 테이블들이 가장 최근에 변경된 시간을 비교한다. 쿼리 캐시를 적용하고 난 후에 쿼리 캐시가 사용하는 테이블에 조금이라도 변경이 있으면 데이터베이스에서 데이터를 읽어와서 쿼리 결과를 다시 캐시한다.

쿼리 캐시를 잘 활용하면 극적인 성능 향상이 있지만 빈번하게 변경이 있는 테이블에 사용하면 오히려 성능이 더 저하된다. 따라서 수정이 거의 일어나지 않는 테이블에 사용해야 효과를 볼 수 있다.

주의
org.hibernate.cache.spi.UpdateTimestampsCache 쿼리 캐시 영역은 만료되지 않도록 설정해야 한다. 해당 영역이 만료되면 모든 쿼리 캐시가 무효화된다. EHCACHE의 eternal="true" 옵션을 사용하면 캐시에서 삭제되지 않는다.

<cache
    name="org.hibernate.cache.spi.UpdateTimestampsCache"
    maxElementsInMemory="10000"
    eternal="true" />

쿼리 캐시와 컬렉션 캐시의 주의점
엔티티 캐시를 사용해서 엔티티를 캐시하면 엔티티 정보를 모두 캐시하지만 쿼리 캐시와 컬렉션 캐시는 결과 집합의 식별자 값만 캐시한다. 그리고 이 식별자 값을 한나씩 엔티티 캐시에 조회해서 실제 엔티티를 찾는다.

문제는 쿼리 캐시나 컬렉션 캐시만 사용하고 대상 엔티티에 엔티티 캐시를 적용하지 않으면 성능상 심각한 문제가 발생할 수 있다.

select m from Member m 쿼리를 실행했는데 쿼리 캐시가 적용되어 있다. 조회 결과는 100건이다.
결과 집합에는 식별자만 있르므로 한 건씩 엔티티 캐시 영역에서 조회한다.
Member 엔티티는 엔티티 캐시를 사용하지 않으므로 한 건씩 데이터베이스에서 조회한다.
100건의 SQL이 실행된다.

따라서 쿼리 캐시나 컬렉션 캐시를 사용하면 결과 대상 엔티티에는 꼭 엔티티 캐시를 적용해야 한다.

16.3 정리

트랜잭션의 격리 수준은 4단계가 있다. 격리 수준이 낮을수록 동시성은 증가하지만 격리 수준에 따른 다양한 문제가 발생한다.
영속성 컨텍스트는 데이터베이스 트랜잭션이 READ COMMITTED 격리 수준이어도 애플리케이션 레벨에서 반복 가능한 읽기(REPEATABLE READ)를 제공한다.
JPA는 낙관적 락과 비관적 락을 지원한다. 낙관적 락은 애플리케이션이 지원하는 락이고, 비관적 락은 데이터베이스 트랜잭션 락 메커니즘에 의존한다.
2차 캐시를 사용하면 애플리케이션의 조회 성능 극적으로 끌어올릴 수 있다.

감사합니다 🙇🏻‍♂️

자바 ORM 표준 JPA 프로그래밍

Twitter Facebook LinkedIn

Oh

1. JPA 소개

1.1 SQL을 직접 다룰 때 발생하는 문제점

1.1.1 반복, 반복 그리고 반복

1.1.2 SQL에 의존적인 개발

1.1.3 JPA와 문제 해결

1.2 패러다임 불일치

1.2.1 상속

1.2.2 연관관계

1.2.3 객체 그래프 탐색

1.2.4 비교

1.2.5 정리

1.3 JPA란 무엇인가?

1.3.1 JPA 소개

1.3.2 왜 JPA를 사용해야 하는가?

1.4 정리

2. JPA 시작

2.1 이클립스 설치와 프로젝트 불러오기

2.2 H2 데이터베이스 설치

2.3 라이브러리와 프로젝트 구조

2.4 객체 매핑 시작

2.5 객체 매핑 시작

2.5.1 데이터베이스 방언

2.6 애플리케이션 개발

2.6.1 엔티티 매니저 설정

2.6.2 트랜잭션 관리

2.6.3 비즈니스 로직

2.6.4 JPQL

2.7 정리

3. 영속성 관리

3.1 엔티티 매니저 팩토리와 엔티티 매니저

3.2 영속성 컨텍스트란?

3.3 엔티티의 생명주기

3.4 영속성 컨텍스트의 특징

3.4.1 엔티티 조회

3.4.2 엔티티 등록

3.4.3 엔티티 수정

3.4.4 엔티티 삭제

3.5 플러시

3.5.1 플러시 모드 옵션

3.6 준영속

3.6.1 엔티티를 준영속 상태로 전환: detach()

3.6.2 영속성 컨텍스트 초기화: clear()

3.6.3 영속성 컨텍스트 종료: close()

3.6.4 준영속 상태의 특징

3.6.5 병합: merge()

3.7 정리

4. 엔티티 매핑

4.1 @Entity

4.2 @Table

4.3 다양한 매핑 사용

4.4 데이터베이스 스키마 자동 생성

4.5 DDL 생성 기능

4.6 DDL 생성 기능

4.6.1 기본 키 직접 할당 전략

4.6.2 IDENTITY 전략

4.6.3 SEQUENCE 전략

4.6.4 TABLE 전략

4.6.5 AUTO 전략

4.6.6 기본 키 매핑 정리

4.7 필드와 컬럼 매핑: 레퍼런스

4.7.1 @Column

4.7.2 @Enumerated

4.7.3 @Temporal

4.7.4 @Lob

4.7.5 @Transient

4.7.6 @Access

5. 연관관계 매핑 기초

5.1 단방향 연관관계

5.1.1 순수한 객체 연관관계

5.1.2 테이블 연관관계

5.1.3 객체 관계 매핑

5.1.4 @JoinColumn

5.1.5 @ManyToOne

5.2 연관관계 사용

5.2.1 저장

5.2.2 조회

5.2.3 수정

5.2.4 연관관계 제거

5.2.5 연관관계 삭제