[JPA] JPA 기초

JPA 소개

JPA

• Java Persistnce API
• Java 진영의 ORM 표준

 

ORM

• Object-relational mapping (객체 관계 매핑)
• 객체는 객체대로 설계하고, 관계형 데이터베이스는 관계형 데이터베이스대로 설계하고, ORM 프레임워크가 객체와 관계형 데이터베이스를 중간에서 매핑
• 대중적인 언어에는 대부분 ORM 기술이 존재

 

JPA는 애플리케이션과 JDBC 사이에서 동작

참고) JDBC(Java Database Connectivity)는 자바에서 데이터베이스에 접속할 수 있도록 하는 자바 API이다.

트랜잭션(Transaction)은 데이터베이스의 상태를 변화시키기 해서 수행하는 작업의 단위이다. 하나의 쿼리문이 아니다.

 

JPA 동작 - 저장

persist를 한다면, MemberDAO(EntityManager)가 Entity Object를 JPA에 전달하고, Entity Object는 JPA가 알아서 분석하고, INSERT까지 해준다.

 

참고) DAO는 Data Access Object로 DB에 접근하는 역할을 하는 객체를 의미한다.

 

JPA 동작 - 조회

MemberDAO(EntityManager)가 JPA에게 id를 넘기면, JPA가 SELECT 해서 Entity Object를 반환한다.

 

JPA는 표준 명세

우리는 JPA라는 표준 인터페이스에 Hibernate라는 구현체를 쓴다.

 

JPA와 CRUD

• 저장: em.persist(member)
• 조회: Member member = em.find(Member.class, memberId)
• 수정: member.setName(“변경할 이름”)
• 삭제: em.remove(member)

 

JPA의 성능 최적화 기능

JPA가 중간에 있기 때문에 가능한 일들이다.

 

1차 캐시와 동일성(identity) 보장

String memberId = "100";
Member m1 = jpa.find(Member.class, memberId); //SQL
Member m2 = jpa.find(Member.class, memberId); //캐시
println(m1 == m2) //true

 

트랜잭션을 지원하는 쓰기 지연 - INSERT

1. 트랜잭션을 커밋할 때까지 INSERT SQL을 모아서 저장
2. JDBC BATCH SQL 기능을 사용해서 한번에 SQL 전송

transaction.begin(); // [트랜잭션] 시작
em.persist(memberA);
em.persist(memberB);
em.persist(memberC);
//여기까지 INSERT SQL을 데이터베이스에 보내지 않는다.
//커밋하는 순간 데이터베이스에 INSERT SQL을 모아서 보낸다.
transaction.commit(); // [트랜잭션] 커밋

 

지연 로딩(Lazy Loading)

 

JPA 시작

JPA 구동 방식

 

영속성 관리 - 내부 동작 방식

영속성 컨텍스트

• 엔티티를 영구 저장하는 환경이라는 의미이다.
• em.persist(entity)는 entity를 DB가 아니라 영속성 컨텍스트에 저장하는 것이다.
• 영속성 컨텍스트는 논리적인 개념이다. 
• 엔티티 매니저를 통해서 영속성 컨텍스트에 접근한다.

 

엔티티의 생명주기

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

 

비영속

// 객체를 생성하기만 한 상태(비영속)
Member member = new Member();
member.setId("member1");
member.setUsername("회원1");

 

영속

//객체를 생성한 상태(비영속)
Member member = new Member();
member.setId("member1");
member.setUsername(“회원1”);

EntityManager em = emf.createEntityManager();
em.getTransaction().begin();

//객체를 영속성 컨텍스트에 저장한 상태(영속)
em.persist(member);

em.persist(member)를 했을 때 DB에 쿼리가 날라가는게 아니라, 트랜잭션이 커밋될 때 쿼리가 날라간다.

 

준영속

//영속성 컨텍스트에 있는 엔티티를 분리한 상태(준영속)
em.detach(member);

 

삭제

//객체를 삭제한 상태(삭제)
em.remove(member);

 

영속성 컨텍스트의 이점

엔티티 조회, 1차 캐시

//엔티티를 생성한 상태(비영속)
Member member = new Member();
member.setId("member1");
member.setUsername("회원1");

//엔티티를 영속
em.persist(member);

EntityManager로 영속성 컨텍스트에 접근하지만, 임시적으로 같다고 취급한다.

 

1차 캐시에 있는 Entity를 조회하는 경우

Member member = new Member();
member.setId("member1");
member.setUsername("회원1");

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

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

영속성 컨텍스트에는 1차 캐시가 있어서 find를 하면, 1차 캐시에서 먼저 조회한다.

 

1차 캐시에 없는 Entity를 조회하는 경우

Member findMember2 = em.find(Member.class, "member2");

1차 캐시에 없는 경우에는 데이터베이스에서 조회하고, 영속성 컨텍스트의 1차 캐시에 저장하고 반환한다.

같은 엔티티를 조회하는 경우, 1차 캐시에서 조회하므로 첫번째 경우와 달리 쿼리문이 날라가지 않는다.

 

참고) 1차 캐시는 사용자 하나(=트랜잭션 하나)에만 연관이 있다.

 

영속성 엔티티의 동일성 보장

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

System.out.println(a == b); //동일성 비교 true

 

트랜잭션을 지원하는 쓰기 지연

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

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

//커밋하는 순간 데이터베이스에 INSERT SQL을 보낸다.
transaction.commit(); // [트랜잭션] 커밋

 

em.persist를 하면, 1차 캐시에 엔티티를 저장할 뿐만 아니라, INSERT SQL을 생성하여 쓰기 지연 SQL 저장소에 저장한다. 그 후, transaction.commit()이 일어난 경우에 DB로 쿼리문을 날린다. 매번 DB로 쿼리문을 날리지 않으므로 최적화의 장점이 있다.

 

엔티티 수정 - 변경 감지 = 더티 체킹

EntityManager em = emf.createEntityManager();
EntityTransaction transaction = em.getTransaction();
transaction.begin(); // [트랜잭션] 시작

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

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

//em.update(member) 또는 em.persist(member)가 없어도 변경내용이 반영됨
transaction.commit(); // [트랜잭션] 커밋

 

JPA는 commit이 호출되면, flush()가 호출되고, 엔티티와 스냅샷을 비교한다. 비교한 내용을 바탕으로 UPDATE 쿼리문을 쓰기 지연 SQL 저장소에 저장한다. 쓰기 지연 SQL 저장소에 있는 쿼리들을 flush하고, commit한다.

 

참고) 스냅샷은 읽어온 시점의 상태를 의미한다.

 

플러시

• 영속성 컨텍스트의 변경 내용을 데이터베이스에 반영하는 것이다.
• 플러시가 발생하면 변경 감지가 일어나고,  엔티티 수정 쿼리를 쓰기 지연 SQL 저장소에 등록하고, 쓰기 지연 SQL 저장소의 쿼리를 데이터베이스에 전송한다.
• 플러시를 하더라도 1차 캐시에는 변함이 없다. 즉, 1차 캐시에 있는 것이 사라지지 않는다는 의미이다.
• 트랜잭션이라는 작업 단위가 중요하기 때문에 커밋 직전에만 플러시하면 된다. 커밋하면 자동으로 플러시된다.

 

참고) flush는 쿼리를 전송하는 역할이고 commit은 내부적으로 flush를 수행한 뒤 트랜잭션을 끝내는 역할

 

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

• em.flush() - 직접 호출
• 트랜잭션 커밋 - 플러시 자동 호출
• JPQL 쿼리 실행 - 플러시 자동 호출

 

준영속 상태로 만드는 방법

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

 

엔티티 매핑

객체와 테이블 매핑

@Entity

• @Entity가 붙은 클래스는 JPA가 관리하는 엔티티이다. 데이터베이스의 테이블과 매핑된다.
• 파라미터가 없는 public 또는 protected 기본 생성자가 필수이다.
• final, enum, interface, inner 클래스 사용 불가

 

@Table

• @Table은 엔티티와 매핑할 테이블 지정

 

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

• DDL을 애플리케이션 실행 시점에 자동 생성하는 기능이다.
• 테이블을 직접 설정하지 않아도 되므로 객체에 집중할 수 있다.
• 데이터베이스 방언을 활용해서 데이터베이스에 맞는 적절한 DDL 생성한다.
• 이렇게 생성된 DDL은 개발 장비에서만 사용해야 한다. 생성된 DDL은 운영서버에서는 사용하지 않거나, 적절히 다듬은 후 사용해야 한다.

