fetch join 시 child table 조건이 실제 쿼리에 반영이 안되네요..

• 자바진영의ORM기술표준 

• JPA를 왜 사용해야 하는가? 

• JPA동작-저장, 조회

• JPA와상속-저장,조회

• 성능최적화 - 1치 캐쉬

• 성능최적화 - Lazy 로딩 

• OSIV 최적화

• 양방향 연관관계 Owner

• QueryDsl 장점

• QueryDsl 쿼리 사용을 위한 Repository 구조 (Custom Repository, Impl, Querydsl4RepositorySupport)

• N+1 문제 해결

.  페이징 & 소팅

• Projections

JPA 관련 강의 5개를 들으면서 정리해 본 주제 인데요.

실무에서 중요한  팁(@OneToMany 에서 batch_size 설정을 통한 N+1 문제 해결, osiv on/off 이슈등) 또는

실무에서 발생할 수 있는 중요 포인트 중에 놓친게 없는지 한번 확인 부탁드려도 될런지요?

나누어서 답을 드릴께요^^

qz.type = :type

-> 저는 잘 되더라구요. 다음 코드를 참고해주세요.

참고로 일대다 fetch join에서 다 쪽을 이렇게 필터링 하는 것은 위험합니다. 다음 링크를 참고해주세요.

https://www.inflearn.com/questions/15876

@Entity
@Getter @Setter
public class Team {

    @Id @GeneratedValue
    private Long id;

    private String teamName;

    @OneToMany(mappedBy = "team")
    private List<Member> members = new ArrayList<>();

}

@Entity
@Getter
@Setter
public class Member {

    @Id
    @GeneratedValue
    private Long id;

    private String memberName;

    @ManyToOne(fetch = FetchType.LAZY)
    @JoinColumn(name = "team_id")
    public Team team;

}

public interface TeamRepository extends JpaRepository<Team, Long> {

    @Query("select t from Team t join fetch t.members m where m.memberName = :memberName")
    List<Team> findTeams(@Param("memberName") String memberName);
}

더불어 일반적인 @OneToMany 를 QueryDsl FetchJoin 으로 작성해 봤는데요

N+1 문제는 잘 해결되는데 페이징 처리는 안되서 혹시 방법이 있는지요?

-> 이 부분은 앞서 말씀드린 것 처럼 활용2편을 보셔야 합니다^^! 궁금해 하시는 모든 내용이 설명되어 있습니다. 활용2편을 차근차근 따라하시면 일대다 fetch join의 문제점과 해결 방안을 모두 이해하실 수 있습니다.

JPQL @Query 어노테이션도 Runtime 에 Syntax 체크를 해주긴 해주더라구요...

QueryDsl 의 경우에는 Syntax 체크가 언어 레벨에서 되는 점이 더 편할 것 같긴 합니다만,

복잡한 쿼리의 경우 QueryDsl 로 작성하는게 더 검증이나 유지보수가 더 편리할까요? (엔터프라이즈 상황에서요)

-> Runtime도 좋지만 컴파일 시점에 되는 것이 확실히 더 편리합니다. 그런데 Querydsl은 자바 코드여서 리펙토링도 가능하고 재사용 가능하도록 구조화도 가능해서 확실히 실무에서 더 좋습니다. 저도 제 주변 개발자 분들도 엔터프라이즈 상황에서 매우 열심히 사용하고 있습니다.

감사합니다.

네 잘 정리해주셨네요^^

우선은 이정도만 알고 들어가도 충분합니다. 나머지는 결국 실무에서 부딪히는 상황마다 조금씩 다른데, 5개 강의를 완강하셨으면 충분히 찾아서 극복하실 수 있을 거에요.

감사합니다.

데모용으로 사용하신 프로젝트를 공유해 주시면 제가 테스트 중인 코드를 좀 더 쉽게 공유할 수 있을 것 같습니다.

혹시 가능하실런지요?

@EntityGraph(attributePaths = ["quizList"])
@Query(value = "select q " +
            " from LneQuest q INNER JOIN q.quizList qz where 1=1 " +
            " and (:type is null or q.type = :type) " +
            " and (:from is null or :from < q.createdAt) " +
            " and (:to is null or q.createdAt < :to) ",
        countQuery = "select count(q)" +
            " from LneQuest q where 1=1 " +
            " and (:type is null or q.type = :type) " +
            " and (:from is null or :from < q.createdAt) " +
            " and (:to is null or q.createdAt < :to)", nativeQuery = false)
fun findAllByJpql(@Param("type")type: String?,
                  @Param("from")from: LocalDateTime?,
                  @Param("to")to: LocalDateTime?, pageable: Pageable): Page<LneQuest>

val jpql =
    selectFrom(lneQuest)
        .innerJoin(lneQuest.quizList, lneQuiz)
        .fetchJoin()
        .where(
            WhereBuilder()
                .optionalAnd(from, { lneQuest.createdAt.after(from) })
                .optionalAnd(to, { lneQuest.createdAt.before(to) })
                .optionalAnd(type, { lneQuest.type.eq(type) })
        )
        .orderBy(*ordable(pageable.sort).toTypedArray())

val countJpql =
        selectFrom(lneQuest)
        .where(
            WhereBuilder()
                .optionalAnd(from, { lneQuest.createdAt.after(from) })
                .optionalAnd(to, { lneQuest.createdAt.before(to) })
                .optionalAnd(type, { lneQuest.type.eq(type) })
        )

return applyPagination(pageable, jpql, countJpql)

안녕하세요 답변 주셔서 감사합니다.

문의 드리고 싶은 부분들을 정리해서 github 에 데모로 만들어서

이슈를 확인받고 싶은데, 잘 안되네요.... ;;;

qz.type = :type

으로 조건을 걸 수 있는 방법이 있다면  추가로 알려주시면 감사하겠습니다.

(Querydsl 또는 JPQL 어노테이션 쿼리 모두 상관없습니다)

-> 가능하면 저도 H2 db 로 테스트 코드 한번 만들어서 공유드리도록 하겠습니다.

더불어 일반적인 @OneToMany 를 QueryDsl FetchJoin 으로 작성해 봤는데요

N+1 문제는 잘 해결되는데 페이징 처리는 안되서 혹시 방법이 있는지요?

-> 아니면 FetchJoin 시에는 구조적으로 페이징 처리가 안되는지요?

.fetchJoin() 을 제거하면 N+1 문제가 발생하지만 페이징 처리와 Sort 는 모두 잘 됩니다.

JPQL @Query 어노테이션도 Runtime 에 Syntax 체크를 해주긴 해주더라구요...

QueryDsl 의 경우에는 Syntax 체크가 언어 레벨에서 되는 점이 더 편할 것 같긴 합니다만,

복잡한 쿼리의 경우 QueryDsl 로 작성하는게 더 검증이나 유지보수가 더 편리할까요? (엔터프라이즈 상황에서요)

안녕하세요. kepha님^^

질문 여부를 떠나서 사실 이 코드는 정상 동작하지 않습니다.

JPA에서 OneToMany 관계를 fetch join 하면 페이징 처리가 불가능합니다. 관련해서 이런 경우 성능을 최적화 할 수 있는 방법을 활용2편에서 설명드립니다.

그리고 적어주신 문제는 추가로 파악해서 도움을 드리고 싶은데, 이 코드만으로는 정확한 이유를 찾기가 쉽지 않네요.

이 문제를 재현할 수 있는 간단한 자바 코드(코틀린X)와 테스트 케이스를 만들고 zipkyh@naver.com로 보내주시면 도움을 드릴께요.

감사합니다.