[스프링 데이터 JPA] 4. 쿼리 메소드 기능

 

0️⃣ 쿼리 메소드 기능 

- 메소드 이름으로 쿼리 생성 
- NamedQuery
- @Query : 리파지토리 메소드에 쿼리 정의 
- 파라미터 바인딩
- 반환 타입
- 페이징과 정렬 
- 벌크성 수정 쿼리 
- @EntityGraph 

-> 스프링 데이터 JPA가 추가로 더 편하게 사용하도록 제공해주는 기능들!! 

 

 

- 쿼리 메소드 기능 3가지 

- 메소드 이름으로 쿼리 생성
- 메소드 이름으로 JPA NamedQuery 호출 
- @Query 어노테이션을 사용해서 리포지토리 인터페이스에 쿼리 직접 정의 

 

 

1️⃣ 메소드 이름으로 쿼리 생성

: 메소드 이름을 분석해서 JPQL 쿼리 실행 

 

- 순수 JPA 리포지토리 

MemberJpaRepository

-> Member객체에서 이름이 같고, 나이가 주어진 나이보다 많은 회원 조회하는 쿼리이다. 

순수 JPA 리포지토리에서는 그냥 조건에 맞게 JPQL 쿼리를 짰다. 

 

 

MemberJpaRepositoryTest

jpql은 sql로 변환되어 데이터베이스에 전송한다. 

 

 

- 스프링 데이터 JPA

MemberRepository

-> 스프링 데이터 JPA에서는 순수 JPA와는 다르게 그냥 메소드 이름을 분석해서 JPQL을 생성해서 실행해준다..!!!

(완전 마법같음.. 짱신기)

 

MemberRepositoryTest

위에 MemberJpaRepositoryTest와 동일한 테스트인데 이번에는 스프링 데이터 jpa를 사용해서 테스트하는 것으로 결과는 위에서 했던 테스트와 동일하다. 

 

 

 

쿼리 메소드 필터 조건

Spring Data JPA - Reference Documentation

Spring Data JPA - Reference Documentation

 

Keyword              Sample                                                                  JPQL snippet

Distinct	findDistinctByLastnameAndFirstname	select distinct …​ where x.lastname = ?1 and x.firstname = ?2
And	findByLastnameAndFirstname	… where x.lastname = ?1 and x.firstname = ?2
Or	findByLastnameOrFirstname	… where x.lastname = ?1 or x.firstname = ?2
Is, Equals	findByFirstname,findByFirstnameIs,findByFirstnameEquals	… where x.firstname = ?1
Between	findByStartDateBetween	… where x.startDate between ?1 and ?2
LessThan	findByAgeLessThan	… where x.age < ?1
LessThanEqual	findByAgeLessThanEqual	… where x.age <= ?1
GreaterThan	findByAgeGreaterThan	… where x.age > ?1
GreaterThanEqual	findByAgeGreaterThanEqual	… where x.age >= ?1
After	findByStartDateAfter	… where x.startDate > ?1
Before	findByStartDateBefore	… where x.startDate < ?1
IsNull, Null	findByAge(Is)Null	… where x.age is null
IsNotNull, NotNull	findByAge(Is)NotNull	… where x.age not null
Like	findByFirstnameLike	… where x.firstname like ?1
NotLike	findByFirstnameNotLike	… where x.firstname not like ?1
StartingWith	findByFirstnameStartingWith	… where x.firstname like ?1 (parameter bound with appended %)
EndingWith	findByFirstnameEndingWith	… where x.firstname like ?1 (parameter bound with prepended %)
Containing	findByFirstnameContaining	… where x.firstname like ?1 (parameter bound wrapped in %)
OrderBy	findByAgeOrderByLastnameDesc	… where x.age = ?1 order by x.lastname desc
Not	findByLastnameNot	… where x.lastname <> ?1
In	findByAgeIn(Collection<Age> ages)	… where x.age in ?1
NotIn	findByAgeNotIn(Collection<Age> ages)	… where x.age not in ?1
True	findByActiveTrue()	… where x.active = true
False	findByActiveFalse()	… where x.active = false
IgnoreCase	findByFirstnameIgnoreCase	… where UPPER(x.firstname) = UPPER(?1)

 

스프링 데이터 JPA가 제공하는 쿼리 메소드 기능

