JPA 10 # 객체 쿼리 언어, JPQL

간단한 CRUD는 JPA 메서드로 충분히 대체 가능했다.

하지만 SQL문은 비즈니스의 구조에 따라 조건이 복잡할수도 있고, 성능 개선이 필요할 수 있다.

이를 위해서 JPA 영속성 컨텍스트에 모든 데이터를 가져오는건 사실상 불가능하다.

이를 위해 JPA에서는 JPQL이라는 Entity용 SQL을 제공한다.

 

 

📌 JPQL 표준 문법

SQL 표준 문법과 매우 유사하다. ANSI (American National Standards Institute) 표준 SQL의 기능은 전부 지원한다.

단 유의할 점은 Entity를 대상으로 하는 쿼리문이다. 당연히 실제 DB Query는 다르게 찍힌다.

/* 주석으로 JPQL 쿼리문을 보여준다 */, 아래는 실제 생성된 SQL문

즉, 추상화된 SQL을 사용하는거라 특정 데이터베이스 SQL에 의존하지 않는다.

 

 

📌 JPQL 생성 - JPA Criteria

JPQL의 기능은 풍부하지만, 아무래도 String 값으로 직접 입력하기에 동적쿼리를 만들기 너무 까다롭다.

만약 파라메타를 가져와서 조건을 넣어서 쿼리를 넣는다고 생각해보자. JPQL 호출 메서드가 매우 더러워진다.

문자열을 합칠 때 생기는 버그도 많고, 신경쓸게 너무 많다.

그래서 Java JPA 표준에서 자바 코드로 쿼리를 생성할 수 있게 Criteria라는 JPQL Builder를 제공해준다.

➡ 그러나 너무 사용법이 복잡해서 아무도 안쓴다. 오픈소스인 QueryDSL을 사용한다. 

예제의 where 절을 보자. 간단한 쿼리도 저렇게 나오는데, 조건이 조금만 추가되도 사용하기가 너무 어렵다.

// 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”)); 

// EntityManager에 Criteria 쿼리 전달
List<Member> resultList = em.createQuery(cq).getResultList();

 

 

📌 QueryDSL (오픈소스)

설정은 조금 귀찮지만, Criteria에 비해서 사용하기 매우 편하다.

또한 자바 코드로 작성되었기에 재사용 가능하고, 컴파일 시점에서 많은 오류를 잡을 수 있다.

// Factory 생성
JPAFactoryQuery query = new JPAQueryFactory(em);

//select m from Member m where m.age > 18
QMember m = QMember.member;

List<Member> list = 
 query.selectFrom(m)
 .where(m.age.gt(18)) 
 .orderBy(m.name.desc())
 .fetch();

QueryDSL도 제대로 공부하면 JPA급 분량이 나오므로, 이 정도만 소개하고 넘어가도록 하겠다.

참고로 이는 Java JPA 표준 기술이 아니라 오픈소스이다.

 

다만 Criteria든 QueryDSL이던 결국 JPQL 을 생성해주는 도구이다.

JPQL의 동작을 이해하고 잘 사용할줄 안다면 위와 같은 도구는 쉽게 사용할 수 있다. (초기설정만 조금 귀찮을 뿐)

 

 

📌 네이티브 SQL

Oracle Connect by와 같이 표준 SQL문법(ANSI)를 벗어나는 기능을 사용하고 싶거나

정말 쿼리로직이 복잡해서 직접 쌩 쿼리를 날리고 싶은 경우 사용한다.

• 특정 데이터베이스만 지원하는 함수, 문법
• SQL 쿼리 힌트
• 인라인 뷰, UNION, INTERSECT
• 스토어드 프로시저

위와 같은 이유로 JPQL을 사용할 수 없는 경우, Native SQL을 통해 직접 SQL을 작성할 수 있다.

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

어노테이션을 이용하면 조금 더 쉽게 적용 가능하다.

@Entity
@NamedNativeQuery(
    name = "Member.memberSQL",
    query = "SELECT ID, AGE, NAME, TEAM_ID " +
            "FROM MEMBER WHERE AGE > ?",
            resultClass = Member.class
)
public class Member {.. }

TypedQuery<Member> nativeQuery =
    em.createNamedQuery("Member.memberSQL", Member.class)
      .setParameter(1, 20);

 

