Spring Data JPA

기억안날 때 쉽게 찾으려고 한 글에 다 적었습니다.

* 스크롤 압박 주의 *

 

스프링 설정을 쉽게 해주는 Spring Boot 프로젝트가 있듯이

스프링에서 데이터를 쉽게 사용하게 해주는 Spring Data 프로젝트가 있다.

Spring Data에 포함된 주요 모듈들. 여기 안나온 다른 기능도 많다.

 

그중 스프링에서 JPA를 추상화하여, 정말 쉽게 사용할 수 있게 만든 Spring Data JPA를 알아보자.

 

 

💭 어떻게 사용하나요

implementation 'org.springframework.boot:spring-boot-starter-data-jpa'

참고로 spring-boot-data-jpa에는 아래의 패키지들을 포함하고 있다.

패키지 내부에서 Spring Core를 사용하고 있으므로, gradle이 spring core 의존성까지 불러온다.

• Jakarta EE(구 Java EE)의 persistence, transaction 모듈
• hibernate-core (JPA 구현체, 하이버네이트)
• spring data-jpa
• spring aspectJ
• spring-boot-starter aop
• spring-boot-starter jdbc

 

요즘은 스프링부트를 사용하므로, @SpringBootApplication 를 사용한다면 특별히 따로 해줄 설정은 없다.

물론 public class Application 이 최상위 패키지가 아니라면 찾지 못한다. 이 경우에만 직접 지정해주자.

package mypackage.myapp; // 이 모듈의 하위 패키지를 모두 적용시킨다.

@SpringBootApplication
public class DataJpaApplication { 
    public static void main(String[] args) {
        SpringApplication.run(DataJpaApplication.class, args);
    }
}

 

만약 스프링 부트를 사용하지 않는다면요?

@EnableJpaRepositories( 스캔 경로 )를 지정해주면 된다. 보통 프로젝트 최상단에 있는 설정 객체에 @Configuration 와 함께 작성한다.

@Configuration
@EnableJpaRepositories(basePackages = "jpabook.jpashop.repository")
public class AppConfig {}

 

 

@Entity의 경우 스프링과 연관없이 그냥 JPA 명세(javax.persistence.Entity)이기에 스프링 의존성이 없더라도 사용할 수 있긴하다. 옛날 Hybernate 시절에는 아래와 같이 설정을 해주었다.

<property name="packagesToScan">myNamespace.*</property>

이 설정 또한 @SpringbootApplication 에 있는 @EnableAutoConfiguraion이 자동으로 해준다.
만약 @Entity가 다른 모듈(또는 외부 JAR)에 있어 스캔이 안되는 경우, 아래와 같이 직접 지정해줄 수 있다.

@EntityScan 으로 스캔할 대상을 추가로 지정한다. 

 

간혹 @ComponetScan과 동일한 기능이라고 생각하는 사람이 있는데, 컴포넌트 스캔은 말 그대로 @Component가 달린 클래스를 스프링 빈으로 등록하는 기능이다. @EntityScan은 Entity를 찾는 범위를 확장할 뿐, 스프링 빈과는 아무런 연관이 없다. 빈을 만들지 않는다.

// 둘 다 설정해줄 때도 이렇게 따로 사용하는게 일반적이다.
@ComponentScan("org.example.base")
@EntityScan("org.example.base.entities")
public class MyConfig {

}

 

Spring Data JPA는 여기에 추가적으로 @Repository가 붙어있는 클래스를 찾아 프록시로 대체해준다.

@Repository // org.springframework.data.repository.Repository

 

 

SpringDataJpa를 사용한다면 EntityManagerFactory는 스프링 컨테이너에 생성되어 있다.

사용할 일은 없겠지만, 만약 스프링 컨테이너에 있는 EntityMangerFactory에서 EntityManager를 받고싶다면 아래와 같이 어노테이션을 이용해서 주입받으면 된다.

@PersistenceContext // 최신 버전 스프링에서는 @Autowired로 사용해도 된다.
EntityManager entityManager;
// EntityManagerFactory entityManagerFactory = Persistence.createEntityManagerFactory("emf name");
// EntityManager entityManager = entityManagerFactory.createEntityManager();

까먹었을까봐 추가설명. 참고로 하이버네이트에서는 SessionManager, SessionFactory라고 불렸다.

 

 

 

그리고 공용 인터페이스인 JpaRepository를 사용한다면, 아무런 추가 작업없이 아래처럼 사용하면 된다.

// 이게 끝. 생략한게 아니라 그냥 인터페이스만 두면 끝이다.
public interface MemberRepository extends JpaRepository<Member, Long> {
}

 

---

💭 기본 사용방법

다만, interface JpaRepository<Entity, ID>를 사용한다면 아무것도 하지 않아도 된다.

해당 인터페이스의 구현체를 만들필요도, @Repository를 붙일 필요도 없다.

// 이게 끝. 생략한게 아니라 그냥 인터페이스만 두면 끝이다.
// SpringDataJpa에서 만든 기본 Jpa 구현체가 스프링 컨테이너에 생성되어있기 때문이다.
public interface MemberRepository extends JpaRepository<Member, Long> {
}

복잡한 조회도 아니고 메서드 이름만 보면 딱 무슨 쿼리인지 보이는데..그냥 알아서 만들어주면 안되나?

➡ 이게 바로 SpringDataJpa의 기능이다.

JpaRepository 인터페이스에는 비즈니스에 자주쓰는 코드 (save, findById, delete..)가 대부분 포함되어있다.

그 외 특정 필드명이 들어가는 경우(findByEmail 등)만 따로 추가로 인터페이스를 작성해주면 된다.

말이 대부분이지, JPA를 사용해서 개발자가 만들 수 있는 모든 메서드를 가지고 있다. 

물론 조건이 여러개거나 쿼리가 복잡해지면 QureyDSL등으로 JPQL을 직접 생성하거나, 그냥 JPA를 안쓰는 경우도 많다.

repository.save(new Member("username", 10));
repository.save(new Member("username", 20));

// 메서드 이름 규칙만 잘 지킨다면, 이런 것도 가능하다.
List<Member> result = repository.findByUsernameAndAgeGreaterThan("username", 15);

assertThat(result.size()).isEqualTo(1);
Member member = result.get(0);
assertThat(member.getUsername()).isEuqalTo("username");
assertThat(member.getAge()).isEqualTo(20);

메서드 이름 규칙 (Count, Between, In등 왠만한건 다 지원한다)_

처음에는 T findOne(ID)도 제공했으나, 최신 버전에는 Optional&amp;amp;amp;amp;amp;amp;amp;lt;T&amp;amp;amp;amp;amp;amp;amp;gt; findById(ID)만 남게되었다.&amp;amp;amp;amp;amp;amp;amp;nbsp;

참고로 find(...)By 사이는 메서드 주석(설명)을 적는 자리이다.

 

문자열 LIKE 를 Spring JPA 메서드네이밍으로 만들기

public interface BookRepository extends JpaRepository<Book, Long>{

  // select ... like %:title%
  List<Book> findBooksByTitleContaining(String title);
  List<Book> findBooksByTitleContains(String title);
  List<Book> findBooksByTitleIsContaining(String title); 
  
  // select ... like :title
  List<Book> findBooksByTitleLike(String title);
  
  // select ... like :title%
  List<Book> findBooksByTitleStartingWith(String title);
  
  // select ... like %:title
  List<Book> findBooksByTitleEndingWith(String title);
  
}

 

💭 이게 어떻게 가능한거죠? -> SimpleJpaRepository

SpringDataJPA는 인터페이스를 바탕으로 class SimpleJpaRepository를 스프링 빈으로 컨테이너에 등록시킨다.
즉 interface JpaRepository 인터페이스에 알맞은 SimpleJpaRepository가 컨테이너에 의해 주입된다.

