정렬 관련

[apptie]

• @DescendingSort과 SortPageableArgumentResolver를 커스터마이징해 Pageable(PageRequest)를 직접 만들어준 이유
  • 저희 서비스 특성상 대부분이 내림차순 정렬입니다
    • 최신순(id desc), 참여 인원순(많은 순이니 auctioneerCount desc), closingTime(마감 임박순이니 closingTime desc), 신뢰도순(높은 회원의 경매글이 먼저 보여야하니 reliability desc)
    • 다만 기본 설정을 통해 Pageable을 받으면 Sort의 기본 정렬 방식(Direction)이 asc입니다
      • 이건 상수로 정의되어 있어서(DEFAULT_DIRECTION) 옵션을 바꿀 수도 없습니다..
      • SortHandlerMethodArgumentResolverSupport.parseParameterIntoSort() 메서드에서 return allOrders.isEmpty() ? Sort.unsorted() : Sort.by(allOrders); 이런 코드를 호출하는데 Sort.by(allOrders) 부분에서 Order를 만들면서 Sort의 정의된 상수로 넣어서 불가능했습니다
      • PageableHandlerMethodArgumentResolver에서 커스터마이징을 하려고 했는데 관련 옵션을 설정하는게 없어서 불가능했습니다
      • 그래서 다음과 같은 방안을 고려했습니다
        • PageableHandlerMethodArgumentResolver부터 커스터마이징
          • 일이 너무 커져서 포기했습니다(PageableHandlerMethodArgumentResolver, SortHandlerMethodArgumentResolver, SortHandlerMethodArgumentResolverSupport 모두 작업 필요)
        • Pageable(PageRequest) 커스터마이징
          • 위보다는 작업할 내용이 적겠지만 그래도 일이 좀 많이 커질 것 같았습니다
        • Pageable(PageRequest)를 감싸는 Wrapper Class를 통해 정렬 조건만 추가 설정
          • 이 방식보다는 ArgumentResolver가 더 유연할 것이라고 생각했습니다
          • 어노테이션을 넣으면 기본 정렬 조건이 desc, 안넣으면 기본 정렬 조건이 asc와 같이 처리할 수 있었기 때문입니다
        • @PageableDefault
          • 컬럼을 하나밖에 설정하지 못합니다
          • 값이 없을 경우 기본 값을 설정해주는 방식이라 제가 원하는 방식(무슨 정렬 조건이 들어와도 기본 정렬 방식이 desc)과는 멀어서 포기했습니다
        • @SortDefault
          • @PageableDefault보다 낫습니다 여러 개 지정 가능합니다
          • 마찬가지로 기본 값을 설정해주는 방식이라 제가 원하는 방식과는 거리가 멀었습니다
        • ArgumentResolver를 통해 경매 목록 조회 시 파라미터를 모두 조회해 적절히 처리한 뒤 이를 기반으로 PageRequest를 만드는 방식
          • 너무 하드코딩하는게 아닌가 싶었는데 고려한 내용 중 이게 가장 간단하고 쉽고 나아보여서 선택했습니다
• Sort
  • 데이터를 정렬할 때 사용합니다
  • Pageable 내부에 있고 JpaRepository에서 메서드 파라미터에 이거 넣을 때 정렬을 알아서 적용해줍니다
    • List<Auction> findAll(final Pageable pageable) 하면 알아서 처리되는 그런 느낌입니다
  • 정렬 기준이 되는 필드는 무슨 타입인지 모르므로 문자열로 받습니다
    • Sort.Order는 Sort에서 컬렉션으로 관리합니다 그래서 문자열도 넣을 때 가변인자로 받고 그래서 여러 개 넣을 수 있습니다
  • 문자열을 받으면 내부적으로 Sort.Order로 변환합니다
  • Sort는 Sort.Order의 일급 컬렉션 느낌이라고 보시면 될 것 같습니다
• Sort.Order
  • 실제로 어떤 필드가 어떤 정렬 순서를 가질지 표현합니다
  • Sort의 내부 클래스입니다 이거말고 Order가 이거저거 많아서 그낭 Sort.Order라고 표현하는게 가장 명확한 것 같습니다
  • 이 순서(오름차순, 내림차순)는 Direction이라는 enum으로 표현합니다
• ComparableExpressionBase
  • Querydsl의 비교를 위한 도메인 엔티티 필드를 표현할 때의 타입입니다
  • QType.fieldName로 접근하면 QType의 필드를 통해 뭐가 되던 조건을 걸게 될 것임을 표현하기 때문에(select절, where절 등등) 이러한 네이밍이라고 보시면 될 것 같습니다
  • 얘를 기반으로 OrderSpecifier, Coalesce를 조회할 수 있습니다
    • Coalesce는 중요한 내용이 아니니까(찾아보니까 DB 함수고 조회 결과 중 처음으로 null이 아닌 값을 반환한다고 하는데 안쓸 것 같습니다) 패스하겠습니다
    • ComparableExpressionBase.asc()나 ComparableExpressionBase.desc()로 손쉽게 OrderSpecifier를 얻을 수 있습니다
• OrderSpecifier
  • Querydsl에서 레코드 조회 시 정렬 방법을 표현하는 클래스입니다
  • orderBy()에 넣으면 끝입니다
  • 주의사항은 orderBy()는 가변인자로 값을 받기 때문에 List를 Array로 변환하는 과정이 필요합니다
    • Sort.Order는 Sort에서 컬렉션으로 활용하므로 값이 몇 개인지 정확하게 명시할 수 없기 때문에 List로 받아주었습니다
      • 물론 저희 서비스에서는 하나만 가능하고 이를 예외 처리까지 해주지만 그래도...코드 상으로는 컬렉션이기는 하니까 get(0)보다는 이게 나아 보였습니다
    • orderSpecifiers.toArray(OrderSpecifier[]::new) 이런식으로 처리했습니다