Feature/#8 프로젝트 등록현황 조회 api 구현#75
Conversation
There was a problem hiding this comment.
Pull request overview
This PR implements an API endpoint to retrieve project submission status for teams in a contest. The implementation addresses previous feedback from PR #74 by properly separating repository-layer DTOs from application-layer DTOs.
Changes:
- Added project submission status query API endpoint (
GET /contests/{contestId}/submissions) with admin-only access - Introduced repository DTO pattern with
TeamSubmissionResultin thedaopackage for clean layer separation - Added
submit()method to Team entity for test fixture support
Reviewed changes
Copilot reviewed 10 out of 10 changed files in this pull request and generated no comments.
Show a summary per file
| File | Description |
|---|---|
| TeamRepository.java | Added JPQL query with LEFT JOIN to fetch team submission data including optional track information |
| TeamSubmissionResult.java | Repository-layer DTO for JPQL projection results |
| ContestSubmissionResponse.java | API response DTO with static factory method to convert from repository DTO |
| TeamQueryService.java | Service method that validates contest existence and transforms repository results to response DTOs |
| ContestController.java | Admin-restricted endpoint to retrieve team submission status |
| Team.java | Added submit() method to support test fixtures |
| TeamQueryServiceTest.java | Integration tests covering success, empty list, and exception cases |
| ContestApiDocsTest.java | API documentation tests with success and failure scenarios |
| TeamFixture.java | Test fixture for creating submitted teams |
| contest.adoc | API documentation for the new endpoint |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
JJimini
left a comment
JJimini
left a comment
There was a problem hiding this comment.
고생하셨습니다~! 간단한 코멘트 남겨두었으니 확인 부탁드릴게요!
| @Secured("ROLE_관리자") | ||
| @GetMapping("/{contestId}/submissions") | ||
| public ResponseEntity<List<ContestSubmissionResponse>> getTeamSubmissions(@PathVariable final Long contestId) { | ||
| final List<ContestSubmissionResponse> responses = teamQueryService.getTeamSubmissions(contestId); | ||
| return ResponseEntity.ok(responses); | ||
| } |
There was a problem hiding this comment.
이 부분 회의 때 언급하려고 했었는데, getMemberVoteCount와 같이 Controller는 Contest, Service는 TeamQuery에 적힌 부분이 어색해 보여요!
이전의 저의 리뷰의 의도는 Controller와 Service 모두 contest로 옮기자라는 뜻이었는데 제가 체크를 다 못하고 approve가 된 것 같습니다..!
그래서 현재 ContestController와 TeamQueryService가 연결돼 있는 것 같습니다. 모듈 간 경계가 모호해진 것 같아요!
저는 MVP때처럼 진행중인 팀의 현황만 조회하는 것이 아닌, 대회별 팀 현황 조회가 가능한 상황이니 의미를 살려 대회의 (팀 별)프로젝트 제출 현황 조회라는 의미로 contest모듈에 위치하는 것은 어떨까 생각합니다
| @Query("SELECT new com.opus.opus.modules.team.domain.dao.TeamSubmissionResult(" + | ||
| "team.id, team.teamName, team.projectName, track.trackName, team.isSubmitted) " + | ||
| "FROM Team team " + | ||
| "LEFT JOIN ContestTrack track ON team.trackId = track.id " + | ||
| "WHERE team.contestId = :contestId " + | ||
| "ORDER BY team.id ASC") | ||
| List<TeamSubmissionResult> findTeamSubmissionsByContestId(final Long contestId); |
There was a problem hiding this comment.
대회 투표 현황 조회와 비슷하게 구현 해주신 것 같아요!
저는 투표 현황 조회에서 DAO(조회 결과)를 반환하는 이유는 DB가 계산한 조회 결과(count)를 제공하기 때문이라고 생각했습니다.
해당 API는 단순 조회처럼 보이는데 DAO를 반환하는 이유가 있을까요?
다른 조회 API들과 구현 방식이 상이하다면, DAO의 반환 기준을 명확히 정의하는 것이 좋을 것 같습니다!
2 participants
🔥 연관된 이슈
close: #8
📜 작업 내용
1. 프로젝트 등록 현황 조회 API를 개발하였습니다.
2. 이전 PR(Feature/#9 10 대회 투표 현황 조회 api 개발) 리뷰를 반영하였습니다.
TeamSubmissionResult)를 dao 패키지에 분리하여 계층 간 의존을 방지하였습니다.💬 리뷰 요구사항
TeamSubmissionResult의 필드가ContestSubmissionResponse와 1:1 대응됩니다. Repository용 dto를 생성함에 따라 계층 분리를 위해 별도로 두었는데, 이런 식으로 분리하는 게 적절한지 의견 부탁드립니다-!✨ 기타