JPA - 영속성 컨텍스트와 JPQL

쿼리 후 영속 상태인 것과 아닌것

-JPQL의 조회 대상은 엔티티, 임베디드 타입, 값 타입 같이 다양하다. 하지만 엔티티를 조회하면 영속성 컨텍스트에 관리되지만 나머지는 관리되지 않는다. 예를 들어 임베디드 타입만 참조해서 조회했을 경우에 값을 변경해서 플러시 시점에 반영되지 않는다. 하지만 엔티티를 조회하여 엔티티가 가지고 있는 임베디드타입을 변경했을 경우에는 플러시 시점에 변경이 반영이 된다.

JPQL로 조회한 엔티티와 영속성 컨텍스트

JPQL과 플러시 모드

JPQL은 영속성 컨텍스트에 있는 데이터를 고려하지 않고 디비에서 데이터를 조회한다. 따라서 JPQL을 실행하기 전에 영속성 컨텍스트의 내용을 디비에 반영해야한다. 그렇지 않으면 의도하지 않은 결과가 발생할 수 있다.

이 예제는 QueryDSL의 수정 배치 쿼리이다. 이 예제의 결과가 어떻게 될것인가? 결과는 정말 의도치 않게 나오게 된다. QueryDSL의 배치쿼리는 영속성컨텍스트와 관계없이 직접 디비로 요청을 보내게 된다. 이러는 순간 디비와 영속성컨텍스트의 동기화는 깨진것이다. 변경을 완료했고 나는 변경된 이름으로 쿼리를 날렸는데, 이게 뭐람 변경전의 "여성게1"이란 결과가 나오게 된다. 이유는 위에서 설명한 것과 같이 영속성컨텍스트에 이미 존재하기 때문에 디비에서 가져온 엔티티가 데이터가 달라도 식별자 값이 같기 때문에 버려지게 되고 수정전에 이름이 출력되게 되는 것이다.

이 코드는 실무에서는 사용할 수없는 코드이다. 하지만 직관적으로 영속성 컨텍스트의 값을 수정배치쿼리와 동일하게 변경한것을 보여주기 위해 짠것이다. 이 예제의 결과는 수정배치에서 변경된 값과 동일한 엔티티가 반환되게 된다.

JPA - JPAQuery와 Q클래스

긴 포스팅은 아니지만 예제로 소스를 짜는 도중에 몰랐던 내용을 알게되어서 작성한다. QueryDSL로 예제중 나온 상황이다.

언뜻 보기에는 크게 문제가 없는 듯 싶다. 하지만 이 소스를 실행하면 이러한 예외가 발생한다.

java.lang.IllegalStateException: qMyEntity is already used

즉, 같은 JPAQuery 객체로 같은 Q타입클래스를 사용할 수없는 것이다. 사실 내부를 까보지는 않아서 원인파악은 해보아야겠지만 일단 결론은 그렇다. 그렇기 때문에 소스가 이런식으로 변경되어야한다.

이런식으로 JPAQuery 객체를 만드는 메소드를 하나 정의하는 것이 좋을 것같다.

언젠가는 이런 상황이 닥칠수도 있을 것같아서 포스팅한다..

JPA - NativeQuery ( SQL ) 네이티브 SQL 사용하기!

JPA는 SQL이 지원하는 대부분의 문법과 SQL 함수들을 지원하지만 특정 데이터베이스에 종속적인 기능은 잘 지원하지 않는다. 하지만 때론 특정 데이터베이스에 종속적인 기능이 필요할 수도 있다. 다양한 이유로 JPQL을 사용할 수 없을 때, JPA는 SQL을 직접 사용할 수 있는 기능을 제공하는데 이것을 네이티브 SQL(네이티브쿼리)라고 한다. 즉, 사용자가 직접 데이터베이스에 날리는 쿼리를 작성하는 것이다. 그렇다면 JPA가 지원하는 네이티브 SQL과 JDBC API를 직접 사용하는 것에는 어떤 차이가 있냐? 그것은 바로 네이트브 쿼리는 엔티티를 조회할 수 있고 JPA가 지원하는 영속성 컨텍스트의 기능을 그대로 사용할 수 있다는 것이다!

Native Query API

