스프링과 JPA를 이용한 웹개발_JQPL

🤔JPQL의 특징을 알아보자 !

1. Polymorphism

• book과 blogpost를 포함하는 publication 조회 가능(book도 개별적으로 조회 가능)
• SELECT p FROM Publication p
• SELECT b FROM BlogPost b

2. Restriction

• where에서 조건 걸기(검색 대상 제한)

SELECT a FROM Author a WHERE a.firstName like ‘%and%’ and a.id >= 20 and size(author.books) >= 5

3. Projection

• 테이블의 모든 컬럼이 아닌 특정 값(컬럼) 만 지정해서 조회
• Projection은 다양한 대상에 적용 가능
• Entities만도 뽑아낼 수 있지만!
  • SELECT a FROM Author a
• Scalar values
  • SELECT a.firstName, a.lastName FROM Author a
• Constructor references(DTO에 매핑)
  • SELECT new org.thoughts.on.java.model.AuthorValue(a.id, a.firstName, a.lastName) FROM Author a

4. Distinct query results

• 중복되는 쿼리를 제외하고 조회
• SELECT DISTINCT a.lastName FROM Author a

5. Function

• upper(String s) 
• lower(String s)
• current_date()
• current_time()
• current_timestamp()
• ➡️SQL에서도 이러한 Function을 사용할 수 있는데 JPQL에서도 똑같이 사용 가능함!

6. Ordering - The ORDER BY clause

• 정렬 방식 지정: ascending (ASC) or a descending (DESC) order
• SELECT a FROM Author a ORDER BY a.lastName ASC, a.firstName DESC

Join도 가능하다!

1. Inner Joins

SELECT a, b FROM Author a JOIN a.publications b

⚠️Inner Joins이기 때문에 그냥 publication이 아니라 a.publication이어야 함 !!

    차이를 이해하시겠죠 ?

• FROM 절은 select 대상이 되는 엔티티를 지정하기 위해 사용
• Author 엔티티가 Hibernate에 publications 엔티티와 어떻게 연관관계를 맺고 있는지 알려주므로 추가적인 ON절이 필요 없음
• 연관관계가 설정되지 않은 엔티티간 조인은 JPA에서 제공하지 않음. 대신 세타 조인와 WHERE절을 이용하여 조인을 수행

SELECT b, p FROM Book b, Publisher p WHERE b.fk_publisher = p.id

2. Left Outer Joins

• 연관관계 여부와 상관 없이 대상 엔티티는 모두 조회할 때 사용
  • 이전 예제의 INNER조인은 publication 이력이 있는 Author만 조회된다면 Left Outer 조인은 publication 여부와 상관없이 모두 조회
  • SELECT a, b FROM Author a LEFT JOIN a.publications b

3. Additional Join Conditions

• JPA 2.1부터 INNER 조인의 ON절 지원

4. Join Fetch

• 대상 엔티티를 조회할 때 연관 엔티티도 함께 조회
• FetchType을 Lazy로 두는 것을 권장하지만 성능 문제가 발생할 수 있음
• 이때, Join Fetch사용
• 아래는 타입을 알고 있으므로 Query생성과 실행을 체이닝 형태로 수행

😶예제 : Join Fetch을 활용해보자!

그.전.에 반환타입을 지정한 JPQL을 사용하고 쿼리 객체를 실행하면 SELECT문이 2번 실행되는 것을 확인할 수 있었다.

이 이유는 Person이 LAZY이기 때문에 query.getResultList()가 실행될 때 1번, forEach문으로 실행될 때 연관관계인 address까지 1번 더 실행되기 때문이다. 

➡️이는 성능에 치명타를 줄 수 있으므로 최대한 SELECT문을 최소한으로 실행시키는 것이 좋다.

⚠️하지만 fetchType을 EAGER으로 바꾸는 것은 오히려 성능에 더 안좋기 때문에 이럴때 Join Fetch를 사용하면 된다!

join fetch p.addresses로 가져오면 SELECT문이 1번 실행되는 것을 확인할 수 있다!

그.러.나.. 이번에는 값의 중복이 발생한다. 

➡️이럴 때에는 distinct를 사용하자!

distinct를 사용 후 중복이 없어졌다.

정리해보자

1. oneToMany든 manyToOne이든 그냥 LAZY로 설정하는 것이 운영하는 관점에서 쉽다.
2. 그러나 한번에 연관관계 엔티티를 조회해야할 때에는 join fetch를 사용해서 함께 조회해올 수 있다.
3. 그리고 oneToMany 경우에는 join를 사용할 때 중복이 발생할 수 있기 때문에 distinct를 사용하면 된다.