어노테이션으로 쉽게 사용할 수 있다. JDBC를 직접 쓰는 것과 다른 점은 Native SQL 사용 시 엔티티를 조회하고, JPA가 지원하는 영속성 컨텍스트의 기능을 그대로 이용 가능하다.

 

참고로 적절하게 설정만 한다면 JPA와 똑같이 결과 매핑( getResultList() )으로 받아올 수도 있다.

@Entity
@SqlResultSetMapping( name = "memberWithOrderCount",
    entities = {@EntityResult (entityClass = Member.class)},
    columns = {@ColumnResult (name = "ORDER_COUNT")}
)
@NamedNativeQuery(
    name = "Member.memberWithOrderCount", // 네임드 쿼리 이름(필수)
    query = "SELECT M.ID, AGE, NAME, TEAM_ID, I.ORDER_COUNT" + // SQL 쿼리(필수)
            "FROM MEMBER M" +
            "LEFT JOIN " +
            "    (SELECT IM.ID, COUNT(*) AS ORDER_COUNT " +
            "    FROM ORDERS O, MEMBER IM" +
            "    WHERE O.MEMBER_ID = IM.ID) I " +
            "ON M.ID = I.ID",
    SqlResultSetMapping = "memberWithOrderCount" // 결과 매핑 사용
)
public class Member { ... }

List<Object[]> resultList =
    em.createNamedQuery("Member.memberWithOrderCount")
      .getResultList();

 

 

📌 JDBC 직접사용 (MyBatis, SpringJdbcTemplate과 함께 사용)

아예 JPA를 안거치고 사용하는 방법.

그냥 사용하는 거다. 영속성 컨텍스트를 안거치고 직접 조회한다.

 

결국 JPA도 저수준에서는 JDBC로 동작한다. 잘 사용한다면 JPA와 JDBC를 함께 사용할 수 있다.

실무에서도 쿼리가 복잡해지거나 성능 튜닝이 필요하다면 SpringJdbcTemplate으로 JPA와 함께 사용하는 경우가 많다.

 

다만 JDBC를 직접 사용하는건 영속성 컨텍스트를 거치지 않으니 JPA와 함께 사용한다면 DB에 반영되었는지 잘 확인하고 사용해야한다. (수동 flush)

 

 

📌 요약

보통

• JPQL
• QueryDSL
• JDBC API (SpringJdbcTemplate) - 단 쿼리가 엄청 복잡한 경우. 대부분은 QueryDSL 선에서 처리 가능

이렇게 3가지를 많이 사용한다.

 

📌 JPQL 문법

📑 기본 문법

그냥 SQL 표준 문법이다.

• select m from member as m m.age > 18
  반드시 별칭(m)은 넣어주어야한다. [as m]을 생략하더라도 하이버네이트는 문제가 없지만, 표준 동작은 아님.
• 엔티티와 속성 (Member, m.age)는 대소문자를 구분한다.
• JPQL 문법 키워드 (SELECT, from)는 대소문자를 구분하지 않는다. 
• 당연한거지만 FROM Entity 로 사용해야한다. 테이블 이름을 쓰는게 아니다. 엔티티에 대한 추상화된 쿼리이다.

 

그 외 COUNT, SUM등은 설명이 필요 없을정도로 사용법도 직관적이다.

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

 

---

📑 쿼리실행과 결과 반환

반환 타입이 명확하지 않다면 Query 객체를 사용한다.

예) select m.username, m.age from Member m ➡ String(username)과 int(age)를 함께 조회. 타입을 알 수 없음.

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

 

반환타입을 이미 알고있다면 제네릭인 TypeQuery를 사용하면 된다.

이 경우 createQurey 메서드의 2번째 인자에 타입을 넘겨주면 된다.

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

 

결과 조회는 아래와 같이 할 수 있다.

query.getResultList(); // 컬렉션. 값이 하나 이상, 결과가 없다면 빈 리스트 반환

query.getSingleResult(); // 단일객체. 값이 단 하나, 결과가 없거나 둘 이상이면 예외를 반환
/*  javax.persistence.NoResultException :: 결과가 없습니다.
    javax.persistence.NonUniqueResultException :: 결과가 유니크하지 않습니다. (여러개 반환) */

 

다만 getSingleResult()는 논란이 많은 메서드이다.

