본문으로 건너뛰기

Recording Block: Policy, Occurrence, Resolved View

문서 정보​

  • 작성일: 2026-04-09
  • 최종 업데이트: 2026-04-09
  • 버전: v1.0.0
TL;DR

반복 차단은 policy, 특정 날짜 차단은 occurrence, FE가 읽는 것은 resolved view로 구분해야 합니다.

목차​

  1. 개요
  2. 핵심 개념
  3. 사용 방법
  4. FAQ

개요​

이 문서는 recording domain에서 차단 정책을 어떻게 저장하고, FE는 어떤 결과를 읽어야 하는지 설명합니다.

핵심 개념​

Policy​

  • 반복 차단 정책
  • source: GymRecurringRecordingBlock
  • 예: 매주 화요일 10:00~15:00

Occurrence​

  • 특정 날짜에 실제 발생한 차단 row
  • source: GymRecordingBlock
  • 예: 2026-04-15 10:00~15:00

Resolved View​

  • 특정 날짜 기준으로 FE가 소비하는 blocked timeline
  • policy + occurrence를 해석한 결과
  • GymStaff는 court-summaries / timeline endpoint로 이 view를 소비함
  • 날짜 문자열(YYYY-MM-DD) 기준 요일 계산은 타임존 경계 drift를 피하기 위해 별도 util 기준으로 수행함

사용 방법​

언제 뭘 쓸까?​

상황추천 방식이유
Admin 반복 차단 저장Policy반복 규칙이기 때문
특정 날짜 예외 차단Occurrence날짜가 확정된 row이기 때문
FE가 화면에 렌더링Resolved Viewraw 모델을 직접 알 필요가 없음
claim/sendOccurrence 선택정책 자체는 액션 대상이 아님

FAQ​

Q: 왜 하나의 테이블로 안 끝내나요?​

반복 규칙과 특정 날짜 예외는 저장 의미가 다르고, 화면이 필요로 하는 값도 다르기 때문입니다.

Q: GymStaff는 무엇을 직접 읽나요?​

GymStaff는 raw policy가 아니라 특정 날짜 기준으로 해석된 blocked timeline을 읽어야 합니다.

Q: claim/send는 무엇을 payload로 보내나요?​

sourceType, sourceUuid, selectedStartTime, selectedEndTime를 함께 보내서 사용자가 선택한 실제 occurrence 한 건을 식별합니다.

Q: send는 어떻게 공유를 만드나요?​

send는 직접 SHARED row를 생성하지 않습니다. sender의 OWNER UserSchedule을 확보한 뒤 LEVEL_1 ShareLink를 자동 생성하고, 대상 user가 그 ShareLink를 자동 access하는 방식으로 정상 share domain 흐름을 탑니다.

Q: 왜 UI는 24:00을 보여주는데 서버는 23:59로 저장하나요?​

FE/사용자 입장에서는 하루의 끝을 24:00으로 보는 것이 직관적이지만, 서버/DB에서는 23:59 저장이 날짜 경계 처리에 더 단순합니다. 따라서 UI 표시와 저장 규칙을 분리합니다.

관련 문서​

변경 이력​

버전날짜변경 내용
v1.0.02026-04-09초기 문서 작성
- Policy / Occurrence / Resolved View 백과 문서 추가