인프런 커뮤니티 질문&답변

# 4주 1회차

두가지 요소를 다 사용하는 전략을 이용할것 같습니다.

1. is_host 만 체크할 경우 호스트 권한은 있지만 캘린터 미생성등으로 캘린더가 없는 host가 api를 호출했을때 500 에러가 발생할 위험이 있습니다.
2. 또한 캘린더 존재만 체크할 경우 일반 유저가 확인하지 못한 경로고 캘린더를 생성하거나, host 권한이 없어진 유저가 호스트 기능을 수행할수 있게 될 위험이 있습니다.

그러므로 먼저 is_host 로 유저의 자격을 검증하고, 이후 실제 비즈니스 로직 진입 전 캘린더 유무를 확인해 예외처리 등을 하는 것이 가장 안정적으로 접근할수 있게 될것 같습니다.

# 4주 2회차
 sqlalchemy를 사용해 기존 예약과 겹치지 않는 지 확인하는 메서드입니다.
```python
from sqlalchemy import select, and_, or_
from app.models.booking import Booking

async def check_timeslot_overlap(session, calendar_id, start_time, end_time):
    # (새로운 시작 시간 < 기존 종료 시간) AND (새로운 종료 시간 > 기존 시작 시간)
    # 위 조건이 참이면 시간이 겹치는 슬롯이 존재함
    stmt = select(Booking).where(
        and_(
            Booking.calendar_id == calendar_id,
            Booking.status != "cancelled",
            Booking.start_at < end_time,
            Booking.end_at > start_time
        )
    )
    result = await session.execute(stmt)
    overlap_booking = result.scalars().first()
    
    if overlap_booking:
        return False # 중복 발생
    return True # 예약 가능
```

# 4주 3회차

동일 일자/ 타임슬롯에 대해 중복 예약을 막되, cancelled 상태인 경우는 제외해야 한다.
-> postgresql에서 지원하는 partial index를 사용하는 것이 가장 깔끔할 것 같습니다.
```python
from sqlalchemy import Index

class Booking(Base):
    # ... 기존 필드 (id, calendar_id, start_at, attendance_status 등) ...

    # attendance_status가 'cancelled'가 아닌 데이터들에 대해서만 
    # calendar_id와 start_at의 조합이 유니크해야 함
    __table_args__ = (
        Index(
            "ix_unique_active_booking",
            "calendar_id",
            "start_at",
            unique=True,
            postgresql_where=(text("attendance_status != 'cancelled'")),
        ),
    )
```

# 4주 4회차

정책 : 
호스트의 노쇼 방지 맟 일정 관리의 안정성을 보장하기 위해서 예약 시간 24시간 전까지 1회에 한해 일정을 변경하는것을 허용한다. 그 이후는 취소 후 재예약만 가능한것으로 구현하는 정책을 구성할 것 같습니다. 
구현 시나리오:

1. 변경 가능 기간 내 시도 (성공)
    게스트가 2월 10일 오후 2시 예약을 2월 8일에 확인.
    2월 11일 오후 4시로 변경 요청.
    시스템은 현재 시간 + 24시간 < 예약 시작 시간을 검증 후 True.
    기존 타임슬롯을 업데이트하고 성공 메시지 반환.

2. 임박한 변경 시도 (실패)
    게스트가 2월 10일 오후 2시 예약을 2월 9일 오후 8시에 변경 시도.
    잔여 시간이 18시간이므로 검증 로직에서 False.
    "예약 24시간 전에는 일정을 변경할 수 없습니다. 취소 후 재예약 바랍니다." 메시지 반환


# 4주 5회차

- soft delete 후 배치 처리를 통한 db 레코드 삭제를 세울것 같습니다.
  - 데이터 복구 가능성 고려
    - 유저가 실수로 예약을 삭제했을때 db 레 코드와 함께 파일까지 지워지면 복구가 불가능합니다.
  - 트렌잭션 성능 고려
    - api 요청 내부에서 s3나 로컬 파일 시스템의 i/o 작업을 직접 수행한다면 응답 시간이 길어집니다.