커서 기반 페이지네이션

[shb03323]

관련이슈

• resolved 오프셋 -> 커서 기반 페이지네이션으로 변경 #506

참고사항

같이 봐야할 것 같아용.

[cookienc]

굳굳👍

[cookienc]

요거 다 같이 PageInfo 같은 객체 하나 만들어서 @ModelAttribute로 받으면 어떤가요?

[hyena0608]

여쭤보고 싶은게 있습니다.
만약 댓글인 경우에는 tagName, reviewStatus가 필요하지 않을가 같은데 이런 필드도 묶어서 사용할 계획인가요? 🤔

[cookienc]

음 보통 그런 경우까지 생각하면 PostSearchCondition, PageInfo 두 개로 나눌거 같아요

[cookienc]

tagName 같은 경우에는 QueryDSL에 BooleanExpression으로 분기 줄일 수 있을 듯. firstPage 도 될거 같은데?

https://dev.gmarket.com/33 <- 요건 참고자료

 @Test
     public void querydslTest2() {
         QMember m = QMember.member;
         String usernameCondition = null;
         int ageCondition = 25;
         List<Member> findMember = queryFactory
                 .select(m)
                 .from(m)
                 .where(usernameEq(usernameCondition), ageGoe(ageCondition))
                 .fetch();
         assertThat(findMember.size()).isEqualTo(3);
     }
     private BooleanExpression usernameEq(String usernameCond) {
         return usernameCond != null ? member.username.eq(usernameCond) : null;
     }
     private BooleanExpression ageGoe(Integer ageCond) {
         return ageCond != null ? member.age.goe(ageCond) : null;
     }

[cookienc]

