일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | |||||
3 | 4 | 5 | 6 | 7 | 8 | 9 |
10 | 11 | 12 | 13 | 14 | 15 | 16 |
17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 |
Tags
- mock
- 레벨2
- JUnit5
- 미션
- Docker
- Spring Batch
- CircuitBreaker
- 프로그래머스
- 자바
- REDIS
- JPA
- Paging
- 트랜잭션
- 스프링 부트
- 우아한테크코스
- 의존성
- 서블릿
- MSA
- 우테코
- 세션
- 코드리뷰
- HTTP
- yml
- AWS
- Level2
- 우아한세미나
- 프리코스
- 스프링부트
- AOP
- 백준
Archives
- Today
- Total
늘
[JPA] cascade = CascadeType.REMOVE와 @OnDelete(action = OnDeleteAction.CASCADE)의 차이 본문
우아한테크코스 4기/프로젝트
[JPA] cascade = CascadeType.REMOVE와 @OnDelete(action = OnDeleteAction.CASCADE)의 차이
giron 2022. 7. 24. 01:13728x90
가장 큰 차이로는, JPA에 의해 처리되느냐, DDL에 의해 cascade가 걸린 테이블이 생겨 DB단에서 처리되느냐 이다.
전자의 방식을 취할 경우, JPA에 의해 외래 키를 찾아가며 참조하는 레코드를 제거해주게 됩니다.
따라서, JPA 상에서는 참조하고 있는 레코드의 개수만큼 delete 쿼리가 생성됩니다.
후자의 방식을 취할 경우, 데이터베이스 자체에서 on delete cascade 제약조건이 걸리게 됩니다. 이를 통해 참조하는 레코드가 모두 제거되는 것입니다.
cascade = CASCADE.REMOVE
- JPA 레벨에서 작동한다.
- 외래 키를 찾아 참조하는 레코드를 제거해준다.
- 참조하고 있는 레코드 수 만큼 delete쿼리가 나간다.
- 부모 테이블의 자식 컬럼에 걸어여하므로(일반적으로 @OneToMany(cascade= CASCADE.REMOVE) 양방향 매핑이 아닌 이상 적용하기 어렵다.
@OnDelete
- database에서 직접 처리한다.
- DDL 생성시 cascade 제약 조건이 생성 됨.
- 데이터베이스 자체에서 on delete cascade 제약조건이 걸리게 된다.
- 따라서 삭제 쿼리가 나가지 않는다!
- 단방향 매핑에서도 적용이 가능하다. - 자식 테이블의 부모 컬럼에 적용하면 된다.
대충 @OnDelete가 좋아보이는데,
@OnDelete 방식으로 테이블을 생성하여 데이터베이스를 직접 다루다보면, on delete cascade에 의해 어떠한 레코드의 참조 레코드까지 연쇄적으로 삭제해버리는 실수 할 여지가 있는 반면,
라고 한다. 해당 부분은 이해가 잘 안가서 다음에 봐야할 것 같다.
728x90
'우아한테크코스 4기 > 프로젝트' 카테고리의 다른 글
토큰과 세션(1) - 토큰과 세션 그리고 쿠키에 대해서 (0) | 2022.08.23 |
---|---|
소나큐브 적용기 (0) | 2022.08.15 |
[테스트 자동화 1] service 테스트에서 롤백 목적으로 @Transactional 사용을 지양하자! 그런데 EntityManager를 활용해서 truncate를 시켜보자 (0) | 2022.07.29 |
HTTPS 적용하기 (0) | 2022.07.28 |
커서 기반 페이지네이션 적용기 (0) | 2022.07.27 |
Comments