발자국남기기

Member와 Team이 다대일 관계로 매칭되어 있고, 지연로딩으로 설정되어있다고 생각해보자. 지연로딩의 특성상 Member를 가져올 때 Team에 대한 정보는 가져오지 않고 proxy 객체를 만들어놓고 Team에 대한 접근이 들어올 때 진짜 Team에 대한 정보를 가져온다. 이렇게 코드가 작성되어 있을 때, 쿼리가 어떻게 나갈까? 먼저 findAll에 의해 한번에 모든 Member에 대한 조회가 이루어질 것이다. 그 후에 우리가 작성한 member의 이름을 출력하였다. 이 때 쿼리문을 살펴보면 team에 관한 데이터는 하나도 가져오지 않은 것을 볼 수 있는데 이것이 바로 proxy객체로 가져오기 때문이다. 즉, findAll이 실행되면 일단 Member만 DB에서 가져온다. 팀의 이름을 가져오기 위해 ..

JPA에서 변경에 사용하는 변경감지 기능은 한건한건씩 진행한다. 만약 전 직원의 연봉을 10% 인상해야한다면? 모든 직원을 하나하나 조회하여 Dirty Checking으로 변경하는 것은 매우 비효율적이다. 이런 경우에는 DB에 update쿼리를 날려 한번에 모두 변경하고 commit을 하는 것이 더 효율적일 것이다.이를 JPA에서 벌크성 수정 쿼리라고 한다. 먼저 JPA를 사용하여 벌크성 수정 쿼리를 작성해보자. 파라미터로 넘어온 나이보다 나이가 많은 모든 사람의 나이를 한살 증가시켜주는 update쿼리를 작성하였다. 이를 스프링 데이터 JPA로 작성해보자. @Query 애노테이션을 사용하여 JPQL을 작성하고 @Param으로 파라미터를 바인딩해준다. @Modifiying은 JPA에서의 excuteUpd..

먼저 순수 JPA로 페이징과 정렬을 하는 법을 다시 한번 살펴보자. 검색 조건 : 나이가 10살 정렬 조건 : 이름으로 내림차순 페이징 조건 : 첫 번째 페이지, 페이지당 3개 totalpage = totalcount / size JPQL을 작성하는데 offset 몇번째부터 limit 몇번째까지 데이터를 가져올 것인지 페이징을하고, 이름순으로 정렬하였다. 또한 전체 데이터의 수를 알기위해 totalcount메서드도 같이 작성 junit 테스트 작성 원하는 대로 페이징이 성공한 것을 확인할 수 있다. 이번에는 스프링 데이터 JPA를 사용하여 페이징과 정렬을 해보자. 정렬 ==> org.springframework.data.domain.Sort 페이징 ==> org.springframework.data.do..

1. 메서드 이름으로 쿼리 생성 2. 메서드 이름으로 JPA NamedQuery 호출 3. @Query 애노테이션을 사용해서 Repository 인터페이스에 쿼리 직접 정의 메서드 이름으로 쿼리 생성 스프링 데이터 jpa 맛보기할 때 잠깐 봤던 내용이다. 회원을 조회하는 메서드가 존재한다고 가정해보자. 이 메서드는 이름과 나이를 매개변수로 받아 이름이 동일하고 매개변수로 들어온 나이보다 더 많은 회원을 조회한다. 순수한 JPA를 사용하여 메서드를 만든다면 다음과 같이 만들 수 있다. 하지만 스프링 데이터 jpa를 사용한다면 구현없이 위와같이 메서드 인터페이스를 만드는 것만으로도 끝이난다. 테스트 또한 성공하는 것을 확인할 수 있다. 어떻게 이것이 가능한 것인지 살펴보자. findBy을 보고 스프링 데이터..