• [ JDBC나 JPA에 발생한 예외 ]를 [ 스프링이 제공하는 예외 ]로 포장시켜서 반환한다.
• 인터페이스의 제네릭 (Entity, ID) 타입을 바탕으로 JPA 쿼리문(em.persist 등)을 생성한다.
• 특정 필드를 이용한 코드( findByUsername, findByEmail ) 또한 메서드 명을 분석하여 JPQL 쿼리를 생성한다.

@Repository 가 붙어있으므로, 이는 스프링 빈으로 등록된다.

실제로 SimpleJpaRepository가 쓰는 QureyUtils 를 살펴보면, 쿼리문에 대한 정규표현식이 정의되어 있다.

public abstract class QueryUtils {

    public static final String COUNT_QUERY_STRING = "select count(%s) from %s x";
    public static final String DELETE_ALL_QUERY_STRING = "delete from %s x";
    public static final String DELETE_ALL_QUERY_BY_ID_STRING = "delete from %s x where %s in :ids";
    private static final String IDENTIFIER = "[._$[\\P{Z}&&\\P{Cc}&&\\P{Cf}&&\\P{Punct}]]+";
    static final String COLON_NO_DOUBLE_COLON = "(?<![:\\\\]):";
    static final String IDENTIFIER_GROUP = String.format("(%s)", IDENTIFIER);
    ... // 생략
}

 

📑 트랜잭션은 어떻게하죠? 없어도 동작하던데?

우선, JPA의 모든 변경은 트랜잭션 안에서만 동작한다. (없으면 예외가 발생한다.)

public static void main(String[] args) {
    /* 어플리케이션이 시작할 때 Factory 생성한다. */
    EntityManagerFactory factory = Persistence.createEntityManagerFactory("hello");

    // 💭 1. 스레드에서 사용할 EntityManager 받아온다. 한 트랜잭션에 한 EntityManager가 사용된다.
    EntityManager entityManager = factory.createEntityManager();

    // 💭 2. JPA를 이용한 모든 데이터 변경은 트랜잭션 안에서만 실행될 수 있다.
    EntityTransaction tx = entityManager.getTransaction();
    try {
        Member member = new Member();
        member.setId(2L);
        member.setName("Kim");

        entityManager.persist(member);

        tx.commit();
    } catch (Exception e) {
        tx.rollback();
    } finally {
        // 💭 3. 사용이 끝난 EntityManager 반납한다.
        entityManager.close();
    }

    factory.close(); /* 어플리케이션이 종료할 때 필요없어진 Factory 반환한다. */
}

SimpleJpaRepository 코드를 보면, 클래스 자체에 @Transactional이 걸려있다.

커맨드성 메서드에만 이렇게 추가로 설정한다.

 

서비스 계층에서 트랜잭션을 시작하지 않는다면 Repository에서 트랜잭션이 시작한다.

(* propagation.Required 옵션이 기본값이기 때문. 이는 트랜잭션이 있다면 그대로 쓰고, 없으면 새로 시작한다. )

 

 

 

Spring Data 프로젝트의 서브 프로젝트가 Spring Data JPA이다.

그래서 아래와 같이 공통부분을 뽑아 상속 관계를 만들어뒀는데, 자세하게 알 필요는 없긴하다.

Repository&amp;amp;amp;amp;amp;amp;amp;lt;T, ID&amp;amp;amp;amp;amp;amp;amp;gt;는 스프링 스캔을 위한 인터페이스일뿐, 코드는 비어있다.

 

그리고 추상화를 잘 시켜놔서 사용을 편하게 만들었을 뿐, 내부코드는 JPA를 사용해서 구현한다.

SimpleJpaRepository의 코드를 뜯어보면 entityManager를 사용하는 부분을 볼 수 있다.

JPA도 결국 Java의 JDBC를 이용해서 데이터베이스를 이용함을 잊지말자.

뭐든지 알아서 처리해주는 마법의 도구가 아니다.

@Transactional 의 동작원리, 트랜잭션 매니저

 

---

💭 스프링에서의 NameQurey

이 기능은 JPA의 @NameQurey를 활용한다. (직접 사용할 일은 없으니 설명만 듣고가자)

이는 엔티티에 특정 쿼리를 할당해놓고, 필요할 때 꺼내서 쓸 수 있는 기능이다.

@Entity
@NoArgsConstructor(access = AccessLevel.PROTECTED)
@NamedQuery(
    name = "Member.findByUsername",
    query="select m from Member m where m.username = :username" // :username 는 파라메타
)
public class Member {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    private String username;
    ...
}

@PersistenceContext
EntityManager em;

public List<Member> findByUsername(String username) {
	// createNameQurey()를 통해서 꺼내 쓸 수 있다.
    return em.createNamedQuery("Member.findByUsername", Member.class)
        .setParameter("username", "이름")
        .getResultList();
}

 

물론 아래와 같이 쿼리를 직접 작성해도 똑같이 동작한다.

이는 재사용성 측면에도 좋지만, NameQurey는 빌드하는 시점에 쿼리의 유효성을 바로 확인할 수 있다는 장점도 있다.

public List<Member> findByUsername(String username) {
    // 이렇게 쿼리를 직접 작성해도 되지만, 이는 실행하는 시점(런타임)에 쿼리 유효성을 판별한다.
    return em.createQuery("select m from Member m where m.username = :username")
        .setParameter("username", "이름")
        .getResultList();
}

@NameQurey는 빌드타임에 JPQL 쿼리문의 오류를 찾아내지만, 그냥 생성하면 실행 시점에 오류가 발생한다.

---

 

 

스프링 데이터 JPA에서는 아래와 같이 @Query를 이용해서 NameQurey를 사용할 수 있다.

public interface JpaMemberRepository extends JpaRepository<Member, Long>, MemberRepository {

    @Query(name = "Member.findByUsername")
    List<Member> findByUsername(@Param("username") String username);

}

@Entity
@NoArgsConstructor(access = AccessLevel.PROTECTED)
@NamedQuery(
    name = "Member.findByUsername",
    query="select m from Member m where m.username = :username" // :username 는 파라메타
)
public class Member {
...
}

 

재밌는점은 @Qurey를 생략하더라도 SpringDataJPA는 NameQurey를 먼저 찾아보고, 없을 때 기본 값을 사용한다.

다만 이런 방법을 권장하지도 않고, 애초에 @NameQurey 자체도 실무에서는 거의 사용하지 않으니 넘어가도록 하자.

 

 

---

💭 @Query(...)

 @NameQuery는 실무에서 거의 사용하지 않고, 보통은 아래와 같이 리포지토리에 쿼리를 직접 작성한다.

public interface JpaMemberRepository extends JpaRepository<Member, Long>, MemberRepository {
    
    @Query("select m from Member m where m.username = :username")
    List<Member> findByUsername(@Param("username") String username); // username 으로 조회

    @Qurey("select m from Member m where m.username in :names")
    List<Member> findByNames(@Param("names") List<String> names); // 컬렉션으로 in 조회
    
    // @Query를 쓰면 이렇게 긴 이름의 메서드를 사용하지 않아도 된다.
    List<Member> findByUsernameAndAgeGraterThanAnd...(...);
}

 

 

이는 @NameQuery와 똑같이 작동한다. 앱 실행시점에 쿼리 오류를 검증한다.

만약 Entity가 아니라 DTO로 조회하고 싶을 때에도, 아래와 같이 사용할 수 있다.

public interface JpaMemberRepository extends JpaRepository<Member, Long>, MemberRepository {
    
    @Query("select new mypackage.dto.MemberDto(m.id, m.username, t.name) from Member.m join m.team t")
    List<MemberDto> findMemberDto();
}

@Data
public final class MemberDto {

    private Long id;
    private String username;
    private String teamName;

	// JPQL 쿼리에 생성자를 사용하므로, 생성자는 필수.
    public MemberDto(Long id, String username, String teamName) {
        this.id = id;
        this.username = username;
        this.teamName = teamName;
    }
}

 

심지어 아래와 같이 제네릭도 지원한다.

참고로 DTO 또한 @Qurey를 생략하더라도 똑같이 동작한다. 당연히 생성자 파라메타는 맞춰줘야함.

 

 

