GTB-60 [fix] API 반환 값 수정 #60
Conversation
| WAITING_OVER_COUNT(412, "WAITING_OVER_COUNT", "예약가능한 주점이 최대 개수를 초과했습니다"), | ||
| WAITING_ALREADY_EXIST(412, "ADMIN_NOT_FOUND", "이미 웨이팅이 존재합니다"), |
There was a problem hiding this comment.
에러 메시지가 ADMIN_NOT_FOUND가 아니라 WAITING_ALREADY_EXIST인 것 같습니다!
|
고생하셨습니다! 의견 확인 부탁드립니다! |
|
추가적인 코드도 확인해 봤는데 이상이 없습니다! 정말 고생 많으셨습니다!!! |
| waiting.getWaitingId(), | ||
| pub.getPubName(), | ||
| waiting.getWaitingStatus().getStatusKo(), | ||
| waitings.indexOf(waiting) + 1)); | ||
| } | ||
|
|
||
| private List<Pub> getPubsFromWaitings(User user) { | ||
| return waitingRepository.findAllByUser(user).stream() | ||
| return waitingRepository.findAllByTel(user.getUserTel()).stream() |
There was a problem hiding this comment.
지난번에 의논했을때는 번호가 아니라 객체로 찾아오는것이 아니었나요? 이렇게 핸드폰 번호로 찾게되면 해당 유저가 현장 웨이팅 한 것만 찾아집니다. (회원가입 한 유저는 웨이팅 객체에 전화번호를 저장하지 않기 때문 -> 회원가입 한 유저인지 아닌지 구별하기 위한 수단)
지난번 정완님 의견은 회원가입을 한 유저랑 그렇지 않고 현장웨이팅만하는 유저를 구분하자고 하셨던걸로 기억합니다.
위 부분에 대해서는 의견이 바뀌신 건지 궁금합니다.
만약 의견이 바뀌셨다면 원격 웨이팅을 할 경우에도 웨이팅 객체의 전화번호(tel) 필드에 전화번호를 채우도록 로직도 변경해야 할 것 같습니다.
++ 추가
이 코멘트를 남기면서 "만약 회원가입한 유저가 현장 웨이팅을하면 어떻게 되지?" 라는 생각이 들었습니다.
어떻게 생각하시는지 의견도 추가적으로 부탁드립니다!
There was a problem hiding this comment.
넵 해당 부분은 의견이 바뀌었고, 결국 웨이팅 객체에는 모든 휴대폰 번호를 넣고, user값이 null인 경우로 현장과 원격을 구분하는 것이 최선이라고 판단하였습니다!
나머지 내용은 만나서 소통하였으므로, 머지하도록 하겠습니다!
1. 무슨 이유로 코드를 변경했나요?
2. 어떤 위험이나 장애를 발견했나요?
3. 관련 스크린샷을 첨부해주세요.
4. 완료 사항
Get /pub/{pubId}(주점 상세정보)에서 주점 status 추가
Get /pub/{pubId}(주점 상세정보)에서 인스타그램 링크 추가 및 도메인 변경
예약 내역, 현황에서 waitingId를 Response로 반환 및 도메인 변경
예약을 위한 사전 조건 예외 처리
주점정보 관련 모든 API에서 이미지 url을 List로 반환
close GTB-60 [fix] API 반환 값 수정 #59
5. 추가 사항