연관관계가 복잡한 경우 엔티티를 삭제하는 작업이 복잡해진다.
참조무결성 제약조건 때문에 자식 엔티티를 먼저 삭제하고, 부모 엔티티를 삭제해줘야 하기 때문이다.
게다가 개인정보 보호법때문에 개인 정보는 일정 기간 보관하고 삭제해야 한다.
먼저 소프트딜리트 처리를 하더라도 나중에는 하드 딜리트를 해야하는데
이때 연관관계에 있는 자식 엔티티를 먼저 삭제해야 하기에 너무 복잡하다.
Cascade란?
유저-매칭 정보, 유저-프로필사진, 유저-프로필 차단 정보 등등
유저는 다양한 엔티티와 연관관게를 맺는다.
이 때 JAP Casacade를 쓰면 밀접한 연관관계 있는 엔티티에 대한 연쇄 작업을 자동화할 수 있다.
부모 엔티티를 지우면 자식 엔티티도 지워지게 할 수 있는 것이다.
Cascade는 왜 실무에서 잘 안쓰는걸까?
실무에서는 연관관계를 잘 안 쓰는 경우도 종종 있다고 한다. Cascade로 Delete를 쓰면 의도치 않게 자식 데이터가 삭제돼서 정합성 문제가 발생할 수 있기 때문이다.
Persist를 쓸 때도 Order 엔티티를 추가한다고 해보자. Order를 추가할 때 어떤 엔티티들이 추가되는지 추적하기가 쉽지 않다는 것도 문제다.
그러면, 언제 써야 할까?
JPA Cascade는 엔티티 간 관계가 명확할 때 사용하는 것이 좋다.
게시글-댓글처럼 부모-자식 관게가 명확하다면 사용해도 괜찮다.
하지만, 매칭-유저 2명처럼 하나의 자식에 여러 부모가 대응하면 사용할 때 예상치 못한 side effect가 발생할 수 있어 주의가 필요하다.
영한샘이 관련된 주제에 달아주신 답변이다.
"개인 소유하는 엔티티", "여러곳에서 참조한다" 이것도 중요한 개념인 것으로 보인다.
생각해보면, 매칭 데이터같은 건 비즈니스 통계적인 데이터니 유저가 탈퇴해도 삭제하지 않는 방식이어도 되지 않을까 싶다. 이건 개인정보 보호법을 다시 한번 확인하고 결정해야겠다
양방향 vs 단방향과도 관련이 있어?
UserViolationStats가 User 외래키를 갖고 있다. 단방향 연관관계다.
방향이 이렇게 돼 있으니
User를 DB에서 지울 때 UserViolationStats에 삭제가 전파되게 하지 못한다는 문제가 있었다.
User가 외래키를 갖도록 하거나 양방향으로 바꿔줘야 한다.
우선, 연관관계가 복잡하고 강하게 밀접되는 건 Cascade로 지워주고 나머지 log성 데이터들은 서비스 레이어에서 지워주는 방식을 택하기로 했다.
