✨ 일정 등록 및 3가지 조회 API

[psychology50]

작업 이유

• 일정 등록
• 임의의 반려동물의 오늘 일정 리스트 조회
• 임의의 반려동물의 오늘 및 현재 시간 이후의 일정 부분 리스트 조회
• 임의의 유저가 관리하는 전체 반려동물의 임의의 날짜에 해당하는 일정 리스트 조회

작업 사항

⚠️ 아직 서버에 반영 안 되어 있습니다. 집에서 반영하고 다시 말씀드릴게요.

1️⃣ 일정 등록

• 요청 경로 : POST /api/v2/users/1/pets/3/schedules
• 요청 포맷

{
    "scheduleName" : "스케줄명",
    "location" : "위치",
    "reservationDate" : "yyyy-MM-dd HH:mm:ss",
    "notifyTime" : "분 단위 정수값",
    "petIds" : ["함께 등록할 반려동물 pk값 배열"]
}

• 응답 포맷 success null

2️⃣ 임의의 반려동물의 오늘 일정 리스트 조회

• 요청 경로 : GET /api/v2/users/1/pets/3/schedules

{
    "status": "success",
    "data": {
        "schedules": [
            {
                "reservationDate": "yyyy-MM-dd HH:mm:ss",
                "scheduleId": , # schedule pk값
                "scheduleName": " ",
                "location": " "
            },
            ...
        ]
    }
}

3️⃣ 임의의 반려동물의 오늘 및 현재 시간 이후의 일정 부분 리스트 조회

• 요청 경로 : GET /api/v2/users/1/pets/3/schedules?count=
  • count 개수만큼 조회합니다.
  • 오늘 날짜에 해당하는 요청 이후 시간만을 반환합니다.
• 응답 포맷
  • 위와 동일

4️⃣ 임의의 유저가 관리하는 전체 반려동물의 임의의 날짜에 해당하는 일정 리스트 조회

• 요청 경로 : GET /api/v2/users/1/schedules?year=&month=&day=
  • 만약 2024년 1월 23일이면, /api/v2/users/1/schedules?year=2024&month=1&day=23가 요청 경로가 됩니다.
• 응답 포맷

{
    "status": "success",
    "data": {
        "schedules": [
            {
                "reservationDate": "yyyy-MM-dd HH:mm:ss",
                "scheduleId": , # 해당 일정 pk
                "scheduleName": "일정 이름",
                "location": "장소",
                "pets": [ # 해당 일정에 참여하는 반려동물 리스트
                    {
                        "petId": , # 반려동물 pk값
                        "petProfileImage": "" # 반려동물 프로필 사진 경로
                    },
                    {
                        "petId": ,
                        "petProfileImage": ""
                    }
                ]
            },
            ...
        ]
    }
}

🧐 더 고민해야 할 점

처음 Join 횟수를 3개 테이블에서 2개 테이블로 줄이기 위해 고안했던 것이
schedule, pet_schedule 테이블만 Join해서 schedule 정보와 관련 pet_id 리스트를 가져온 후
해당 pet_id 정보들을 중복 없이 추출하여 findAll하는 전략을 취했다.

하지만 코드 복잡도와 경직도가 높아진다는 문제로 인하여 Join을 최적화하기 위한 전략을 구상하는 것으로 방향을 바꾸었다.

가장 처음엔 member_id만으로 Sub Query와 Join을 사용하였으나, cost가 높아서 사용할 수 없었다.

따라서, member_id로 manager 테이블에서 관리 중인 반려동물의 pet_id 리스트를 요청하는 로직을 분리하고,
해당 값을 QueryDsl의 인자로 넘겨줌으로써 cost를 낮출 수 있었다.

하지만 여전히 Full Table Scan이 발생하는 등, 데이터가 커지면 요청이 오래 걸릴 수 있다는 우려가 존재한다.
View를 생성했을 때, 더 좋은 이점을 취할 수 있을까?
보다 더 많은 연구가 필요하다.

이슈 연결

close #84

[heejinnn]

서버에 반영하고 말씀해주세요~

[psychology50]

이렇게