JPA Unidirectional @ManyToOne, "Why it creates more select queries than I expected"

[@avijitsharma5050]

Please put some lectures in English as well so that i can also study

[@keesun.b]

Welcome to Korean channel. I might gonna try it later but I am not sure when it exactly would be.

[@avijitsharma5050]

백기선 Thanks , I am waiting

[@joont92]

제가 생각하는 답변입니다!! 1. member와 team을 저장한 후 바로 findAll로 조회했기 떄문입니다. member와 team은 영속성 컨텍스트에 들어가있는 상태이므로 추가적인 조회 쿼리를 날릴 필요없이 영속성 컨텍스트에서 꺼내오기만 하면 되기 떄문입니다. 1번 날아간 member 전체 조회는, findAll이 JPQL이기 때문입니다(JPQL은 먼저 쿼리를 날리고 난 후 결과를 영속성 컨텍스트와 비교합니다) 2. fetch type lazy를 사용합니다 3. JPQL fetch 조인을 사용하는것이 가장 빠른 방법인것 같습니다

[@keesun.b]

음 일단 JPQL은 아니고 Criteria로 구현되어 있긴한데 그래서 일까요?

[@joont92]

@@keesun.b 음.. 제가 말을 이상하게 써놨네용 테스트 코드에서는 하나의 메서드 내에서 persist, find를 모두 수행했으므로 영속성 컨텍스트에 team이 계속 유지되기 때문에 추가쿼리가 필요하지 않았고, 컨트롤러에서는 member 조회하면서 team을 같이 들고오게 되는데(eager때문) 영속성 컨텍스트에 없어서 추가 조회가 발생한다로 정정하겠습니다

[@joont92]

@@keesun.b JPQL을 언급한 이유는 member 객체가 이미 다 영속성 컨텍스트에 들어있는데 왜 member 쿼리가 날라가느냐? 에 대해 앞서서 대답해봤어요..ㅋㅋㅋㅋ

[@JoKwanghee]

1번 은 전체 조회 한번하고 모두 영속성 안에 있으니 더 이상 쿼리되지 않는 것 같고요. 2번 은 fetch 전략을 lazy로 두면 될 것 같은데 초반에 복선을 두셨듯이 ToString에서 team이 배제되어 있지 않으므로 toString()을 사용하거나 logger 로 모델을 찍어보거나 IDE에서 debug 실행시 모델정보 표시하면서 toString이 사용되서 참조되는 경우만 조심하면 될 것 같네요. 3번 은 딱 떠오르는 건 fetchJoin을 사용하면 될듯 한데, EntityGraph 로도 가능하지 않을까 싶기도 하고... ManyToOne에는 사용해보지 않아서 한번 해봐야겠어요ㅎ

[@keesun.b]

잘 아시네요! 댓글 감사합니다.

[@sangwoobae8973]

1. 테스트 코드는 인서트 하면서 팀이 이미 퍼시스트 상태라서 멤버만 가져온다? 2. 멤버정보만 쿼리하려면 매니투원 패치 모드를 레이지로 한다? 3. 한번에 가져오려면 패치조인을 한 쿼리메서드를 만든다? 민방위 교육받고 귀가하는 버스에서 뇌피셜로 적어봤습니다.

[@keesun.b]

2번 처럼 하더라도 조금 주의할게 있습니다.

[@sangwoobae8973]

@@keesun.b 매니투원 필드를 사용하는 순간 셀렉트가 일어나니 사용하지 말아야한다!? 정답영상 기다리겠습니다!ㅎㅎ

[@마구잡이-s6b]

LAZY 인경우 반환되는 타입은 프록시입니다.

[@마구잡이-s6b]

JPQL에서 즉시로딩 전략인경우에 발생하는 N+1 과 동일한문제

[@hch4102]

이거는 eager여서 그렇습니다 ㅎ.ㅎ