[BE] Stage 생성, 수정, 삭제 시 발생하는 비효율적인 쿼리 개선 (#988)

📌 관련 이슈

closed: #988

✨ PR 세부 내용

이슈에는 수정만 포함했지만, 이슈를 처리하며 StageArtistRepository를 개선했더니, 생성과 삭제 쿼리 또한 최적화 되었습니다.

기존에 생성, 수정, 삭제 시 발생하는 쿼리는 다음과 같습니다.

생성 (아티스트 5명 추가)

변경전_공연_생성_쿼리

수정 (아티스트 1명 삭제)

변경전_공연_수정_쿼리

삭제

변경전_공연_삭제_쿼리

개선 후 발생하는 쿼리는 다음과 같습니다.

생성 (아티스트 5명 추가)

변경후_공연_생성_쿼리

수정 (아티스트 1명 삭제)

변경후_공연_수정_쿼리

삭제

변경후_공연_삭제_쿼리

삭제의 경우 거의 비슷하지만, 생성, 수정의 경우 2배 정도 쿼리가 줄어들었습니다.

@OneToMany 관계의 List<StageArtist>로 StageArtist를 관리해서 그런것도 있지만, FestivalQueryInfo를 재갱신 할 때 사용되던 FestivalIdStageArtistsResolverImpl의 구현 로직을 QueryDSL을 사용하여 한 번의 쿼리로 List<Artist>를 가져온게 더 크네요. 😂

List<StageArtist>로 StageArtist를 영속함에 따라 보다 성능 향상과 도메인에 비즈니스 로직이 집중되는 결과를 얻었지만, 약간 애매한 부분도 남았는데, StageArtistRepository를 완전히 삭제할 수 없다는 것 입니다.

이유는 StageArtist의 영속은 JPA의 동작에 의존하는데, StageArtist가 들어있는 Stage는 영속된 상태여야 합니다.

하지만 QueryService를 테스트 할 때, 조회할 데이터를 넣어야 하는데, 이때 테스트에 트랜잭션이 적용되어 있지 않으므로 StageArtist를 영속시킬 수 없습니다..!

따라서 StageArtistRepository는 프로덕션 코드에서 사용되는 곳이 하나도 없지만, 테스트를 위해 존재해야 합니다.

예전에 QueryService 테스트에서 데이터 설정은 Repository를 사용하기로 했었는데, 여기서 한계가 명확하게 보이네요 😂

그래서 통합 테스트를 RestAssured를 사용한 방법을 사용해야하나 고민이 드네요.

woowacourse-teams / 2023-festa-go