참고) DDL(Data Definition Language, 데이터 정의어)는 데이터베이스 구조 정의에 사용하는 언어로, 테이블이나 컬럼 등을 생성, 수정, 삭제한다.

 

주의사항

• 운영 장비에는 절대 create, create-drop, update 사용하면 안된다.
• 개발 초기 단계는 create 또는 update
• 테스트 서버는 update 또는 validate
• 스테이징과 운영 서버는 validate 또는 none

 

DDL 생성 기능

• @Column(nullable = false, length = 10) == 제약조건 추가: 필수, 10자 초과X
• DDL 생성 기능은 DDL을 자동 생성할 때만 사용되고, JPA의 실행 로직에는 영향을 주지 않는다.

 

필드와 컬럼 매핑

매핑 애노테이션 정리

 

@Column

unique 대신 @Table에서 uniqueConstraints를 사용한다.

 

@Enumarated

USER, ADMIN만 있다가 맨 앞에 GUEST를 추가하는 경우, USER와 GUEST가 같게 되는 문제가 발생한다. 따라서, 무조건 EnumType.STRING을 사용해야 한다.

 

@Temporal

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

 

참고) LocalDate, LocalDateTime을 사용하면, 최신 하이버네이트 알아서 날짜 타입으로 매핑해주기 때문에 @Temporal은 요즘은 쓰지 않는다.

 

@Lob

• 대형 오브젝트에 사용한다.
• @Lob에는 지정할 수 있는 속성이 없다.
• 매핑하는 필드 타입이 문자면 데이터베이스에서 CLOB과 매핑되고, 나머지는 BLOB 매핑된다.
• CLOB: String, char[], java.sql.CLOB
• BLOB: byte[], java.sql. BLOB

 

기본 키 매핑

직접 할당

setId를 사용하여 원하는 값으로 직접 할당

 

자동 생성(@GeneratedValue)

• IDENTITY: 데이터베이스에 맡긴다. MySQL에서는 주로 AUTO_INCREMENT를 사용한다. IDENTITY의 문제는 id값의 생성을 데이터베이스에 맡기기 때문에, em.persist를 해서 1차 캐시에 저장을 하려고 해도 id값을 모른다. 그래서 예외적으로 IDENTITY 경우에만 em.persist를 할 때, 추가적으로 flush를 해서 데이터베이스에서 생성된 id 값을 가지고 1차 캐시에 저장한다.

@Entity
public class Member {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;
    
    ...
}

System.out.println("=================");
em.persist(member);
System.out.println("=================");

 

• SEQUENCE: 데이터베이스 시퀀스를 사용한다. 데이터베이스 시퀀스는 유일한 값을 순서대로 생성하는 특별한 데이터베이스 오브젝트이다. @SequenceGenerator가 필요하고, generator를 매핑한다. ORACLE 데이터베이스에서 주로 사용한다.

@Entity
@SequenceGenerator(
        name = "MEMBER_SEQ_GENERATOR",
        sequenceName = "MEMBER_SEQ", //매핑할 데이터베이스 시퀀스 이름
        initialValue = 1, allocationSize = 1)
public class Member {
    @Id
    @GeneratedValue(strategy = GenerationType.SEQUENCE, generator = "MEMBER_SEQ_GENERATOR")
    private Long id;

    ...
}

SEQUENCE도 마찬가지로 데이터베이스 시퀀스를 이용하기 때문에 1차 캐시에 저장하려고 할 때 id를 모른다. flush까진 아니고, 데이터베이스 시퀀스에서 id값만 받아오고 1차 캐시에 저장한다. 

 

initialValue = 1, allocationSize = 50이라면, 순서번호 50개를 미리 받아서 메모리에 저장 후 하나씩 사용한다.

 

참고) ddl-auto: create에서 삭제되고 새로 생성되는 것은 테이블이다.

 

• TABLE: 키 생성용 테이블 사용, 모든 DB에서 사용, @TableGenerator 필요
• AUTO: 방언에 따라 자동 지정, 기본값

 

권장하는 식별자 전략

• 기본 키 제약 조건: null이 아니어야 함, 유일, 변하면 안된다.
• 미래까지 이 조건을 만족하는 자연키는 찾기 어렵다. 대리키(대체키)를 사용하자.
• 예를 들어 주민등록번호도 기본 키로 적절하기 않다.
• 권장: 타입은 Long형 + 대체키 + 키 생성전략 사용

결론은 Auto Increment, 시퀀스 오브젝트, uuid 사용 권장

 

실전 예제 1 - 요구사항 분석과 기본 매핑

도메인 모델 분석

• 회원과 주문의 관계 : 한 회원은 여러 개의 주문을 할 수 있다. (일대다)
• 주문과 상품의 관계 : 한 주문에는 여러 개의 상품이 포함될 수 있다. 한 상품은 여러 주문에 포함될 수 있다. (다대다) 인데, 주문상품이라는 것을 도입하여 일대다, 다대일로 풀어낸다.

 

엔티티 설계

 

테이블 설계

 

테이블의 외래키를 객체에 그대로 가져오는 것은 좋은 객체 지향 설계 방법이 아니다. 객체에서 바로 접근할 수 있는 것이 좋다.

 

연관관계 매핑 기초

예제 시나리오

• 회원과 팀이 있다.
• 회원은 하나의 팀에만 소속될 수 있다.
• 회원과 팀은 다대일 관계다.

 

객체를 테이블에 맞추어 모델링 (객체 연관관계 없음)

회원과 팀이 다대일 관계일 때, 회원이 속한 팀은 하나이므로, 회원에, 다시 말해서 다 쪽에 외래키를 두는 것이 옳다.

 

Team team = new Team();
team.setName("레알 마드리드");
em.persist(team);

Member member = new Member();
member.setUsername("호날두");
member.setTeamId(team.getId());
em.persist(member);

Member findMember = em.find(Member.class, member.getId());
Long findTeamId = findMember.getTeamId();
Team findTeam = em.find(Team.class, findTeamId);

객체에 외래키를 직접 저장하고, 이를 이용하여 조회하는 방법은 객체 지향적인 방법도 아니고, 매우 번거로워진다.

 

단방향 연관관계

객체 지향 모델링 (객체 연관관계 사용)

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

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

    @ManyToOne(fetch = FetchType.LAZY)
    @JoinColumn(name = "TEAM_ID")
    private Team team;

    ...
}

Team team = new Team();
team.setName("떡잎마을방범대");
em.persist(team);   // TEAM_ID를 얻은 상태

Member member = new Member();
member.setUsername("신짱구");
member.setTeam(team);   // MEMBER의 TEAM_ID에 team의 id를 외래키로 저장
em.persist(member); // MEMBER_ID를 얻은 상태

Member findMember = em.find(Member.class, member.getId());

System.out.println(findMember.getTeam().getName());

tx.commit();

Member의 team을 지정하면 TEAM의 TEAM_ID와 바로 매핑되는 것이 아니다. MEMBER의 TEAM_ID와 매핑되고, 그 TEAM_ID가 TEAM의 TEAM_ID와 매핑된다.

 

Member의 team을 바꾸면, 그 team의 TEAM_ID로 MEMBER의 TEAM_ID (FK)가 변경된다.

 

양방향 연관관계와 연관관계의 주인

양방향 연관관계와 mappedBy

Member에서 team을 바꾸는 경우, MEMBER 테이블에서는 키 값만 변경하면 되지만, 객체에서는 Member에서 team을 바꾼다고 해서 Team의 members가 변화하지 않는다. 추가 설정이 필요하다. 이 추가 설정이 mappedBy이다.

 

@Entity
public class Team {

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

    private String name;

    @OneToMany(mappedBy = "team")	// Member에서 매핑될 변수명
    private List<Member> members = new ArrayList<>();
	
    ...
}

Team team = new Team();
team.setName("떡잎마을방범대");
em.persist(team);   // TEAM_ID를 얻은 상태

Member member = new Member();
member.setUsername("신짱구");
member.setTeam(team);   // MEMBER의 TEAM_ID에 team의 id를 외래키로 저장
em.persist(member); // MEMBER_ID를 얻은 상태

em.flush();
em.clear();

