Repository navigation
feat: [alt-309] 고정 근무 반복·적용 기간 계약 및 생성 규칙 정립 - #121
Conversation
|
Important
This repository does not receive automatic reviews because it has fewer than 10 stars.
 |
hodoon
left a comment
hodoon
left a comment
There was a problem hiding this comment.
리뷰했습니다. 머지 전에 확인이 필요한 부분이 있어 인라인으로 남겼습니다.
| LocalDate upper = earlier(left.getEndDate(), right.getEndDate()); | ||
| // 무기한 요일 규칙도 Gregorian 달력의 400년 주기로 반복된다. | ||
| if (lower == null) { | ||
| lower = upper == null ? LocalDate.of(2000, 1, 1) : upper.minusYears(400); |
There was a problem hiding this comment.
두 규칙 중 하나라도 시작일이나 종료일이 없으면 비교 구간이 400년(약 2만 주)으로 잡힙니다. 마이그레이션된 기존 데이터는 전부 start/end가 null인 WEEKLY라서 거의 모든 비교가 이 경로로 가는 것 같습니다. 겹치지 않는 정상 케이스에서는 조기 종료가 없고, 생성 API는 규칙 쌍마다 이 전개를 반복하니 쓰기 트랜잭션 안에서 할당량이 꽤 커질 수 있을 것 같습니다.
최소한 두 규칙이 모두 WEEKLY일 때는 주기가 1주이니 lower 기준 2주 정도 창으로 줄이고, MONTHLY가 끼는 경우에만 긴 창을 쓰면 어떨까요? (요일 배치는 28년 단위로 반복되므로 그 정도로 줄여도 충분해 보입니다)
|
#107(feat/alt-295)이 먼저 머지될 예정이고, 그 PR도 참고: 로컬 DB에 이 PR의 V16이 이미 적용돼 있다면, 파일 이름을 바꾼 뒤 |
기존 데이터는 대부분 기간 없는 WEEKLY라 충돌 검사마다 400년치를 전개했다. 근무 길이가 7일 미만이고 매주 규칙은 1주 주기라 두 규칙 모두 WEEKLY면 2주 창으로 충분해 줄이고, MONTHLY가 섞인 경우는 윤년 예외 때문에 기존 창을 유지한다.
PR 번호 순서대로 병합하면 #107(ALT-295)의 V16이 먼저 들어가므로 번호 충돌을 피한다.
기존 데이터는 대부분 기간 없는 WEEKLY라 충돌 검사마다 400년치를 전개했다. 근무 길이가 7일 미만이고 매주 규칙은 1주 주기라 두 규칙 모두 WEEKLY면 2주 창으로 충분해 줄이고, MONTHLY가 섞인 경우는 윤년 예외 때문에 기존 창을 유지한다.
관리하지 않는 업장은 실제로 400(B008)인데 404(B019)로, 근무 시간 검증·겹침 문구도 바뀐 규칙과 다르게 적혀 있어 클라이언트가 잘못된 코드를 처리하지 않도록 UseCase·엔티티의 실제 응답에 맞춘다.
기존 고정 근무 API는 요일과 시간만 저장해 반복 방식과 적용 기간을 보존하지 못했습니다. 매주 또는 매월 n번째 요일 규칙과 적용 기간을 등록·조회·수정하고, 다음 달 실제 근무 생성에 반영합니다.
변경사항
검증
통합 및 남은 검증
관련 문서
ALT-309: 고정 근무 반복·적용 기간 계약 및 생성 규칙 정립