마지막으로 동적쿼리는 문자열로 입력하기에는 너무 까다롭다. 그래서 보통 쿼리빌더(QueryDSL등)을 활용한다.

사실 위에서 언급한 방법들도 QueryDSL을 사용하면 훨씬 간편하게 만들 수 있긴하다.

동적쿼리가..뭐였죠?

작성한 쿼리가 어떠한 상황에서도 변경되지 않는 쿼리가 정적쿼리가 될 것이고 입력값이나 특정 상황에 따라 쿼리문이 변경될 수 있는 쿼리가 동적쿼리이다.

동적쿼리

• 코드 실행 시점에 SQL 쿼리문이 동적으로 구성되고 실행되는 쿼리
• Stored Procedure를 생성할 때 필요에 따라 동적 쿼리로 작성
• 동적 쿼리 실행 SQL 문자열에 값이 바뀌는 변수를 넣어 쿼리문을 작성하게 되면 SP가 새로 캐싱되어 재사용성을 떨어트림
• 동적쿼리는 EXEC()함수를 사용하거나 SP_EXECUTESQL을 사용하여 실행한다.

정적쿼리

• 일반적인 쿼리
• 변수에 문자열을 대입하여 쿼리문을 작성하는 것이 아닌 일반적으로 작성된 SQL 쿼리
• 정적 쿼리로 작성된 Stored Procedure는 새로 캐싱되지 않아 재사용성을 떨어트리지 않는다.

CREATE PROCEDURE TestSP 
	-- Add the parameters for the stored procedure here
    @input       NVARCHAR(50) =null,
    @output     INT                 =0   OUT
AS
-- sp_executesql을 실행할 변수 선언
DECLARE @Sql      NVARCHAR(MAX) = ''
DECLARE @Where  NVARCHAR(MAX) = ''
DECLARE @Param  NVARCHAR(MAX) = ''


-- 입력 이름이 들어오면 WHERE절 추가
IF ISNULL(@input,'') <> '' BEGIN
SET @Where = @Where + N'
    WHERE NAME = @input '
END


BEGIN
	-- SET NOCOUNT ON added to prevent extra result sets from
	-- interfering with SELECT statements.
	SET NOCOUNT ON;

SET @Sql = @Sql + N'
    SELECT @output = AGE
    FROM   dbo.testTable '

SET @Sql = @Sql + @Where

SET @Param = N'
    @input  NVARCHAR(50),
    @output INT OUT '

EXEC SP_EXECUTESQL @Sql
                  ,@Param
                  ,@input  = @input
                  ,@output = @output

 

 

---

💭 반환 타입

참고로 SpringDataJpa는 다양한 반환 타입을 지원한다.

보통은 아래의 3가지. 컬렉션, 객체, Optional<객체> 를 많이 사용한다.

List<Member> findByUsername(String name); //컬렉션
Member findByUsername(String name); //단건
Optional<Member> findByUsername(String name); //단건 Optional

컬렉션은 값이 없어도 예외가 발생하지는 않고, 빈 컬렉션을 반환한다.

단건 조회인데 만약 결과가 2건 이상이면 예외(javax.NonUniqueResultException)이 발생한다.

단건 조회시 결과가 없으면 null이나 Optional.Empty를 반환한다.

단건 조회의 내부 동작은 JPA의 Query.getSingleResult()를 호출하는데, 해당 메서드는 `javax.NoResultException` 예외를 발생시킨다. 단건 조회시 검색결과가 없는건 예외 상황이 아니라, 충분히 있을 수 있는 상황이다. 그래서  개발자 입장에서 매우 번거로운데, 스프링에서는 이 예외를 잡아 null로 반환하도록 처리하고있다.

 

자주 사용하는게 위에 3가지라는거지, 거의 대부분의 반환타입을 SpringDataJPA에서는 제공하고 있다.

void, 기본타입(int, long), Mono<T>, Flux<T>, Maybe<T>, Future<T>, Stream<T>, Iterator<T>, Map<K,V>..

 

 

---

💭 페이징

데이터베이스에서 페이징은 언제나 골치아픈 반복 작업이었다. 매번 구글링을 통해 최적화된 페이징 SQL을 찾아야했다.

순수 JPA는 페이징을 간단하게 만들어줬었다.

public List<Member> findByPage(int age, int offset, int limit) {
    // 등록된 DBMS 에 최적화된 쿼리를 생성한다.
    return em.createQuery("select m from Member m where m.age = :age order by m.username desc")
        .setParameter("age", age)
        .setFirstResult(offset) // 시작위치
        .setMaxResults(limit) // 최대개수
        .getResultList();
}

public long totalCount(int age) {
    return em.createQuery("select count(m) from Member m where m.age = :age ", Long.class)
        .setParameter("age", age)
        .getSingleResult();
}

생성된 쿼리문

다른 DBMS으로 바꾼 경우. 해당 DBMS에 최적화된 페이징 쿼리가 생성된다.

 

스프링 데이터 JPA에서는 페이징 쿼리를 Sort 와 Pageable 인터페이스로 표준화 시켰다.

// Page, Slice, Sort, Pageable 등은 org.sptringframework.data.domain.* 에 존재한다.

Page<Member> findByUsername(String name, Pageable pageable); //count 쿼리 사용
Slice<Member> findByUsername(String name, Pageable pageable); //count 쿼리 사용안함
List<Member> findByUsername(String name, Pageable pageable); //count 쿼리 사용안함
List<Member> findByUsername(String name, Sort sort); // 정렬

또한 Page와 Slice라는 반환 타입을 제공해준다.

반환 타입을 Page나 Slice로 받는다면 추가적으로 필요한 값들(totalCount 등)을 쿼리로 날린다.

• 컬렉션(List)로 받으면 그냥 결과만 컬렉션에 받아온다.
• Page 는 Slice를 상속받아 만든 객체로, 결과에 count 쿼리 결과를 포함한다.
• Slice 는 결과에 count 쿼리 없이 다음페이지만 확인한다. (limit+1 조회, 페이지 번호가 필요없는 경우. 더보기버튼)

@Test
public void page() throws Exception {
    //given
    repoistory.save(new Member("member1", 10L)); // Member(name, code)
    repoistory.save(new Member("member2", 10L));
    repoistory.save(new Member("member3", 10L));
    repoistory.save(new Member("member4", 10L));
    repoistory.save(new Member("member5", 10L));

    //when
    PageRequest pageRequest = PageRequest.of(// page, size, Sort 구현체
        0, 3, Sort.by(Direction.DESC, "username"));
    Page<Member> page = repoistory.findByCode(10L, pageRequest);

    //then
    List<Member> content = page.getContent(); //조회된 데이터
    assertThat(content.size()).isEqualTo(3); //조회된 데이터 수
    assertThat(page.getTotalElements()).isEqualTo(5); //전체 데이터 수
    assertThat(page.getNumber()).isEqualTo(0); //페이지 번호
    assertThat(page.getTotalPages()).isEqualTo(2); //전체 페이지 번호
    assertThat(page.isFirst()).isTrue(); //첫번째 항목인가?
    assertThat(page.hasNext()).isTrue(); //다음 페이지가 있는가?
}

 

Pageable을 사용할 떄에는 org.springframework.data.domain에 있는 PageRequest를 구현체로 사용한다. 

PageRequest.of( offset, limit )를 전달하면 된다. 필요하다면 3번째 인자로 Sort 를 이용해 정렬정보를 제공해줄 수 있다.

//when
PageRequest pageRequest = PageRequest.of( 0, 3, Sort.by(Direction.DESC, "username") );
Page<Member> page = repoistory.findByCode(10L, pageRequest);

이를 이용해 Page<Entity>를 쉽게 받아올 수 있다.

만약 정렬 기준이 너무 복잡해서, Sort로 처리하기 까다롭다면 그냥 @Query(...)를 이용해서 직접 작성하는걸 권장한다.

 

 

참고로 Page 는 Slice를 상속받아 구현되어있는데, 실제 코드를 살펴보면 아래와 같다.