Member findMember = em.find(Member.class, member.getId());
List<Member> members = findMember.getTeam().getMembers();

for (Member m : members) {
    System.out.println("m = " + m.getUsername());
}

tx.commit();

 

객체와 테이블이 관계를 맺는 차이

• 객체 연관관계 = 2개 : 회원 -> 팀 연관관계 1개(단방향), 팀 -> 회원 연관관계 1개(단방향)
• 테이블 연관관계 = 1개 : 회원 <-> 팀의 연관관계 1개(양방향), MEMBER.TEAM_ID 외래 키 하나로 양방향 연관관계를 가진다. (양쪽으로 조인할 수 있다)

SELECT *
FROM MEMBER M
JOIN TEAM T ON M.TEAM_ID = T.TEAM_ID

SELECT *
FROM TEAM T
JOIN MEMBER M ON T.TEAM_ID = M.TEAM_ID

 

 

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

• 객체의 두 관계 중 하나를 연관관계의 주인으로 지정
• 연관관계의 주인만이 외래 키를 관리(등록, 수정)
• 주인이 아닌 쪽에 mappedBy 속성으로 주인을 지정하고, 주인이 아닌 쪽은 읽기만 가능하다.
• 외래 키가 있는 곳, 다 쪽의 관련 멤버를 주인으로 정해라. 여기서는 Member.team

 

양방향 매핑시 가장 많이 하는 실수 (연관관계의 주인에 값을 입력하지 않음)

연관관계의 주인이 아닌 쪽에 값을 넣으려고 하면, 연관관계 주인이 아닌 쪽은 읽기 전용이기 때문에 반영되지 않는다. 

Team team = new Team();
team.setName("TeamA");
em.persist(team);

Member member = new Member();
member.setName("member1");

//역방향(주인이 아닌 방향)만 연관관계 설정
team.getMembers().add(member);

em.persist(member);

 

순수한 객체 관계를 고려하면, 양쪽 다 값을 입력하는 것이 좋다

Team team = new Team();
team.setName("떡잎마을방범대");
em.persist(team);   // TEAM_ID를 얻은 상태

Member member = new Member();
member.setUsername("신짱구");

member.setTeam(team);   // MEMBER의 TEAM_ID에 team의 id를 외래키로 저장
team.getMembers().add(member);

em.persist(member); // MEMBER_ID를 얻은 상태

//em.flush();
//em.clear();

Member findMember = em.find(Member.class, member.getId());
List<Member> members = findMember.getTeam().getMembers();

• 중간에 em.flush()를 하지 않을 경우, 1차 캐시에서는 연관관계 매핑이 완벽하게 이루어지지 않았으므로, em.find()로 1차 캐시에서 호출할 때, Team에는 member들이 없는 문제가 발생한다. em.find로 새로 받아와야 한다.
• 연관관계 메소드를 작성하는 것이 좋다. Setter와 구별하기 위해 이름에서 change, add 등을 사용한다.

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

• 양방향 매핑시에 무한 루프를 조심하자.
  • toString() (= 객체를 toString 형식으로 출력함) + lombok -> toString에서 연관관계에 있는 필드들 제거
  • JSON 생성 라이브러리 -> @Controller에서 엔티티를 직접 반환하지 않고, DTO로 변경해서 반환할 것

 

양방향 매핑 정리

• 단방향 매핑을 우선적으로 잘 하고, 양방향은 필요할 때(반대방향으로 조회가 필요할 때) 추가해도 됨(테이블에는 영향이 없음)
• JPQL에서 역방향으로 탐색할 일이 많음

 

실전 예제2 - 연관관계 매핑 시작

테이블 구조

 

객체 구조

(Member는 Order를 읽기만 하기 때문에?) 실제로는 Member에 orders를 넣는 것은 좋지 않다. ORDERS에 Member에 대한 FK가 있으므로, 쿼리문을 통해 orders를 구할 수 있기 때문이다.

 

실제로 List는 없어도 된다. 단방향 연관관계만 만족해도 된다. 편리를 위해 설정해둔 것 뿐이다. 하지만, JPQL 작성을 위해서 양방향을 하는 경우가 많다.

 

Member

@Entity
public class Member {

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

    private String name;

    private String city;

    private String street;

    private String zipcode;

    @OneToMany(mappedBy = "member")
    private List<Order> orders = new ArrayList<>();

    public Long getId() {
        return id;
    }

    public void setId(Long id) {
        this.id = id;
    }

    public String getName() {
        return name;
    }

    public void setName(String name) {
        this.name = name;
    }

    public String getCity() {
        return city;
    }

    public void setCity(String city) {
        this.city = city;
    }

    public String getStreet() {
        return street;
    }

    public void setStreet(String street) {
        this.street = street;
    }

    public String getZipcode() {
        return zipcode;
    }

    public void setZipcode(String zipcode) {
        this.zipcode = zipcode;
    }

    public List<Order> getOrders() {
        return orders;
    }

    public void setOrders(List<Order> orders) {
        this.orders = orders;
    }
}

 

Order

@Entity
@Table(name = "ORDERS")
public class Order {

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

    @ManyToOne(fetch = FetchType.LAZY)
    @JoinColumn(name = "MEMBER_ID")
    private Member member;

    @OneToMany(mappedBy = "order")
    private List<OrderItem> orderItems = new ArrayList<>();

    private LocalDateTime orderDate;

    @Enumerated(EnumType.STRING)
    private OrderStatus status;

    public Long getId() {
        return id;
    }

    public void setId(Long id) {
        this.id = id;
    }

    public Member getMember() {
        return member;
    }

    public void setMember(Member member) {
        this.member = member;
        member.getOrders().add(this);
    }

    public List<OrderItem> getOrderItems() {
        return orderItems;
    }

    public LocalDateTime getOrderDate() {
        return orderDate;
    }

    public void setOrderDate(LocalDateTime orderDate) {
        this.orderDate = orderDate;
    }

    public OrderStatus getStatus() {
        return status;
    }

    public void setStatus(OrderStatus status) {
        this.status = status;
    }

    // 연관관계 메소드
    public void addOrderItem(OrderItem orderItem){
        orderItems.add(orderItem);
        orderItem.setOrder(this);
    }
}

 

OrderItem

@Entity
public class OrderItem {

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

    @ManyToOne(fetch = FetchType.LAZY)
    @JoinColumn(name = "ITEM_ID")
    private Item item;

    @ManyToOne(fetch = FetchType.LAZY)
    @JoinColumn(name = "ORDER_ID")
    private Order order;

    private int orderPrice;

    private int count;

    public Long getId() {
        return id;
    }

    public void setId(Long id) {
        this.id = id;
    }

    public Item getItem() {
        return item;
    }

    public void setItem(Item item) {
        this.item = item;
    }

    public Order getOrder() {
        return order;
    }

    public void setOrder(Order order) {
        this.order = order;
    }

    public int getOrderPrice() {
        return orderPrice;
    }

    public void setOrderPrice(int orderPrice) {
        this.orderPrice = orderPrice;
    }

    public int getCount() {
        return count;
    }

    public void setCount(int count) {
        this.count = count;
    }
}

 

Item

@Entity
public class Item {

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

    private String name;

    private int price;

    private int stockQuantity;
}

 

결론은 단방향 연관관계로 작성하고 필요하면 양방향을 추가하자.

 

다양한 연관관계 매핑

연관관계 매핑 시 고려사항 3가지

• 다중성 : @ManyToOne, @OneToMany, @OneToOne, @ManyToMany
• 단방향, 양방향 : 테이블은 외래 키 하나로 양쪽 조인이 가능하므로 방향이라는 개념이 없다. 객체는 참조용 필드가 있는 쪽으로만 참조가 가능한데, 한쪽만 참조하면 단방향, 양쪽이 서로 참조하면 양방향(단방향 2개)이다.
• 연관관계 주인: 외래 키를 관리하는 참조, 주인의 반대편은 외래 키에 영향을 주지 않고 읽기만 가능하다.

 

다대일 [N:1]

다대일 단방향

@Entity
public class Member {
	...

    @ManyToOne(fetch = FetchType.LAZY)
    @JoinColumn(name = "TEAM_ID")
    private Team team;
	
    ...
}

 

다대일 양방향

@Entity
public class Member {
	...

    @ManyToOne(fetch = FetchType.LAZY)
    @JoinColumn(name = "TEAM_ID")
    private Team team;
	