예외를 반환하면 try - catch문으로 분기를 작성해줘야하는데, 이게 여러번 반복되면 상당히 번거롭기 때문. 그래서 Spring Data JPA에는 이를 추상화시켜  null이나 Optional을 반환하도록 동작한다. (내부 코드에서 JPA catch를 잡아서 처리한다.) 

 

📑 파라미터 바인딩

이름 기준 바인딩 :name

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

// 쿼리 파라메타 입력
query.setParameter("username", usernameParam);

 

위치 기준 바인딩 ?n - 다만 사용하지말것. 순서를 바꾸면 버그가 쉽게 발생함.

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

// 쿼리 파라메타 입력
query.setParameter(1, usernameParam);

 

다만 위와 같이 쿼리를 메서드로 분리해서 사용하는 경우는 거의 없다.

메서드 체이닝을 이용해 한번에 적는 걸 권장한다.

em.createQuery("SELECT m FROM Member m where m.username=:username ", Member.class)
     .setParameter("username", "member1")
     .getSingleResult();

 

📑 프로젝션(Projection)

프로젝션은 Select 절에 조회할 대상을 지정하는 것을 의미한다. DB 프로젝션이랑 비슷한 의미.

프로젝션 대상: 엔티티, 임베디드 타입, 스칼라 타입(숫자, 문자등 기본 데이터 타입)

DB와 다르게 JPA에는 [엔티티, 임베디드] 타입이란 개념이 있으니까.

 

🚩퀴즈 - 아래의 쿼리는 Member 객체의 list를 반환한다.

그렇다면 리스트 안에 있는 각각의 'Member' 객체는 영속성 컨텍스트에 관리가 될까? 안될까?

정답 : 된다. List 안에 있는 모든 객체가 영속성 컨텍스트에 저장된다.

그래서 엔티티 프로젝션이라는 말로 따로 언급하는 것이다. 이는 당연히 저장되는게 아니다.

List 안에 있는 Member를 변경해도, 영속성 컨텍스트가 동작해서 Dirty-Checking을 해준다.

 

당연한거지만 임베디드 타입은 '값' 이기 때문에 조회할 때 소속된 Entity를 이용해서 가져와야한다.

em.createQuery("SELECT o.address FROM Order o", Address.class)
// SELECT address FROM Address a 는 불가능.

 

스칼라 타입(그냥 값)의 경우에는 아래와 같이 사용하면된다.

em.createQuery("SELECT m.name FROM Member m")

 

그런데 만약 값이 2개가 넘는다면 어떻게 받아와야할까? 임베디드 타입은 Class로 묶여있지만 스칼라는 그냥 값인데?

em.createQuery("SELECT m.name, m.age FROM Member m") // name(String)과 age(Int)를 함께 받아오는법??

이 때는 TypeQuery 대신를 그냥 Query를 사용하면 된다.

그럼 내부적으로 Object 2차원 배열이 반환된다.

타입을 지정해주지 않으면 원소값으로 Object[ username, age ] 가 들어가있다.

 

 

참고로 List<Object[]>로 사용하면 TypeQuery를 사용해서 가져오게된다. 사용법은 동일하다.

List<Object[]> resultList = em.createQuery("select m.username, m.age from Member m");
								.getResultList();
                                
Object[] result = resultList.get(0);
// result[0] == username1
// result[1] == age1

 

조금 더 깔끔한 방법은 new 명령어를 사용하는 것이다.

DTO를 바로 만들어서 반환받을 수 있다. 다만 전체 패키지명을 다 적어줘야한다는 단점이 있다.

* 나중에 쿼리빌더 (QueryBuilder)를 사용하면 패키지명을 쉽게 입력할 수 있다.

SELECT new com.mypackage.UserDTO(m.username, m.age) FROM Member m

List<MemberDTO> result = em.createQuery("SELECT new jpabook.jpql.UserDTO(m.username, m.age) FROM Member m")
      		  .getResultList();

 

📑 페이징 API

DB SQL을 써봤다면 알겠지만, 페이징 쿼리는 언제나 골칫거리였다.

-- 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 ?, ?

-- Oracle
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_ > ?

그래서 JPA에서는 페이징을 단 2개로 추상화한 API를 제공해준다.

1번부터 10페이지까지..와 신세계! (참고로 실제 쿼리는 위의 예제처럼 찍힌다.)

 

📑 JPQL 조인

간단하다.