public interface Page<T> extends Slice<T> {
    int getTotalPages(); //전체 페이지 수
    long getTotalElements(); //전체 데이터 수
    <U> Page<U> map(Function<? super T, ? extends U> converter); //변환기
}

public interface Slice<T> extends Streamable<T> {

    int getNumber(); //현재 페이지
    int getSize(); //페이지 크기
    int getNumberOfElements(); //현재 페이지에 나올 데이터 수
    List<T> getContent(); //조회된 데이터
    boolean hasContent(); //조회된 데이터 존재 여부
    Sort getSort(); //정렬 정보
    
    boolean isFirst(); //현재 페이지가 첫 페이지 인지 여부
    boolean isLast(); //현재 페이지가 마지막 페이지 인지 여부
    boolean hasNext(); //다음 페이지 여부
    boolean hasPrevious(); //이전 페이지 여부

    Pageable getPageable(); //페이지 요청 정보
    Pageable nextPageable(); //다음 페이지 객체
    Pageable previousPageable();//이전 페이지 객체

    <U> Slice<U> map(Function<? super T, ? extends U> converter); //변환기
}

 

Slice는 count 쿼리를 날리지 않고, 최대 개수(limit)를 다 가져왔다면 다음페이지가 있는 걸로 판단한다.

테이블에 데이터가 많아서 totalCount를 세는 쿼리가 부담스럽다면, Slice를 대신 사용해서 쿼리를 최적화 할 수 있다.

테이블 레코드가 오지게많아서, Count가 부담스럽다면 Slice도 고려해보라

 

Page와 Slice에 있는 map 메서드는 다른 객체로 매핑할 때 사용한다.

아래와 같이 람다함수를 이용해서 DTO에 쉽게 매핑할 수 있다.

PageRequest pageRequest = PageRequest.of( 0, 3 );
Page<Member> page = repository.findByAge(age, pageReuqest);
Page<MemberDto> toMap = page.map(member -> new MemberDto(member.getId(), member.getUsername()));

 

 

---

💭 @Modify, 벌크성 수정 쿼리

순수 JPA의 벌크성 쿼리(executeUpdate)를 이해해야 스프링의 @Modify를 이해할 수 있다.

JPA는 커밋 시점에 Entity의 변경을 감지해서 적절한 쿼리를 발생시킨다.

하지만 작업을 하다보면 벌크성 쿼리(ex 재고가 10개 미만인 상품 전체의 가격을 20% 상승) 작업을 할 때도 있다.

 

SQL로는 간단한 작업이지만 JPA 변경감지로는 리소스도 많이 잡아먹고, 쿼리가 변경된 개수만큼 나갈 수 있다.

그래서 순수 JPA에서도 이러한 작업을 위해 executeUpdate() 라는 메서드를 제공해줬었다.

• 해당 메서드는 영속성 컨텍스트를 무시하고, 데이터베이스에 직접 쿼리를 날린다.
  = 벌크연산은 변경감지가 작동하지 않는다. 사용하면 영속성 컨텍스트와 Database의 정합성이 깨진다.
• 그래서 벌크연산 이후에 영속성 컨텍스트를 초기화(em.clear)하고 다른 작업을 하는 것을 권장한다.
  가능하면 벌크연산을 먼저 하고 em.clear()를 하도록 하자.
  영속성 컨텍스트를 완전히 비워버리면 데이터베이스에서 다시 조회하기 때문에 정합성이 깨지지않는다.

참고로 JPA 는 Update, Delete 쿼리만 지원하고, 하이버네이트에서는 select (insert into select문)까지 추가 지원한다.

// Update 벌크연산
String query = "update Product p "+
    "set p.price = p.price * 1.1 " +
    "where p.stockAmount < :stockAmount";

int resultCount = em.createQuery(query)
                    .setParameter("stockAmount", 10)
                    .executeUpdate();

// Delete 벌크연산. (Select 벌크연산은 JPA 스펙에는 없고, 하이버네이트만 지원한다.)
int deletedCount = em.createQuery("DELETE FROM Country").executeUpdate();

참고로 하이버네이트만 지원하는 벌크성 insert into select는 아래와 같은 배치 쿼리를 말한다.

// Batch
INSERT INTO table1 (col1, col2) VALUES
(val11, val12),
(val21, val22),
(val31, val32);

---

 

SpringDataJpa에서는 벌크성 쿼리를 아래와 같이 정의할 수 있다.

public interface JpaMemberRepository extends JpaRepository<Member, Long>, MemberRepository {

    // @Modifying 이 붙어있으면 executeUpdate()를 실행한다.
    // 없으면 getResultList(), getSingleResult() 호출 => 쿼리 예외(not supported DML) 발생.
    @Modifying
    @Query("update Member m set m.age = m.age + 1 where m.age >= :age")
    int bulkAgePlus(@Param("age") int age);


}

참고로 벌크성 수정, 삭제쿼리에 @Modifying을 붙이지않으면 아래와 같은 예외가 발생한다.

org.hibernate.hql.internal.QueryExecutionRequestException: Not supported for DML operations

 

벌크연산은 영속성 컨텍스트를 무시하고 실행하기 때문에, Database와 컨텍스트간의 정합성이 깨질 수 있다.

• 그래서 벌크 연산 이후에는 entityManager.clear()를 실행해서 컨텍스트를 비워버리고, DB에서 조회하라고 했다.

이는 @Modifying(clearAutomatically = true)로 설정할 수 있다. 중요한 건 이 속성의 기본값은 false이다.

flushAutomatically 라는 옵션도 있는데, 가능하면 이걸 쓰기보다는 한 트랜잭션에서 벌크 연산을 제일 먼저 하는게 좋다.

 @Modifying(clearAutomatically = true) // 해당 쿼리문 실행 이후, entityManager.clear() 실행
 @Modifiying(flushAutomatically = true) // 해당 쿼리문 실행 이전, entityManager.flush() 실행

 

 

사실 이 부분은 벌크연산 뿐 아니라, JDBC 나 MyBatis같은 생 쿼리를 JPA와 함께 쓸때도 마찬가지이다.

같은 이유로 쌩 쿼리를 날리기전 flush(가능하면 쌩 쿼리를 처음으로), 날리고 나서 clear를 해주는게 좋다.

 

---

💭@EntityGraph

순수 JPA에서는 연관관계인 객체를 Lazy하게 가져올 수 있다. 이 때 1+N 문제를 피하기 위해 join fetch(패치조인)을 적절하게 사용해야 한다.

연관관계인 객체를 Lazy로 설정해놓으면, 사용하는 시점까지 실제 쿼리문이 발생하지 않는다.
null 역할을 하는 프록시가 삽입되어 있다가, 프록시를 사용하는 시점에 새로운 쿼리가 발생한다.

이게 OneToMany 관계 문제가 발생할 수 있다. 1개를 조회했는데 거기에 연관된 100개의 객체가 조회되는데, JPA 특성상 해당 쿼리가 100번 나가기 때문.

 

만약 member.team.order 같이 연관관계에 또 다른 연관관계가 있다면? 곱해져서 몇만개의 쿼리가 발생할지도 모른다. 이를 1+N 문제라고 부르고, 이를 방지하기 위해서 JPA에서는 join fetch, 패치조인이라는 기능을 제공한다.

• select ... from ... join fetch (가져올 연관관계 필드)
• select m from Member m join fetch m.team

String jpql = "select m from Member m join fetch m.team";
List<Member> members = em.createQuery(jpql, Member.class).getResultList();
    
// 패치 조인으로 회원을 가져올때 (연관된 팀 객체를 inner join으로) 가져와서 지연 로딩 X
for (Member member : members) {
    log.info("username = " + member.getUsername() + ", " +
        "teamName = " + member.getTeam().name());
}

@Query("select m from Member m left join fetch m.team")
List<Member> findMemberFetchJoin();

 

참고로 join fetch가 아니라 그냥 join만 사용해서는 1+N문제를 해결하지 못한다.