    ...
}

@Entity
public class Team {
	...

    @OneToMany(mappedBy = "team")   // Member에서 매핑될 변수명
    private List<Member> members = new ArrayList<>();
	
    ...
}

team에서 member를 찾는 로직이 많을 때, 위 코드를 추가하여 양방향 관계 매핑 설정한다.

 

일대다 [1:N]

연관관계 주인이 다 쪽이 아닌 일 쪽에 있다는 의미이다. 다대일을 사용하자.

 

일대일 [1:1]

• 일대일 관계는 그 반대도 일대일
• 주 테이블이나 대상 테이블 중에 외래 키를 저장할 곳 선택 가능
• 외래 키에 데이터베이스 유니크(UNI) 제약조건 추가

참고) 주 테이블은 주로 접근하는 테이블

 

일대일: 주 테이블에 외래 키 단방향

@Entity
public class Member {
	...

    @OneToOne(fetch = FetchType.LAZY)
    @JoinColumn(name = "LOCKER_ID")
    private Locker locker;
    
    ...
}

 

일대일: 주 테이블에 외래 키 양방향

@Entity
public class Member {
	...

    @OneToOne(fetch = FetchType.LAZY)
    @JoinColumn(name = "LOCKER_ID")
    private Locker locker;
    
    ...
}

@Entity
public class Locker {
	...
    
    @OneToOne(fetch = FetchType.LAZY, mappedBy = "locker")
    private Member member;
}

• 다대일 양방향 매핑 처럼 외래 키가 있는 곳이 연관관계의 주인
• 반대편은 mappedBy 적용

 

외래 키 위치에 따른 비교

•  주 테이블에 외래 키
  • 주 객체가 대상 객체의 참조를 가지는 것처럼 주 테이블에 외래 키를 두고 대상 테이블을 찾음
  • 객체지향 개발자들이 선호
  • JPA 매핑 편리
  • 장점 : 주 테이블만 조회해도 대상 테이블에 데이터가 있는지 확인 가능
  • 단점 : 값이 없으면 외래 키에 null 허용
• 대상 테이블에 외래 키
  • 대상 테이블에 외래키가 존재
  • 전통적인 데이터베이스 개발자가 선호
  • 장점 : 주 테이블과 대상 테이블을 일대일에서 일대다 관계로 변경할 때 테이블 구조 유지
  • 단점 : 대상 테이블에서 값을 찾아야 함. 프록시 기능의 한계로 지연로딩으로 설정해도 항상 즉시 로딩됨

 

다대다 [N:N]

연결 테이블을 추가해서 일대다 + 다대일로 바꾸는 것이 좋다.

 

@JoinColumn

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

 

고급 매핑

상속관계 매핑

• 관계형 데이터베이스는 상속 관계가 없음
• 슈퍼타입 서브타입 관계라는 모델링 기법이 객체 상속과 유사
• 상속관계 매핑: 객체의 상속 구조와 DB의 슈퍼타입 서브타입 관계를 매핑

 

주요 애노테이션

• @Inheritance(strategy=InheritanceType.XXX)
  • JOINED: 조인 전략
  • SINGLE_TABLE: 단일 테이블 전략
  • TABLE_PER_CLASS: 구현 클래스마다 테이블 전략
• @DiscriminatorColumn(name=“DTYPE”) : DB에서 작업을 고려하여 구분 행 생성
• @DiscriminatorValue(“XXX”) : DB에서 작업을 고려하여 구분할 때 사용할 값 지정

 

조인 전략

• 각각 테이블로 변환
• 장점
  • 테이블 정규화
  • 외래 키 참조 무결성 제약조건 활용 가능, ID를 이용 가능
  • 저장공간 효율화
• 단점
  • 조회시 조인을 많이 사용하여 성능 저하
  • 조회 쿼리가 복잡합
  • 데이터 저장시 INSERT SQL 2번 호출

@Entity
@Inheritance(strategy = InheritanceType.JOINED)
public abstract class Item {

    @Id
    @GeneratedValue
    private Long id;

    private String name;

    private int price;

}

ITEM, ALBUM, MOVIE, BOOK 테이블 모두 생성된다.

 

단일 테이블 전략

• 한 테이블에 모두 저장하고, DTYPE으로 구분
• 장점 
  • 조인이 필요 없으므로 일반적으로 조회 성능이 빠름
  • 조회 쿼리가 단순함
• 단점
  • 자식 엔티티가 매핑한 컬럼은 모두 null 허용
  • 단일 테이블에 모든 것을 저장하므로 테이블이 커질 수 있고, 상황에 따라서 조회 성능이 오히려 느려질 수 있다.

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

    @Id
    @GeneratedValue
    private Long id;

    private String name;

    private int price;

}

ITEM 테이블만 생성된다. @DiscriminatorColumn이 없어도 필요하기 때문에 자동으로 생성된다.

 

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

장점이 없다. 사용하면 안된다.

@Entity
@Inheritance(strategy = InheritanceType.TABLE_PER_CLASS)
public abstract class Item {

    @Id
    @GeneratedValue
    private Long id;

    private String name;

    private int price;
}

ITEM이 생성되지 않고, MOVIE, ALBUM, BOOK만 생성된다.

Item.class로 find할 경우에 세 테이블을 모두 탐색해야 하기 때문에 성능이 좋지 않다.

 

@MappedSuperclass

id, name 같은 공통 매핑 정보가 필요할 때 사용

public class Member extends BaseEntity{

• 상속관계 매핑과 관련이 없다.
• 엔티티가 아니기 때문에 테이블과 매핑되지 않는다.
• 부모 클래스를 상속 받는 자식 클래스에 매핑 정보만 제공된다.
• 조회, 검색 불가하다, 예를 들어 em.find(BaseEntity) 불가능
• 직접 생성해서 사용할 일이 없으므로 추상 클래스로 생성하는 것이 좋다.
• 주로 등록일, 수정일, 등록자, 수정자 같은 전체 엔티티에서 공통으로 적용하는 정보를 제공하기 위해 사용한다.
• @Entity 클래스는 엔티티나 @MappedSuperclass로 지정한 클래스만 상속 가능하다.

 

프록시와 연관관계 관리

프록시

• em.find() : 1차 캐시에 없는 경우, 데이터베이스를 통해서 실제 엔티티 객체 조회
• em.getReference() : 1차 캐시에 없는 경우, 데이터베이스 조회를 미루는 가짜(프록시) 엔티티 조회

 

프록시 특징

• 실제 클래스를 상속 받아서 만들어지고, 실제 클래스와 겉 모양이 같다.
• 이론상 사용하는 입장에서는 진짜 객체인지 프록시 객체인지 구분하지 않고 사용하면 된다.
• 프록시 객체도 영속성 컨텍스트가 관리한다.
• 프록시 객체를 호출하면 프록시 객체는 실제 객체의 메소드를 호출한다.
• 프록시 객체는 처음 사용할 때, 프록시 객체가 실제 엔티티로 바뀌는 것이 아니라 참조가 저장된다.
• 프록시 객체는 원본 엔티티를 상속받는데, 완전히 같은 타입은 아니다. 따라서 Class 체크시 주의해야 한다. (==가 실패한다, 대신 instance of 사용하면 성공)
• 영속성 컨텍스트에 찾는 엔티티가 이미 있으면 em.getReference()를 호출해도 실제 엔티티 반환
• 영속성 컨텍스트의 도움을 받을 수 없는 준영속 상태일 때, 프록시를 초기화하면 문제 발생 (하이버네이트는 org.hibernate.LazyInitializationException 예외를 터트림)

 

프록시 객체의 초기화

Member member = em.getReference(Member.class, "id1");
member.getName();

getName을 하면, 프록시 객체가 영속성 컨텍스트에 초기화를 요청하고, DB를 조회해서 영속성 컨텍스트에 실제 엔티티를 생성하고 target에 연결한다.

 

프록시 확인

• 프록시 인스턴스의 초기화 여부 확인 : emf.getPersistenceUnitUtil.isLoaded(PROXY)
• 프록시 클래스 확인 방법 : entity.getClass() 출력(..javasist.. or HibernateProxy…)
• 프록시 강제 초기화 : org.hibernate.Hibernate.initialize(PROXY);
• 참고: JPA 표준은 강제 초기화 없음. 강제 호출: member.getName() 

 

즉시 로딩과 지연 로딩

지연 로딩

@Entity
public class Member extends BaseEntity{
	...

