※ 본 포스팅은 김영한 강사님의 인프런 '실전! 스프링 부트와 JPA 활용1 - 웹 애플리케이션 개발' 강의를 들으며 작성한 수강일지 입니다.
| 웹 계층 개발
1. 홈 화면과 레이아웃
2. 회원 등록
3. 회원 목록 조회
4. 상품 등록
5. 상품 목록
6. 상품 수정
7. 변경 감지와 병합(merge)
8. 상품 주문
9. 주문 목록으로 검색, 취소
10. 다음으로
7. 변경 감지와 병합(merge)
참고: 정말 중요한 내용이니 꼭! 완벽하게 이해하기
준영속 엔티티?
영속성 컨텍스트가 더는 관리하지 않는 엔티티를 말한다(JPA 영속성 컨텍스트가 더이상 관리하지 않는 엔티티).
ex) item 수정 시 이미 한 번 DB에 저장이 되어서 불러온..
@PostMapping("items/{itemId}/edit")
public String updateItem(@PathVariable String itemId, @ModelAttribute("form") BookForm form) {
Book book = new Book();
book.setId(form.getId()); // 이미 db에 정확한 식별자가 있는 객체 -> 준영속 상태의 객체
book.setName(form.getName());
book.setPrice(form.getPrice());
book.setStockQuantity(form.getStockQuantity());
book.setAuthor(form.getAuthor());
book.setIsbn(form.getIsbn());
itemService.saveItem(book);
return "redirect:/items";
}
(여기서는 itemService.saveItem(book) 에서 수정을 시도하는 Book 객체다. Book 객체는 이미 DB 에 한번 저장되어서 식별자가 존재한다. 이렇게 임의로 만들어낸 엔티티도 기존 식별자를 가지고 있으면 준 영속 엔티티로 볼 수 있다.)
cf) entity가 영속 상태로 관리가 되면, 그 값이 변경되면, JPA에서 감지하고 값을 update 쳐버림
-> 변경 감지 === Dirty Checking
// EX 1
//==비즈니스 로직==//
/**
* 주문 취소
*/
public void cancel() {
if (delivery.getStatus() == DeliveryStatus.COMP) {
throw new IllegalStateException("이미 배송완료된 상품은 취소가 불가능합니다.");
}
this.setStatus(OrderStatus.CANCEL); // 따로 Commit 해주지 않아도 JPA의 변경 감지(Dirty Checking)에 의해 CANCEL 상태로 update 됨(em.update, em.merge 등 하지 않았는데도 Tx commit 시점에 flush 시 dirty checking이 일어남)
for (OrderItem orderItem : orderItems) {
orderItem.cancel(); // item 재고 원복시킴
}
}// EX 2
package jpabook.jpashop.service;
import jpabook.jpashop.domain.item.Book;
import org.junit.jupiter.api.Test;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.test.context.SpringBootTest;
import javax.persistence.EntityManager;
//@RunWith(SpringRunner.class)
@SpringBootTest
public class ItemUpdateTest {
@Autowired
EntityManager em;
@Test
public void updateTest() throws Exception {
Book book = em.find(Book.class, 11);
//Tx(Transaction)
book.setName("asdfasdf"); // JPA가 변경분을 찾아서 알아서 반영함 -> 변경감지 == Dirty checking -> 이걸 이용해서 내가 원하는 data update 칠 수 있음
//Tx commit
}
}
준영속 엔티티를 수정하는 2가지 방법
- 변경 감지 기능 사용
- 병합( merge ) 사용
변경 감지 기능 사용(== Dirty Checking)
// service/ItemService.java
// 준영속 엔티티 관리 -> 변경 감지 기능 사용(Dirty Checking)
@Transactional
public void updateItem(Long itemId, Book param) {
Item findItem = itemRepository.findOne(itemId); // findOne으로 찾아온 얘는 영속 상태이므로 값을 세팅한 다음에 뭘 해주지 않아도 flush 때 Dirty Checking에 의해 바뀐 값을 update 침
findItem.setPrice(param.getPrice());
findItem.setName(param.getName());
findItem.setStockQuantity(param.getStockQuantity());
}
영속성 컨텍스트에서 엔티티를 다시 조회한 후에 데이터를 수정하는 방법 트랜잭션 안에서 엔티티를 다시 조회, 변경할 값 선택 트랜잭션 커밋 시점에 변경 감지(Dirty Checking) 이 동작해서 데이터베이스에 UPDATE SQL 실행
병합 사용(merge)
// 준영속 엔티티 관리 -> 2 병합 사용(Merge)
@Transactional
public Item updateItem(Long itemId, Book param) {
Item findItem = itemRepository.findOne(itemId); // findOne으로 찾아온 얘는 영속 상태이므로 값을 세팅한 다음에 뭘 해주지 않아도 flush 때 Dirty Checking에 의해 바뀐 값을 update 침
findItem.setPrice(param.getPrice());
findItem.setName(param.getName());
findItem.setStockQuantity(param.getStockQuantity());
return findItem; // 영속 상태의 findItem 반환
}병합은 준영속 상태의 엔티티를 영속 상태로 변경할 때 사용하는 기능이다
병합: 기존에 있는 엔티티
병합 동작 방식
1. merge() 를 실행한다.
2. 파라미터로 넘어온 준영속 엔티티의 식별자 값으로 1차 캐시에서 엔티티를 조회한다.
2-1. 만약 1차 캐시에 엔티티가 없으면 데이터베이스에서 엔티티를 조회하고, 1차 캐시에 저장한다.
3. 조회한 영속 엔티티( mergeMember )에 member 엔티티의 값을 채워 넣는다. (member 엔티티의 모든 값 을 mergeMember에 밀어 넣는다. 이때 mergeMember의 “회원1”이라는 이름이 “회원명변경”으로 바 뀐다.)
4. 영속 상태인 mergeMember를 반환한다.
참고: 책 자바 ORM 표준 JPA 프로그래밍 3.6.5
병합시 동작 방식을 간단히 정리
1. 준영속 엔티티의 식별자 값으로 영속 엔티티를 조회한다.
2. 영속 엔티티의 값을 준영속 엔티티의 값으로 모두 교체한다.(병합한다.)
3. 트랜잭션 커밋 시점에 변경 감지 기능이 동작해서 데이터베이스에 UPDATE SQL이 실행
주의: 변경 감지 기능을 사용하면 원하는 속성만 선택해서 변경할 수 있지만, 병합을 사용하면 모든 속성이 변경된다(parameter로 넘어온 것). 병합시 값이 없으면 null 로 업데이트 할 위험도 있다. (병합은 모든 필드를 교체한다.)
@PostMapping("/items/new")
public String create(BookForm form) {
// 실무에서는 이렇게 setter를 열어놓고 사용하지 않음
Book book = new Book();
book.setName(form.getName());
// book.setPrice(form.getPrice()); // 만약 이 부분이 필요없어서 항목에서 빼버리면, 값 세팅을 안해줬기 때문에 DB에 기존 값이 아닌, null로 update를 해버림
book.setStockQuantity(form.getStockQuantity());
book.setAuthor(form.getAuthor());
book.setIsbn(form.getIsbn());
itemService.saveItem(book);
return "redirect:/";
}--> 실무에서 merge 말고 조금 불편하더라도 Dirty Checking을 사용하라!!(내가 필요한 field만 set 해서 사용하라)
@PostMapping("/items/new")
public String create(BookForm form) {
// 실무에서는 이렇게 setter를 열어놓고 사용하지 않음
Book book = new Book();
book.setName(form.getName());
book.setPrice(form.getPrice()); // 만약 이 부분이 필요없어서 항목에서 빼버리면, 값 세팅을 안해줬기 때문에 DB에 기존 값이 아닌, null로 update를 해버림
book.setStockQuantity(form.getStockQuantity());
book.setAuthor(form.getAuthor());
book.setIsbn(form.getIsbn());
itemService.saveItem(book);
return "redirect:/";
}-> 또한, 보통 update는 이렇게 단발성으로 해서는 안됨
// 준영속 엔티티 관리 -> 2 병합 사용(Merge)
@Transactional
public Item updateItem(Long itemId, Book param) {
Item findItem = itemRepository.findOne(itemId); // findOne으로 찾아온 얘는 영속 상태이므로 값을 세팅한 다음에 뭘 해주지 않아도 flush 때 Dirty Checking에 의해 바뀐 값을 update 침
findItem.setPrice(param.getPrice());
findItem.setName(param.getName());
findItem.setStockQuantity(param.getStockQuantity());
// 보통 update는 위처럼 단발성으로 해서는 안됨
// findItem.change(price, name, stockQuantity); // 위처럼 단발성으로 값을 변경하면 안됨(set을 막 깐다던지 .. 등 X)
// findItem.addStock(); // 이런식으로 의미있는 메서드를 만들어야 함
// // -> 이렇게 해야 변경 지점이 Entity로 감(도대체 어디서 변경되는거야?? 하는걸 막을 수 있음)
return findItem; // 영속 상태의 findItem 반환
}
ItemRepository
public void save(Item item) {
// item은 jpa가 저장하기 전까지 id 값이 없기 때문(완전히 새로 생성하는 객체)
if (item.getId() == null) {
em.persist(item); // JPA가 제공하는 persist로 아이템을 신규로 등록
} else { // 이미 존재한다면
em.merge(item); // 진짜 update는 아니지만 강제 update라고 이해하면 됨
}
}
- save() 메서드는 식별자 값이 없으면( null ) 새로운 엔티티로 판단해서 영속화(persist)하고 식별자가 있 으면 병합(merge)
- 지금처럼 준영속 상태인 상품 엔티티를 수정할 때는 id 값이 있으므로 병합 수행
새로운 엔티티 저장과 준영속 엔티티 병합을 편리하게 한번에 처리
상품 리포지토리에선 save() 메서드를 유심히 봐야 하는데, 이 메서드 하나로 저장과 수정(병합)을 다 처 리한다. 코드를 보면 식별자 값이 없으면 새로운 엔티티로 판단해서 persist() 로 영속화하고 만약 식별자 값이 있으면 이미 한번 영속화 되었던 엔티티로 판단해서 merge() 로 수정(병합)한다. 결국 여기서의 저장 (save)이라는 의미는 신규 데이터를 저장하는 것뿐만 아니라 변경된 데이터의 저장이라는 의미도 포함한다. 이렇게 함으로써 이 메서드를 사용하는 클라이언트는 저장과 수정을 구분하지 않아도 되므로 클라이언트의 로직이 단순해진다.
여기서 사용하는 수정(병합)은 준영속 상태의 엔티티를 수정할 때 사용한다. 영속 상태의 엔티티는 변경 감 지(dirty checking)기능이 동작해서 트랜잭션을 커밋할 때 자동으로 수정되므로 별도의 수정 메서드를 호 출할 필요가 없고 그런 메서드도 없다.
참고: save() 메서드는 식별자를 자동 생성해야 정상 동작한다. 여기서 사용한 Item 엔티티의 식별자는 자동으로 생성되도록 @GeneratedValue 를 선언했다. 따라서 식별자 없이 save() 메서드를 호출하면 persist() 가 호출되면서 식별자 값이 자동으로 할당된다. 반면에 식별자를 직접 할당하도록 @Id 만 선언 했다고 가정하자. 이 경우 식별자를 직접 할당하지 않고, save() 메서드를 호출하면 식별자가 없는 상태로 persist() 를 호출한다. 그러면 식별자가 없다는 예외가 발생한다.
참고: 실무에서는 보통 업데이트 기능이 매우 제한적이다. 그런데 병합은 모든 필드를 변경해버리고, 데이터 가 없으면 null 로 업데이트 해버린다. 병합을 사용하면서 이 문제를 해결하려면, 변경 폼 화면에서 모든 데 이터를 항상 유지해야 한다. 실무에서는 보통 변경가능한 데이터만 노출하기 때문에, 병합을 사용하는 것이 오히려 번거롭다.
가장 좋은 해결 방법
엔티티를 변경할 때는 항상 변경 감지를 사용하자
- 컨트롤러에 어설프게 엔티티를 생성하지 마라.
- 트랜잭션이 있는 서비스 계층에 식별자(id)와 변경할 데이터를 명확하게 전달하라.(파라미터 or dto)
- 트랜잭션이 있는 서비스 계층에서 영속 상태의 엔티티를 조회하고, 엔티티의 데이터를 직접 변경하라.
- 트랜잭션 커밋 시점에 변경 감지가 실행된다.
// ItemService.java
@Transactional
public void updateItem(Long itemId, String name, int price, int stockQuantity) {
Item findItem = itemRepository.findOne(itemId); // findOne으로 찾아온 얘는 영속 상태이므로 값을 세팅한 다음에 뭘 해주지 않아도 flush 때 Dirty Checking에 의해 바뀐 값을 update 침
// findItem.setPrice(param.getPrice());
// findItem.setName(param.getName());
// findItem.setStockQuantity(param.getStockQuantity());
// 보통 update는 위처럼 단발성으로 해서는 안됨
// findItem.change(price, name, stockQuantity); // 위처럼 단발성으로 값을 변경하면 안됨(set을 막 깐다던지 .. 등 X)
// findItem.addStock(); // 이런식으로 의미있는 메서드를 만들어야 함
// // -> 이렇게 해야 변경 지점이 Entity로 감(도대체 어디서 변경되는거야?? 하는걸 막을 수 있음)
findItem.setName(name);
findItem.setPrice(price);
findItem.setStockQuantity(stockQuantity);
} // ItemController.java
@PostMapping("items/{itemId}/edit")
public String updateItem(@PathVariable Long itemId, @ModelAttribute("form") BookForm form) {
// Book book = new Book(); // 내가 new 해서 객체 생성 -> 자동으로 update 치지 않음
// book.setId(form.getId()); // 이미 db에 정확한 식별자가 있는 객체 -> 준영속 상태의 객체
// book.setName(form.getName());
// book.setPrice(form.getPrice());
// book.setStockQuantity(form.getStockQuantity());
// book.setAuthor(form.getAuthor());
// book.setIsbn(form.getIsbn());
// itemService.saveItem(book); // 얘가 없으면 Update 되지 않음
itemService.updateItem(itemId, form.getName(), form.getPrice(), form.getStockQuantity());
return "redirect:/items";
}
-> 데이터가 너무 많아 parameter가 많아지면 Service 계층에 DTO를 만들기
service/UpdateItemDto 생성 후 ItemService 다음과 같이 수정
ItemService
// 위 방식대로 하다가 파라미터가 너무 많아지면 service/UpdateItemDto 생성 후 아래와 같이 변경
// @Transactional
// public void updateItem(Long itemId, UpdateItemDto itemDto) { //
// Item findItem = itemRepository.findOne(itemId); // dto에 id가 들어가도 됨
// ...
// ...
// ...
// }