JPA는 데이터베이스에 FK 정의가 아예 없으면 애플리케이션 레벨 cascade도 작동하지 않는다는 뜻은?

 

 

JPA의 cascade = CascadeType.*는 **“객체 그래프를 메모리에서 어떻게 전이할 것인가”**를 JPA 구현체에게 알려주는 애플리케이션-레벨 설정입니다.
반면에 @JoinColumn(foreignKey = …) 로 테이블에 DDL 생성 시 데이터베이스 FK 제약을 만들지 말지를 결정합니다.

따라서

“DB에 FK 정의가 아예 없으면 애플리케이션 레벨 cascade도 작동하지 않는다”

는 말은 사실이 아닙니다.
정확히 풀어 쓰면 다음과 같습니다.

---

1. JPA cascade는 DB FK 유무와 논리적으로 독립이다

---

• cascade = CascadeType.PERSIST / MERGE / REMOVE / ALL
  → 영속성 컨텍스트(=메모리) 안에서 엔티티 상태 변화를 자식에게 복제하는 기능.
• 이 동작은 EntityManager#persist(), #merge(), #remove() 호출 시에만 일어나고,
  DB의 FK 존재 여부와는 무관하다.

예시

java

 

Parent p = new Parent();
Child  c = new Child();
p.getChildren().add(c);   // 연관 설정

em.persist(p);            // CASCADE=PERSIST 이면
                          // DB에 FK가 없어도 Child INSERT가 같이 나간다.

---

1. DB에 FK가 없어도 cascade가 잘 작동한다

---

• Hibernate, EclipseLink 모두 FK 제약이 없어도
  CASCADE로 인한 INSERT / UPDATE / DELETE SQL을 그대로 생성한다.
• 단, DB 입장에서는 참조 무결성을 보장하지 않으므로
  – 자식을 먼저 지우고 부모를 지우는 식의 잘못된 순서가 나가도
  DB가 막지 않는다(무결성 깨질 가능성 있음).

---

1. 그런데 왜 “작동 안 한다”는 말이 나올까?

---

(1) “DB FK 없음 → DDL 생성 안 됨 → 연관관계가 없는 줄 안다”
→ @JoinColumn(foreignKey = @ForeignKey(value = ConstraintMode.NO_CONSTRAINT))
로 두면 DDL에는 FK가 안 생기지만, JPA 메타모델에는 연관이 그대로 있으므로
cascade는 여전히 작동한다.

(2) “연관관계 자체를 매핑하지 않음 → cascade 어노테이션을 붙일 곳이 없음”
→ FK 제약이 없다고 해서 연관관계 매핑을 안 한 경우,
cascade 옵션을 줄 필드가 없으므로 “cascade가 안 먹히는 것”처럼 보일 뿐이다.

(3) “잘못된 순서로 DELETE → SQL 실패”
→ DB에 FK는 없지만 애플리케이션이
부모 삭제 → 자식 삭제 순으로 SQL을 생성하지 못하면
자식 테이블에 부모 키를 참조하는 row가 남아
이후 비즈니스 로직에서 예외가 터질 수 있다.
이런 상황을 “cascade가 안 된다”고 말하는 경우도 있다.

---

1. 결론

---

• “DB에 FK 정의가 없다” ≠ “JPA cascade가 작동하지 않는다”
• JPA cascade는 객체 그래프 전이 기능이며, DB FK 유무와 무관하게 작동한다.
• 다만 FK가 없으면
  – DB가 무결성을 검증하지 않으므로 잘못된 데이터 삽입/삭제가 가능하고
  – 개발자가 삭제 순서나 ** orphanRemoval ** 등을 더 신경 써야 한다.

---

요약 한 줄
JPA cascade는 메모리에서의 엔티티 전이이지, DB FK 제약과는 별개이므로
DB에 FK가 없어도 애플리케이션 레벨 cascade는 정상 작동합니다.