Spring Data JPA를 사용하게되면 인터페이스를 상속받는 것 만으로도 save, findById 와 같이 제공되는 메서드를 구현없이 사용할 수 있다. 어떻게 이것이 가능한 것일까? 주입받은 memberRepository 인스턴스를 직접 출력해보자. Spring Data JPA가 인터페이스를 보고 구현클래스를 만들어 프록시 객체를 만들어 넣어준 것이다. 따라서 우리는 인터페이스만 만들어 놓으면 구현체는 Spring Data JPA가 만들어 주입해준다. 또한 @Repository 애노테이션 생략이 가능하다. 컴포넌트 스캔을 스프링 데이터 JPA가 자동으로 처리한다. JPA 예외를 스프링 예외로 변환하는 과정도 자동으로 처리해준다.(원래는 @Repository가 하는 기능임) JpaRepository를..

http://www.querydsl.com/

Repository 인터페이스를 만들고 JpaRepository를 상속받아 사용한다. 상속 관계를 다이어그램으로 살펴보면 위와 같고 JpaRepository를 상속받으므로써 이미 구현되어있는 save(), findAll() 등과 같은 필요한 거의 모든 메서드를 바로 사용할 수 있다. 스프링 데이터 JPA는 JpaRepository 라는 인터페이스를 제공하는데, 여기에 기본적인 CRUD 기능이 모두 제공된다. (일반적으로 상상할 수 있는 모든 기능이 다 포함되어 있다.) 하지만 interface이기 때문에 구현체가 필요한거 아니야?? 구현체도 스프링 데이터 JPA가 알아서 만들고 주입해준다. 위와 같은 메서드는 모두 필요없어진다. findByName은 공통할 수 없으므로 JpaRepository에서 제공하..

OSIV = Open Session In View(하이버네이트) Open EntitiyManager In View(JPA) 하이버네이트에서의 Session이 JPA에서의 EntityManager이다.(관례상 OSIV라고 부름) OSIV ON(default) spring.jpa.open-in-view:true // 기본값 애플리케이션을 실행하면 스프링부트는 다음과 같은 warning 로그를 남긴다. WARN 25168 --- [ restartedMain] JpaBaseConfiguration$JpaWebConfiguration : spring.jpa.open-in-view is enabled by default. Therefore, database queries may be performed during ..

1. 지연 로딩과 조회 성능 최적화 엔티티를 직접 노출 저장된 모든 order를 찾아 리스트에 담고 엔티티를 그대로 반환 Postman으로 요청을 전송해보자. 먼저 앞서 공부한 것과 같이 엔티티를 그대로 노출하는 것은 굉장히 좋지 않은 행위이다. 또한, 응답을 보면 무한 loop에 빠져 StackOverflow가 발생하는 것을 확인할 수 있다. 이는 Order와 Member가 현재 양방향 관계로 매핑되어 있기 때문에 양방향관계에 의한 순환 참조로 인해 무한 Loop가 발생하기 때문이다. 이를 어떻게 해결하여야 할까? 현재 주문을 조회하고 있기 때문에 반대쪽 Member, OrderItem, Delivery에서 Order로 오는 것을 @JsonIgnore을 통해 막아야한다. 즉, 양방향 연관관계가 걸리는 ..

엔티티를 파라미터로 받을 경우의 문제 컨트롤러 엔티티 검증을 위한 @NotEmpty같은 로직들이 엔티티에 추가된다. 엔티티를 위한 매우 다양한 API가 만들어지는데, 한 엔티티에 각각의 API를 위한 요구사항들을 담기는 어려움 가장 큰 문제는 엔티티가 변경되면 API 스펙 자체가 변한다. 만약 엔티티의 name필드가 username으로 변경된다면 API 스펙 자체가 변하기 때문에 큰 문제가 발생한다. API 요청 스펙에 맞춰 별도의 DTO클래스를 만들어 DTO 객체를 파라미터로 받아야한다. 절대 파라미터로 엔티티를 바로 받지 말자!! 엔티티를 API 스펙에 노출 X 이와 같이 따로 DTO 클래스를 만들어 파라미터로 받아야한다. 예제를 위해 setter를 사용했지만 실제는 사용 X 엔티티와 표현 계층을 위..