Feat: 예약 수정 API #287
Feat: 예약 수정 API #287
Conversation
| reservation.updateReservation(BoothReservationUpdateData.builder() | ||
| .name(request.name()) | ||
| .description(request.description()) | ||
| .image((request.image()!=null) ? s3Service.uploadFileAndGetUrl(request.image()):null) | ||
| .price(request.price()) | ||
| .date(request.date()) | ||
| .build() | ||
| ); |
There was a problem hiding this comment.
이렇게 수정할 경우 똑같은 서비스의 다른 날짜의 내용은 변경되지 않을 것 같은데 괜찮을까요?
예시 사진입니다!
전에 말씀드린 것처럼 아예 정보 엔티티를 분리해서 수정하거나 예약 생성 구현하신 것 처럼 전부 순환해 수정하는 방법이 있을 것 같네요! 😃
There was a problem hiding this comment.
똑같은 서비스의 다른날짜의 내용이 변경되지 않을 것 같다는 말씀이 한 요청에 다른 날짜들을 한번에 수정하는 경우를 말씀하신 걸까요??
제가 개발한 API는 수정하고자 하는 예약ID 하나씩 수정하는 방향으로 진행 되었습니다. 현재 프론트 사항을 보고 개발해본건데 참고 사진 올리겠습니다!
There was a problem hiding this comment.
프론트에서 저렇게 구현했군요! 그런데 저 예약 날짜들을 생성할 때 같은 서비스로 묶고 싶어서 한번에 생성한 걸텐데 정작 보이는건 다른 서비스처럼 보여서 이상하긴 하네요 그럼 결국 서비스의 내용을 수정하는 것이 아니라 선택한 서비스를 그냥 다른 서비스로 분리하는 것처럼 될 것 같습니다.
만약 '아이스크림 만들기' 서비스의 설명을 수정하고 싶을 경우 지금처럼 구현한다면(프론트, 백 둘 다) 저기 있는 아이스크림 서비스의 날짜들을 일일히 선택해 수정해야 되니까 그 경우 안 좋을 것 같다는 의견이였습니다!
There was a problem hiding this comment.
프론트분들께도 말씀드리면 좋을 것 같은 내용이네요 사실 처음에 엔티티 나눴으면 됐는데 넘기다 보니 처리가 어렵게 된 느낌도 있는 것 같습니다 지금 뜯어 고치기에 시간이 걸릴 수 있으니 그냥 진행하는 방법도 있을 것 같아요! 하지만 발표 이후에라도 수정하면 좋을 것 같은 내용이네요 🙂
There was a problem hiding this comment.
그 부분은 추후 회의를 통해 조정해보겠습니다! 의견 감사합니다 👍🏻
src/main/java/com/openbook/openbook/service/booth/BoothReservationDetailService.java
Outdated
Show resolved
Hide resolved
|
말씀해주신 사항을 참고해서 에러 코드와 메세지를 변경했습니다! |
Summary
PATCH /booth/reserve/{reserve_id}
Key Changes
Testing
테스트1 (날짜와 이름을 수정 할 경우)
📌 수정 전
📌 요청 값
📌 수정 후
테스트2 (시간을 수정할 경우)
📌 수정 전
📌 요청 값
📌 수정 후
To Reviewers