결론
JpaRepository는 DirtyChecking(더티체킹)을 해준다. 즉, Entity 객체를 수정했다면, 따로 save와 같은 함수를 호출하지 않아도, 자동으로 커밋시 update query를 날려준다.
상황
JPA 학습 시 Dirty Checking에 대해 들은 바가 기억나, 업무에서 API를 구현하며 필드를 수정한 후 save를 하지 않았는데, 어떤 DVO는 save없이 커밋되고, 어떤 DVO는 커밋되지 않아서, 차이점이 무엇인지 고민하던 상황이었다.
코드는 간결화 했을 시 대략 아래와 같은 상황.
WorkDVO work = workRepository.findById(workId);
OrderDVO order = orderRepository.findById(workId);
order.setName("ORDER");
MoneyDVO money = moneyRepository.findById(workId);
money.setName("MONEY");
work.setName("WORK");
// 위 코드 실행 시 order와 money의 nameField는 DB에 변경된채로 반영되어있는데, work는 nameField는 변하지 않은 상태.
workRepository.save(work);
// 위 코드까지 실행해야, work의 변경사항이 반영 됨.원인
- OrderRepository와 MoneyRepository는 JpaRepository 인터페이스를 구현하고, WorkRepository는 CrudRepository 인터페이스를 구현해서 생긴 문제였다.
즉, JpaRepository는 DirtyChecking을 지원하기 때문에 엔티티가 수정되었을 경우, 커밋시 엔티티의 변경 내역을 파악해 update query를 날려주지만, CrudRepository는 그런 기능이 없으므로 엔티티의 필드를 수정해도 save를 하지 않으면, query가 나가지 않는 것이다.
변경 감지(더티 체킹 - Dirty Checking)
- update나 save같은 메소드를 실행하지 않았는데 자동으로 update 쿼리가 날라가는 것.
- 영속성 컨텍스트에서는 엔티티와 스냅샷을 비교해서, 값이 다르면 UPDATE SQL을 생성한다.
This is titu