다음과 같이 두 User 가 있다고 할 때
User “페이버222”를 User “페이버111”의 Friend로 추가 (UserFriend)
하지만 User “페이버222”를 삭제해도 User “페이버111”의 friendList에서 사라지지 않는 이슈가 있었다.
다른 매핑된 도메인 사이에서는 Cascade가 잘 일어났지만 User와 Friend 도메인 사이에서는 그렇지 않았다. 이는 어플의 기획에 의한 Friend의 특수함 때문이다.
- Friend는 boolean 필드 isUser 에 의해서
사용자가 다른 사용자를 친구로 추가한 FriendUser인지 직접 생성한 friend인지 구분된다. - User A가 User B를 친구로 추가해 자신의 friendList에 추가해도
User B의 DB에는 아무 변화가 없다. (추후 변경 될수도)
이 두 가지 조건 때문에 User B를 삭제해도 User A의 friendList에 변화가 없었던 것이다. (User A가 User B를 친구로 추가할 때 User B의 friendList에 User A가 추가되지 않기 때문)
친구를 추가할 경우 신청 알람이 가게 되고 신청을 받은 사람이 수락하면 서로가 서로의 friendList에 추가되는 방식으로 하면 좋겠지만 어플의 주 기능이 SNS가 아니다보니 이렇게 기획된 것 같다.
어떻게 해결하면 좋을까 고민하던 중 UserService에 friendRepository를 의존성주입받아 해결할 수 있지 않을까 생각했다.
DB상의 Friend들 중 삭제될 User의 userNo를 갖고있는 Friend(FriendUser)들을 삭제하는 방법으로 해결했다.
수정 후 “페이버222”를 삭제하고 나니 “페이버111”의 friendList에서도 삭제되었다.
아직 해결해야 할 큰 과제가 남아있는데, Friend or FriendUser를 Delete하더라도 관련된 Reminder는 삭제하고 Gift는 남겨둬야 한다고 한다. 현재는 동일하게 전부 Cascade 되는데....
Friend를 Delete 하기 전에 관련된 선물의 friend 필드값을 null로 바꾸어 해결할 수 있지 않을까 했지만 당연히 해당 Gift를 읽는 과정에서 NPE가 발생한다. 조금 더 곰곰이 생각하고 해결해보자..
'Project > Favor 프로젝트' 카테고리의 다른 글
년/월 필터 Validation, 회원가입시 자동 이름과 랜덤 ID 생성 (0) | 2023.04.20 |
---|---|
프로젝트 날짜 필터 구현 (0) | 2023.04.19 |
API 응답 ResponseDto 에서 ResponseEntity로 바꾸기 (0) | 2023.03.22 |
import가 제대로 되지 않는 오류 (0) | 2023.03.12 |
회원가입 처리 이슈 (API 분리) (0) | 2023.03.07 |