물론 조인문을 직접 사용하지 않아도 조회할때 조인이 필요하면, Join SQL이 나가게 된다.

하지만 가능하면 JPQL도 명시적인 Join문을 사용해주자. DB 튜닝 할때 도움되기도하고, 되도록이면 SQL과 비슷하게 구성하는게 좋다.

(내부조인 중 하나인 세타 조인)은 특정 조건(=, &amp;gt;, &amp;lt;)으로 조인하는 것을 의미한다.

 

📑 신기능 - 조인 ON절

(JPA 2.1 + 하이버네이트 5.1)부터 ON절을 활용할 수 있다. 연관 관계가 없는 외부조인이 가능하다. (JPQL)

다만 그 이하 버전을 사용하는 기업(SpringBoot 1.0 버전 시절)은 거의 없으므로, 그냥 기본기능이라고 생각해도 좋다.

ON으로 조인 조건(조인대상 필터링)이 가능하다.

 

📑 서브쿼리

크게 어렵지 않다. 

--팀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)

 

다만 2번 예제처럼 서브쿼리가 외부 참조값이 있으면 성능이 좋지않다.

 

다만 JPA 에서는 WHERE, HAVING 서브쿼리만 제공하고, 하이버네이트에서는 SELECT 서브쿼리까지 지원한다.

인라인 뷰(FROM 절 서브쿼리)는 JPQL에서는 불가능하다 

from 서브쿼리는 불가능. 조인으로 풀어서 해결해야함.

이게 안되는 이유는 ORM 기술의 한계..뭐 이런건 아니고 하이버네이트 JPQL Parser가 아직 인라인뷰를 지원하지 않기 때문이다. SQL 쿼리를 생성하는데 어려움이 있어서 그러한 듯 하다. 하이버네이트 6.0이 나오면 해결될 수도 있다.

 

만약 인라인뷰를 조인으로 풀 수가 없는 상황이라면 아래와 같은 대안이 있다.

1. 조인으로 변경한다.

2. 쿼리를 여러개로 분리한다.

3. 그래도 답이 안나오면 네이티브 쿼리를 사용한다.

 

조인은 말 그대로 테이블 2개를 가져오는거고, 네이티브는 그냥 쌩 SQL을 쓰는거다.

쿼리를 여러개로 분리하는 방법을 설명하자면, 아래와 같은 예제 테이블이 있다고 생각해보자.

예제 테이블 구조

 

그리고 인라인뷰(From절 서브쿼리)가 필요할 때

-- 팀당 나이가 가장 많은 회원의 정보(username, age)를 출력하라
SELECT m.*
FROM member m, (select team_id, max(age) as max_age from member group by team_id) m2
WHERE m.team_id = m2.team_id and m.age = m2.max_age;

 

이렇게 2개로 쪼개라는 말이다. 조금 번거롭긴 하다.

-- 1. 팀당 max(age)를 뽑아냄. Java 변수로 값을 저장해둠
select team_id, max(age) as max_age from member m2 group by team_id;

--2. 저장한 max(age)를 이용해서 원하는 회원을 조회함.
select m.team_id, m.username, m.age from member m
where (m.team_id = 1 and m.age = 20) or (m.team_id=2 and m.age=30);

예제 테이블 구조

 

다만 위에서 말한 것처럼, 쿼리가 정말 복잡해서 JPQL로 만들기 어려운 경우가 종종 있다.

그땐 그냥 네이티브 쿼리를 사용하거나 순수 JDBC(SpringJDBCTemplate)를 이용해서 쌩 SQL을 사용하면 된다.

 

영속성 컨텍스트 flush만 적절하게 해준다면, 큰 문제없이 함께 사용할 수 있다.

 

📑JPQL 타입 표현

우리가 직접만든 엔티티나 임베디드 타입은 패키지명을 그대로 쓰면 사용이 가능했다.

보통은 위와 같이 파라메타를 넣어서 메서드로 할당하기에 크게 어렵지 않다.

이외에도 JPQL 구문에 아래와 같은 기본타입들을 사용할 수 있다.

이렇게 결과값에 상수를 박아넣을 수도 있다. ('HELLO' , TRUE)

참고로 엔티티 타입으로 조회도 가능하다.

@DiscriminatorValue와 함께 사용할 수 있다.

 

📑 조건 CASE 식

JPQL은 간단한 조건식 (case when else)를 제공해준다.