1. //결과 타입 정의
2. public Query createNativeQuery(String sqlString, Class resultClass) {}
3. //결과 타입을 정의할 수 없을 때
4. public Query createNativeQuery(String sqlString) {}
5. //엔티티 타입이 아닌 결과 값일때
6. public Query createNativeQuery(String sqlString
7.                         ,String resultSetMapping) {}

 이렇게 세가지의 오버로딩된 메소드를 사용한다.

1. /*
2.  * 네이티브쿼리는 위치기반 파라미터 바인딩만 지원한다.(구현체중 일부는 이름기반 파라미터 바인딩도 지원함)
3.  */
4. public void nativeQuery() {
5.         String sql = "SELECT MEMBER_JPQL_ID,USERAGE,USERNAME,TEAM_ID FROM MEMBER_JPQL WHERE USERAGE> ?";
6.         
7.         Query nativeQuery = em.createNativeQuery(sql,MemberJPQL.class).setParameter(1, 35);
8.         
9.         List<MemberJPQL> resultList = nativeQuery.getResultList();
10.         
11.         System.out.println("====================nativeQuery=====================");
12.         
13.         for(MemberJPQL m : resultList) {
14.                 System.out.println(m.toString());
15.         }
16.         
17.         System.out.println("====================nativeQuery=====================");
18. }

리턴타입이 엔티티일 경우이다. em.createNativeQuery(SQL문장,리턴타입클래스)로 Query객체를 만들어낸다. 위의 예제를 보면 JPQL과 다를 것은 쿼리를 직접작성하냐 안하냐의 차이지 대부분의 로직은 비슷하다.(JPA가 자동으로 생성해주는 SQL를 사용자가 직접 작성한 것뿐 더이상의 차이는 거의없다.)

그리고 Native Query에서는 반환타입이 명시되어도 Query 객체로 반환받는다는 점을 유의하자.

다음은 결과 매핑 사용 예제이다.

1. @Entity
2. @Table(name = "MEMBER_JPQL")
3. //@Getter
4. //@Setter
5. @ToString
6. @SqlResultSetMapping(name = "memberWithOrderCount",
7.                                         entities = {@EntityResult(entityClass = MemberJPQL.class)},
8.                                         columns = {@ColumnResult(name = "ORDER_COUNT")})
9. public class MemberJPQL {....}

1. /*
2.  * ResultMapping
3.  */
4. public void nativeQuery2() {
5.         String sql = "SELECT M.MEMBER_JPQL_ID AS ID,USERAGE AS AGE,USERNAME,TEAM_ID,I.ORDER_COUNT "
6.                                 + "FROM MEMBER_JPQL M JOIN  "
7.                                                 + "(SELECT IM.MEMBER_JPQL_ID, COUNT(*) AS ORDER_COUNT "
8.                                                 + "FROM ORDER_JPQL O, MEMBER_JPQL IM "
9.                                                 + "WHERE O.MEMBER_JPQL_ID = IM.MEMBER_JPQL_ID) I "
10.                                 + "ON M.MEMBER_JPQL_ID = I.MEMBER_JPQL_ID";
11.                                 
12.         Query nativeQuery = em.createNativeQuery(sql,"memberWithOrderCount");
13.         
14.         List<Object[]> resultList = nativeQuery.getResultList();
15.         
16.         System.out.println("====================nativeQuery2=====================");
17.         
18.         for(Object[] m : resultList) {
19.                 System.out.println(m[0].toString());
20.                 System.out.println(m[1]);
21.         }
22.         
23.         System.out.println("====================nativeQuery2=====================");
24. }

특별한 것은 없다. 엔티티클래스에 네이티브 쿼리로 받을 반환 타입을 명시해주었고, 네이티브 쿼리를 사용한 쪽에서는 반환타입을 엔티티클래스에 작성한 반환타입 이름 값을 문자열로 넘겨주었다. 그래서 반환된 Object[]에서 Object[0]은 회원엔티티로 매핑되고, Object[1]은 스칼라타입으로 ORDER_COUNT를 담고있다.

어노테이션을 보면 속성 값이 entities,columns로 된것으로 보아 여러개의 엔티티,칼럼을 매핑할 수 있다. 그리고 @SqlResultSetMappings 어노테이션이 있기 때문에 여러개의 매핑타입을 만들 수 있다.

그런데 대부분 엔티티 클래스의 id클래스의 필드명은 "id"로 거의 동일하게 하는 경우도 많다. 그래서 조회를 하면 칼럼명이 중복나는 경우가 생기게 된다. 그때는 필드매핑까지 포함하여서 조회가능하다.