join 만 사용하면 테이블을 조인할 때만 사용한다. 즉 DB 조인 쿼리에만 사용될 뿐, 영속성 컨텍스트에 연관된 객체(Team)을 가져오지는 않는다. 결국 사용하는 시점에는 추가적인 쿼리가 필요하다.

사실상 join fetch (패치조인)의 간편버전이라고 생각하면 된다.

 

---

@EntityGraph는 사실상 join fetch (패치조인)의 간편버전이라고 생각하면 된다.

JPQL 쿼리를 사용하지는 않지만, 내부 구현 코드의 동작은 패치조인과 같다.

 

하나 다른점은 LEFT OUTER JOIN (아래 코드에서 Member를 기준으로 LEFT 조인)을 사용한다.

//공통 메서드 오버라이드
@Override
@EntityGraph(attributePaths = {"team"}) // left join fetch m.team
List<Member> findAll();

//JPQL + 엔티티 그래프
@EntityGraph(attributePaths = {"team"}) // left join fetch m.team
@Query("select m from Member m")
List<Member> findMemberEntityGraph();

//메서드 이름으로 쿼리에서 특히 편리하다.
@EntityGraph(attributePaths = {"team"}) // left join fetch m.team
List<Member> findByUsername(String username)

@Query("select m from Member m left join fetch m.team") // 해당 기능과 동일하다.
List<Member> findMemberFetchJoin();

 

잘 사용하지는 않지만, @NameQuery 처럼 @NamedEntityGraph라는 기능도 제공해주긴 한다.

@Entity
@NameEntityGraph(name="Member.all", attributeNodes = @NamedAttributeNode("team"))
public class Member{
...
}

@EntityGraph("Member.all")
List<Member> findByUsername(@Param("username") String username);

 

 

💭 JPA Hint & Lock

@QueryHints는 JPA 구현체에 제공하는 힌트이다. 마치 DB에 SQL 힌트를 제공해서 튜닝하는 것처럼.

@QueryHints( value = @QueryHint(name = "org.hibernate.readOnly", value ="true") )
Member findReadOnlyByUsername(String username);

 

동작을 강제하지는 않고, 최적화에 도움을 준다.

예를 들어 JPA는 변경감지를 이용하여 Update 쿼리문을 반영시킨다. 즉 변경하든 말든 최초 조회시의 Entity를 가지고 있다가, 나중에 변경되었는지 확인용으로 사용한다.

 

만약 위와 같이 해당 조회 건이 `readOnly`임을 알려준다면 변경감지를 따로 하지 않는다.

다만 대부분 JPA 쿼리 최적화는 별 효과가 없어서 거의 사용하지 않는다. 대부분 만들어진 SQL의 쿼리문의 문제이다.

 

 

데이터베이스에는 비관적 Lock, 낙관적 Lock 을 지정하는 기능이 있는데, JPA도 마찬가지로 제공한다.

이는 @Lock(...)으로 지정할 수 있다.

@Lock(LockModeType.PESSIMISTIC_WRITE) // 또는 LockModeType.OPTIMISTIC_~~~
List<Member> findByUsername(String name);

 

비관적, 낙관적 lock은 데이터베이스를 깊게 공부하다보면 알 수있는 내용이다. 간단하게 설명하자면

• 비관적(perssimistic lock) : 트랜잭션 충돌이 난다 가정한다. 사용전 락을 걸고, 수정하는 시점에 충돌을 알 수 있다.
  DB가 제공하는 Lock 기능을 사용한다. 예를 들어 Select for update 등이 있다.
• 낙관적(optimisitc lock) : 트랜잭션 충돌이 나지 않는다고 가정한다. 락을 걸지않고 사용한다.
  쉽게 말해 Lock을 걸지 않는다. 어플리케이션 단에서 처리하거나 version 같은 값을 이용해서 충돌을 감지한다. 커밋시점에 충돌이 감지(=version이 다름)된다면 롤백하는 방식이다.

성능은 당연히 트랜잭션에 락을 걸지않는 낙관적 락이 좋지만, 충돌이 발생했을 때 어플리케이션 단에서 복구를 위한 추가적인 작업을 해줘야한다. (보상 트랜잭션 등)

 

락은 DBMS마다 사용하는 방법이 조금씩 다르다. 낙관적 락의 경우 어플리케이션 단에서만 처리할 수도 있다.

이는 데이터베이스를 공부하다보면 자연스럽게 알게되는 내용이니, 지금은 간단하게만 알고 넘어가도록 하자.

 

 

💭 사용자 정의 Repository 구현

SpringDataJpa의 기능을 사용하면 너무 편하지만, 특정 구현부분을 변경하고 싶을 수 있다. (조회 쿼리등)

• 스프링 JDBC Template, MyBatis등을 사용할 때
• QueryDSL등을 사용할 때

이 때 JpaRepository<Entity, ID> 의 구현체를 직접 만들어줘야하는데, 메서드가 워낙 많아서 사실상 불가능하다.

이런 경우에는 [ 인터페이스명 + Impl ] 이름을 가진 구현체를 만들면 원하는 부분만 커스텀하여 사용할 수 있다.

// 1. 사용하는 메서드의 인터페이스만 정의한다.
public interface MemberRepositoryCustom {
    List<Member> findMemberCustom();
}

//2. 해당 인터페이스를 구현한다. 원하는 방식으로 커스텀한다.
public class MemberRepositoryCustomImpl implements MemberRepositoryCustom {

    private final EntityManager em;
    public MemberRepositoryImpl(EntityManager em) { this.em = em; }

    @Override
    public List<Member> findMemberCustom() {
        return em.createQuery("select m from Member m")
            .getResultList();
    }
}

//3. 그 외 기본값으로 사용하고 싶은 메서드는 아래와 같이 주입받는다.
public interface MemberRepository extends JpaRepository<Member, Long>, MemberRepositoryCustom {
}

참고로 Spring Data 2.0 이전에는 [ JpaRepository가 연결된 인터페이스의 이름 ] 을 사용했어야했다.

즉 MemberRepositoryImpl 로 이름을 지었어야 했는데 최신 버전에서는 위 예제처럼 사용할 수 있다. 더 자연스럽다. 

 

[ 인터페이스명 + Impl ] 이름 규칙을 가지고 있다면 SpringDataJpa에서 해당 클래스를 스프링 빈으로 등록한다.

그리고 JpaRepository 구현체에 커스텀한 메서드가 적용되도록 만들어준다.

// 이렇게 사용하면, 내가 커스텀한 메서드가 실행된다.
List<Member> result = memberRepository.findMemberCustom();

 

참고로 이름 규칙은 아래와 같이 변경할 수 있다. 물론 굳이 변경 해야할 이유는 없다. 관례를 따르자.

@EnableJpaRepositories(basePackages = "study.datajpa.repository",
                            repositoryImplementationPostfix = "Impl") // 여기

 

다만 이렇게하면 MemberRepository가 너무 복잡해진다는 문제가 있다.

그래서 아예 조회성 쿼리와 커맨드성 쿼리를 분리해서 사용하기도 한다. 이때는 굳이 CustomRepository.. 이런걸 만들지 말고, 리포지토리를 하나 더 만들면 된다.

@Repository
public class MemberQueryRepository{

    private final EntityManager em;
    
    List<Member> findAllMembers(){
    	...
    }
}

이 경우에는 SpringDataJpa와는 별 관련없고, 그냥 스프링 빈으로 리포지토리를 하나 더 등록해서 사용하는 방법이다.

 

 

💭 Auditing (감사, 등록시간, 수정시간)

대부분의 테이블에 등록일, 수정일은 필수로 들어간다. 운영상황에서는 데이터를 검색하거나 맞춰야하는 일이 많은데, 이 때 이런 값이 없으면 로그를 다 뒤지는 노가다를 할 수도 있다.

 

거기에 필요에 따라 등록자, 수정자가 누군지도 기록하기도 한다. 이런 부분들을 Auditing이라고 부른다.

 

순수 JPA에서 Auditing을 하는 방법

