[feat] #200 - 공연회차 등록 10회까지 가능하도록 수정

[hyerinhwang-sailin]

Related issue 🛠

• closes [feat] 공연회차 등록 10회까지 가능하도록 수정 #200

Work Description ✏️

• 공연회차를 10회로 늘렸으며, 공연 수정 중 최대회차 검증 로직도 10회까지 허용하도록 수정했습니다.
• SEVENTH의 경우 기존 ScheduleNumber의 최대 문자열 길이보다 길어 머지 전 db 상 수정이 필요합니다.

ALTER TABLE schedule MODIFY COLUMN schedule_number VARCHAR(10);

• FE 쪽의 요청에 따라 dev 서버의 accessToken expire time을 수정했습니다.

Trouble Shooting ⚽️

Related ScreenShot 📷

10회차 공연 생성 테스트

10회차 공연 상세정보 조회

등록한 공연 목록 조회

비회원 예매 요청 테스트

비회원 예매 확인

회원 예매 요청 테스트

회원 예매 확인

예매자 목록 조회

전체 예매자 목록 조회가 정상적으로 이루어짐을 확인했습니다.

회차별 예매자 목록 조회가 정상적으로 이루어짐을 확인했습니다.

수정하기에 필요한 공연 상세정보 조회

10회차 공연 정보 수정 테스트

• 6회차를 삭제하고, 5회차 날짜를 수정했습니다.
• 그 결과 총 회차가 9회차가 됐습니다.
• 5회차 날짜를 등록한 회차 중 가장 늦은 날짜로 수정했으므로 기존 5회차는 마지막 회차인 NINTH로 scheduleNumber가 업데이트됐습니다.

예매하기에 필요한 공연 상세정보 조회

예매자 입금 여부 수정

예매 취소 요청

추가 테스트

• 공연 정보 수정 시 request body에 scheduleNumber 미포함해도 수정되는지 확인
  
  9회차까지 존재하던 공연에 회차를 하나 추가하는 수정 요청을 보낸 결과 정상적으로 추가됨을 확인했습니다. 이때 기존 dto 양식에 맞게 request body에 scheduleNumber 미포함했습니다.

• 공연 정보 수정 시 회차 추가로 인해 총 회차가 10회를 초과하는 요청을 보낼 때 에러 반환하는지 확인
  
  의도한대로 에러를 반환하는 것을 확인했습니다.

Uncompleted Tasks 😅

To Reviewers 📢

scheduleModifyRequests에 scheduleNumber 포함해서 요청했을 때도 정상 요청으로 인식되고 수정도 성공한 것에 대한 확인을 위해 테스트를 진행했습니다.

• scheduleModifyRequests에 일부만 scheduleNumber 포함해서 요청했을 때 확인
  
  1회차의 티켓 수를 수정하는 요청을 scheduleNumber을 포함해 보내자 정상 요청으로 판단했고 수정도 성공했습니다.
  dto와 달리 request body를 작성했음에도 수정에 필요한 필드만 다 확인되면 정상으로 판단한 것으로 보입니다.

1회차의 티켓 수를 수정하는 요청을 보내며 이번엔 기존과 다른 scheduleNumber 포함해서 요청하는 테스트를 해봤는데 정상 요청으로 판단했고 티켓 수 수정도 성공했으며, response body에서 scheduleNumber가 duedate에 따라 다시 재부여되여 FIRST로 변경된 것도 확인했습니다.

이 부분에 대해 dto 양식에 대해 재검증하는 로직이 추가로 필요한가에 대한 리뷰어분의 생각이 궁금합니다. 저는 프론트 측에서 요청을 보낼 때 저희가 작성한 api 명세서에 맞춰 scheduleNumber를 포함하지 않고 보낼 것이고 서버에서는 request body로 받은 scheduleNumber 를 이용하지 않고 수정하기 때문에 로직을 추가로 작성하는 것의 필요성은 없다고 생각했지만 또 한편으로 다른 api도 request body에 dto와 다른 추가 필드를 포함했을 때 문제가 발생할 여지가 있는지에 대한 검토는 필요하다고 생각했습니다.

[hoonyworld]

혜린님 고생하셨습니다!!

다만, 첫 공연 생성 시에는 scheduleNumber를 주지만 이후 공연 수정에서는 scheduleNumber를 부여하지 않고 performanceDate로 정렬할 수 있도록 리팩토링을 해놓았습니다. 그런데 postman상 put 요청에서 scheduleNumber를 부여하시는 것 같은데, 부여하지 않고 다시 한 번 테스트를 해서 잘 작동이 되는지 확인해주시면 감사하겠습니다~

[hoonyworld]

이 부분 회차가 10개 넘어갈 시 에러를 반환하는지도 같이 테스트 해주시면 감사할 것 같습니다!

[hyerinhwang-sailin]

테스트 후 conversation에 추가해뒀습니다!

[hoonyworld]

request body에 dto와 다른 추가 필드를 포함했을 때 문제가 발생할 여지가 있는지에 대한 검토는 필요하지 않을 것 같습니다!

왜냐하면 Spring Boot에서 Jackson 라이브러리를 사용하여 JSON을 처리할 때, 기본적으로 알 수 없는 속성(즉, DTO에 정의되지 않은 속성)은 무시되도록 설정되어 있기 때문입니다.
찾아보니 이 설정은 Jackson의 기본 동작으로, DeserializationFeature.FAIL_ON_UNKNOWN_PROPERTIES 옵션이 false로 설정되어 있기 때문이라고 하네요!!

참고하시면 좋을 링크 남기고 갑니다 ㅎㅎ

https://siahn95.tistory.com/173#google_vignette
https://www.baeldung.com/spring-boot-customize-jackson-objectmapper