[Feat] 임시저장 API 구현 (#23)#40
Conversation
- 지원 플로우 작성 상태를 저장하기 위한 ApplicationDraft 엔티티 추가 - 작성 단계 관리를 위한 ApplicationDraftStep enum 추가 - 기존 ApplyType을 재사용하여 실제 공고/가상 공고 지원 유형 저장 - 로그인 사용자 기준 임시저장 생성 및 수정 API 구현 - 로그인 사용자 기준 최근 임시저장 조회 API 구현 - 로그인 사용자 기준 임시저장 삭제 API 구현 - 사용자당 임시저장 1건만 유지되도록 user_id unique 제약 및 upsert 로직 적용 - selectedQuestionIds를 ElementCollection으로 저장하고 null 요청 시 빈 리스트로 처리 - 기존 공통 응답 포맷(ApiResponse)과 인증 사용자 조회 방식 준수 - 임시저장 생성, 수정, 삭제 서비스 테스트 추가
| summary = "내 임시저장 생성/수정", | ||
| description = "로그인한 사용자의 지원 플로우 임시저장을 생성하거나 수정합니다. 사용자당 최근 임시저장 1개만 유지합니다." | ||
| ) | ||
| @PutMapping("/me") |
There was a problem hiding this comment.
임시저장 자체가 이미 개인화된거니까 굳이 url에 me를 쓸 필요 없을거 같기도,,,
There was a problem hiding this comment.
me 넣는게 더 명확할 것 같긴 했는데.. 걍 짧게 ㄱㄱ 할게
| return ApiResponse.onSuccess("임시저장이 삭제되었습니다."); | ||
| } | ||
|
|
||
| private User getCurrentUser(UserDetailsImpl userDetails) { |
| @AllArgsConstructor(access = AccessLevel.PRIVATE) | ||
| @Builder(access = AccessLevel.PRIVATE) | ||
| @Table(name = "application_drafts") | ||
| public class ApplicationDraft { |
There was a problem hiding this comment.
ApplicationDraft가 step을 세분화해서 상태를 저장하고 있는데 현재 draft에서 실제 MockApply로 전환되는 흐름이 없는거 같은데 그러면 사실상 임시 수정값 저장 용도로만 쓰이는 거인듯..? draft 테이블을 두기보다 MockApply에 status enum을 두고 지원 공고 추출/지원서 생성 -> 질문 선택 -> 답변 작성 -> 완료 정도의 큰 단계만 관리하는 쪽이 더 나을듯
There was a problem hiding this comment.
처음에는 최종 제출 전까지 mockapply를 안 만드는 구조를 생각해서 임시저장 테이블을 나눌라 했는데, #43 에서 문항 선택 단계 진입 전에 mockapply를 먼저 생성하고 mockApplyId 기준으로 이어지는 구조가 됐으니 너 말대로 enum을 두고 관리하는게 좋을듯
There was a problem hiding this comment.
회의록에서도 물어볼라카는거 같으니 답변 미리 준비해놓을게
|
@shinae1023 |
우혁피티 뭔데~~ |
2 participants
✨ 어떤 이유로 PR를 하셨나요?
📋 세부 내용 - 왜 해당 PR이 필요한지 작업 내용을 자세하게 설명해주세요
📸 작업 화면 스크린샷
🚨 관련 이슈 번호 [#23 ]