• @PrePersist / @PostPersist 메서드
• @PreUpdate / @PostUpdate 메서드

@Entity마다 직접 적어도 되지만, 아래와 같이 공통된 부분을 @MappedSuperclass로 뽑아 쓰기도 한다.
참고로 @MappedSuperclass는 실제 상속 관계가 아니고, 자바의 extend를 이용해 속성만 받아 쓰는 방법이다.

public class Member extends JpaBaseEntity {}

아래와 같이 엔티티가 영속화 되기전/ 업데이트 되기 전에 할 행동을 정의할 수 있다.
이를 이용해 수정일, 등록일을 저장할 수 있다.

@MappedSuperclass
@Getter
public class JpaBaseEntity {

    @Column(updatable = false)
    private LocalDateTime createdDate;
    private LocalDateTime updatedDate;

    @PrePersist
    public void prePersist() {
        LocalDateTime now = LocalDateTime.now();
        createdDate = now;
        updatedDate = now;
    }

    @PreUpdate
    public void preUpdate() {
        updatedDate = LocalDateTime.now();
    }
}

 

스프링 데이터 JPA에서는 이를 위해 몇가지 어노테이션을 제공해준다.

단 사용하기 전 @EnableJpaAuditing을 활성화 해주어야한다.

@EnableJpaAuditing // JPA Auditing 애노테이션을 활성화시킵니다.
@SpringBootApplication
public class DataJpaApplication {

    public static void main(String[] args) {
        SpringApplication.run(DataJpaApplication.class, args);
    }

}

그리고 아래의 어노테이션을 사용하면 된다.

• @EntityListeners(AuditingEntityListener.class)
• @CreatedDate / @LastModifiedDate
• @CreatedBy / @LastModifiedBy

public class Member extends BaseEntity {}

@EntityListeners(AuditingEntityListener.class)
@MappedSuperclass
@Getter
public class BaseEntity {

    @CreatedDate
    @Column(updatable = false) // 이 설정은 안해도 되지만, 일종의 안전장치.
    private LocalDateTime createdDate;
    
    @LastModifiedDate
    private LocalDateTime lastModifiedDate;
}

참고로 최초 생성 시점에 수정일자도 함께 기록된다. 보통 이렇게 하는게 변경을 추적하기 편해서 일반적이다.

만약 바꾸고 싶다면 @EnableJpaAuditing(modifyOnCreate = false) 로 수정자는 null로 시작하게끔 만들 수도 있다.

 

 

다만 시간은 그렇다 치더라도, 아래와 같이 등록자, 수정자는 어떻게 자동으로 추가할까?

@LastModifiedBy
private String lastModifiedBy; // JPA가 수정자 이름이 무엇인지 어떻게 알지?

이는 우리가 직접 등록해주어여한다. auditorProvider를 빈으로 등록해주면 된다. 근데 잘 사용은 안할 듯.

@Bean
public AuditorAware<String> auditorProvider() {
	// 보통 세션 정보나, 스프링 시큐리티에서 ID를 받아온다.
    return () -> Optional.of(UUID.randomUUID().toString());
}

 

📑 좀 더 실용적인 방법(@CreationTimestamp)

근데 @EntityListeners를 등록하는 과정이 번거롭긴하다. 물론 전역으로 설정하는 방법도 있지만 그래도 귀찮다.
META-INF/orm.xml 설정을 통해 @EntiyListeners를 엔티티 전체에 자동 적용시키는 방법.

<?xml version=“1.0” encoding="UTF-8”?>

<entity-mappings xmlns=“http://xmlns.jcp.org/xml/ns/persistence/orm”
 xmlns:xsi=“http://www.w3.org/2001/XMLSchema-instance”
 xsi:schemaLocation=“http://xmlns.jcp.org/xml/ns/persistence/
orm http://xmlns.jcp.org/xml/ns/persistence/orm_2_2.xsd”
 version=“2.2">
 <persistence-unit-metadata>
     <persistence-unit-defaults>
         <entity-listeners>
            <entity-listener class="org.springframework.data.jpa.domain.support.AuditingEntityListener”/>
         </entity-listeners>
     </persistence-unit-defaults>
 </persistence-unit-metadata>
 
</entity-mappings>

 

이 때는 실용적인 방법으로 JPA가 아닌 Hybernate에서 제공하는 아래 어노테이션을 사용할 수도 있다.

• @CreateTimestamp - 엔티티에 대해 INSERT 쿼리가 발생할 때 현재 시간을 해당 필드의 값으로 채운다.
• @UpdateTimestamp - 엔티티에 대해 UPDATE 쿼리가 발생할 때 현재 시간을 해당 필드의 값으로 채운다.

설명을 보면 알겠지만, 해당 어노테이션들은 Spring이나 JPA의 EntityListeners와는 아무런 관련이 없다.

하이버네이트 자체에서 쿼리가 발생하는 시점에 필드의 값을 채워주는 기능이다.

import org.hibernate.annotations.CreationTimestamp;
import org.hibernate.annotations.UpdateTimestamp;

@Entity
@Getter
public class Post {
    @Id
    @GeneratedValue
    private Long id;

    @CreationTimestamp // INSERT 시 자동으로 값을 채워줌
    @Column(name = "created_at")
    private LocalDateTime createdAt;

    @Column(name = "updated_at")
    @UpdateTimestamp // UPDATE 시 자동으로 값을 채워줌
    private LocalDateTime updatedAt;
}

참고로 LocalDateTime은 현재 국가에 적용되는 시간이고, 전세계 기준은 ZonedDateTime 을 사용하면 된다.

 

물론 이는 JPA 공식 명세에 있는 기능이 아니라서, 사용하기 꺼려지긴한다. 하지만 현실적으로 하이버네이트를 사용하지 않는 기업은 없고, 나중에 변경하기에도 어렵지 않기에 사용해도 큰 상관없다고 본다. 

 

조금 더 나아가, 도메인에 기술적인 의존성(hibernate)가 들어가면 안된다고 생각할 수 있다.

근데 생각해보면 JPA 또한 추상화된 도메인이 아닌, 기술적인 의존성이라 분리하는 것이 맞다.

 

하지만 현실적으로 연관관계를 도메인에 매핑하기에는 까다롭기에, 타협을 봐서 JPA 정도까지는 도메인에 추가해서 가는 실용적인 선택지를 골랐다면, hibernate를 포함하는것 정도는 허용가능한 수준이라고 볼 수 있다.

 

---

💭 Web 확장기능1 - 도메인 엔티티 컨버터

결론부터 말하면 쓰지마라. 쓸 일 없는 기능이다.

물론 트랜잭션이 없는 범위에서 엔티티를 조회했으므로, 변경해도 영속성 컨텍스트나 DB에 반영되지 않는다. 없으니까!

@RestController
@RequiredArgsConstructor
public class MemberController {

    private final MemberRepository memberRepository;

    @GetMapping("/members/{id}") 
    public String findMember(@PathVariable("id") Member member) {
        // ArgumentResolver에서 JpaRepository를 이용해서 꺼내온다.
        return member.getUsername();
    }
}

 

 

💭 Web 확장기능2 - 페이징과 정렬

ArgumentResolver에서 Pageable을 생성해서 받을 수도 있다.

요청 URI /members? page=0 & size=3 & sort=id,desc & sort=username,desc
page : 현재페이지 offset (0부터 시작)
size : 한 페이지에 노출할 건 수, limit
sort : 정렬 조건 (기본 asc)

@GetMapping("/members")
public Page<Member> list(Pageable pageable) {
    Page<Member> page = memberRepository.findAll(pageable);
    return page;
}

 

참고로 URI 쿼리 파라메타를 생략하면 스프링 부트에 있는 기본 설정 값을 사용한다.

spring.data.web.pageable.default-page-size=20 /# 기본 페이지 사이즈/
spring.data.web.pageable.max-page-size=2000 /# 최대 페이지 사이즈/

 

쿼리 파라메타를 생략했을 때 따로 기본값을 지정해줄 수도 있다. 아래와 같이 사용한다.

