[YS-203] hotfix: 공고 등록 API 비대면 옵션 선택 시 필드 처리 개선 #56
Conversation
- 공고 등록 시, 비대면 매칭타입일 경우, `Region` `Area` `univName` nullable 처리 - 공고 등록 유즈케이스 검증 로직 함수로 모듈화하여 분리
- nullable 조건 추가로 인한 자잘한 리팩터링 - 커스텀 예외 로직 반환하도록 수정
Walkthrough이 풀 리퀘스트는 실험 게시물 관련 여러 클래스에서 Changes
Sequence DiagramsequenceDiagram
participant User
participant CreateExperimentPostUseCase
participant Validator
User->>CreateExperimentPostUseCase: 실험 게시물 생성 요청
CreateExperimentPostUseCase->>Validator: 입력 데이터 검증
Validator-->>CreateExperimentPostUseCase: 검증 결과
alt 검증 실패
Validator->>CreateExperimentPostUseCase: 예외 발생
else 검증 성공
CreateExperimentPostUseCase->>CreateExperimentPostUseCase: 게시물 생성 로직 수행
end
Possibly related PRs
Suggested labels
Suggested reviewers
Poem
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (2)
src/main/kotlin/com/dobby/backend/domain/model/experiment/ExperimentPost.kt (1)
26-28: 도메인 객체 내 null 허용 필드 도입에 따른 후속 처리가 필요한지 확인
univName,region,area가 null일 수 있도록 바뀌어, save/update 로직에서 null이 들어올 때의 예외 처리나 상태 변화 로직(특히 ONLINE인 경우)이 적절히 대응되고 있는지 다시 한 번 점검해 주세요.src/main/kotlin/com/dobby/backend/infrastructure/database/entity/experiment/ExperimentPostEntity.kt (1)
64-65: 컬럼 Nullable 처리 변경 확인
univName,region,area필드를 nullable로 변경하여 ONLINE 매칭 타입 시 null을 허용하도록 조정했습니다. 문제없이 반영된 것으로 보이며, 비대면 옵션 대응에 적절합니다.
또한 여러var속성들을 다수 보유한 엔티티이므로, 낙관적 락(Optimistic Locking)을 위한@Version필드 추가를 고려해보시면 동시성 문제 예방에 유익할 수 있습니다.Also applies to: 68-69, 72-73
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (7)
src/main/kotlin/com/dobby/backend/application/usecase/experiment/CreateExperimentPostUseCase.kt(3 hunks)src/main/kotlin/com/dobby/backend/application/usecase/experiment/GetExperimentPostsUseCase.kt(1 hunks)src/main/kotlin/com/dobby/backend/domain/exception/ErrorCode.kt(1 hunks)src/main/kotlin/com/dobby/backend/domain/model/experiment/ExperimentPost.kt(1 hunks)src/main/kotlin/com/dobby/backend/infrastructure/database/entity/experiment/ExperimentPostEntity.kt(1 hunks)src/main/kotlin/com/dobby/backend/presentation/api/dto/request/experiment/CreateExperimentPostRequest.kt(1 hunks)src/main/kotlin/com/dobby/backend/presentation/api/dto/response/experiment/ExperimentPostDetailResponse.kt(1 hunks)
🧰 Additional context used
📓 Learnings (1)
src/main/kotlin/com/dobby/backend/infrastructure/database/entity/experiment/ExperimentPostEntity.kt (1)
Learnt from: chock-cho
PR: YAPP-Github/25th-Web-Team-2-BE#51
File: src/main/kotlin/com/dobby/backend/infrastructure/database/entity/experiment/ExperimentPostEntity.kt:0-0
Timestamp: 2025-01-23T01:55:28.827Z
Learning: In JPA entities where multiple properties are mutable (var), optimistic locking using @Version annotation is recommended to prevent concurrent modification issues, especially for important business entities like experiment posts. This is preferred over pessimistic locking when concurrent updates are infrequent, as it provides better performance with less overhead.
🪛 detekt (1.23.7)
src/main/kotlin/com/dobby/backend/application/usecase/experiment/CreateExperimentPostUseCase.kt
[warning] 190-191: This else block is empty and can be removed.
(detekt.empty-blocks.EmptyElseBlock)
⏰ Context from checks skipped due to timeout of 90000ms (1)
- GitHub Check: build
🔇 Additional comments (10)
src/main/kotlin/com/dobby/backend/presentation/api/dto/request/experiment/CreateExperimentPostRequest.kt (1)
22-24: 비대면(matchType=ONLINE) 상태와 필드의 null 처리 관련 검증 확인 필요
이제univName,region,area가 모두 nullable로 바뀌었으므로, 비대면(ONLINE)일 때 이 필드들이 실제로 null인지 유효성 검증이 잘 동작하는지 확인이 필요합니다.src/main/kotlin/com/dobby/backend/application/usecase/experiment/GetExperimentPostsUseCase.kt (1)
50-50: 비대면 여부에 따라univName이 null로 처리되는 로직의 일관성 검증
univName이 nullable로 변경됨에 따라, 안전한 null 처리가 필요한 부분(예: 화면에 노출하는 부분 혹은 로깅 등)을 한 번 더 점검하면 좋겠습니다.src/main/kotlin/com/dobby/backend/presentation/api/dto/response/experiment/ExperimentPostDetailResponse.kt (1)
91-97: 주소 정보에서도 null 허용을 반영한 후, null 처리 흐름 최종 점검
univName,region,area모두 null 허용으로 변경되어 UI나 API 응답에 빈 문자열 대신 null이 내려갈 가능성이 있습니다.
기존 클라이언트 쪽에서 null 처리가 어떻게 진행되는지 최종 확인이 필요합니다.src/main/kotlin/com/dobby/backend/domain/exception/ErrorCode.kt (1)
92-92: 에러 코드 추가 적용 확인
이 에러 코드는matchType이 ONLINE일 때univName,region,area값이 null이 아니면 예외로 처리하는 로직에 적합하며, 기존 요구사항과 일치합니다. 동일 코드(EP008) 재사용 시 충돌 가능성을 점검해보시길 권장합니다.src/main/kotlin/com/dobby/backend/application/usecase/experiment/CreateExperimentPostUseCase.kt (6)
41-43: 필드를 Nullable로 변경
univName,region,area필드를 nullable로 변경하여 ONLINE 매칭 시 null 값을 허용하도록 한 점이 이번 PR 요구사항에 부합합니다.
89-89: 유효성 검사 호출 추가
execute내에서validate함수를 호출하여 입력값에 대한 검증을 수행하는 흐름이 명확해졌습니다.
178-182: 검증 로직 분리로 가독성 개선
validate메서드를 별도 생성하여 유효성 검사 단계를 모듈화한 점이 유지보수에 유리합니다.
184-187: 연구자 권한 확인 로직
validateMemberRole에서 연구자가 아닐 경우 예외를 던지도록 구현되어 있으며, 역할 기반 접근 제어 방식에 부합합니다.
189-192: 이미지 개수 제한 검사
이미지 리스트가 3장을 초과하면 예외를 던지는 로직이 명확하고 간결합니다. 불필요한 else 블록이 없어도 문제 없습니다.🧰 Tools
🪛 detekt (1.23.7)
[warning] 190-191: This else block is empty and can be removed.
(detekt.empty-blocks.EmptyElseBlock)
194-200: 비대면 옵션 필드 검증
matchType이 ONLINE일 때univName,region,area필드가 null이 아니면 예외를 던지도록 한 로직이 이번 PR의 요구사항과 완전히 일치합니다.
* refact: add nullable fields for `Online` MatchType - 공고 등록 시, 비대면 매칭타입일 경우, `Region` `Area` `univName` nullable 처리 - 공고 등록 유즈케이스 검증 로직 함수로 모듈화하여 분리 * fix: fix another logic related to non-null constraints - nullable 조건 추가로 인한 자잘한 리팩터링 - 커스텀 예외 로직 반환하도록 수정
💡 작업 내용
matchType을 Online(비대면)으로 선택했을 때,univName,region,area를 null로 주어야한다는 검증로직을 추가했습니다.matchType= 비대면일 시- case 1) 200 OK -
univNameregionarea필드 값 전부 null이어야 함- case 2) 400 Bad Request -
univNameregionarea필드 값 중 어느 1개도 null이 아닐경우✅ 셀프 체크리스트
🙋🏻 확인해주세요
🔗 Jira 티켓
https://yappsocks.atlassian.net/browse/YS-203
Summary by CodeRabbit
새로운 기능
버그 수정
기타 변경사항