- 조회: find...By, read...By, query..By, get...By 

Spring Data JPA - Reference Documentation

Spring Data JPA - Reference Documentation

interface PersonRepository extends Repository<Person, Long> {

  List<Person> findByEmailAddressAndLastname(EmailAddress emailAddress, String lastname);

  // Enables the distinct flag for the query
  List<Person> findDistinctPeopleByLastnameOrFirstname(String lastname, String firstname);
  List<Person> findPeopleDistinctByLastnameOrFirstname(String lastname, String firstname);

  // Enabling ignoring case for an individual property
  List<Person> findByLastnameIgnoreCase(String lastname);
  // Enabling ignoring case for all suitable properties
  List<Person> findByLastnameAndFirstnameAllIgnoreCase(String lastname, String firstname);

  // Enabling static ORDER BY for a query
  List<Person> findByLastnameOrderByFirstnameAsc(String lastname);
  List<Person> findByLastnameOrderByFirstnameDesc(String lastname);
}

예) findHelloBy 처럼 ...에는 식별하기 위한 내용(설명)이 들어가도 된다. 

 

COUNT: count...By 반환타입 long

EXISTS: existst...By 반환타입 boolean

삭제: delete...By, remove...By 반환타입 long 

DISTINCT: findDistinct, findMemberDistinctBy

LIMIT: findFirst3, findFirst, findTop, findTop3

https://docs.spring.io/spring-data/jpa/docs/current/reference/html/ #repositories.limit-query-result

Spring Data JPA - Reference Documentation

User findFirstByOrderByLastnameAsc();

User findTopByOrderByAgeDesc();

Page<User> queryFirst10ByLastname(String lastname, Pageable pageable);

Slice<User> findTop3ByLastname(String lastname, Pageable pageable);

List<User> findFirst10ByLastname(String lastname, Sort sort);

List<User> findTop10ByLastname(String lastname, Pageable pageable);

 

❗ 참고

이 기능은 엔티티의 필드명이 변경되면 인터페이스에 정의한 메서드 이름도 꼭 함께 변경해야 한다!!

그렇지 않으면 애플리케이션 시작하는 시점에 오류가 발생한다!! 

이렇게 애플리케이션 로딩 시점에 오류를 인지할 수 있는 것이 스프링 데이터 JPA의 매우 큰 장점이다. 

 

 

2️⃣ JPA NamedQuery

: Jpa의 NamedQuery를 호출할 수 있음. 

 

Member

Member 객체에 @NamedQuery 어노테이션으로 Naemd 쿼리 정의할 수 있다. 

그러면 해당 select m from Member ~ 쿼리의 이름은 Member.findByUsername이다. 

 

 

- 순수 JPA를 사용해서 Named 쿼리 호출

MemberJpaRepository

이런식으로 createNamedQuery 메소를 사용해서 아까 Member에 지정했던 NamedQeury 이름을 설정해준다. 

 

- 스프링 데이터 JPA로 NamedQuery 사용

MemberRepository

@Query(name = "Member.findByUsername") 이걸 생략해도 동작한다!!

그럴 수 있는 이유가 우선 해당 메서드 이름을 가지고 NamedQuery를 Member객체에서 찾는데, 

같은 이름이 존재하기 때문에 NamedQuery를 사용한다. 

근데 만약 Member 객체에 동일한 메서드 이름을 가진 NamedQuery가 없다면 그때 메서드 이름을 기준으로 쿼리를 생성하는 방식이다. 

 

❗ 스프링 데이터 JPA는 선언한 "도메인 클래스 + .(점) + 메서드 이름"으로 Named 쿼리를 찾아서 실행 

그리고 만약 실행한 Named 쿼리가 없으면 메서드 이름으로 쿼리 생성 전략을 사용한다. 

(필요하면 전략을 변경할 수도 있는데 굳이 권장하지는 않는다고 한다.)

 

 

 

3️⃣ @Query, 리포지토리 메소드에 쿼리 정의하기 

MemberRepository

: 메서드에 JPQL 쿼리 작성 

@org.springframework.data.jpa.repository.Query 어노테이션 사용 

실행할 메서드에 정적 쿼리를 직접 작성하므로 이름 없는 Named 쿼리라고 할 수 있다. 

JPA Named 쿼리처럼 애플리케이션 실행 시점에 문법 오류를 발견할 수 있음 (엄청난 장점!!) 