    @ManyToOne(fetch = FetchType.LAZY)
    @JoinColumn(name = "TEAM_ID")
    private Team team;

	...
}

Team team = new Team();
team.setName("1박2일");
em.persist(team);

Member member = new Member();
member.setUsername("강호동");
member.setTeam(team);
em.persist(member);

em.flush();
em.clear();

Member findMember = em.find(Member.class, member.getId());
System.out.println("=====================");
System.out.println(findMember.getTeam().getClass());
System.out.println("=====================");
System.out.println(findMember.getTeam().getName());
System.out.println(emf.getPersistenceUnitUtil().isLoaded(findMember.getTeam()));
System.out.println(findMember.getTeam().getClass());
System.out.println("=====================");

tx.commit();

지연 로딩으로 설정한 필드의 클래스를 조회하면, Proxy라는 것을 알 수 있다.

실제 team을 사용하는 시점에 쿼리문이 날라간다.

실제 객체를 참조해도 Proxy 타입이 여전히 유지된다는 것에 유의하자.

 

즉시 로딩

 

Team team = new Team();
team.setName("1박2일");
em.persist(team);

Member member = new Member();
member.setUsername("강호동");
member.setTeam(team);
em.persist(member);

em.flush();
em.clear();

Member findMember = em.find(Member.class, member.getId());
System.out.println("=====================");
System.out.println(findMember.getTeam().getClass());
System.out.println(findMember.getTeam().getName());
System.out.println("=====================");

tx.commit();

실제 team을 사용하기 전에 이미 실제 객체로 초기화되어 있다.

 

프록시와 즉시 로딩 주의

• 가급적 지연 로딩만 사용(특히 실무에서), 즉시 로딩을 하게 되면 JOIN을 무수히 많이 하기 때문에 성능이 안좋아짐.
• 즉시 로딩을 적용하면 예상하지 못한 SQL이 발생
• 즉시 로딩은 JPQL에서 N+1 문제를 일으킨다.

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

SQL문 select * from Member이 실행되고, 즉시 로딩에 의해 각 member의 team들이 채워져야 하기 때문에 추가적으로 SQL문이 실행된다. 위 쿼리 하나로 얻은 member들 각각의 team을 로딩하기 위한 N개의 쿼리문이 필요하다는 의미이다.

• @ManyToOne, @OneToOne은 기본이 즉시 로딩 -> LAZY로 설정
• @OneToMany, @ManyToMany는 기본이 지연 로딩

 

참고) JOIN : 두 개의 테이블을 엮어서 원하는 데이터를 추출할 때 사용한다.

 

영속성 전이 : CASCADE

• 특정 엔티티를 영속 상태로 만들 때 연관된 엔티티도 함께 영속 상태로 만들고 싶을 때 사용한다. 예를 들어 부모 엔티티를 저장할 때 자식 엔티티도 함께 저장하고 싶을 때 사용한다.
• 영속성 전이는 연관관계를 매핑하는 것과는 아무 관련이 없다. 엔티티를 영속화할 때 연관된 엔티티도 함께 영속화하는 편리함을 제공할 뿐이다.
• 옵션에서 ALL과 PERSIST를 주로 사용한다.
• 소유자가 하나일 때, 예를 들어 Child가 Parent와만 관련이 있을 때만 사용한다.

Child child1 = new Child();
Child child2 = new Child();

Parent parent = new Parent();
parent.addChild(child1);
parent.addChild(child2);

//            em.persist(child1);
//            em.persist(child2);
em.persist(parent);

List<Child> childList = em.find(Parent.class, parent.getId()).getChildList();
for (Child child : childList) {
    System.out.println("child = " + child);
}

tx.commit();

위 코드에서 parent 객체에는 child 객체들이 저장되어 있지만, em.find로 가져온 객체에는 데이터베이스에서는 child가 없으므로 반영되지 않는다.

 

@Entity
public class Parent {
	...

    @OneToMany(mappedBy = "parent", cascade = CascadeType.ALL)
    private List<Child> childList = new ArrayList<>();

    // 연관관계 메소드
    public void addChild(Child child){
        child.setParent(this);
        childList.add(child);
    }
    
    ...
}

cascade를 설정하면, parent만 persist해도 컬렉션에 있는 child들까지 persist 된다.

 

고아 객체

• 부모 엔티티와 연관관계가 끊어진 자식 엔티티를 데이터베이스에서 자동 삭제시킨다.
• 참조하는 곳이 하나일 때 사용해야 함, 즉 특정 엔티티가 개인 소유할 때 사용
• @OneToOne, @OneToMany만 가능

@Entity
public class Parent {
	...
    
    @OneToMany(mappedBy = "parent", cascade = CascadeType.ALL, orphanRemoval = true)
    private List<Child> childList = new ArrayList<>();
	
    ...
}

Parent findParent = em.find(Parent.class, parent.getId());
findParent.getChildList().remove(0);

 

• em.remove로 부모를 삭제하면, 자식도 삭제된다.

 

영속성 전이 + 고아 객체

• CascadeType.ALL + orphanRemoval=true
• 스스로 생명주기를 관리하는 엔티티는 em.persist()로 영속화, em.remove()로 제거
• 두 옵션을 모두 활성화 하면 부모 엔티티를 통해서 자식의 생명 주기를 관리할 수 있음
• 도메인 주도 설계(DDD)의 Aggregate Root개념을 구현할 때 유용

 

값 타입

JPA의 데이터 타입 분류

• 엔티티 타입
  • @Entity로 정의하는 객체
  • 데이터가 변해도 식별자(id)로 지속해서 추적 가능
• 값 타입
  • int, String처럼 단순히 값으로 사용하는 자바 기본 타입이나 객체
  • 식별자가 없고 값만 있으므로 변경 시 추적 불가, 예를 들어 이름을 변경하면 완전히 다른 값으로 대체

 

값 타입 분류

• 기본값 타입
  • 자바 기본 타입(int, double)
  • 래퍼 클래스(Integer, Long)
  • String
• 임베디드 타입(embedded type, 복합값 타입) : 좌표, 주소 값이 묶어서 쓰고 싶을 때
• 컬렉션 값 타입 : 자바 컬렉션

 

기본값 타입

• 생명 주기를 엔티티에 의존, 예를 들어 회원을 삭제하면 이름, 나이 필드도 함께 삭제
• 값 타입은 공유하면 안됨, 예를 들어 회원 이름 변경 시 다른 회원의 이름도 함께 변경하면 안됨
• 자바 기본 타입은 공유되지 않고, 값을 복사함, 하지만, 래퍼 클래스나 String 같은 특수한 클래스는 공유 가능한 객체이지만 변경 불가 

 

임베디드 타입

• 새로운 값 타입을 직접 정의할 수 있음
• 주로 기본 값 타입을 모아서 만들어서 복합 값 타입이라고도 함
• int, String과 같은 값 타입, 값으로 사용함
• @Embeddable로 정의하고, @Embedded로 사용

 

임베디드 타입의 장점

• 재사용
• 높은 응집도
• Period.isWork()처럼 해당 값 타입만 사용하는 의미 있는 메소드를 만들 수 있음.
• 임베디드 타입을 포함한 모든 값 타입은, 값 타입을 소유한 엔티티에 생명주기를 의존함.

 

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

 

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

• 임베디드 타입은 엔티티의 값일 뿐이다.
• 임베디드 타입을 사용하기 전과 후에 매핑하는 테이블은 같다.
• 객체와 테이블을 아주 세밀하게 매핑하는 것이 가능하다.
• 잘 설계한 ORM 애플리케이션은 매핑한 테이블의 수보다 클래스의 수가 더 많다.
• 임베디드 타입 필드를 null로 정의하면, 그 안에 있는 필드들도 null로 되어 테이블에 반영된다.

 

임베디드 타입과 연관관계

 

@AttributeOverride: 속성 재정의

• 한 엔티티에서 임베디드 타입을 두 번 이상 사용하면 중복되기 때문에 오류가 발생한다.
• @AttributeOverrides, @AttributeOverride를 사용해서 컬럼 명 속성을 재정의하므로써 해결할 수 있다.

@Embedded
private Address homeAddress;

