4주 1회차 과제

두 요소의 용도를 구분해서 설정하시는군요. 🙂

4주 5회차 과제

확인했습니다. 🙂glob으로 일괄 삭제하는 체계를 세우셨군요. 👍 경로 체계에서 개인정보 유추가 되지 않게 구성하는 등 유의점을 고려한다면 구현 편의성이 좋을 것 같습니다.

4주 5회차 과제 제출

확인했습니다. 🙂

4주 4회차 과제 제출

꼼꼼하게 시나리오를 세우셨군요. 👍

refresh() 메서드와 픽스처에 대해 질문이 있습니다.

이 실행 순서를 결정하는 프로세스에 대해서도 궁금합니다!실행 순서는 의존성 주입순입니다. client_with_auth 에 host_user_calendar 의존성 주입(pytest fixture)을 선언하면, host_user_calendar 픽스처가 먼저 실행되지요. pytest를 실행하면 fixture 의존성 그래프를 형성하는데, FastAPI와 마찬가지로 fixture 의존성 순서를 따릅니다. ( pytest.mark.usefixture 나 autouse 옵션도 우선순위에 영향을 미치는데, 일단 여기에선 의존성 선언에 따른 순서만 설명드려도 이해하실 듯 해서 생략합니다. 🙂 )그렇다면 첨부하신 이미지에서는 질문하시는 순서라면, 테스트 함수에서 client_with_auth 와 host_user_calendar 를 함께 선언하는 경우를 염두에 두신 것 같은데, 아마 매개변수 순서일 겁니다. 그런데 해당 host_user 객체는 반환되지 않고 host_user_calendar 픽스처에 남아있게 되어 접근할 수 없으니 무의미한 행동이라고 보여졌습니다.의문을 섬세하게 가지셨네요. 👍 이는 pytest와 TestClient의 동작 특성에 기인하는 상황이긴 합니다. 실제 환경에서는 애플리케이션 서버가 구동된 상황과 사용자가 API를 호출하는 상황은 서로 독립되고 분리된 상황입니다. 그래서 말씀하신대로 의미없습니다.하지만, 테스트 동작 상황에서는 이들이 한 프로세스(pytest 프로세스)에서 다루는 메모리에 올라가서 동일한 맥락 안에서 동작합니다. 왜냐하면, pytest에 선언한 SQLAlchemy 세션 객체를 픽스처, pytest 테스트 함수, TestClient가 모두가 공유해서 사용하며 동작하고 있습니다. TestClient 객체는 FastAPI 객체를 사용하고, FastAPI 객체에 의존성을 오버라이딩하여 주입하는 세션 객체는 fixture 만드는 데 사용한 세션 객체와 동일하거든요. 그래서 pytest fixture에서 host_user에 calendar 데이터가 적재되지 않은 상태라는 건, TestClient가 FastAPI 객체를 사용해 동작하는 환경과 동일한 세션 객체 상황/맥락입니다.정리하면 애플리케이션 서버를 구동해 네트워크로 HTTP 연결을 호출하는 실제 환경과 동일하게 동작하는 게 아니라 빠르게 동작시키기 위해 ASGI 애플리케이션 객체를 사용해 실제 환경처럼 동작하는 특성에 대한 의아함을 가지신 겁니다. 🙂 그래서 이 경우엔, HTTP API 관점으로 보기보다는 pytest 맥락에서 동일한 SQLAlchemy 세션 객체가 바라보는 ORM 객체 상태로 동작 상황을 머리 속에 그리시면 명확해지실 거예요.

4주 3회차 과제

수고하셨습니다. 🙂

4주 2회차 과제 질문

책에서는 일정이 정각에 시작되어 한 시간 동안 진행된다는 전제로 타임슬롯의 시간 중복 검사를 구현했습니다. 그래서 18시 30분에 시작해서 40분동안 하는 타임슬롯의 경우, 책에 나온 질의문으로는 중복 검사가 완전히 되지 않아요. 과제는 이에 대한 구현을 내드린 거예요. 🙂

4주 1회차 과제

판단의 정보 원천을 하나로 통일하는 선택을 하셨군요. 🙂

4주 1회차 과제

is_host 는 호스트 자격 검증용, calendar 관계 데이터는 호스트 준비와 같은 상태 검증용으로 쓰시는 거군요. 🙂

4주 3회차 과제

기술 요구사항을 잘 기술하셨어요. 이 요구사항을 PostgreSQL로 구현한다면 조건부 고윳값 제약으로 충족할 수 있습니다. 🙂 조건부 고윳값 제약을 지원하지 않는 데이터베이스(예 : SQLite 등)를 사용한다면 애플리케이션 계층에서 검사하거나 다른 방식으로 데이터베이스의 고윳값 제약을 활용할 수 있지요. 예를 들어, 부킹에 이력(revision)을 저장하고, 고윳값 제약은 when, timeslot_id, revision으로 묶어서 설정한 후, 예약 상태인 부킹의 revision은 고정한다면 SQLite에서도 고윳값 제약으로 무결성을 충족할 수 있지요.