해결된 질문
23.10.01 15:58 작성
·
583
·
수정됨
1
갱신된 강의자료에도 나와 있듯이, fetchResult, fetchCount 등의 메소드는 deprecated 예정입니다. 또한 해당 메소드는 Page 타입을 반환하기 때문에 Page 타입을 직접적으로 조작해야 한다는 제약이 있습니다. 이걸 잘 쓰면 되는데, Page 의 시작번호 등 제약도 있어서 저는 회사에서 Page 를 따로 만들어서 사용하거든요. 그래서 search 메소드와 count 메소드는 항상 분리하고 있습니다.
2. 그런 점에서 count 만 최적화하는 로직만 베껴서 만든 최적화 메소드입니다.
실제로 count 구문을 실행하기 위한 메소드입니다. 필요에 따라서 public 으로 만들어도 될 것 같네요.
// count 실행 메소드
private Long countByCond(MemberSearchCond cond) {
return query
.select(member.countDistinct())
.from(member)
.where(
usernameEq(cond.getUsername()),
teamNameEq(cond.getTeamName()),
ageGoe(cond.getAgeGoe()),
ageLoe(cond.getAgeLoe())
)
.fetchOne();
}
최적화 로직을 베낀 메소드입니다.
스프링 데이터 JPA 는 아래 코드와 같이 page, size 값이 null 이 아니고, 적절한 범위에 있는지를 판단하여 isPaged 라는 분기를 만듭니다. 참고로 코드를 분석하면서 내린 뇌피셜이니 혹시 틀리다면 말씀해주세요.
page 가 0 이 아니라 1 부터 시작하는 건 제 취향입니다. 회사에서 그렇게 쓰고 있거든요. 필요에 따라 0 부터 시작하도록 바꾸는 건 어렵지 않을 것 같습니다.
public Long countByCondOptimization(List<?> content, MemberSearchCond cond, Long page, Long size) {
boolean isPaged = page != null && size != null && page > 0 && size > 0;
long offset = isPaged ? (page - 1) * size : 0L;
long contentSize = content.size();
if (!isPaged || offset == 0) {
if (!isPaged || size > contentSize) {
return contentSize;
}
return this.countByCond(cond);
}
if (contentSize != 0 && size > contentSize) {
return offset + contentSize;
}
return this.countByCond(cond);
}
이렇게 하여 count 쿼리를 리스트 조회 쿼리와 분리하여 재사용성을 높이면서, 성능도 최적화할 수 있습니다.
감사합니다.