-> 스프링 데이터 jpa는 먼저 애플리케이션 실행 시점에 쿼리들을 모두 파싱해서 sql로 변환하는 작업을 한다고 한다.

 근데 파싱하면서도 오류가 있는지 확인할 수 있다!!! 

 

❗ 참고

실무에서는 메소드 이름으로 쿼리 생성 기능은 파라미터가 증가하면 메서드 이름이 매우 지저분해진다...! (조건이 많아지면 메소드 이름이 너무 길어지니까..) 

따라서 @Query 기능을 훨씬 많이 사용한다고 한다~~ 

 

 

🙂 @Query 값 DTO로 조회하기 

JPA 활용편을 듣다보면 알 수 있는 내용인데 엔티티를 직접 반환해서 엔티티를 노출하는 방법은 권장하는 방법이 아니기 때문에 DTO로 변환해서 반환하라고 한다. 

 

그럴때 스프링 데이터 JPA에서도 JPA와 동일한 방식을 제공해준다. 

 

MemberDto

-> MemberDto에는 id와 username, teamName 정도만 필요하다고 가정한다.

 

MemberRepository

그리고 @Query 어노테이션 안에 Jpa 의 new 명령어를 사용해서 DTO로 조회하고자 하는 값들을 나열해주면 되는데, 

이때 해당 값들이 들어가는 생성자가 필요하다. 

 

MemberRepositoryTest

 

 

4️⃣ 파라미터 바인딩 

- 위치 기반
- 이름 기반 

-> 파라미터 바인딩에는 위치 기반과 이름 기반 두개가 있는데 위치 기반으로 하면 변경이 일어나면 전부 바꿔줘야 하기 때문에 유지보수성이 안좋기 때문에 이름 기반으로 해주는 것이 좋다! 

 

 

MemberRepository

-> :name이면 @Param("name") 하고 String username이면 이제 username으로 받아온 값을  스프링 데이터 jpa가 파라미터 바인딩해준다. 

 

 

컬렉션 파라미터 바인딩

: Collection 타입으로 in절 지원

 

MemberRepositoryTest

in 절을 사용해서 memberA와 memberB를 조회해오는 것을 확인할 수 있다. 

 

 

5️⃣ 반환 타입 

: 스프링 데이터 JPA는 유연한 반환 타입을 지원한다. 

 

MemberRepository

https://docs.spring.io/spring-data/jpa/docs/current/reference/ html/#repository-query-return-types

 

MemberRepositoryTest

-> 조회 쿼리는 모두 똑같은데 반환 타입만 다르게 이루어진다. 

 

❓ 조회 결과가 많거나 없다면..?

컬렉션: 

    - 결과 없음: 빈 컬렉션 반환 

단건 조회: 

   - 결과 없음: null 반환 

   - 결과가 2건 이상: javax.persistence.NonUniqueResultException 예외 발생 

 

❗ 참고

단건으로 지정한 메서드를 호출하면 스프링 데이터 JPA는 내부에서 JPQL의 Query.getSingleResult() 메서드를 호출한다. 

이 메서드를 호출했을 때, 조회 결과가 없으면 NoResultException 예외가 발생하는데 개발자 입장에서 다루기가 상당히 불편하다.. 

스프링 데이터 JPA는 단건을 조회했을 때 이 예외가 발생하면 예외를 무시하고 대신에 NULL 값을 반환해준다.

 

 

6️⃣ 순수 JPA 페이징과 정렬 

페이징 & 정렬

 

- JPA 페이징 리포지토리 코드 

MemberJpaRepository

JPQL에서 페이징할 때는 setFirstResult로 처음 가져올 값을 설정해주고, setMaxResult를 통해 가져올 데이터 수를 지정해준다. 

 

그리고 페이징할 때 totalCount도 필요한 경우가 많은데 이럴 때를 위해 따로 메소드를 하나 더 만들어준다. 

count 값을 구할 때는 굳이 order by를 해줄 필요가 없기 때문에 성능 최적화를 위해서 정렬은 생략했다. 

 

MemberJpaRepositoryTest

-> limit을 통해 페이징을 하는 쿼리를 확인할 수 있다.  

그리고 이때 offset은 어차피 0부터 시작이라 생략해준 것이다. 