@Embedded
@AttributeOverrides({
        @AttributeOverride(name="city",
                column=@Column(name = "SCHOOL_CITY")),
        @AttributeOverride(name="street",
                column=@Column(name = "SCHOOL_STREET")),
        @AttributeOverride(name="zipcode",
                column=@Column(name = "SCHOOL_ZIPCODE"))})
private Address schoolAddress;

 

값 타입과 불변 객체

값 타입 공유 참조

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

Address address = new Address("마산", "거리1", "1000");

Member member1 = new Member();
member1.setUsername("강호동");
member1.setHomeAddress(address);
em.persist(member1);

Member member2 = new Member();
member2.setUsername("이수근");
member2.setHomeAddress(address);
em.persist(member2);

member1.getHomeAddress().setCity("서울");

• 값 타입의 실제 인스턴스를 공유하는 것은 위험하다.
• 새로운 인스턴스를 만들고, 값을 복사해서 사용해야 한다.

 

객체 타입의 한계

• 공유 참조로 인해 발생하는 부작용을 피하기 위해 항상 값을 복사해서 사용해야 한다.
• 문제는 임베디드 타입처럼 직접 정의한 값 타입은 자바의 기본 타입이 아니라 객체 타입이다.
• 객체 타입은 참조 값을 직접 대입하는 것을 막을 방법이 없다. 객체의 공유 참조는 피할 수 없다.

 

불변 객체

• 객체 타입을 수정할 수 없게 만들면 부작용을 원천 차단할 수 있다.
• 값 타입은 불변 객체(immutable object)로 설계해야 한다. 불변 객체란 생성 시점 이후 절대 값을 변경할 수 없는 객체
• 생성자로 생성 시점에만 값을 설정하고, Setter를 만들지 않거나 private으로 생성해야 한다. 이렇게 하면, 값을 바꾸고 싶어도 바꾸지 못하므로 새로 인스턴스를 만들고, 값을 복사하여 원하는 부분만 바꾸고 넣어주어야 한다.

Address address = new Address("마산", "거리1", "1000");

Member member1 = new Member();
member1.setUsername("강호동");
member1.setHomeAddress(address);
em.persist(member1);

Address newAddress = new Address("서울", member1.getHomeAddress().getStreet(), member1.getHomeAddress().getZipcode());
member1.setHomeAddress(newAddress);

• 참고) Integer, String은 자바가 제공하는 대표적인 불변 객체

 

값 타입의 비교

• 동일성(identity) 비교: 인스턴스의 참조 값을 비교, == 사용
• 동등성(equivalence) 비교: 인스턴스의 값을 비교, 클래스에서 equals()를 override해서 사용해야 한다.
• 값 타입은 a.equals(b)를 사용해서 동등성 비교를 해야 함

 

값 타입 컬렉션 

• 쓰지 않는 것이 좋다.
• 관계형 데이터베이스에는 컬렉션을 저장할 수 없다. 따라서 컬렉션을 따로 테이블로 만들어야 한다.
• 값 타입을 하나 이상 저장할 때 사용한다.
• @ElementCollection, @CollectionTable 사용한다.
• 기본적으로 지연 로딩 전략을 사용한다.

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

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

 

값 타입 컬렉션도 값 타입이므로 엔티티의 생명주기와 일치한다. 값 타입 컬렉션은 영속성 전에(Cascade) + 고아 객체 제거 기능을 필수로 가진다고 볼 수 있다.

 

값 타입 컬렉션 수정

findMember.getFavoriteFoods().remove("치킨");
findMember.getFavoriteFoods().add("족발");

findMember.getAddressHistory().remove(new Address("old1", "street1", "zipcode1"));
findMember.getAddressHistory().add(new Address("new1", "street1", "zipcode1"));

 

값 타입 컬렉션의 제약사항

• 값 타입은 엔티티와 다르게 식별자 개념이 없다.
• 값은 변경하면 추적이 어렵다.
• 값 타입 컬렉션에 변경 사항이 발생하면, 주인 엔티티와 연관된 모든 데이터를 삭제하고, 값 타입 컬렉션에 있는 현재 값을 모두 다시 저장한다. -> 결론적으로 쓰면 안된다.
• 값 타입 컬렉션을 매핑하는 테이블은 모든 컬럼을 묶어서 기본 키를 구성해야 한다: null 입력X, 중복 저장X

 

값 타입 컬렉션 대안

• 실무에서는 상황에 따라 값 타입 컬렉션 대신에 일대다 관계를 고려
• 일대다 관계를 위한 엔티티를 만들고, 여기에서 값 타입을 사용
• 영속성 전이(Cascade) + 고아 객체 제거를 사용해서 값 타입 컬렉션 처럼 사용
• EX) AddressEntity

package hellojpa;

import jakarta.persistence.Entity;
import jakarta.persistence.GeneratedValue;
import jakarta.persistence.Id;
import jakarta.persistence.Table;

@Entity
@Table(name = "ADDRESS")
public class AddressEntity {

    @Id
    @GeneratedValue
    private Long id;

    private Address address;

    public AddressEntity() {
    }

    public AddressEntity(String city, String street, String zipcode) {
        this.address = new Address(city, street, zipcode);
    }

    public Long getId() {
        return id;
    }

    public void setId(Long id) {
        this.id = id;
    }

    public Address getAddress() {
        return address;
    }

    public void setAddress(Address address) {
        this.address = address;
    }
}

 

JPQL

JPA의 쿼리 방법

• JPQL
  • JPA가 제공하는 SQL을 추상화한 객체 지향 쿼리 언어, SQL과 문법 유사하다.
  • JPQL은 엔티티 객체를 대상으로 쿼리, SQL은 데이터베이스 테이블을 대상으로 쿼리한다.
  • JPQL은 결국 SQL로 변환된다.

List<Member> members = em.createQuery("select m from Member m where m.username like '%kim%'", Member.class).getResultList();

 

• QueryDSL
  • http://querydsl.com/
• SpringJdbcTemplate
  • JPA를 우회해서 SQL을 실행할 때는 영속성 컨텍스트가 데이터베이스에 반영되지 않기 때문에 그 전에 영속성 컨텍스트를 적절한 시점에 강제로 플러시하는 것이 필요하다.

 

JPQL

Java Persistence Query Language

 

JPQL 문법

• select m from Member as m where m.age > 18
• 엔티티(Member)와 속성(age)은 대소문자를 구분한다.
• JPQL(SELECT, FROM, where) 키워드는 대소문자를 구분하지 않는다.
• 테이블 이름이 아니라 엔티티 이름(Member)을 사용한다. 기본적으로 클래스 이름이다.
• 별칭(m)은 필수 (as는 생략가능)

 

집합과 정렬

select
	COUNT(m), //회원수
	SUM(m.age), //나이 합
	AVG(m.age), //평균 나이
	MAX(m.age), //최대 나이
	MIN(m.age) //최소 나이
from Member m

GROUP BY, HAVING, ORDER BY

 

TypeQuery, Query

• TypeQuery: 반환 타입이 명확할 때 사용

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

• Query: 반환 타입이 명확하지 않을 때 사용

Query query = em.createQuery("SELECT m.username, m.age from Member m");

 

 

결과 조회 API

• query.getResultList(): 결과가 하나 이상일 때, 리스트 반환, 결과가 없으면 빈 리스트 반환
• query.getSingleResult(): 결과가 정확히 하나, 단일 객체 반환
  • 결과가 없으면: jakarta.persistence.NoResultException
  • 둘 이상이면: jakarta.persistence.NonUniqueResultException

 

프로젝션 (SELECT)

• SELECT 절에 조회할 대상을 지정하는 것
• 프로젝션 대상: 엔티티, 임베디드 타입, 스칼라 타입(숫자, 문자등 기본 데이터 타입)
• SELECT m FROM Member m -> m이 Member이므로 엔티티 프로젝션
• SELECT m.team FROM Member m -> m과 연관된 team이 엔티티이므로, 엔티티 프로젝션
• SELECT m.address FROM Member m -> 임베디드 타입 프로젝션
• SELECT m.username, m.age FROM Member m -> 스칼라 타입 프로젝션
• DISTINCT로 중복 제거할 수 있다.
• 조회한 결과는 영속성 컨텍스트로 관리된다.

 

프로젝션 - 여러 값 조회

SELECT m.username, m.age FROM Member m