1. @Entity
2. @Table(name = "MEMBER_JPQL")
3. //@Getter
4. //@Setter
5. @ToString
6. @SqlResultSetMappings({
7.         @SqlResultSetMapping(name = "memberWithOrderCount",
8.                         entities = {@EntityResult(entityClass = MemberJPQL.class)},
9.                         columns = {@ColumnResult(name = "ORDER_COUNT")}
10.         )
11.         ,@SqlResultSetMapping(name = "memberInfo",
12.                         entities = {
13.                                         @EntityResult(entityClass=MemberJPQL.class,
14.                                         fields = {
15.                                                         @FieldResult(name = "id",column = "member_id")
16.                                                         ,@FieldResult(name = "age",column = "client_age")
17.                                         })
18.                         }
19.         )
20.         
21. })
22. public class MemberJPQL {...}

1. public void nativeQuery3() {
2.         String sql = "select MEMBER_JPQL_ID as member_id,USERAGE as client_age "
3.                         + "from member_jpql where USERNAME = '여성게1'";
4.         
5.         Query nativeQuery = em.createNativeQuery(sql,"memberInfo");
6.         
7.         List<MemberJPQL> resultList = nativeQuery.getResultList();
8.         
9.         System.out.println("====================nativeQuery3=====================");
10.         
11.         for(MemberJPQL m : resultList) {
12.                 System.out.println(m.toString());
13.         }
14.         
15.         System.out.println("====================nativeQuery3=====================");
16. }

부득이하게 조회할 컬럼명을 별칭으로 주었을 경우, 엔티티 클래스와 매핑이 되지 않는다. 그럴때 엔티티클래스에 필드매핑을 이용한다.

@FieldResult(name = "id",column = "member_id")

name이 엔티티클래스의 필드명이고, column이 조회하였을 때 반환되는 컬럼명이다.

마지막으로 이전에 다루었던 정적쿼리(@NamedQuery)처럼 네이티브 쿼리로 정적쿼리처럼 엔티티클래스에 정의할 수 있다.

▶︎▶︎▶︎JPA - @NamedQuery , 정적 쿼리

1. @Table(name = "MEMBER_JPQL")
2. //@Getter
3. //@Setter
4. @ToString
5. @SqlResultSetMappings({
6.         @SqlResultSetMapping(name = "memberWithOrderCount",
7.                         entities = {@EntityResult(entityClass = MemberJPQL.class)},
8.                         columns = {@ColumnResult(name = "ORDER_COUNT")}
9.         )
10.         ,@SqlResultSetMapping(name = "memberInfo",
11.                         entities = {
12.                                         @EntityResult(entityClass=MemberJPQL.class,
13.                                         fields = {
14.                                                         @FieldResult(name = "id",column = "member_id")
15.                                                         ,@FieldResult(name = "age",column = "client_age")
16.                                         })
17.                         }
18.         )
19.         
20. })
21. @NamedNativeQueries({
22.         @NamedNativeQuery(name = "Member.memberSQL",
23.                                                 query = "select member_jpql_id,userage,username,team_id "
24.                                                                 + "from member_jpql "
25.                                                                 + "where username = ?",
26.                                                 resultClass=MemberJPQL.class)
27.         ,@NamedNativeQuery(name = "Member.memberSQL2",
28.                         query = "select MEMBER_JPQL_ID as member_id,USERAGE as client_age "
29.                                         + "from member_jpql where USERNAME = ?",
30.                         resultSetMapping = "memberInfo")
31. })
32. public class MemberJPQL {}

1. public void nativeQuery4() {
2.         
3.         Query nativeQuery = em.createNamedQuery("Member.memberSQL",MemberJPQL.class)
4.                         .setParameter(1, "여성게1");
5.         
6.         List<MemberJPQL> resultList = nativeQuery.getResultList();
7.         
8.         System.out.println("====================nativeQuery4=====================");
9.         
10.         for(MemberJPQL m : resultList) {
11.                 System.out.println(m.toString());
12.         }
13.         
14.         System.out.println("====================nativeQuery4=====================");
15. }
16. public void nativeQuery5() {
17.         
18.         Query nativeQuery = em.createNamedQuery("Member.memberSQL2")
19.                         .setParameter(1, "여성게1");
20.         
21.         List<MemberJPQL> resultList = nativeQuery.getResultList();
22.         
23.         System.out.println("====================nativeQuery5=====================");
24.         
25.         for(MemberJPQL m : resultList) {
26.                 System.out.println(m.toString());
27.         }
28.         
29.         System.out.println("====================nativeQuery5=====================");
30. }

