[BilRyoZo] JPA Soft Delete 구현, @SQLDelete, @Where, JPQL

✨ 개요

도서 엔티티의 soft delete 구현 방식을 고민하던 중, @SQLDelete와 엔티티 내에 메소드를 구현하는 방식을 두고 비교하였다.

도서 엔티티에는 삭제 시각을 저장하는 deletedAt, 삭제한 관리자 id를 저장하는 deletedBy 필드가 있는 상황이었다.

지난 프로젝트에서 사용했던 @SQLDelete를 사용하려 했으나, 지난번과 다르게 이번에는 deletedBy라는 필드가 있었기 때문에 다른 방식을 찾아보게 되었다.

 

 

 

✨ @SQLDelete vs 엔티티 내부 메소드

@SQLDelete를 사용하는 경우에는 

쿼리가 간소화되며 JPA에서 제공하는 자동화된 방식으로 엔티티의 상태 변경을 자동으로 처리할 수 있다.

하지만 @SQLDelete는 update 쿼리만 지원하므로 추가적인 로직을 구현하기가 어렵고 복잡한 로직을 처리하기 어렵다.

 

엔티티 내에 메소드를 구현하는 경우에는

삭제 로직을 직접 구현할 수 있어 유연성이 좋고, 특정 비즈니스 로직을 추가할 수 있다.

하지만 엔티티에 코드를 추가하면 복잡해진다는 단점이 있다.

 

현재는 복잡한 로직이 필요하지 않지만 현재 rent 도메인이 구현이 안되어있는 상황이고

추후 유지보수를 고려해 유연성이 높은 엔티티 내에 삭제 로직을 구현하는 방식을 채택하였다.

 

 

 

✨ @Where vs JPQL

그리고 soft delete에 대해 찾아보며 @Where을 실무에서는 잘 사용하지 않는다는 사실을 알았다.

삭제된 데이터를 경우에 따라 조회해야 할 필요가 있기 때문에 대신 JPQL을 사용한다고한다.

참고 : https://www.inflearn.com/community/questions/304378/baseentity%EC%99%80-softdelete-%EC%A7%88%EB%AC%B8

지난 프로젝트에서도 soft delete를 구현 시 같은 이유로 JPQL을 사용했다.

현업에서도 JPQL을 쓴다고 하고, 연관관계 때문에 이번에도 JPQL을 사용하기로 결정했다.

 

 

 

✨ 결론

soft delete를 구현하는 방식으로 유연성과 유지보수성이 좋은 엔티티 내에 삭제 로직을 구현하는 방식을 채택하였고

데이터 조회 시 삭제 데이터를 제외하는 로직은 연관관계 JPQL로 구현할 것이다.

rent 엔티티와 book 엔티티가 연관관계를 맺고 있기 때문에 @Where을 사용하면 rent 데이터 조회 시 문제가 발생할 것으로 예상하여 JPQL을 사용할 것이다.