아래와 같은 특수한 조건식도 제공해준다.

이는 JPA 표준함수라서, 모든 DB에서 동일하게 동작을 보장한다.

그 외 아래와 같은 JPQL 표준 함수들이 존재한다. 생각보다 많이 없다.

 

그 외 특정 DB에서만 제공하는 함수는 아래와 같이 정의할 수 있다.

물론 그냥 되는건아니고, 해당 DB의 Dialect를 등록해주어야하는데 이미 다양한 종류의 Dialect를 하이버네이트에서 제공해주므로 편하게 쓸 수 있다. 만약 내가 쓰는 DB가 없다면 직접 Dialect를 등록해야한다. 물론 그럴 일은 없지만

 

📑 경로 표현식

경로 표현식은 객체 그래프탐색 (member.name)을 의미한다.

SQL에는 이런게 없으니까, 이런 객체 그래프 탐색을 JPQL 에서 제공하는 경로표현식이라고 부른다.

 

상태, 단일 연관, 컬렉션 연관을 굳이 구분하는 이유는, JPA의 동작이 달라지기 때문이다.

 

각각의 동작은 아래와 같다.

결론부터 이야기 하자면, 묵시적 조인이 발생하지 않도록 JPQL을 만들자.

당연한거긴한데, 임베디드 값 타입의 경우에도 탐색이 가능하다. Address.city&amp;nbsp;

m.team.name 처럼 객체 그래프 탐색이 가능하다.

컬렉션 연관관계는 탐색은 안되지만, 내부에서 조인은 그대로 발생한다.

그냥 객체가 컬렉션(List) 에 들어가니까, List.size() 이런 메서드밖에 호출이 안되서 탐색이 안되는거지 [단일 값 연관경로]와 똑같이 조인은 발생한다. 만약 as로 별칭을 주면 탐색가능하다.

이렇게 join 구문을 이용해서 별명을 지정해주면 team.member.username 이런 탐색이 가능.

즉 JPQL에서는 아무일이 없는 것 같지만, 아무도 모르게 SQL 성능이 구려진다. 매우 조심스럽게 사용해야한다.

그냥 묵시적 조인을 쓰지말고, 내부에서 조인이 발생한다면 JPQL join 구문을 이용해서 명시적으로 바꿔주자.

간단한 쿼리인데, 조인쿼리가 발생했다. 나중에 이런거 찾아서 DB튜닝하려면 매우 귀찮다.

만약 school.class.students.student.address.city 이렇게 탐색을 해버리면

SQL 이너조인이 7번 발생한다. 도메인 설계, 성능 둘 다 끔찍하다.

실무에서는 명시적 조인만 사용하자. SQL 튜닝이 매우 중요하다.

 

📑 join fetch(패치조인)

참고로 DB에는 패치조인이라는 개념이 없다.

JPA에서 성능 최적화를 위해 제공하는 기능으로, 연관된 엔티티나 컬렉션을 SQL한방쿼리로 바꾸는 기능이다.

참고로 Inner Join으로 가져오게 된다.

회원4 는 Team이 없어서 제외됨.(inner join)

String jpql = "select m from Member m join fetch m.team";

List<Member> members = em.createQuery(jpql, Member.class)
    .getResultList();
    
for (Member member : members) {
    //페치 조인으로 회원과 팀을 함께 조회해서 지연 로딩X
    System.out.println("username = " + member.getUsername() + ", " +
        "teamName = " + member.getTeam().name());
}

 

 

일대다 (@OneToMany)도 마찬가지.

다만 이 경우 N+1 문제가 발생하는 걸 잊지말자. 이는 Lazy로 조회해도 마찬가지이다. (Lazy는 실 사용까지 조회 타이밍을 늦춰줄 뿐, N+1을 최적화시켜서 제거하는게 아니다)

 

📑 패치조인과 Distinct

SQL의 DISTINCT는 중복을 제거하는 명령이다.

하지만 일대다(@OneToMany)관계에서는 위 그림처럼 중복 레코드(팀A-회원1, 팀A-회원2, 팀A-회원3...)가 발생하기 때문에, 패치조인과 함께 사용하면 DISTINCT가 제대로 동작하지 않는다. 다대일 관계에서는 중복이 발생할 일이 없다.

SQL의 DISTINCT는 모든 값이 똑같아야 제거된다. 패치 조인때문에 제대로 제거되지 않는다.