Suggested change

	if (Objects.isNull(readElement)) {
	if (readElement == null) {

어떤가요?

[hyena0608]

저 이거 찬성합니다 👍

[cookienc]

이렇게 쓰는거 굳! 근데 ServiceTestConfig에서 안쓸거 같은데 SerivceTestConfig랑 RepositoryTestConfig 분리하는거 어떤가요?

[shb03323]

매우 찬성

[hyena0608]

찬성하고 갑니당

[cookienc]

문제 있는건가요?

[shb03323]

위의 테스트랑 중복이어서 헤나랑 이야기해보려했어용

[shb03323]

아 아니다. 이거 지원자 수 메소드 검증인데 private 메소드로 바꿔서 테스트 불가능하게 된거에용

[hyena0608]

집가서 확인해볼게요 ㅎㅎ

[hyena0608]

헬로우 디이투우우 D2
커서 기반 페이지네이션에 QueryDsl 까지 굿굿 고생했어요~

오늘 QueryDsl로 분기문을 해결할거라 얘기가 나왔으니 세세한 코드 리뷰는 아직 안했어요!
그래서 조금 다른 주제로 리뷰 남깁니다.
좀.. 길어요 🙇‍♂️🫣

현재 레포지터리는 다음과 같이 구성되어 있네요.

flowchart RL
    RunnerPostRepository ---> |implements| JpaRepository
    RunnerPostRepository ---> |implements| RunnerPostCustomRepository
    RunnerPostCustomRepositoryImpl ---> |implements| RunnerPostCustomRepository

Loading

RunnerPostCustomRepository 인터페이스를 통해서 QueryDsl에서 사용할 메서드를 정의하고 RunnerPostCustomRepositoryImpl을 통해서 구현체를 이용하고 있습니다.

이러한 구조를 선택하신게 RunnerPostRepository를 유연하게 사용하기 위해서라고 생각했습니다. 👍

하지만 너무 많은 메서드가 RunnerPost를 통해서 사용하게 되어서 헷갈리는 문제가 있는거 같습니다. 🥲

개인적인 생각일지도 모르겠지만 생각나는 예시를 들어보겠습니다.

먼저 RunnerPostService에 있는 조회 메서드를 봐보려고 합니다.

RunnerPostRepository를 받아서 findByPageInfoAndReviewStatus() 메서드 내부 동작을 보고 이해하려고 했습니다.

@RequiredArgsConstructor
@Transactional(readOnly = true)
@Service
public class RunnerPostReadService {

    private final RunnerPostRepository runnerPostRepository;

    public RunnerPostResponses.Simple readRunnerPostByPageInfoAndReviewStatus(final Long cursor,
                                                                              final int limit,
                                                                              final ReviewStatus reviewStatus
    ) {
        final List<RunnerPost> runnerPosts = runnerPostRepository.findByPageInfoAndReviewStatus(cursor, limit, reviewStatus);
        final List<RunnerPostTag> runnerPostTags = runnerPostRepository.findRunnerPostTagsByRunnerPosts(runnerPosts);
        final RunnerPostsApplicantCount runnerPostsApplicantCount = readRunnerPostsApplicantCount(runnerPosts);
        return convertToSimpleResponses(runnerPosts, runnerPostTags, runnerPostsApplicantCount);
    }

    // ...
}

저는 다음과 같이 RunnerPostRepository에 들어갔습니다.

flowchart RL
    RunnerPostRepository

Loading

코드가 길어서 JPQL과 매개변수를 모두 지워서 작성했습니다.

아래와 같이 8가지 메서드가 존재합니다.

현재 코드에서는 제가 보려는 findByPageInfoAndReviewStatus()가 존재하지 않습니다.

RunnerPostCustomRepository에 들어가서 작성된 QueryDsl도 보아야 외부에서 어떤 값을 불러오는지 알 수 있습니다.

public interface RunnerPostRepository extends JpaRepository<RunnerPost, Long>, RunnerPostCustomRepository {

    Optional<RunnerPost> joinMemberByRunnerPostId(/* ... */);

    Page<RunnerPost> findByReviewStatus(/* ... */);
    
    Page<RunnerPost> findByRunnerIdAndReviewStatus(/* ... */);

    List<RunnerPost> findByRunnerId(/* ... */);

    Page<RunnerPost> findBySupporterIdAndReviewStatus(/* ... */);

    Page<RunnerPost> joinSupporterRunnerPostBySupporterIdAndReviewStatus(/* ... */);

    List<RunnerPostApplicantCountDto> countApplicantsByRunnerPostIds(/* ... */);

    Page<RunnerPost> findByTagReducedNameAndReviewStatus(/* ... */);
}

여기서 한 딮스를 더 들어가야 합니다.

아래와 같이 QueryDsl로 작성될 코드를 볼 수 있습니다.

public interface RunnerPostCustomRepository {

    List<RunnerPost> findByPageInfoAndReviewStatus(/* ... */);

    List<RunnerPost> findLatestByLimitAndReviewStatus(/* ... */);

    List<RunnerPost> findByPageInfoAndReviewStatusAndTagReducedName(/* ... */);

    List<RunnerPost> findLatestByLimitAndTagNameAndReviewStatus(/* ... */);

    List<RunnerPostTag> findRunnerPostTagsByRunnerPosts(/* ... */);
}

하지만 현재 CustomRepository는 구현체가 아닙니다.

코드 동작을 보려면 한 딮스를 더 들어가야 합니다.

@RequiredArgsConstructor
@Repository
public class RunnerPostCustomRepositoryImpl implements RunnerPostCustomRepository {

    private final JPAQueryFactory jpaQueryFactory;

    @Override
    public List<RunnerPost> findByPageInfoAndReviewStatus(/* ... */) {
       // ...
    }

    @Override
    public List<RunnerPost> findLatestByLimitAndReviewStatus(/* ... */) {
        // ...
    }

    @Override
    public List<RunnerPost> findByPageInfoAndReviewStatusAndTagReducedName(/* ... */) {
        // ...
    }

    @Override
    public List<RunnerPost> findLatestByLimitAndTagNameAndReviewStatus(/* ... */) {
        // ..
    }

    @Override
    public List<RunnerPostTag> findRunnerPostTagsByRunnerPosts(/* ... */) {
        // ...
    }
}

이런 느낌으로 실제 구현된 부분을 보기에 어렵다고 느꼈습니다.

오늘 나왔던 얘기로 QueryDsl 의 이점을 더 활용해서 구현된 메서드들이 적어져서 현재보다 더 가독성 좋은 코드가 나올거라 기대합니다. 😋

그렇지만 다른 조회 요구사항이 추가된다면 메서드가 더 늘어나도 다시 똑같은 상황이 나올거 같다고 생각됩니다. 🥲

저의 개인적인 생각으로는 Repository를 하나로 해결하지 않고 나눠서 구현하면 파악하기 좋을거 같다 생각합니다.

클래스명은 예시입니다!

flowchart RL
    RunnerPostRepository ---> |implements| JpaRepository
    RunnerPostQueryDslDao

Loading

아래와 같이 QueryDsl과 관련된 부분을 다른 클래스로 분리해도 좋을거 같아요.

@RequiredArgsConstructor
@Transactional(readOnly = true)
@Repository
public class RunnerPostQueryDslDao {
    
    private final JPAQueryFactory query;
    
    // ...
}

[cookienc]

LGTM!