@GetMapping("/members_page")
public String list(@PageableDefault(size = 12, sort = "username",
    direction = Sort.Direction.DESC) Pageable pageable) {
	...
}

 

한번에 여러가지 Pageable을 받아오는 방법도 있다. 쿼리에 접두사를 추가하면 된다.

 /members? member_page=0 & order_page=1
 
 {접두어}_page, {접두어}_size... 이런 식으로 지정해주면 된다.

@GetMapping("/members")
public String list(
 @Qualifier("member") Pageable memberPageable,
 @Qualifier("order") Pageable orderPageable){
 	...
 }

 

앞에서 배운 Page.map, Slice.map와 함께 이용하면 꽤나 유용하게 사용할 수 있다.

Pageable을 파라메타로 받아서, EntityDTO로 반환하는 코드.

@GetMapping("/members")
public Page<MemberDto> list(Pageable pageable) {
    Page<Member> page = memberRepository.findAll(pageable);
    Page<MemberDto> pageDto = page.map(MemberDto::new);
    return pageDto;
}

@GetMapping("/members") // 한줄로 작성하면 이렇게 된다.
public Page<MemberDto> list(Pageable pageable) {
    return memberRepository.findAll(pageable).map(MemberDto::new);
}

 

📑 혹시 Page를 1부터 시작하도록 설정을 바꿀 수 있나요?

스프링 데이터는 Page를 0부터 시작한다.

보통은 그냥 0 그대로 쓰고 클라이언트에서 처리하긴 하지만, 아예 서버에서 page=1로 전달하고 싶을 수 있다.

 

그럴땐 Page를 그대로 반환하지말고, MyPage<MemberDto> 이런식으로 DTO를 만들어서 반환하는 걸 권장한다.

@GetMapping("/members") // 한줄로 작성하면 이렇게 된다.
public MyPage<MemberDto> list(Pageable pageable) {
    Page<MemberDto> = memberRepository.findAll(pageable).map(MemberDto::new);
	
    /*.. Page<MemberDto> ➡ MyPage<MemberDto> 변환 ..*/
    
    return MyPage<MemberDto>
}

 

스프링 자체에 page를 1부터 시작하는 옵션이 있긴하다.

근데 사용했다가는 나중에 클라이언트에서 실수하기 쉬워서 추천하지 않는 방법이다.

# resource/application.yml
spring:
  data:
    web:
      pageable.one-indexed-parameters = true

왜냐하면 이는 컨트롤러 입출력에서만 page가 -1 될 뿐, 실제 페이지 객체안의 값은 그대로이기 때문. 사용이 번거롭다.

https://mysite/members?page=0 (page 0을 전달해도 page 1로 처리해준다.)
https://mysite/members?page=1 
{
     "id": 1 // 첫번째 데이터가 잘 전달되었다.
     "content": [...],
     "pageable": {
         "offset": 0,
         "pageSize": 10,
         "pageNumber": 0 // ??? 넌 왜 0이니
     }
}

https://mysite/members?page=2
{
     "id": 2 // 두번째 데이터가 잘 전달되었다.
     "content": [...],
     "pageable": {
         "offset": 0,
         "pageSize": 10,
         "pageNumber": 1 // ????
     }
}

 

 

🧨 SpringDataJpa에서 .save(entity)를 사용할 때 주의할점.

이는 SimpleJpaRepository.save() 의 구현코드를 보면 바로 알 수 있다.

• 새로운 엔티티가 아니라면 merge로 저장한다. ( Detached된 경우, 영속성 컨텍스트에 ID만 남아있는 경우)

@Transactional
@Override
public <S extends T> S save(S entity) {
    Assert.notNull(entity, "Entity must not be null.");

    if (entityInformation.isNew(entity)) {
        em.persist(entity);
        return entity;
    } else {
        return em.merge(entity);
    }
}

JPA를 배웠다면 알겠지만, merge는 성능상 좋지 않다. 데이터 변경은 JPA의 변경감지로 하는게 맞다.
애초에 merge는 준영속 -> 영속으로 바꿀 때 쓰는거지, 데이터를 변경하기 위한 기능이 아니다.

• persist()는 새로운 엔티티를 DB insert 쿼리로 저장한다.
• merge()는 먼저 DB select를 날려서 엔티티를 가져온 후, 거기에 값을 채워서 새로운 update 쿼리를 날린다.
  정확히는 영속성 컨텍스트에 해당 id가 있다면 update 쿼리만 실행하고, 없을때만 DB select를 시도한다.

 

새로운 엔티티인지 판별하는 entityInformation.isNew(..)는 아래와 같이 동작한다.

• Entity.getId() == null ( 만약 객체가 아니라면 0 )이라면 새로운 객체로 판단, true를 반환한다.

@Entity
@Getter
class Item{
    @Id
    @GeneratedValue
    private Long id; // 여기에 값이 없는 경우에만, 새로운 엔티티로 취급
}

@GeneratedValue로 생성된 아이디는 em.persist() 메서드에서 주입된다. 그래서 merge가 발생할 일은 없다.

 

하지만 @GenratedValue를 쓰지 않고 엔티티 ID를 setter로 직접 설정하는경우, persist가 아닌 merge가 발생한다.

당연히 영속성 컨텍스트에는 미리 저장된 엔티티가 없으므로 쓸때없이 쿼리가 2번나간다. (select -> update)

 

문제는 쿼리가 2번 나가는 건 추적이 가능하지만, 왜 이런 현상이 발생하는지 찾기 까다롭다.

애초에 정말 특수한 상황이 아니라면 현업에 준영속 엔티티를 merge() 할 일이 없어서 잘 모르는 것도 있다.

 

📑 그럼 Id를 직접 지정할때에는 어떻게 해야하나요?

아래와 같이 interface Persistable<ID>를 구현해서 isNew() 메서드를 오버라이딩 해주자.

그럼 새로운 엔티티를 저장할 때 merge가 발생하는 실수를 막을 수 있다.

import org.hibernate.annotations.CreationTimestamp;
import org.springframework.data.domain.Persistable;

@Entity
@NoArgsConstructor(access = AccessLevel.PROTECTED)
public class Member implements Persistable<Long> {

    @Id
    private Long id;

    @CreationTimestamp
    private LocalDateTime createdDate;

    void setId(Long id) {
        this.id = id;
    }

    @Override
    public boolean isNew() {
        /* entityInformation.isNew() 로직을 직접 작성 */
        return createdDate == null;
    }
}

 

 

💭 잘 사용하지않는 기타기능들

실무에서 거의 사용할 일 없지만, 스프링 공식문서에는 있는 기능들이다.

QureyDSL이 너무 편리하기도 하고, 기능 자체에 조금씩 하자(?)가 있어서 그렇다. 재미로 보고 넘어가자. 

 

📑 native 쿼리

JPA에서는 SQL을 직접 사용할 수 있는 native 쿼리를 제공해준다.

스프링 JPA에서도 @Qurey(nativeQurey=true)로 추상화한 기능을 제공한다.

과거에는 구려서 거의 사용을 안했지만 최근에는 나름 쓸만해졌다. 물론 그래도 QueryDSL 쓰지 이런거 안쓴다.

public interface JpaMemberRepository extends JpaRepository<Member, Long>, MemberRepository {

    // 이렇게 DB SQL을 그대로 사용할 수 있다.
    @Query(value = "select * from member where username = ?", nativeQuery = true)
    Member findByNativeQuery(String username);

}

앱 실행시점에 해당 쿼리의 유효성을 알 수 없고, JPQL과 쌩 SQL의 차이로 사용하기 매우 복잡하다.

하지만 그럼에도 불구하고 '쓸만해졌다'고 말한 이유는, [인터페이스 DTO]와 함께 사용하면 나름 유용하기 때문이다.

public interface JpaMemberRepository extends JpaRepository<Member, Long>, MemberRepository {

