✔ 순수 JPA 기반 페이징 정렬
JpaRepository
테스트 코드
순수 JPA 기반으로 페이징을 정렬하려면 복잡한 페이지 계산 공식을 적용해야 한다.
그렇게 때문에 스프링 Data Jpa가 제공하는 편리한 기능을 사용해야 한다.
✔ 스프링 데이터 JPA 페이징과 정렬
1.정렬 기능 : Sort
2.페이징 기능 (내부에 sort포함) : Pageable
반환 타입
1. Page : 추가 count 쿼리 결과를 포함하는 페이징
2. Slice : 추가 count 쿼리 없이 다음 페이지만 확인 가능 (내부적으로 limit + 1조회)
3. List (자바 컬렉션) : 추가 count 쿼리 없이 결과만 반환
Repository
카운트 쿼리 분리 , 실무에서 매우 중요!!!
(이건 복잡한 sql에서 사용, 데이터는 left join, 카운트는 left join 안해도 됨)
- Slice (count X) 추가로 limit + 1을 조회한다. 그래서 다음 페이지 여부 확인(최근 모바일 리스트생각해보면 됨)
TestCode (Page)
-PageRequest를 이용해서 페이지의 시작인덱스와 크기와 정렬순서를 정의해서 하나의 Page를 만들수 있다.
-✨ 실무에서는 반환타입을 엔티티객체 그대로 반환하면 엔티티가 노출되기 때문에 api방식으로 리턴할때는 map을 이용해 객체를 map에 담아서 Dto방식으로 리턴 해야한다.
✔ 벌크성 쿼리
Repository
TestCode
벌크성 쿼리는 update쿼리를 날려서 db의 값 여러개를 update하는 것이다. 하지만 jpa에서는 객체를 save하면 영속성 컨텍스트라는 곳에 1차캐시정보에 정보를 담고 있고 트랜잭션이 끝나는 시점에 flush를 해서 db에 정보를 반영한다. 하지만 벌크성 update쿼리는 영속성 컨텍스트를 거치지않고 바로 db에 정보를 변경하기 때문에 영속성 컨텍스트에는 update하기 전의 정보가 그대로 담겨있어서 에러가 발생한다. 그렇기 때문에 update쿼리를 날리게 되면 영속성 컨텍스트를 flush해줘야한다. 이 flush하는 것을 @Modifying(clearAutomatically = true) 어노테이션을 이용해서 문제점을 해결한다.
✔ Entity Graph
entity graph는 연관된 엔티티들을 SQL 한번에 조회하는 방식이다. 지연로딩 관계에서 member -> team 관계에서 select m from Member m 을 날리면 team 객체는 프록시 객체로 조회가 된다. 여기서 team의 프로퍼티를 조회하게 되면 team을 조회하는 쿼리가 한번 더 나가게 된다. N+1 문제이다. jpa 에서는 이 문제를 fetch join 으로 해결한다. 그렇게 되면 한 번의 쿼리로 연관관계의 프로퍼티까지 조회할 수 있다.
Repository ( jpql을 이용한 fetch join )
Repository ( Entity Graph를 이용 )
이 기능을 사용하면 Jpql없이 fecth join을 사용할 수 있다.
- 정리
- 사실상 페치 조인(FETCH JOIN)의 간편 버전
- LEFT OUTER JOIN 사용
- NamedEntityGraph라는 기능도 있다.
✔ JPA Hint & Lock
JPA Hint : JPA 쿼리 힌트(SQL 힌트가 아니라 JPA 구현체에게 제공하는 힌트)
JPA Lock : @Lockk(LockModeType.PESSIMISTIC_WRITE) 어노테이션 사용
Repository
TestCode (queryHints)
QueryHints를 사용하면 스냅샷도 없고 , 변경감지를 무시하고 db 상관없이 member를 조회할때 영속성 컨텍스트 캐시에서 "member2"이름만 조회 할수있다. 조회용으로만 사용하기 위해서 set()을 해줘도 업데이트 쿼리를 보내지 않고 최적화 하는 방법. 업데이트 쿼리방지.
TestCode (Lock)
조회하면서 username에 대한 수정못하게 잠금을 걸어버린다.