• 1. Query 타입으로 조회
• 2. Object[] 타입으로 조회
• 3. new 명령어로 조회
  • 단순 값을 DTO로 바로 조회
  • 패키지 명을 포함한 전체 클래스 명 입력
  • 순서와 타입이 일치하는 생성자 필요

List<MemberDto> resultList = em.createQuery("select new jpql.MemberDto(m.username, m.age) from Member m", MemberDto.class).getResultList();

 

페이징

• setFirstResult(int startPosition) : 조회 시작 위치 (0부터 시작)
• setMaxResults(int maxResult) : 조회할 데이터 수

List<Member> resultList = em.createQuery("select m from Member m order by m.age desc", Member.class).setFirstResult(1).setMaxResults(10).getResultList();

 

조인

id가 기본 조건

• 내부 조인: 두 테이블을 조인할 때, 두 테이블에 모두 지정한 열의 데이터가 있어야 한다. 없으면 결과에 포함되지 않는다.

SELECT m FROM Member m [INNER] JOIN m.team t

 

• 외부 조인: OUTER JOIN(외부 조인)은 두 테이블을 조인할 때, 1개의 테이블에만 데이터가 있어도 결과가 나온다. 

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

• 세타 조인: 곱집합

select count(m) from Member m, Team t where m.username = t.name

 

조인 - ON 절

• 조인 대상 필터링

예) 회원과 팀을 조인하면서, 팀 이름이 A인 팀만 조인

SELECT m, t FROM Member m LEFT JOIN m.team t on t.name = 'A'	//JPQL
SELECT m.*, t.* FROM Member m LEFT JOIN Team t ON m.TEAM_ID=t.id and t.name='A'	//SQL

• 연관관계 없는 엔티티 외부 조인 가능

예) 회원의 이름과 팀의 이름이 같은 대상 외부 조인

SELECT m, t FROM Member m LEFT JOIN Team t on m.username = t.name	//JPQL
SELECT m.*, t.* FROM Member m LEFT JOIN Team t ON m.username = t.name	//SQL

 

서브 쿼리

• 나이가 평균보다 많은 회원

 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 where o.member = m) > 0

 

서브 쿼리 지원 함수

• [NOT] EXISTS (subquery): 서브쿼리의 결과가 존재하면 참
• {ALL | ANY | SOME} (subquery)
• ALL 모두 만족하면 참
• ANY, SOME: 같은 의미, 조건을 하나라도 만족하면 참
• [NOT] IN (subquery): 서브쿼리의 결과 중 하나라도 같은 것이 있으면 참

 

예제

• 팀A 소속인 회원

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

 

• 전체 상품 각각의 재고보다 주문량이 많은 주문들

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)

 

JPA 서브 쿼리 한계

FROM 절에서 서브 쿼리 불가능

 

JPQL 타입 표현과 기타식

• 문자: ‘HELLO’, ‘She’’s’
• 숫자: 10L(Long), 10D(Double), 10F(Float)
• Boolean: TRUE, FALSE
• ENUM: jpabook.MemberType.Admin (패키지명 포함)
• 엔티티 타입: TYPE(m) = Member (상속 관계에서 사용) ex) type(i) = Book

select m.username, 'Hello', TRUE from Member m where m.type jpql.MemberType.ADMIN

 

• EXISTS, IN
• AND, OR, NOT
• =, >, >=, <, <=, <>
• BETWEEN, LIKE, IS NULL

 

조건식 - CASE 식

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

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

 

• COALESCE : 하나씩 조회해서 null이 아니면 첫 번째 값 반환, null이면 두 번째 값 반환

select coalesce(m.username,'이름 없는 회원') from Member m

• NULLIF : 두 값이 같으면 null 반환, 다르면 첫 번째 값 반환

select NULLIF(m.username, '관리자') from Member m

 

JPQL 기본 함수

데이터베이스 상관없이 사용 가능하다.

• CONCAT
• SUBSTRING
• TRIM
• LOWER, UPPER
• LENGTH
• LOCATE
• ABS, SQRT, MOD
• SIZE, INDEX(JPA 용도)

 

경로 표현식

점을 찍어 객체 그래프를 탐색하는 것

select m.username -> 상태 필드 (그냥 값)
	from Member m
	join m.team t -> 단일 값 연관 필드 (엔티티)
	join m.orders o -> 컬렉션 값 연관 필드 (엔티티 컬렉션)
where t.name = '팀A'

 

• 상태 필드(state field): 단순히 값을 저장하기 위한 필드 (ex: m.username)
• 연관 필드(association field): 연관관계를 위한 필드
  • 단일 값 연관 필드: @ManyToOne, @OneToOne, 대상이 엔티티(ex: m.team)
  • 컬렉션 값 연관 필드: @OneToMany, @ManyToMany, 대상이 컬렉션(ex: m.orders)

 

경로 표현식 특징

• 상태 필드(state field): 경로 탐색의 끝, m.username에서 추가로 .을 찍을 수 없음

select m.username from Member m

• 단일 값 연관 경로: 묵시적 내부 조인(inner join) 발생, 탐색O

select o.member from Order o

• 컬렉션 값 연관 경로: 묵시적 내부 조인 발생, 탐색X, t.members에 많은 member들이 있기 때문에 추가로 .을 찍을 수 없음
  • FROM 절에서 명시적 조인을 통해 별칭을 얻으면 별칭을 통해 탐색 가능

select t.members from Team t

select m.username from Team t join t.members m

 

 

명시적 조인, 묵시적 조인

• 명시적 조인: join 키워드를 직접 사용, select m from Member m join m.team t
• 묵시적 조인: 경로 표현식에 의해 묵시적으로 SQL 조인 발생(내부 조인만 가능), select m.team from Member m

 

실무 조언

• 가급적 묵시적 조인 대신에 명시적 조인 사용
• 조인은 SQL 튜닝에 중요한 부분임
• 묵시적 조인은 조인이 일어나는 상황을 한눈에 파악하기 어려움

 

페치 조인(fetch join)

• SQL 조인 종류가 아니라 JPQL에서 성능 최적화를 위해 제공하는 기능
• 연관된 엔티티나 컬렉션을 SQL 한 번으로 함께 조회하는 기능
• join fetch 명령어 사용
• 페치 조인 ::= [ LEFT [OUTER] | INNER ] JOIN FETCH 조인경로

 

엔티티 페치 조인

회원을 조회하면서 연관된 팀도 함께 조회하고 싶을 때

select m from Member m join fetch m.team	// JPQL

SELECT M.*, T.* FROM MEMBER M				// SQL
INNER JOIN TEAM T ON M.TEAM_ID=T.ID

m만 조회했지만, 팀도 다같이 가져온다.

 

Team team = new Team();
team.setName("떡잎마을방범대");
em.persist(team);

Team team2 = new Team();
team2.setName("콩잎마을방범대");
em.persist(team2);

Member member1 = new Member();
member1.setUsername("짱구");
member1.addTeam(team);
em.persist(member1);

Member member2 = new Member();
member2.setUsername("맹구");
member2.addTeam(team);
em.persist(member2);

Member member3 = new Member();
member3.setUsername("철수");
member3.addTeam(team2);
em.persist(member3);

em.flush();
em.clear();

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

fetch join을 하면 회원의 팀이 프록시가 아니라 실제 객체이기 때문에 추가 쿼리문이 발생하지 않는다. 지연 로딩보다 페치 조인이 우선이다.

 

컬렉션 페치 조인

일대다 페치 조인이므로 중복이 발생한다.

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

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

Team team1 = new Team();
team1.setName("떡잎마을방범대");
em.persist(team1);

Team team2 = new Team();
team2.setName("콩잎마을방범대");
em.persist(team2);

Member member1 = new Member();
member1.setUsername("짱구");
member1.addTeam(team1);
em.persist(member1);

Member member2 = new Member();
member2.setUsername("맹구");
member2.addTeam(team1);
em.persist(member2);

Member member3 = new Member();
member3.setUsername("철수");
member3.addTeam(team2);
em.persist(member3);

em.flush();
em.clear();

List<Team> teams = em.createQuery("select t from Team t join fetch t.members where t.name = '떡잎마을방범대'", Team.class).getResultList();
for (Team team : teams) {
    System.out.println("teamName = " + team.getName());
    for (Member member : team.getMembers()) {
        System.out.println("memberName = " + member.getUsername());
    }
}

현 버전에서는 자동으로 중복이 생략된다.

 

