-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[이성 목록 조회] 이성 목록을 조건에 따라 조회할 수 있다(#43) #83
Conversation
보낼 화살 수를 담은 요청 DTO 정의
- 화살 송수신 내역 repository 정의 - 보낸 사용자, 받은 사용자를 통해 내역 존재 여부를 확인하는 로직 구현
보낸 사용자, 받은 사용자를 통해 송수신 내역 존재 여부를 확인하는 로직 구현
다음 상황들에 대한 예외 enum을 정의하였다. - 자기 자신에게 화살을 보내는 경우 - 이미 화살을 보낸 사용자인 경우 - 가진 화살 수가 부족해 화살을 보낼 수 없는 경우
감소하려는 화살 수가 사용자가 보유한 화살 수보다 클 경우 예외 발생
화살 보내기 비즈니스 로직은 다음 과정을 거친다. 1. 자기 자신에게 화살을 보내는 상황 검증 2. 화살을 보낸 사용자에게 또 보내는 상황 검증 3. 화살 내역 저장 4. 보내는 사용자 화살 감소, 화살이 부족할 경우 예외 발생(과정 3 롤백) 5. 받는 사용자 화살 증가
- query, command를 service, repository를 중개하는 별도의 계층을 통해 구분 - 이에 따라 기존 command repository 삭제 - 기존 command repository 사용 위치, 화살 command로 대체
# Conflicts: # be/src/main/java/yeonba/be/arrow/repository/ArrowCommand.java # be/src/main/java/yeonba/be/arrow/service/ArrowService.java # be/src/main/java/yeonba/be/exception/CommonException.java # be/src/main/java/yeonba/be/user/entity/User.java
서로 대치되는 작업을 수행하는 상황을 잘 표현할 수 있도록 메서드 이름 수정
- 이미 화살을 보낸 사용자 예외 - 화살이 부족하여 화살을 보낼 수 없는 예외
가독성 향상을 위해 간단한 이름을 수정
dev 브랜치 작업 내역 병합에 따른 코드 배치 수정
좀 더 명확하게 대치되는 의미를 나타낼 수 있도록 화살을 받는 사용자 ID 파라미터 이름을 receiverId로 수정
- 이름 칼럼 추가 - 테스트시 활용 가능한 생성자 추가
- 래퍼 타입 필드들 기본 타입으로 변경 - 프로필 사진 URL 리스트 필드 추가 - 사용자가 가진 총 화살 수 필드 추가 - 음주 성향, 흡연 성향 필드 추가 - 코드 정렬
- 레퍼런스 타입 not null 필드들, Column 어노테이션 사용 명시 - salt 필드 추가 - 생성 일시, 최종 수정 일시 필드 추가 - JpaAuditing 활용, 생성/최종 수정 일시 필드들 엔티티 저장시 자동 설정 - 새로운 생성자 구성
프로필을 조회하는 사용자 ID의 경우 상대방이 화살을 보넀던 사용자인지 확인하기 위해 파라미터로 받는다.
- 요구사항 변경에 따라 음주 성향, 흡연 성향 필드 삭제 - 성별 정보 제공 메서드 추가
- 음주 성향, 흡연 성향 필드 삭제 - 성별 필드 추가
- 음주 성향, 흡연 성향 필드 삭제 - 생성자 성별 필드 설정 로직 수정 - 코드 정렬
- 음주 성향, 흡연 성향 삭제 - 성별 정보 응답에 포함토록 수정 - 코드 정렬
- 메서드명 수정 - 불필요하게 상수로 정의된 값들 지역 변수로 변경
- 이성 목록 조회 API 메서드명 및 로직 수정 - 다른 사용자 프로필 조회 메서드명 수정
- 즐겨찾는 이성 조회 기준, FAVORITES로 변경 - 페이지 번호 nullable하게 변경
- 응답 DTO, 즐겨찾기 존재 여부 필드명 변경에 따른 조회 로직 수정 - 추천 이성 조회 로직, 사용자 성별 파라미터 추가 - 추천일 파라미터명 변경
- 이성 목록 조회시 조회하는 사용자 존재 여부 검증 추가 - 추천 이성 조회시 고정 2 사이즈의 첫 페이지를 조회하도록 수정 - 추천 이성 조회시 사용자 성별 전달하도록 수정
- 차단한 사용자 제외 조건 추가 - 같은 날 추천/검색된 사용자 제외 조건 메서드명 수정
- 기존 이성 목록 조회 API에서 추천 이성 목록을 함께 제공할 경우 로직이 부자연스럽게 구성 - 추천 이성 조회 API를 별도로 분리하여 코드 개선
조회 쿼리와 카운팅 쿼리에서 중복하여 사용되는 조회 조건, 별도 메서드 분리하여 코드 중복 제거
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
시연이 급해 approve 하겠습니다. 이후 버그 발생 시 수정부탁드립니다.
public class UserSearchLog { | ||
@Id | ||
@GeneratedValue(strategy = GenerationType.IDENTITY) | ||
private Long id; | ||
|
||
@ManyToOne | ||
@JoinColumn(name = "user_id") | ||
private User user; | ||
|
||
@ManyToOne | ||
@JoinColumn(name = "searched_user_id") | ||
private User searchedUser; | ||
|
||
@CreatedDate | ||
private LocalDateTime createdAt; | ||
|
||
public UserSearchLog(User user, User searchedUser) { | ||
|
||
this.user = user; | ||
this.searchedUser = searchedUser; | ||
} | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
public class UserSearchLog { | |
@Id | |
@GeneratedValue(strategy = GenerationType.IDENTITY) | |
private Long id; | |
@ManyToOne | |
@JoinColumn(name = "user_id") | |
private User user; | |
@ManyToOne | |
@JoinColumn(name = "searched_user_id") | |
private User searchedUser; | |
@CreatedDate | |
private LocalDateTime createdAt; | |
public UserSearchLog(User user, User searchedUser) { | |
this.user = user; | |
this.searchedUser = searchedUser; | |
} | |
} | |
public class UserSearchLog { | |
@Id | |
@GeneratedValue(strategy = GenerationType.IDENTITY) | |
private Long id; | |
@ManyToOne | |
@JoinColumn(name = "user_id") | |
private User user; | |
@ManyToOne | |
@JoinColumn(name = "searched_user_id") | |
private User searchedUser; | |
@CreatedDate | |
private LocalDateTime createdAt; | |
public UserSearchLog(User user, User searchedUser) { | |
this.user = user; | |
this.searchedUser = searchedUser; | |
} | |
} | |
boolean userGender, | ||
PageRequest pageRequest, | ||
LocalDate recommendDay); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
} | |
} | |
JOIN_REWARD_ARROWS, | ||
joinRewardArrows, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
왜 바꾸신 건가요?
작업 대상
📄 작업 내용
🙋🏻 주의 사항
응답 DTO 조회 쿼리, 별도 메서드 분리 -
selectUserQueryResponse()
공통적으로 사용되는
BooleanExpression
별도 메서드 분리exists()
,notExists()
를 사용하는 경우로 나뉨BooleanExpression
이 아닌JPAQuery<Integer>
를 반환하는 형태로 분리, 경우에 따라 달리 사용이성 목록 조회시 공통적으로 제외되는 사용자
즐겨찾기한 이성, 화살을 보내거나 받은 이성
추천 이성 조회
앞서 언급했던 제외 조건에 추천 이성 조회시 충족해야 하는 조건은 다음과 같다.
📎 관련 이슈
user_id
,favorite_user_id
와 같이 테이블에서 고유 조합인 경우 고유 인덱스를 형성하여 조회 성능을 개선할수 있을 것이라 판단
BooleanExpression
,JPAQuery<?>
를 별도 메서드 분리한 경우 메서드 네이밍을 어떤 식으로 하면 좋을 지논의하면 좋을 것 같습니다.
레퍼런스