[TIL] 9월 6일

@OneToOne 관계에서 fetch type을 lazy로 설정했는데 왜 지연로딩이 동작하지 않을까

OrderSheet 와 OrderHistory의 관계는 OneToOne 이고 지연로딩으로 설정해놨다.

위의 findWithOrderSheetByUserId() 를 호출하면 해당 쿼리 이후에 아래와 같이 orderHistory의 select 쿼리가 나간다...

orderHistory를 이용하는 코드도 없는데 왜 그럴까..

JPA에서는 1:1 관계에서 Lazy Loading을 무조건 지원하지 않는다.

JPA에서 OneToOne 관계에서의 Lazt Loading 발동 조건

특정 조건을 모두 만족해야지만 지연 로딩이 동작하고 이외에는 FetchType을 LAZY로 지정하더라도 즉시 로딩으로 동작한다.

1:1 관계에서 null이 허용되는 경우, 프록시 형태로 null 객체를 반환할 수 없기 때문이다. (프록시 객체는 실제 엔티티 객체를 참조하고 있다.)

내 프로젝트에서는 OrderHistory에서 OrderSheet을 참조하는 것만으로 충분해 보여서 단방향 매핑으로 변경해주었다. OrderSheet를 통해 OrderHistory를 접근할 일은 현재로선 없어보인다.

https://thorben-janssen.com/hibernate-tip-lazy-loading-one-to-one/ 영상을 보니 1:1관계에서 지연로딩을 지원하는 방법을 소개 한다. 필요할 때 참고하면 좋을거 같다.

---

오늘 한일

• 프로그래머스 문제풀이
• JPA 책 8장 학습
  • 프록시란, 프록시 객체의 초기화, 즉시로딩과 지연로딩
• JPA 영한님 강의 실전편2
  • 컬렉션 조회 최적화, 컬렉션 페치조인 때는 distinct를 쓴다. 하지만 SQL문의 distinct와 JPA의 distinct는 다르다.
    • SQL에서는 로우의 값이 완전히 같을 때 적용된다. JPA의 distinct는 SQL문에 distinct를 추가하고 더불어, 애플리케이션에서 엔티티의 중복을 제거한다.
  • 컬렉션의 페치조인 사용 시 주의점
• ITDA 프로젝트 배송지 입력하기 기능 구현 완료, 마이페이지에서 주문 조회 하기 기능 구현 중인데 api 설계를 변경해야할 거 같다. 회의 때 이야기하기
  • 현재 api대로 가면 마이페이지에서 주문 조회할 때 여태까지 주문했던 모든 내역이 조회된다.
  • 피그마를 보니 이전 주문 내역이 아니라 현재 주문 내역이 필요한거 같다. → 그렇다면 orderSheet의 id값이 필요할 것이다.
  • 주문 이후에 orderSheetId 도 같이 반환하도록 수정해야한다.