페치 조인과 DISTINCT

JPQL의 DISTINCT 2가지 기능 제공

• SQL에 DISTINCT를 추가
• 애플리케이션에서 엔티티 중복 제거

 

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

일반 조인

일반 조인 실행시 JPQL은 결과를 반환할 때 연관관계를 고려하지 않고, 단지 SELECT 절에 지정한 엔티티만 가져올 뿐이다. 아래 경우에 팀 엔티티만 가져오고, 회원 엔티티는 가져오지 않는다.

 

페치 조인

페치 조인을 사용할 때만 연관된 엔티티도 함께 가져온다(즉시 로딩). 페치 조인은 객체 그래프를 SQL 한번으로 가져오는 개념이다.

 

페치 조인의 특징과 한계

객체 그래프는 기본적으로 Team에서 members에 접근할 때, 다 조회되는 것을 목적으로 한다.

• 페치 조인 대상에는 별칭을 줄 수 없다. 하이버네이트는 가능하지만, 가급적이면 사용하지 않는 것을 권장한다.

select t from Team t join fetch t.members m

select t from Team t join fetch t.members

• 둘 이상의 컬렉션은 페치 조인할 수 없다. 일대다+다대다
• 컬렉션을 페치 조인하면 페이징 API(setFirstResult, setMaxResults)를 사용할 수 없다.
  • 일대일, 다대일 같은 단일 값 연관 필드들은 페치 조인해도 페이징 가능
  • 컬렉션 페치 조인은 위의 예에서 setMaxResults를 1로 지정할 때, 팀A의 회원2가 반영이 안되는 문제가 발생.
  • 하이버네이트는 경고 로그를 남기고 메모리에서 페이징(매우 위험)

 

컬렉션 페치 조인 해결

순서 바꾸기

select t from Team t join fetch t.members

=> select m from Member m join fetch m.team t

 

BatchSize 지정

<property name="hibernate.default_batch_fetch_size" value="100"/>

List<Team> teams = em.createQuery("select t from Team t", Team.class).setFirstResult(0).setMaxResults(2).getResultList();
System.out.println("result size = " + teams.size());
for (Team team : teams) {
    System.out.println("teamName = " + team.getName());
    for (Member member : team.getMembers()) {
        System.out.println("memberName = " + member.getUsername());
    }
}

team마다 members를 가져오기 위해 쿼리문을 또 team 수만큼 보내야 한다. BatchSize를 지정하면, members와 관련된 TEAM_ID 뿐만 아니라 다른 TEAM_ID들도 지정한 size만큼 같이 한 쿼리문에 지정해서 보내기 때문에 최종적으로 보내게 되는 쿼리문의 수가 줄어들게 된다.

 

정리

• 페치 조인은 객체 그래프를 유지하면서 찾아가야할 때 사용하면 효과적
• 여러 테이블을 조인해서 엔티티가 가진 모양이 아닌 전혀 다른 결과를 내야 하면, 페치 조인보다는 일반 조인을 사용하고 필요한 데이터들만 조회해서 DTO로 반환하는 것이 효과적

 

다형성 쿼리

Type

조회 대상을 특정 자식으로 한정

// Item 중에 Book, Movie를 조회해라
select i from Item i where type(i) IN (Book, Movie)

 

Treat

자바의 타입 캐스팅과 유사하며 상속 구조에서 부모 타입을 특정 자식 타입으로 다룰 때 사용한다.

select i from Item i where treat(i as Book).author = ‘kim’

 

엔티티 직접 사용

• JPQL에서 엔티티를 직접 사용하면 SQL에서 해당 엔티티의 기본 키 값을 사용

select count(m) from Member m //엔티티를 직접 사용
==
select count(m.id) from Member m //엔티티의 아이디를 사용

 

String jpql = “select m from Member m where m = :member”;
List resultList = em.createQuery(jpql).setParameter("member", member).getResultList();
==
String jpql = “select m from Member m where m.id = :memberId”;
List resultList = em.createQuery(jpql).setParameter("memberId", memberId).getResultList();

 

Member findMember = em.createQuery("select m from Member m where m=:member", Member.class).setParameter("member", member1).getSingleResult();
System.out.println("findMember.getUsername() = " + findMember.getUsername());

 

where에 id 조건으로 추가된 것을 확인할 수 있다.

 

• 외래키 값으로 사용하는 경우

List<Member> resultList = em.createQuery("select m from Member m where m.team = :team", Member.class).setParameter("team", team1).getResultList();
for (Member member : resultList) {
	System.out.println("memberName = " + member.getUsername());
}

List<Member> resultList = em.createQuery("select m from Member m where m.team.id = :teamId", Member.class).setParameter("teamId", team1.getId()).getResultList();
for (Member member : resultList) {
    System.out.println("memberName = " + member.getUsername());
}

m.team이 외래키 값으로 사용된다.

 

Named 쿼리

• 미리 정의해서 이름을 부여해두고 사용하는 JPQL
• 정적 쿼리
• 어노테이션, XML에 정의
• 애플리케이션 로딩 시점에 JPQL을 검증하고, SQL로 초기화함. 이후에는 재사용

@Entity
@NamedQuery(
        name = "Member.findByUsername",
        query = "select m from Member m where m.username = :username"	// Member가 아니라 Memberr이면 오류를 발생시킴
)
public class Member {

List<Member> resultList = em.createNamedQuery("Member.findByUsername", Member.class).setParameter("username", "짱구").getResultList();
for (Member member : resultList) {
    System.out.println("member.getUsername() = " + member.getUsername());
}

 

@NamedQuery 대신 스프링 데이터 JPA를 사용한다.

https://spring.io/projects/spring-data-jpa

Spring Data JPA

 

벌크 연산

• 쿼리 한 번으로 여러 테이블 로우 변경
• executeUpdate()의 결과는 영향받은 엔티티 수 반환
• UPDATE, DELETE에 대하여 가능
• INSERT(insert into ... select)는 하이버네이트가 지원해서 가능하다.
• 벌크 연산은 영속성 컨텍스트를 무시하고 데이터베이스에 직접 쿼리를 날린다. 
  • 영속성 컨텍스트에 값을 넣기 전에 벌크 연산을 먼저 실행
  • 영속성 컨텍스트에 값이 있다면 벌크 연산 수행 후 영속성 컨텍스트를 초기화 시킨다.

Team team1 = new Team();
team1.setName("떡잎마을방범대");
em.persist(team1);

Team team2 = new Team();
team2.setName("콩잎마을방범대");
em.persist(team2);

Member member1 = new Member();
member1.setUsername("짱구");
member1.addTeam(team1);
em.persist(member1);

Member member2 = new Member();
member2.setUsername("맹구");
member2.addTeam(team1);
em.persist(member2);

Member member3 = new Member();
member3.setUsername("철수");
member3.addTeam(team2);
em.persist(member3);

int resultCount = em.createQuery("update Member m set m.age = 20").executeUpdate();
System.out.println("resultCount = " + resultCount);

em.clear();

createQuery를 하기 전에 flush가 호출되어 Member와 Team 정보가 DB에 반영되어 있다. 벌크 연산을 수행하면, 영속성 컨텍스트는 무시하고, 데이터베이스 값만 변경하기 때문에 영속성 컨텍스트에서는 나이가 20살로 반영되지 않는다. 이때 em.clear()를 해주면, 영속성 컨텍스트에 있던 것들이 모두 사라지고, 다음에 호출할 때 DB에서 받아오므로 업데이트가 반영된 정보를 얻는다.

 

기억하면 좋을 것

• 연관관계 주인은 다 쪽, 외래키를 저장하는 쪽의 필드에 설정하고, 연관관계 메소드는 영향력을 시작하는 부분에 설정한다.
• 값 타입 컬렉션은 매우 간단한 경우가 아니면 사용하지 않는다. 값 타입은 정말 값 타입이라 판단될 때만 사용
• 식별자가 필요하고, 지속해서 값을 추적, 변경해야 한다면 그것은 값 타입이 아닌 엔티티
• 영속성 컨텍스트에 있는 객체에 대한 정보를 애플리케이션에서 변경하면 더티체킹에 의해 데이터베이스에 변경된 정보가 반영되지만, 벌크 연산으로 데이터베이스에서 변경하면 영속성 컨텍스트에 있는 객체는 영향을 받지 않는다.