이 기능들을 실무에서 자주 사용하지는 않는다.

마지막에 나오는 네이티브 쿼리는 들어두면 좋다.

Specifications(명세)

스프링 데이터 JPA는 JPA Criteria를 활용해서 이 개념을 사용할 수 있도록 지원

하지만, JPA Criteria는 너무 복잡하고 코드가 더러워서 실무에서는 금지시키는 경우도 많음

술어

• 참 또는 거짓으로 평가
• AND OR 같은 연산자로 조합해서 다양한 검색조건을 쉽게 생성(컴포지트 패턴)
• 스프링 데이터 JPA는
  org.springframework.data.jpa.domain.Specification 클래스로 정의

명세 기능 사용 방법

JpaSpecificationExcutor를 넣으면 사용가능

Criteria 문법이 들어가 있어서 내용 이해가 잘 안된다.

이런 식으로 조건 입력이 가능하다.

하지만, 실무에서는 거의 안쓴다. 대신에 QueryDSL을 사용하자.

Query By Example

Probe: 필드에 데이터가 있는 실제 도메인 객체
ExampleMacher: 특정 필드를 일치시키는 상세한 정보 제공, 재사용 가능
Example: Probe와 ExampleMatcher로 구성, 쿼리를 생성하는데 사용

장점

• 동적 쿼리를 편리하게 처리
• 도메인 객체를 그대로 사용
• 데이터 저장소를 RDB에서 NOSQL로 변경해도 코드 변경이 없게 추상화 되어있음
• 스프링 데이터 JPA 인터페이스에 이미 포함

단점

• 조인은 가능하지만 내부 조인(INNER JOIN)만 가능하다.
  외부 조인(LEFT JOIN) 안됨
• 다음과 같은 중첩 제약조건 안됨
  • firstname = ?0 or (firstname = ?1 and lastname = ?2)
• 매칭 조건이 매우 단순함
  • 문자는 starts/contains/ends/regex
  • 다른 속성은 정확한 매칭(=)만 지원

실무에서는 QueryDSL을 사용하자

Projections

앞에 것들은 다 도움이 안되는 것들인데,
이건 도움이 될 때가 있다.

이름만 검색하기 위한 인터페이스를 생성한다.

그리고 MemberRepository에 이렇게 메서드를 추가한다.

이렇게 테스트를 하게 되면,

스프링 데이터가 프록시를 잘 이용해서, UsernameOnly 인터페이스는 프록시가 되고, 딱 이름만 검색해서 데이터를 가져오게 된다.

추가로 이렇게 설정할 경우,

엔티티 전체를 검색한 다음, 조건을 찾고 문법에 맞게 저장된다.

이번엔 클래스를 이용해보자.

여기서 이 파라미터가 중요하다. 이 파라미터를 기준으로 검색을 한다.

바꾸고

이렇게 실행하면,

잘 된다.

참고로 쿼리가 똑같지만, 다른 Dto로 받는 형식을 만들고 싶다면 이와같이 클래스를 받게 만들면 된다.

그럼 이렇게 클래스에 맞춰서 형태가 맞춰진다.
이번에는 중첩 검색을 해보자.

이와 같이 테스트를 해보면,

이렇게 Member는 딱 이름만 가져왔으나,
Team은 엔티티 전체를 검색한 것을 확인할 수 있다.

이처럼 중첩 구조에서 root인 Member는 정확한 검색이 가능하지만,
안쪽으로 들어갈때는 엔티티 전체를 조회한다.

정리

• root에서 검색이 끝난다면 Projections을 활용하자.
• 조금만 복잡해지면, QueryDSL`을 사용하자.`

네티이브 쿼리

가급적 네이티브 쿼리는 사용하지 않는게 좋음, 정말 어쩔 수 없을 때 사용
최근에 나온 궁극의 방법 -> 스프링 데이터 Projections 활용

MemberRepository에 이렇게 작성하면, 네이티브 쿼리라는 것을 알려줄 수 있다.

근데 제약이 많다.

• 반환타입 Object[], Tuple, DTO 3개밖에 안됨
• Sort 처리가 안될수도 있음
• JPQL처럼 로딩 시점에 문법 확인 불가
• 동적 쿼리 불가

최근에 추가된 페이징 기능