em.createNativeQuery()에서 다루던 것을 어노테이션으로 다 가져다 놓았다고 보면된다. 그리고 조금 특이한 것은 @NamedQuery와 같이 em.createNamedQuery()를 사용한다는 것이다.

JPA - QueryDSL, JPQL Query Builder Class

이전 포스팅에서 다뤘던 JPA Criteria는 문자가 아닌 코드로 JPQL을 작성하도록 도와주는 쿼리빌더였기 때문에 문법 오류를 컴파일 단계에서 잡을 수 있고 IDE툴을 이용하여 자동완성 기능의 도움을 받을 수 있기 때문에 여러가지 장점이 있었다. 하지만 Criteria의 가장 큰 단점은 코드양이 줄지도 않고 너무 복잡하며 바로바로 쿼리를 예상하기가 쉽지 않았다. 하지만 이번에 다룰 QueryDSL은 Criteria와 같이 문자가 아닌 코드로 쿼리를 작성하며, 쉽고 간결하고 빌더로 작성된 모양도 쿼리와 비슷해 쉽게 예상이 가능하다. 오히려 Criteria보다 사용하기 편하다. 하지만 큰 문제라고는 할 수 없지만 Criteria는 JPA가 지원하는 표준이고, QueryDSL은 표준은 아니고 그냥 오픈소스이다. 

▶︎▶︎▶︎JPA - Criteria Query(객체지향 쿼리 빌더), JPQL Query Builder Class

▶︎▶︎▶︎QueryDSL Reference 번역 By 최범균

▶︎▶︎▶︎JPQL(객체지향쿼리),Java Persistence Query Language

QueryDSL이 지원하는 프로젝트

JPA - Criteria Query(객체지향 쿼리 빌더), JPQL Query Builder Class

Criteria 쿼리는 JPQL을 자바 코드로 작성하도록 도와주는 빌더 클래스 API이다. Criteria를 사용하면 문자가 아닌 코드로 JPQL를 작성하므로 문법 오류를 컴파일 단계에서 잡을 수 있고 문자 기반의 JPQL보다 동적 쿼리를 안전하게 생성할 수 있다. 하지만 이번에 Criteria를 간단하게만 다루려고 한다. 이유는 실제 Criteria를 사용해서 개발하다보면 코드가 복잡하고 장황하며 직관적으로 이해하기 힘들다는 단점이 있기때문이다. 다음 포스팅에서는 코드로 쿼리를 작성할 수 있고 간단한 QueryDSL을 다음에 자세히 다뤄볼 예정이기에 이번 포스팅은 몇가지 간단하게만 다뤄본다.

Criteria 기초

이렇게  Criteria쿼리를 완성하고 나면 다음 순서는 기존의 JPQL과 같다. em.createQuery(query)에 완성된  Criteria쿼리를 넣어주면 된다.

다음으로는 검색조건,정렬조건을 정의하는 부분이다. 위와 같이 where절에 들어가는 부분은 Predicate 클래스로, orderBy에 들어가는 부분은 Order 클래스로 정의해준다. 위와 같이 객체로 정의하여도 되지만