그리고 count값도 구해온 쿼리를 확인할 수 있다. 

 

 

7️⃣ 스프링 데이터 JPA 페이징과 정렬 

페이징과 정렬 파라미터

-org.springframework.data.domain.Sort : 정렬 기능 
-org.springframework.data.domain.Pageable : 페이징 기능( 내부에 Sort 포함) 

 

특별한 반환 타입 

-org.springframework.data.domain.Page : 추가 count 쿼리 결과를 포함하는 페이징 
-org.springframework.data.domain.Slice : 추가 count 쿼리 없이 다음 페이지만 확인 가능 
-> 내부적으로 limit + 1 조회 
- List(자바 컬렉션) : 추가 count 쿼리 없이 결과만 반환 

 

MemberRepository

Page는 count 쿼리를 사용하는 것으로 count 쿼리를 분리해서 다음과 같이 지정해 줄 수도 있다. 

두번째 파라미터로 받은 Pageable 은 인터페이스로 실제 사용할 때는 해당 인터페이스를 구현한 org.springframework.data.domain.PageRequest 객체를 사용한다. 

 

 

MemberRepositoryTest

PageRequest 생성자의 첫번째 파라미터에는 현재 페이지를, 두번째 파라미터에는 조회할 데이터 수를 입력해준다. 

여기에 이제 추가로 정렬 정보도 파라미터로 사용할 수 있다. 

(참고로 페이지는 0부터 시작한다.) 

 

❗ 주의: page는 시작이 1부터가 아니라 0부터이다. 

 

-> 반환타입이 Page 일때는 count 쿼리도 함께 나간것을 확인할 수 있다. 

 

반환 타입을 Slice로 바꿔서 테스트 코드를 실행하면 이때 Slice일 때는 지원하지 않는 메소드들이 있기 때문에 그것들은 주석 처리를 해줬다. 

(그리고 MemberRepository 인터페이스의 findByAge 메소드 반환타입도 Slice로 변경해줘야 한다!!)

 

-> 이때는 count 쿼리가 나가지 않고 select 페이징 쿼리만 나가는 것을 확인할 수 있다. 

그리고 Slice로 하면 limit이 3이 아니라 4가 나가는데 이유는 limit+1을 조회해서 다음 페이지 여부를 확인하기 위해서 +1 해서 조회해준다. 

 

 

페이지를 유지하면서 엔티티를 dto로 변환하기 

Page의 map 메소드를 이용해서 Member 엔티티를 dto로 변환할 수 있다. 

 

 

8️⃣ 벌크성 수정 쿼리 

 

- JPA를 사용한 벌크성 수정 쿼리 

MemberJpaRepository

-> 그냥 jpql로 update 쿼리를 짰는데 이때 m.age가 파라미터로 주어진 age보다 값이 크면 해당 Member객체의 age를 +1씩 증가하는 벌크 수정 쿼리이다. 

 

MemberJpaRepositoryTest

 

- 스프링 데이터 JPA를 사용한 벌크성 수정 쿼리 

MemberRepository

벌크성 수정, 삭제 쿼리에는 @Modifying 어노테이션을 사용해야 한다. 

사용하지 않으면 org.hibernate.hql.internal.QueryExecutionRequestException: Not supported for DML operations 예외 발생한다. 

 

😎 벌크성 쿼리를 실행하고 나서 영속성 컨텍스트 초기화: @Modifying(clearAutomatically = true) 

: 이 옵션 없이 회언을 f indById로 다시 조회하면 영속성 컨텍스트에 과거 값이 남아서 문제가 될 수있다.

따라서 다시 조회해야한다면 꼭 영속성 컨텍스트를 초기화해야한다. 

 

 

MemberRepositoryTest

원래 벌크 연산을 수행한 다음에는 영속성 컨텍스트를 flush 해서 영속성 컨텍스트를 비워야 같은 트랜잭션안에서 다른 로직이 있을 때 데이터 변경이 반영된것을 조회하거나 할 수 있다. 

그런데 스프링 데이터 jpa에서는 인터페이스에서 @Modifing 어노테이션 중 clearAutomatically 옵션을 true로 설정해주면 따로 flush를 안해줘도 자동으로 flush를 해준다! 

 

❗ 참고

벌크 연산은 영속성 컨텍스트를 무시하고 실행하기 때문에, 영속성 컨텍스트에 있는 엔티티의 상태와 DB에 엔티티 상태가 달라질 수 있다. 

