[mod] 여유시간이 null인 약속 조회시 사용자 디폴트 여유시간이 반환되도록 수정

[JunbeomKoreaUniv]

수정한 코드

• 여유시간이 null인 약속 조회시 사용자 디폴트 여유시간이 반환되도록 수정하였음.
• scheduleService의 mapToDto 메서드에서 3항 연산자를 이용해 약속의 여유시간이 null이면 사용자의 여유시간을 가져오게 코드 수정하였음.
• 이 때, 그냥 가져오게 되면 약속가져오는 쿼리 한 번, 해당 약속의 사용자 여유시간을 가져오는 쿼리 한번해서 총 2번 쿼리가 나가게 돼 응답시간에 손해를 봄. 따라서 처음에 약속을 조회할 때 사용자를 페치조인하여 가져오도록 코드 수정하였음
  • 약속 여유시간이 null이 아닌 약속은 유저와 페치조인을 할 필요가 없음에도 페치조인이 된다는 단점이 있으나,
    처음 약속을 DB에서 가져오기 전에는 spareTime을 알 수 없어 위 단점은 필연적임.
  • 여유시간이 null인 약속들에 대해 쿼리 2번 날리기 vs 모든 약속에 대해 조인하기 중 차악을 선택해야하는 상황인데, 저는 우선 후자를 선택하였으나 이에 대한 고민을 같이 해주면 좋을 것 같습니다.
    • 차후, 실 사용자가 생기면 여유시간을 설정하는 약속의 비율을 파악해 두 방법 중 어느 방법이 효율적일지 정확한 판단이 가능할 것같음.

테스트

DB에는 schedule_spare_time이 null로 저장된 약속을 조회하면 사용자 디폴트 시간이 여유시간으로 반환됨

[jjjh02]

효율적인 조회 방식을 고민하는 과정에서 다음과 같은 방법을 생각해봤습니다.

showSchedulesByPeriod에서 조회하는 Schedule의 User는 모두 동일하므로, Schedule을 조회할 때 User를 FETCH JOIN하지 않고,
별도의 SELECT 문(@Query("SELECT u.spareTime FROM User u WHERE u.id = :userId"))을 통해 User.spareTime을 한 번만 조회한 후, scheduleSpareTime이 NULL인 경우 이를 재사용하는 방식입니다.

이 방식은 User.spareTime을 가져오는 추가적인 SELECT가 발생하지만, 한 번만 실행되므로 성능 부담이 크지 않습니다.

Schedule 데이터가 많지 않다면 JOIN FETCH 방식이 더 간단하고 효율적이고
Schedule 데이터가 많아지고 User가 중복 조회되는 것이 부담된다면, User.spareTime을 별도로 한 번만 조회하는 방식이 적절할 것으로 보입니다.

저희 서비스는 약속생성하는게 메인이기 때문에 Schedule 데이터가 많아질 경우를 대비한다면
'user.spareTime을 별도로 한 번만 조회하는 방식'도 고려해봐도 좋을 것 같은데 어떻게 생각하시나요?

[JunbeomKoreaUniv]

말씀하신 방법이 저희 프로젝트에 더 적합한 것 같네요!
사용자 여유시간 미리 조회해놓고 여러 약속 조회하는 API 호출할 때 약속의 여유시간이 null일 시 사용자 여유시간을 반환하는 방식으로 코드 수정하였습니다~
확인 부탁드려요!

[jjjh02]

Entity에서는 @Setter 사용을 지양하는 쪽으로 코드 리팩토링을 진행했었는데 여기서는 DTO라 Entity와는 달리 단순히 데이터를 전달하는 역할이라 @Setter를 사용하신게 맞을까요?

[JunbeomKoreaUniv]

네 DTO이고, DTO 내부에 따로 비즈니스 메서드가 있는것도 아니여서 Setter 사용에 무리가 없을 것 같습니다

[jjjh02]

넵넵! 확인했습니다

[jjjh02]

수고 많으셨습니다 ~! 머지하겠습니다