~.where(builder.equal(m.get("username"),"여성게1"); 

-->이런식으로 where절에 바로 넣어주어도 된다.

조회(한건,여러건) - Criteria

크게 어려울 부분은 없을 것같다. select()는 단일조회, select2()는 다중값 조회이다. 하지만 여기서 JPQL을 생각해보면 여러 값의 조회를 하나의 DTO클래스로 반환받았던 것이 기억날 것이다. Criteria 역시 NEW 명령어 쿼리를 지원한다.

NEW 명령어를 이용하여 다중값 특정 객체 매핑이후 반환 - Criteria

JPQL과 비교하여 달라진 점이 좀있다. 문자기반이 아니라 코드기반으로 쿼리를 다루다보니 DTO클래스를 풀 패키지명으로 안써도 되는 것이다. 이런것들을 생각하면 문자열을 잘못넣어서 오류날 일은 거의 없을듯 싶다. 하지만 아직까지도 문자열을 쓰는 부분은 조금 남아있다.

Java Map과 비슷한 TupleQuery - Criteria

만약 반환값이 여러개라면 위처럼 DTO로 받을 수도 있지만 마치 Map과 같은 객체처럼 느껴지는 Tuple이라는 객체를 이용해서도 다중 값 쿼리가 가능하다.

코드만 봐도 조금은 직관적으로 보인다. Tuple의 key가 될 값을 반환value.alias(key값)로 지정해준다. 그런다음 결과를 꺼낼때 Tuple객체에서 키값과 반환타입을 넘겨 꺼낸다. 위의 주석에도 있듯이 스칼라타입의 필드말고 엔티티를 전체로 튜플의 값으로도 설정해줄수 있다.

결론적으로 튜플은 이름 기반이므로 순서 기반의 Object[]로 반환받는 것보다 훨씬 안전하다. 그리고 tuple.getElements() 같은 메소드를 사용해서 현재 튜플의 별칭과 자바 타입도 조회가능하다.

조인(Join & Fetch Join) - Criteria

JPQL에서 다루었던 조인과 패치조인이다. 크게 어려울 부분은 없을 것같아 몇가지만 설명하려고 한다. 

Join<MemberJPQL, TeamJPQL> t =m.join("team",JoinType.INNER);

->JPQL과 비교하면 ~ [inner] join m.team t 와 비슷한 구문이라고 보면된다.

그리고 튜플로 반환받기위해 두개의 엔티티 모두에게 별칭을 주었고 마지막 결과를 출력하는 부분에 별칭을 이용하여 객체를 얻어왔다.

그 다음은 패치조인이다.

m.fetch("team"/*,JoinType.LEFT*/);

-> 

일반 조인과는 다르게 반환값을 받아서 사용하지 않는다. 즉, 조회의 결과로 나오는 회원엔티티의 team필드에 값이 세팅되서 나오는 것이다. 그래서 결과값을 받을 경우 회원엔티티로만 받고 그 회원엔티티의 팀엔티티 필드에서 값을 꺼내 사용한다.(사실 Criteria에서 패치조인을 이용하여 두개의 결과값을 받을 수 있는지는 확실히 모르겠다. 혹시 아시는 분은 댓글부탁드립니다.)

Parameter Binding

query.select(m).where(builder.equal(m.get("username")

 ,builder.parameter(String.class,"username")));

-> 이름기반 파라미터 정의를 해준다. (Predicate 객체로 선언해도되지만 이렇게 where절에 바로 넣어도된다.)

TypedQuery<MemberJPQL> query2 = em.createQuery(query)

.setParameter("username", param);

->JPQL과 동일하게 setParameter메소드를 호출해서 세팅해준다.

Criteria Meta Code Generate

지금까지 간단하게 Criteria 쿼리를 설명했다. 확실히 그냥 JPQL을 사용할때 보다 문자열을 사용하여 쿼리를 작성하는 부분이 확 줄었다. 그렇지만 그렇다고 100% 문자열을 사용하지 않는 것은 아니다. 그 말은 100% 실수하지 않으리라는 보장이 없는 것이다. 이때 사용할 수 있는 것이 Meta Code를 생성하여서 위에서 조금 사용한 문자열마저 사용하지 않는 것이다. Meta Code를 생성하면 각 엔티티 클래스마다 메타정보를 가진 자바파일들이 생성되게 된다.

<pom.xml>

이렇게 두개를 설정해준다. 첫번째 의존 라이브러리를 내려받아주고, 두번째는 Meta Code를 생성하기 위한 플러그인 설정을 해주는 것이다.

->Run As..->Run Configuration 에 들어가서 해당 프로젝트의 메이븐 빌드 Goals를 입력하고 Run을 해준다.

->빌드가 완료되었다면 target->generated-sources에 Meta Code들이 생성되어 있을 것이다. 이 다음은 과정은 각자의 IDE환경에 따라 다르다. 만약 target>generated-sources가 자동으로 클래스패스로 잡힌다면 문제가 없지만 만약 클래스패스로 잡히지 않는다면 직접 등록해주어야한다. 클래스패스가 디폴트로 잡히지 않는다는 가정하에 진행한다.

-> 첫 이미지처럼 반드시 패키지명직전까지를 패스로 잡아야한다. 그래서 Meta Code생성시 package관련 에러가 뜨지 않는다. 마지막으로 Apply를 누르면 방금생성된 메타코드가 클래스패스에 들어가있을 것이다(기존의 target부분에는 코드가 없어짐). 혹시나 에러표시가 프로젝트에 계속 난다면 maven update를 하길바란다.

Criteria Meta Code 적용후 쿼리

m.get(MemberJPQL_.username)

->여기에서 사용하던 문자열이 없어졌다. 이제 조금은 에러가 줄것 같다.

지금까지 간단하게 Criteria를 다뤄봤습니다. 사실 개인적인 생각으로는 이것이 편해진것인가...? 하는 생각이 조금 들었습니다. 문자기반으로 작성하지 않을 뿐이고 오히려 코드는 그냥 JPQL을 쓸때보다 복잡해진것같기도 하는 생각이 듭니다.(개인적인 생각입니다. 물론 런타임시점에 에러를 발견해야하는 큰 문제를 해결해준 것만으로도 엄청난 가치가 있다고 생각듭니다.) 그래서 다음 포스팅에서는 쉽고, 간단하고, 코드로 쿼리를 다룰 수 있는 QueryDSL을 이용하여 JPA쿼리를 다뤄보겠습니다.

JPA - JPQL 서브쿼리 (객체지향 쿼리 언어),컬렉션 식

JPQL도 서브 쿼리를 지원하지만 몇 가지 제약사항이 존재한다.

-WHERE, HAVING 절에서만 사용할 수 있고, SELECT,FROM절에서는 사용할 수 없다.

서브쿼리함수

컬렉션식

JPA - JPQL 조인(객체지향쿼리),Java Persistence Query Language 

JPQL 조인은 SQL 조인과 기능은 거의 같고 문법만 약간 다르다.

내부 조인(inner join)

JPQL 내부 조인 구문을 보면 SQL 문법과는 약간 다르다. SQL에서는 조인문에 연관테이블의 외래키로 직접 조인을 하지만 JPQL에서는 from 절의 엔티티의 연관필드로 조인하게 되어 있다. 만약 SQL처럼 조인하면 안된다. (ex ~ FROM MemberJPQL m JOIN TeamJPQL t --->오류발생)

그리고 select 다음에 만약 조인한 엔티티의 특정필드만 뽑는다면 위와 같이 꼭 조인할 연관엔티티에 별칭을 넣어줘야한다.

외부조인(outer join)

컬렉션 조인(Collection Join)

위 주석에도 달려있지만 일대다, 다대다 관계처럼 연관필드에 컬렉션으로 정의되어있는 엔티티를 조인하는 방법이다.

세타조인(Theta Join)

WHERE 절을 사용해서 세타조인을 할 수 있다. SQL에서도 그렇듯이 세타 조인은 내부 조인만 가능하다. 그리고 위에서 했던 조인들은 연관된 엔티티필드를 이용해 조인을 했지만, 세타 조인은 전혀 관계없는 엔티티도 조인할 수 있다. 여기서 전혀 관계가 없다는 것은 매핑된 외래키로 조인하는 것이 아닌 일반 필드로 조인이 가능하다는 뜻이다.

Join on 절

JPA 2.1 버전부터 지원하는 기능이며, On절을 사용하면 조인 대상을 필터링하고 조인할 수 있다. 참고로 내부조인의 On절은 where절에서 필터링하는 결과와 같음으로 보통 On절은 외부 조인에서 사용한다.

패치조인(fetch Join)

패치조인은 SQL에 존재하는 조인의 종류는 아니고 JPQL에서 성능 최적화를 위해 제공하는 기능이다. 이것은 연관된 엔티티나 컬렉션을 한번에 같이 조회하는 기능이다.

패치조인 문법 ::= [ LEFT [OUTER] | INNER ] JOIN FETCH 조인경로 ([]는 선택사항이다)

JPQL문을 보면 t.members로 패치조인한 것이 눈에 보일 것이다. 다른 엔티티를 조인한 것이 아니고 자기자신의 연관필드로 조인을 한것이다. 그리고 패치조인에서는 조인대상이 되는 연관필드에 별칭을 넣을 수 없다. 즉, 사용이 불가한 것이다.

위의 JPQL은 밑의 SQL로 실행된다.

=>

SELECT

M.*,T.*

FROM TEAM_JPQL T

INNER JOIN MEMBER_JPQL M ON M.TEAM_ID=T.ID

팀엔티티는 프로젝션에 포함되지 않았는데, SQL은 팀엔티티까지 조회하게 된다.

위의 주석에도 설명했지만, 회원을 조회할 때 패치조인을 이용하여 팀엔티티를 같이 조회했을 경우에는 아무리 팀엔티티가 지연로딩(FetchType.LAZY)여도 프록시로 반환되는 것이 아니라 실제 엔티티가 반환되고 해당 엔티티가 영속성컨텍스트에 저장된다는 점이다.

컬렉션 패치조인 (Collection fetch Join)의 문제점과 해결방법

위에서 패치조인을 이용하여 팀엔티티의 연관 컬렉션인 회원엔티티를 한번에 조회했다. 하지만 이 조회에는 조금 문제가 있다.

위 그림과 같이 데이터베이스는 같은 팀테이블이지만 데이터가 다른 2개의 로우를 반환하고 있고, 그에 따라 JPA도 2개의 팀엔티티를 결과 리스트로 반환한다. 여기서 생각해보면 팀 테이블은 로우의 데이터가 다르니 2개의 반환값을 갖는 것이 이해되지만 애플리케이션 단의 JPA에서는 같은 팀 엔티티 객체를 꼭 2개를 반환할 필요는 없을 것 같다. 여기서 DISTINCT를 사용한다.

바뀐 것은 select 다음에 distinct를 넣어준 것이다. 이 명령어가 하는 역할은 SQL에 DISTINCT명령어를 추가하는 것은 물론이고 애플리케이션단에서 한번 더 중복을 제거한다. 하지만 이 예제에서 SQL에 DISTINCT명령어가 추가되더라도 달라질 것은 없다. 왜냐? 두개의 로우의 데이터가 다르기 때문이다. 하지만 애플리케이션단에서는 다르다 중복된 팀엔티티 결과를 하나로 줄여주는 역할을 한다.

마지막으로 패치조인의 사용전략이다. 보통 애플리케이션에서 최적화를 위해 글로벌 로딩 전략으로 즉시 로딩(FetchType.EAGER)으로 설정하면 애플리케이션 전체에 불필요한 즉시로딩이 일어난다. 물론 일부는 빠를수도 있지만 전체적으로 봤을 경우엔 성능에 최악이다. 그래서 글로벌 로딩 전략으로는 지연로딩으로 설정하고 필요할때 패치조인을 이용한다면 애플리케이션 성능에 있어 훨씬 효과적일 것이다.

패치조인 특징

1. 패치조인 대상에는 별칭을 줄수 없다.

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

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

경로표현식

쉽게 말하면 쿼리에서 .(점)을 찍어 객체 그래프를 탐색하는 것이다.

ex) m.username, m.team, t.name ....

