🎄메리크리스마스🎄

🤔 Stream으로 수동 페이징?

시작하기에 앞서, 보통 JPA에서 페이징이 필요하면 Page<T> 타입으로 리턴받는 게 가장 깔끔하다.

Page<Entity> res = repository.findByStatus("PENDING", pageable);

이 방식이 가장 이상적인 형태고, 성능상으로도 효율적이다.

하지만 오늘 나의 상황에서는 stream으로 필터링 후, PageImpl로 수동 페이징을 하는게 나을 때가 존재한다.

1. 사용자의 필터 조건이 많고
2. 그 중 일부는 null일 수도 있고
3. 일부는 포함 검색이고
4. 날짜 범위 조건까지 존재했다.

이 조건들을 모두 JPQL이나 @Query로 짜는 건 복잡도도 높고 유지보수의 지옥이 될 것 같았다.

그래서 findAll()이나 간단한 조건을 걸어서 repository에서 조회 후 stream().filter(...)로 필터링을 했다.

물론 데이터 수가 적을때만 해당한다.

📌 전체 코드 예시

// 1. 데이터 조회
List<Entity> entityList = repository.findById(id);

// 2. 조건 필터링 + 정렬
List<Entity> filteredEntityList = entityList.stream()
	.filter(entity -> entity.getStatus().equals(dto.getStatus()))
    .filter(entity -> entity.getCont().getContNm().toLowerCase().contains(dto.getSearchNm().toLowerCase())
    .filter(entity -> dto.getTypeCodeList().contains(entity.getTypeCode())
    .sorted(Comparator.comparing(Entity::getCrtTime).reversed())
    .toList();

// 3. Pageable 객체 생성 (pageable은 F/E에서 넘어옴)
Pageable page = PageRequest.of(pageable.getPageNumber(), pageable.getPageSize());

// 4. 페이징 처리
int start = (int) page.getOffset();
int end = Math.min((start + page.getPageSize()), filteredEntityList.size());

Page<Entity> entityPage = new PageImpl<>(
	filteredEntityList.subList(start, end),
    page,
    filteredEntityList.size()
);

💥 .filter(...) 조건이 많아질 경우 리팩토링

Jave Stream의 filter()은 조건이 많아질수록 가독성이 떨어진다.

이를 위해 조건을 별도 메서드로 분리하는 것이 좋다.

List<Entity> filteredEntityList = entityList.stream()
    .filter(entity -> filterSearchNm(entity, dto.getSearchNm()))
    .filter(entity -> filterReqTypeCode(entity, dto.getReqTypeCodeList()))
    .sorted(Comparator.comparing(Entity::getCrtTime).reversed())
    .toList();

// 조건 분리 메서드
private boolean filterSearchNm(Entity entity, String searchNm) {
	if (StringUtils.isEmpty(searchNm)) return true;
    
    String keyword = searchNm.toLowerCase();
    return entity.getCont().getContNm().toLowerCase().contains(keyword) ||
    	   entity.getComp().getCompNm().toLowerCase().contains(keyword);
}

private boolean filterReqTypeCode(Entity entity, List<String> codeList) {
	return Collectionutils.isEmpty(codeList) ||
    	   codeList.contains(entity.getReqTypeCode());
}

🧸 Pageable

Spring Data JPA에서 데이터 조회 시 페이징 처리를 지원하는 인터페이스이다.

PageRequest.of(페이지번호, 페이지크기)로 간단하게 사용할 수 있다.

⬇️ 정렬까지 함께 사용하기

Pageable pageable = PageRequest.of(0, 10, Sort.by(Sort.Direction.DESC, "createdDate"));

• 0: 첫 페이지 (0부터 시작)
• 10: 한 페이지에 10개씩
• "createDate": 정렬 기준 컬럼
• DESC: 내림차순

🎡 Repository 메서드에서 사용

Page<Entity> findAll(Pageable pageable);

// Specification과 함께 사용
Page<Entity> findAll(Specification<Entity> spec, Pageable pageable);

🎡 Controller에서 사용

@GetMapping("/list")
public Page<ResponseDto> getList(@RequestParam int page,
                                 @RequestParam int size) {
    Pageable pageable = PageRequest.of(page, size, Sort.by(Sort.Direction.DESC, "createdDate"));
    return repository.findAll(spec, pageable).map(entity -> toDto(entity));
}

🪄 Pageable(Sort 포함) 사용 시 콘솔 출력 쿼리

    order by
        mer1_0.[CREATE_DATE] desc 
    offset
        ? rows 
    fetch
        first ? rows only

문제

Brazilian E-Commerce Public Dataset by Olist 데이터베이스는 브라질의 이커머스 웹사이트인 Olist Store의 판매 데이터 입니다. 그 중 olist_orders_dataset 테이블에는 주문 ID, 고객 ID, 주문 상태, 구매 시각 등 주문 내역 데이터가 들어있습니다. Olist의 주문부터 배송까지 프로세스는 다음 단계를 통해 이루어지고, 각 단계마다 시각을 기록하고 있습니다.

1. 고객의 구매
   • order_purchase_timestamp 컬럼에 구매 시점이 저장됨
2. 판매자가 주문을 승인
   • order_approved_at 컬럼에 승인 시점이 저장됨
3. 택배사에 도착하여 배송 시작
   • order_delivered_carrier_date 컬럼에 배송 시작 시점이 저장됨
4. 배송 완료
   • order_delivered_customer_date 컬럼에 배송 완료 시점이 저장됨

추가로 order_estimated_delivery_date 컬럼에는 주문 시점에 계산한 배송 예정 시각이 저장되어 있습니다. 예를 들어, 컬럼에 값이 ‘2017-02-24 00:00:00’로 들어있는 경우, 배송을 2017년 2월 24일 자정까지 완료하겠다는 의미를 담고 있습니다.

2017년 1월 한 달 동안 발생한 주문의 배송 예측이 정확했는지 분석을 하려고 합니다. 고객의 구매 일자별로 배송 예정 시각 안에 고객에게 도착한 주문과, 배송 예정 시각이 지나서 고객에게 도착한 주문을 각각 집계하는 쿼리를 작성해주세요. 배송 완료 또는 배송 예정 시각 데이터가 없는 경우는 계산에서 제외합니다. 계산 결과는 구매 날짜를 기준으로 오름차순 정렬되어야 하고, 아래 컬럼을 포함해야 합니다.

• purchase_date - 구매 날짜 (예: 2017-01-01)
• success - 배송 예정 시각 안에 고객에게 도착한 주문 수
• fail - 배송 예정 시각이 지나 고객에게 도착한 주문 수

결과 데이터 예시

• 2017년 1월 6일 구매된 주문은 총 4건이고 모두 배송 예정일 안에 배송 완료됨
• 2017년 1월 7일 구매된 주문은 총 4건이고 그 중 3건은 배송 예정일 안에 배송 완료되었으나, 1건은 배송 예정일 이후에 배송 완료됨

제출

SELECT DATE(order_purchase_timestamp) AS 'purchase_date'
     , SUM(IIF(order_estimated_delivery_date >= order_delivered_customer_date, 1, 0)) AS 'success'
     , SUM(IIF(order_estimated_delivery_date < order_delivered_customer_date, 1, 0)) AS 'fail'
FROM olist_orders_dataset
WHERE order_delivered_customer_date IS NOT NULL
  AND order_estimated_delivery_date IS NOT NULL
  AND purchase_date LIKE '2017-01%'
GROUP BY purchase_date
ORDER BY purchase_date
;

특정 버전 이상이 되어야 사용할 수 있는 함수들이 존재할 때, 현재 버전 확인하는 방법

SELECT @@VERSION;

예시 결과

Microsoft SQL Server 2019 (RTM-CU29-GDR) (KB5046860) - 15.0.4410.1 (X64) 
	Oct 23 2024 15:50:49 
	Copyright (C) 2019 Microsoft Corporation
	Standard Edition (64-bit) on Windows Server 2019 Standard 10.0 <X64> (Build 17763: )

JSP 작업 중 login() 함수가 두번 호출되는 문제가 있었다.

<!-- 기존 코드 (type 미지정) -->
<button onclick="login();" style="cursor:pointer; border:0px;">LOGIN</button>

login() 함수 내부를 보면, 아이디와 비밀번호 검증 후

document.f.submit();을 호출하여 폼을 제출한다.

function login() {
    if (document.getElementById('id').value == '') {
        alert('아이디를 입력하십시오.');
        return;
    }

    if (document.getElementById('pwd').value == '') {
        alert('비밀번호를 입력하십시오.');
        return;
    }

    document.f.submit();
}

이때 문제가 발생하는 원인은 버튼 태그의 기본 동작이 submit 타입으로 인식되기 때문이다.

(<button> 태그의 기본 type은 submit)

<button> 태그의 기본 type인 submit으로 폼 제출이 되고,

login() 내에서 document.f.submit();을 호출하여 폼이 두 번 제출된다.

따라서 기본 type이 아닌 type="button"을 통해 타입을 명시해주면

브라우저 기본 폼 제출을 방지할 수 있다.

<!-- type 명시 -->
<button type="button" onclick="login();" style="cursor:pointer; border:0px;">LOGIN</button>

이 문제는 JSP뿐만 아니라 일반적인 HTML + JavaScript 환경에서도 발생할 수 있다.

특히 이런 불필요한 함수 중복 호출을 방지하기 위해 타입을 명시하자 😉

특정 branch clone

git clone -b {branch_name} --single-branch {저장소 URL}
ex) git clone -b javajigi --single-branch https://github.com/javajigi/java-racingcar

single branch clone 이후 특정 branch 추가 clone

git remote set-branches --add origin {branch_name}
git fetch origin dev_front

# 브랜치 리스트 확인
git branch -a

git checkout {branch_name}

외래 키 제약 조건 비활성화 방법

ALTER TABLE 테이블명 NOCHECK CONSTRAINT 제약조건명;

외래 키 제약 조건 활성화 방법

ALTER TABLE 테이블명 WITH CHECK CHECK CONSTRAINT 제약조건명;

모든 외래 키 제약 조건을 한 번에 비활성화/활성화하기

-- 모든 제약 조건 비활성화
ALTER TABLE 테이블명 NOCHECK CONSTRAINT ALL;

-- 모든 제약 조건 활성화
ALTER TABLE 테이블명 WITH CHECK CHECK CONSTRAINT ALL;

에러메세지 내용

Module Error (from ./node_modules/eslint-loader/index.js):
error: Use object destructuring (prefer-destructuring) at src\views\mr\BrandPerformance.vue:296:13:
  294 |       const compComboId = '#PRODUCT_BY_RANGE#';
  295 |       const yyyymm = this.query.yyyymm.replace(/-/gi, '');
> 296 |       const prodRangeCd = this.query.prodRangeCd;
      |             ^
  297 |       const rs = await this.compCodeList(compComboId, yyyymm, prodRangeCd);
  298 |       const clsRow = rs.data.resultList;

위 에러는 this.query.prodRangeCd를 구조 분해를 통해 가져오지 않았기 때문에 발생한다.

객체 구조 분해를 통해 this.query의 속성을 좀 더 간결하게 추출하라는 내용이다.

this.query 객체에서 여러 속성을 가져온다면 구조 분해를 통해 코드의 가독성을 높일 수 있다.

수정 반영

const { yyyymm, prodRangeCd } = this.query;
const compComboId = '#PRODUCT_BY_RANGE#';
const formattedYyyymm = yyyymm.replace(/-/gi, '');
const rs = await this.compCodeList(compComboId, formattedYyyymm, prodRangeCd);
const clsRow = rs.data.resultList;

이렇게 수정하면 this.query 객체에서 yyyymm과 prodRangeCd를 한 번에 구조 분해하여 추출할 수 있다.