Conversation
- 크루 Fixture 추가 및 기존 테스트 리팩토링
- application.in 패키지 변경
mandykr
changed the title
| return crewQueryRepository.findAllContainsMember(pageable, demand.getMemberId()); | ||
| } | ||
|
|
||
| private static void throwIfNotLeader(Crew crew, UUID memberId, BusinessException exception) { |
There was a problem hiding this comment.
해당 코드가 서비스 로직에 있는것이 맞는걸까요??
There was a problem hiding this comment.
조회를 위한 검증이라 entity로 옮기긴 애매할것 같아요. 생각나는 좋은 방법 있으신가요?
There was a problem hiding this comment.
엔티티에 있으면 좋을 것 같다고 생각하긴 했는데.. 말씀주신대로 조회를 위한 검증이라 서비스에 있는것이 좋을 것 같습니다.
추가로 Crew 조회 시, Crew Member와 같이 Fetch 조인하면, Query를 1번만 호출할 거 같네요!
| return ApproveDemandResponse.of(demand); | ||
| } | ||
|
|
||
| private Demand findDemandByIdAndCrewId(UUID demandId, UUID crewId) { |
There was a problem hiding this comment.
CrewId까지 Join한 이유가 궁금합니다~
추가로 CrewId로 조인한 것이면, Crew를 조회할 필요가 있을지도 궁금합니다!
There was a problem hiding this comment.
crew는 approveDemand를 호출하기 위해 필요하고 demand를 조회할때 crewId를 파라미터로 사용한 이유는 크루에 해당하는 demand를 안전하게 조회하기 위함입니다. 또한 demand에서 crewId는 외래키이기 때문에 조인은 되지 않습니다.
There was a problem hiding this comment.
2테이블을 Join 조회 한 후, Demand에 대한 정보만 조회한다면, Query 1번 만으로 가능할 거 같아서요!
현재는 Crew 조회(DB 조회) > Crew, DemandId를 통한 Demand 엔티티 조회(DB조회)
-> Demand 조회 시, Crew & Demand 테이블을 조인해서 조회 (DB 조회)
There was a problem hiding this comment.
이해했습니다. crew를 조회할때 demand도 함께 가져오는게 좋겠네요.
| import java.util.UUID; | ||
|
|
||
| public interface CrewDemandRepository extends JpaRepository<Demand, UUID> { | ||
| Page<Demand> findByCrewIdAndStatus(UUID crewId, DemandStatus pending, Pageable pageRequest); |
There was a problem hiding this comment.
정수님이 공유주신 무한 스크롤 사용해야 될 것 같아요
There was a problem hiding this comment.
사용자(크루 리더) 입장에서 많은 수의 참여 요청 목록을 수시로 조회할때 페이지 번호를 선택해서 필요한 위치로 이동하는게 더 편할것 같다고 생각했어요
| @Override | ||
| public String convertToDatabaseColumn(RecruitmentStatus status) { | ||
| if(status == null){ | ||
| throw new NullPointerException("crewMemberRole을 DB 칼럼으로 변경하는 과정에서 null이 포함되었습니다."); |
| private Optional<Demand> findReDemand(UUID memberId) { | ||
| return demands.stream() | ||
| .filter(d -> isReDemand(memberId, d)) | ||
| .findFirst(); |
There was a problem hiding this comment.
any() 메서드가 따로 없나요? any 메서드가 있다면 해당 메서드를 사용하는게 의미상 더 명확해 보입니다.!
|
|
||
| private static void throwIfNotPending(Demand find) { | ||
| if (find.isNotPending()) { | ||
| throw new IllegalStateException("참여 요청의 상태가 대기중이 아닙니다."); |
There was a problem hiding this comment.
커스텀 예외를 만드는게 적절해 보이네요
| return ApiResponse.created(demand); | ||
| } | ||
|
|
||
| @PutMapping("/{crewId}/demands/{demandId}/cancel") |
There was a problem hiding this comment.
Demand 별도로 Controller 분리하는것도 좋은 방안일 것 같습니다.!
| jpa: | ||
| hibernate: | ||
| ddl-auto: create-drop | ||
| ddl-auto: create |
There was a problem hiding this comment.
db 데이터 확인을 하는 과정에서 커밋에 포함되었네요. 로컬이나 테스트 환경 설정 파일은 자유롭게 수정해서 사용하시면 될것같아요
- crew 조회 -> demand 조회로 분리된 로직을 crew와 demand를 조인해서 조회하도록 변경
3 participants
🔍 PR 타입 선택
아래 타입 중 해당하는 하나를 선택해 주세요. 반드시 하나만 선택해 주세요.
feat: 새로운 기능 추가📝 변경 사항 요약
변경 사항을 간단히 요약해 주세요.
🛠 관련 이슈
Resolves: #3
추가 설명 (선택 사항)