프로젝트 저장 유효성 검사 완료 및 테스트 코드 일부 작성 #71
Conversation
This reverts commit 4cfe9b0.
…eek/sidepeek_backend into feat/#27-validate-project
Sehee-Lee-01
changed the title
Sehee-Lee-01
changed the base branch from
feat/#57-apply-querydsl-in-read-project
to
dev
There was a problem hiding this comment.
QueryDSL에서 만들어주는 generated 폴더는 .gitignore에 추가해도 될 것 같긴 하네용!
There was a problem hiding this comment.
엇 제가 테스트 코드 작성하면서 QClass 관련 파일들 .gitignore에 추가할게요!
| @Column(name = "owner_id", columnDefinition = "BIGINT") | ||
| private Long ownerId; | ||
| @Column(name = "owner_id", columnDefinition = "BIGINT", nullable = false) | ||
| private Long ownerId; // TODO: User로 설정하는 것이 좋을까요? 놓는다면 [accessToken id 일치 확인 + 유저 존재 확인(추가 발생)] 해야합니다! |
There was a problem hiding this comment.
전 개인적으로 저희가 ORM을 사용하고 있기 때문에 객체를 사용하는 것이 좋을 것 같다곤 생각합니당..! 객체지향 vs 효율(복잡성) 차이일 것 같긴합니당!
There was a problem hiding this comment.
저는 개인적으로 ownerId라는 컬럼이 프론트단에서 프로젝트의 유저인지 확인하는 용도로만 쓰이기 때문에 User 객체보다는 ownerId를 그대로 유지하는 것이 좋다고 생각해요..! 혹시 프로젝트 게시글 작성자에 대한 추가 정보가 요구되는 일이 있을까요?
There was a problem hiding this comment.
추가 정보를 요구하는 일은 없습니다!
생각해보니 로그인을 하면 보통 유저가 삭제된 상태는 아닐테니 우선 요 부분은 효율성을 위해서 Id로 남겨두고 나중에 필요하면 유저로 바꾸는 것으로 하겠습니당! 다들 감사합니다ㅠㅠㅠ
src/main/java/sixgaezzang/sidepeek/projects/util/converter/YearMonthDateAttributeConverter.java
Show resolved
Hide resolved
| public static void validateFellowMemberUser(User user) { | ||
| Assert.notNull(user, "회원인 멤버의 유저 Id를 입력해주세요."); | ||
| } |
There was a problem hiding this comment.
회원인 경우 닉네임(비회원인 경우 받는 닉네임)도 함께 요청이 오면 그 닉네임은 그냥 무시되는 걸까요?
There was a problem hiding this comment.
넵 맞습니다! 혹시 저희 갑자기 어렴풋이 기억나는데 회원 멤버도 이름 커스텀으로 넣을 수 있게 하도록 했나요!
There was a problem hiding this comment.
엇 제가 테스트 코드 작성하면서 QClass 관련 파일들 .gitignore에 추가할게요!
| @Column(name = "owner_id", columnDefinition = "BIGINT") | ||
| private Long ownerId; | ||
| @Column(name = "owner_id", columnDefinition = "BIGINT", nullable = false) | ||
| private Long ownerId; // TODO: User로 설정하는 것이 좋을까요? 놓는다면 [accessToken id 일치 확인 + 유저 존재 확인(추가 발생)] 해야합니다! |
There was a problem hiding this comment.
저는 개인적으로 ownerId라는 컬럼이 프론트단에서 프로젝트의 유저인지 확인하는 용도로만 쓰이기 때문에 User 객체보다는 ownerId를 그대로 유지하는 것이 좋다고 생각해요..! 혹시 프로젝트 게시글 작성자에 대한 추가 정보가 요구되는 일이 있을까요?
| public static MemberSummary from(Member member) { | ||
| User user = member.getUser(); | ||
| UserSummary userSummary = (user == null) | ||
| ? UserSummary.from(member.getNickname()) | ||
| : UserSummary.from(user); | ||
| return MemberSummary.from(member, userSummary); | ||
| } | ||
|
|
||
| public static MemberSummary from(Member member, UserSummary userSummary) { | ||
| return MemberSummary.builder() | ||
| .id(member.getId()) | ||
| .role(member.getRole()) | ||
| .userSummary(userSummary) | ||
| .build(); | ||
| } | ||
|
|
There was a problem hiding this comment.
from 메서드가 QueryDSL 적용으로 필요없어서.. 관련 dev 브랜치 pull 받아와주실 수 있으신가요?
There was a problem hiding this comment.
pull 했는데 프로젝트 저장 후에 저장된 맴버 객체 내려줄 때 필요해서 남겨두었습니다! 추후 리팩토링 때 반영해보겠습니다!
🎫 관련 이슈
Fixes #40
✅ 구현 내용
유효성 검사
테스트 코드
기타 변경사항
추가로 해야하는 것
faker.internet().username();해결: 가끔 테스트 코드 돌리면 희박하게 실패할 때가 있는데 값이 닉네임 최대 길이를 넘을 때가 있더라구요!💬 코멘트
feat/#57-apply-querydsl-in-read-project브랜치를 머지하여 올립니다!feat/#57-apply-querydsl-in-read-project브랜치로 머지하게 해놨지만 승인이 되면 dev로 바꾸고 확인한 후 머지할 예정입니다!