<경로표현식 용어 정리>

<경로표현식 특징>

위소스코드를 보면 "컬렉션은 더이상 참조가 불가능하다면서?"라는 생각이 들것이다. 하지만 t.members.size에서 size는 참조가 아니고 하나의 함수라고 생각하면된다. 

그렇다면 위에서 컬렉션을 더 참조하고 싶다면 

SELECT m.username FROM TeamJPQL t join t.members m 

처럼 명시적인 조인을 해주어야 연관 컬렉션의 그래프 탐색이 가능하다.

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

1. 항상 내부 조인이다.

2. 컬렉션은 경로 탐색의 끝이다. 컬렉션에서 경로 탐색을 하려면 명시적인 조인구문이 들어가야한다.

3. 경로 탐색은 주로 select, where 절에서 사용하지만 묵시적 조인으로 인해 SQL의 FROM절에 영향을 준다.

4. 조인은 성능상 차지하는 이슈가 크다. 그리고 묵시적 조인은 예상하기 힘든 조인이기에 왠만하면 조인은

명시적조인으로 표현해주는 것이 좋다.

JPA - JPQL(객체지향쿼리)

jpa-study.zip

(예제소스파일/ jpql package참조)

JPQL은 가장 중요한 객체지향 쿼리 언어이다. Criteria나 QueryDSL은 결국 JPQL을 편리하게 사용하도록 도와주는 기술이므로 JPA로 데이터베이스 엑세스를 다룬다면 JPQL은 꼭 필수라고 생각이 든다. SQL과 꼭 닮은 쿼리 언어이며 SQL은 데이터 중심의 쿼리라고 하면 JPQL은 엔티티를 대상으로 하는 쿼리 언어라고 할 수 있다. 결국 JPA에서 해당 JPQL을 분석한 다음 적절한 SQL로 변환해주어서 데이터베이스에서 데이터를 가져오는 것이다.