    @Query(value = "SELECT m.member_id as id, m.username, t.name as teamName " +
        "FROM member m left join team t",
        countQuery = "SELECT count(*) from member", // JPA 쿼리가 아님. count 쿼리 필수
        nativeQuery = true)
    Page<MemberProjection> findByNativeProjection(Pageable pageable);

}

 

하지만 QueryDSL이 있기 때문에 이런 거 안쓴다.

극한의 조회 성능이 필요하다면 그냥 쌩쿼리 - JdbcTemplate 이나 MyBatis, jooq 같은 외부라이브러리 사용을 권장한다.

사실 Hadoop & Spark & kafka 조합이 나온 뒤로는 엄청나게 복잡한 쿼리를 짤 일이 많이 줄었긴 하다.

 

 

📑 DTO Projections (DTO 프로젝션)

이건 신기능이라기보단, Repository에서 Entity가 아닌 커스텀객체(EntityDTO)를 반환받는 걸 의미한다.

 

결론부터 말하면, 나름 유용한 기능이다.

다만 단점이 DTO 프로젝션 대상이 root 엔티티면 상관없는데, 그게 아니라면 JPQL select 최적화가 안된다.

( Item - ItemOption - Option )에서 Item 엔티티 정도는 괜찮지만, 그 밑에 있는건 최적화가 안된다는 말.

 

대부분의 경우, DTO 프로젝션은 조회성능을 높이기 위해서 사용하기 때문에 그냥 QureyDSL을 사용하는 것을 권장한다.

성능이 중요하지 않다면 굳이 DTO로 받기보단, 그냥 Entity를 받아서 변환하는게 유지보수 측면에서 더 나을 수 있다.

 

간단하게 소개를 해보자면 아래와 같이 인터페이스를 DTO로 사용할 수도 있다.

// 1. 인터페이스를 만든다.
public interface UsernameOnly {
    String getUsername();
}

// 2. 그냥 쓴다. (프록시 객체가 삽입된다.)
public interface JpaMemberRepository extends JpaRepository<Member, Long>, MemberRepository {
    
    List<UsernameOnly> findByUsername(String username);

}

 

이 기능은 interface 뿐 아니라 Class는 당연히 된다. 심지어는 아래와 같이 제네릭까지 지원한다.

제네릭 처럼 타입에 따라 다르게 값이 채워지는 것을 Dynamic Projection이라고 한다. (동적 프로젝션)

// 참고로 find(...)By 이 사이에는 내가 원하는 이름을 넣으면 된다.
<T> List<T> findProjectionsByUsername(String username, Class<T> type);

List<UsernameOnly> result = memberRepository.findProjectionsByUsername("m1", UsernameOnly.class);

 

중첩 구조도 지원한다. 

public interface NestedClosedProjection {

    String getUsername();
    TeamInfo getTeam();
 
    interface TeamInfo {
        String getName();
    }
}
/*
참고로 Member, Team을 조인해서 필요한거만 가져온다.
select
    m.username as col_0_0_,
    t.teamid as col_1_0_,
    t.teamid as teamid1_2_,
    t.name as name2_2_ 
from
    member m 
left outer join
    team t 
        on m.teamid=t.teamid 
where
    m.username=?
*/

 

 

SpEL 문법 이용해서 새로운 값을 만들수 있다. (*다만 DB에서 필드를 조회한 후에 가공하는거라, 쿼리 최적화는 안된다.)

참고로 쿼리랑 DTO랑 정확하게 일치하면 close projection, 필요없는 데이터를 더 가져오면 open projection라고 부른다.

public interface UsernameOnly {

    @Value("#{target.username + ' ' + target.age + ' ' + target.team.name}")
    String getUsername();
}

 

 

📑 Predicate 기능 (*DDD 의 Specifications)

결론부터 말하자면 안쓴다. JPA Criteria를 추상화해서 만든 기능인데, Criteria를 아무도 안써서 이것도 함께 안쓴다.

 

DDD에서 에그리거트가 특정 조건(스펙)을 만족하는지 검증할 때, Specification을 추상화하여 사용하기도 한다.

public interface Specification<T> {
    public boolean isSatisfiedBy(T agg);
}

public class OrdererSpec implements Specification<Order> {
    private String ordererId;
    public OrdererSpec(String ordererId) {
        this.overerId = ordererId;
    }

    @Override
    public boolean isSatisfiedBy(Order agg) {
        return agg.getOrdererId().getMemberId().getId().equals(ordererId);
    }
}

 

이러면 이 Specification들을 논리연산 (and, or)으로 조합하거나, 아래와 같이 만족하는 엔티티를 필터링하기 좋다.

Specification<Order> ordererSpec = new OrdererSpec("madvirus");
List<Order> orders = orderRepository.findAll(ordererSpec);

AndSpec<T> spec = new AndSpec(ordererSpec, orderDateSpec); // Spec1 And Spec2
List<Order> orders = orderRepository.findAll(spec);

public class MemoryOrderRepository implements OrderRepository {
    public List<Order> findAll(Specification spec) {
        List<Order> allOrders = findAll(); // 해당 스펙을 만족하는 엔티티만 반환.
        return allOrders.stream().filter(order -> spec.isSatisfiedBy(order)).collect(toList());
    }
}

 

SpringDataJpa는 JPA Criteria를 활용해서 만든 Predicate라는 기능이 있다.

다만 Jpa Criteria가 너무 구려서 아무도 사용하지 않기에 함께 묻혀버린 안타까운 기능

 

Specification<> 과 JpaSpecificationExecutor<>등을 이용해서 위에 예제처럼 사용할 수 있다.

겉보기엔 편하고 신박하긴 하지만, 이를 쓰고싶으면 JPA Criteria 을 배워야한다. 너무 복잡하고 사용하기 어렵다.

// org.springframework.data.jpa.domain.Specification
Specification<Member> spec = MemberSpec.teamName("A").and( MemberSpec.username("kim") );
List<Member> result = memberRepository.findAll(spec);

대충 이런식으로 조건 객체인 Specification.toPredicate(...)을 구현해서 사용한다.

 

 

 

📑 Qurey By Example (사용하지 않는 신기능)

결론부터 말하자면 안쓴다. 사용하지 않는 기능이다. 동적쿼리를 Example객체로 자동 생성해주는 기능이다.

 

다만 좋은점은 JpaRepository에 이미 포함되어있어서, 별도의 구성없이 바로 사용할 수 있다.

interface JpaRepository를 까보면 위에서 언급하지않은 QueryByExampleExecutor<T> 라는게 있다.

여기있지롱

 

이를 이용해서 동적쿼리를 자동으로 생성해서 처리할 수 있다.

Member member = new Member("m1");
Example<Member> example = Example.of(member); // Example을 생성한다.

// Member("m1")과 동일한 모든 엔티티를 조회.
List<Member> result = repository.findAll(example);

 

복잡한 조회 조건이 있다면, ExampleMatcher를 사용하면 된다.

//ExampleMatcher 생성, age 값은 무시
 ExampleMatcher matcher = ExampleMatcher.matching()
                                         .withIgnorePaths("age");
 
 // age를 제외한 다른 필드 값이 같은 Member들을 조회
 Example<Member> example = Example.of(member, matcher);
 List<Member> result = memberRepository.findAll(example);

 

간단한 조건이면 유용하게 쓰겠지만, 실제 조회에서는 조건이 복잡하거나 테이블을 조인할 일이 많다.

하지만 Example의 기술적 한계상, Inner Join을 제외한 다른 조인을 제공해주지 않는다.

// 사실 조인이 아니더라도, 아래와 같이 복잡한 조건도 처리가 불가능하다.
firstname = ?0 or (firstname = ?1 and lastname = ?2)

 

굳이 이렇게 하지않고 그냥 QueryDSL을 쓰는게 훨씬 깔끔하다. 즉 사용하지 않는 기능.

 

다만 QueryByExample은 비교적 최근(2020, 1.1버전)에 나온 기능이고 SpringData에 포함된 기능이라 JPA에 의존성이 없어서, 미래에 나올 스프링 신버전에서 기능이 좋아진다면 사용할 수도 있다.