다만 JPA에서 엔티티를 조회하면 제거가 되어있는데, 이는 어플리케이션(JPA)에서 중복된 엔티티를 제거하기 때문이다.

뭐 별 생각없이 사용할 수도 있겠지만, JPA에서 한번 더 처리하기에 실제 SQL 쿼리문은 다르다는걸 인지하고있자.

 

fetch 키워드 사용은, 객체 그래프를 SQL 한방에 (즉시로딩) 가져온다 생각해도 된다.

패치조인 사용시 이렇게 쿼리가 바뀐다.

 

📑 패치조인의 한계

패치조인은 말 그대로 객체 그래프에 있는 모든 객체를 한방에 가져오는 쿼리다.

만약 별칭(m.username)을 주고 일부만 사용하면, 나머지 데이터에 대해서 JPA가 이상하게 동작할 수 있다.  

하이버네이트 경고. 데이터가 뻥튀기 되어 [ 회원수 * 팀수 * 팀수 ] 이런 식의 미친 쿼리가 나올 수 있다.

별칭과 같은 이유로 페이징 API를 사용해서는 안된다. 물론 데이터 뻥튀기가 되지않는 ManyToOne은 상관없다.

데이터가 뻥튀기 되어 페이징이 이상하게 될 수 있다.

만약 그런게 필요하다면 다대일(@ManyToOne)에서 별도의 쿼리로 직접 가져오도록 하자.

 

사용하지 않는 나머지 데이터가 삭제되거나 제대로 반영되지 않을 수 있다. (정합성 이슈) 패치 조인은 객체 그래프에 있는 데이터를 전부 다 가져오도록 설계되었으므로, 이러한 오류를 보장해주지 않는다.

 

✔ 다만 아래와 같은 경우, 조인 패치를 적을 때 별칭을 사용하기도 한다.

다만 join fetch를 적기 위해서 사용한거지, 별칭으로 m.username 이런걸 쓰는건 절대금지.

 

마지막으로 둘 이상의 컬렉션을 패치조인하면 안된다. 일대다(@OneToMany)도 데이터가 뻥튀기 되는데, (@OneToManyToMany) 이렇게 해버리면 정합성이 깨질 수 있다.

 

 

📑 패치조인의 특징과 한계

 

 

📌 벌크 연산 (수정,삭제)

JPA는 커밋 시점에 Entity의 변경을 감지해서 적절한 쿼리를 발생시킨다.

하지만 작업을 하다보면 벌크성 쿼리(ex 재고가 10개 미만인 상품 전체의 가격을 20% 상승) 작업을 할 때도 있다.

 

SQL로는 간단한 작업이지만 JPA 변경감지로는 리소스도 많이 잡아먹고, 쿼리가 변경된 개수만큼 나갈 수 있다.

그래서 순수 JPA에서도 이러한 작업을 위해 executeUpdate() 라는 메서드를 제공해줬었다.

• 해당 메서드는 영속성 컨텍스트를 무시하고, 데이터베이스에 직접 쿼리를 날린다.
  = 벌크연산은 변경감지가 작동하지 않는다. 사용하면 영속성 컨텍스트와 Database의 정합성이 깨진다.
• 그래서 벌크연산 이후에 영속성 컨텍스트를 초기화(em.clear)하고 다른 작업을 하는 것을 권장한다.
  가능하면 벌크연산을 먼저 하고 em.clear()를 하도록 하자.
  영속성 컨텍스트를 완전히 비워버리면 데이터베이스에서 다시 조회하기 때문에 정합성이 깨지지않는다.

참고로 JPA 는 Update, Delete 쿼리만 지원하고, 하이버네이트에서는 select (insert into select문)까지 추가 지원한다.

// Update 벌크연산
String query = "update Product p "+
    "set p.price = p.price * 1.1 " +
    "where p.stockAmount < :stockAmount";

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

// Delete 벌크연산. (Select 벌크연산은 JPA 스펙에는 없고, 하이버네이트만 지원한다.)
int deletedCount = em.createQuery("DELETE FROM Country").executeUpdate();

참고로 하이버네이트만 지원하는 벌크성 insert into select는 아래와 같은 배치 쿼리를 말한다.

// Batch
INSERT INTO table1 (col1, col2) VALUES
(val11, val12),
(val21, val22),
(val31, val32);