권장하는 방안

1. 영속성 컨텍스트에 엔티티가 없는 상태에서 벌크 연산을 먼저 실행한다. 

2. 부득이하게 영속성 컨텍스트에 엔티티가 있으면 벌크 연산 직후에 영속성 컨텍스트를 초기화한다. 

 

 

 

9️⃣ @EntityGraph

: 연관된 엔티티들을 SQL 한번에 조회하는 방법 

 

member -> team 은 지연로딩 관계이다.

따라서 다음과 같이 team의 데이터를 조회할 때 마다 쿼리가 실행되는 N + 1 문제가 발생한다. 

 

MemberRepositoryTest

 

member.getTeam().getName()을 하는 순간 member의 수만큼 select team을 조회한 것을 확인할 수있다.

이런 문제를 N+ 1 문제라고 한다. 

 

이 N + 1 문제를 해결하기 위해 연관된 엔티티를 한번에 조회하려면 페치 조인이 필요하다. 

 

MemberRepository

 

MemberRepositoryTest

-> 페치 조인을 사용하는 코드로 바꿔서 테스트를 수행하니 left outer join을 통해서 한번에 조회해 오는 것을 확인할 수 있다. 

 

 

EntityGraph

: 스프링 데이터 JPA는 JPA가 제공하는 엔티티 그래프 기능을 편리하게 사용하게 도와준다. 

이 기능을 사용하면 JPQL 없이 페치 조인을 사용할 수 있다. (JPQL + 엔티티 그래프도 가능) 

 

MemberRepository

-> findAll 공통 메서드를 오버라이드 해서 @EntityGraph를 추가해줬다. 

 

그리고 다시 Test 코드를 수행하면 

LEFT OUTER JOIN을 사용한 것을 확인할 수 있다. 

이렇게 보면 그냥 EntityGraph는 사실상 페치 조인의 간편 조인이라고 할 수 있다. 

 

 

🔟 JPA Hint & Lock 

JPA Hint 

: JPA 쿼리 힌트(SQL 힌트가 아니라 JPA 구현체에게 제공하는 힌트) 

 

MemberRepository

 

MemberRepositoryTest

-> 테스트 결과를 확인해보면 findReadOnlyByUsername은 readOnly로 설정해뒀기 때문에 setUsername을 통해 이름을 변경하더라도 변경감지가 일어나지 않는다. (무시해버린다고 한다?)

 

Lock 

MemberRepository

-> org.springframework.data.jpa.repository.Lock 어노테이션을 사용한다. 

 

MemberRepositoryTest

해당 테스트를 실행하면 이런 쿼리가 실행되는 것을 확인할 수 있다. 

Lock에 대해서는 이렇게만 얘기하고 빨리 넘어가버려서 이해가 잘 안돼서 더 검색해봤다. 

 

SELECT FOR UPDATE=동시성 제어를 위해 특정row에 배타적 LOCK을 거는 행위
“데이터 수정하려고 찾은 것이니, 다른분들은 건드리지 마세요!”

 

PESSMISTIIC_WRITE 는 비관적 잠금이라고 한다.

비관적 잠금(Pessimistic Lock)

동일한 데이터를 동시에 수정할 가능성이 높다는 비관적인 전제로 잠금을 거는 방식입니다. 예를 들어 상품의 재고는 동시에 같은 상품을 여러명이 주문할 수 있으므로 데이터 수정에 의한 경합이 발생할 가능성이 높다고 비관적으로 보는 것입니다. 이 경우 충돌감지를 통해서 잠금을 발생시키면 충돌발생에 의한 예외가 자주 발생하게 됩니다. 이럴경우 비관적 잠금을 통해서 예외를 발생시키지 않고 정합성을 보장하는 것이 가능합니다. 다만 성능적인 측면은 손실을 감수해야 합니다. 주로 데이터베이스에서 제공하는 배타잠금(Exclusive Lock)을 사용합니다.

출처: https://reiphiel.tistory.com/entry/understanding-jpa-lock [레이피엘의 블로그:티스토리]

 

배타적 잠금(Exclusive Lock)을 획득하고 데이터를 다른 트랜잭션에서 READ, UPDATE, DELETE 하는것을 방지 할 수 있습니다.