22.05.18

변경 감지와 병합(merge)

영속성 엔티티는 JPA가 변경을 감지하여 트랜잭션 커밋 시점에 데이터베이스에 반영시킨다.

 

준영속 엔티티

영속성 컨텍스트가 더는 관리하지 않는 엔티티

임의로 만들어낸 엔티티도 기존 식별자(id)를 가지고 있으면 준영속 엔티티로 볼 수 있다.

 

준영속 엔티티를 수정하는 2가지 방법

• 변경 감지( dirty check ) 기능 사용
• 병합( merge ) 사용

변경 감지 기능 사용

@Transactional
void update(Item itemParam) { //itemParam: 파리미터로 넘어온 준영속 상태의 엔티티
    Item findItem = em.find(Item.class, itemParam.getId()); //같은 엔티티를 조회한다.
    findItem.setPrice(itemParam.getPrice()); //데이터를 수정한다.
}

 

• 영속성 컨텍스트에서 엔티티를 다시 조회한 후에 데이터를 수정하는 방법
• 트랜잭션 안에서 엔티티를 다시 조회, 변경할 값 선택 -> 트랜잭션 커밋 시점에 변경 감지(Dirty Checking) 가 동작해서 데이터베이스에 UPDATE SQL 실행

병합 사용

병합은 준영속 상태의 엔티티를 영속 상태로 변경할 때 사용하는 기능

정확히는 준영속 상태의 엔티티를 통해 영속 상태의 엔티티를 반환한다. 그 자체가 영속 상태가 되는 것은 아님

 

@Transactional
void update(Item itemParam) { //itemParam: 파리미터로 넘어온 준영속 상태의 엔티티
    Item mergeItem = em.merge(item);
}

 

병합: 기존에 있는 엔티티

 

병합 동작 방식

1. 파라미터로 넘어온 준영속 엔티티의 식별자 값으로 1차 캐시에서 엔티티를 조회한다.

  만약 1차 캐시에 엔티티가 없으면 데이터베이스에서 엔티티를 조회하고, 1차 캐시에 저장한다.

2. 조회한 영속 엔티티(mergeMember)의 값을 준영속 엔티티(member)의 값으로 모두 교체한다.

3. 영속 상태인 mergeMember를 반환한다. (트랜잭션 커밋 시점에 변경 감지 기능이 동작해서 데이터베이스에 UPDATE SQL이 실행)

 

주의: 변경 감지 기능을 사용하면 원하는 속성만 선택해서 변경할 수 있지만, 병합을 사용하면 모든 속성이 변경된다.

병합시 값이 없으면(변경하지 않으면) null 로 업데이트 할 위험도 있다. (병합은 모든 필드를 교체한다.)

애초에 사용자가 변경 가능한 속성은 한정적이기 때문에 모든 속성을 변경하는 것은 비효율적이다.

 

ItemRepository 의 save() 메서드 분석

public void save(Item item) {
    if (item.getId() == null) {
        em.persist(item);
    } else {
        em.merge(item);
    }
}

 

• 여기서의 저장(save)이라는 의미는 신규 데이터를 저장하는 것뿐만 아니라 변경된 데이터의 저장이라는 의미도 포함한다.
• 이 메서드를 사용하는 클라이언트는 저장과 수정을 구분하지 않아도 되므로 클라이언트의 로직이 단순해진다.
• 영속 상태의 엔티티는 변경 감지(dirty checking) 기능이 동작해서 트랜잭션을 커밋할 때 자동으로 수정되므로 별도의 수정 메서드를 호출할 필요가 없다. 병합(em.merge())은 준영속 엔티티를 수정할 때 사용한다.

참고: save() 메서드는 식별자를 자동 생성해야 정상 동작한다. 여기서 사용한 Item 엔티티의 식별자는 자동으로 생성되도록 @GeneratedValue 를 선언했다. 따라서 식별자 없이 save() 메서드를 호출하면 persist() 가 호출되면서 식별자 값이 자동으로 할당된다. 반면에 식별자를 직접 할당하도록 @Id 만 선언 했다고 가정하자. 이 경우 식별자를 직접 할당하지 않고, save() 메서드를 호출하면 식별자가 없는 상태로 persist() 를 호출한다. 그러면 식별자가 없다는 예외가 발생한다.

 

참고: 실무에서는 보통 업데이트 기능이 매우 제한적이다. 그런데 병합은 모든 필드를 변경해버리고, 데이터가 없으면 null 로 업데이트 해버린다. 따라서 수정에서 병합을 사용하려면 변경 폼 화면에서 모든 데이터를 항상 유지해야 한다. 실무에서는 보통 변경 가능한 데이터만 노출하기 때문에, 병합을 사용하는 것이 오히려 번거롭다.

가장 좋은 해결 방법

엔티티를 변경할 때는 항상 변경 감지를 사용하자

• 컨트롤러에서 엔티티 생성XX (준영속 엔티티)
• 트랜잭션이 있는 서비스 계층에 식별자( id )와 변경할 데이터를 명확하게 전달 (기본적으로는 파라미터로 넘기고, 넘겨야 할 데이터가 많다면 DTO를 생성하여 넘긴다.)
• 트랜잭션이 있는 서비스 계층에서 영속 상태의 엔티티를 조회하고, 엔티티의 데이터를 직접 변경 (update 메서드)
• 트랜잭션 커밋 시점에 변경 감지 실행

ItemController

/**
 * 상품 수정, 권장 코드
 */
@PostMapping(value = "/items/{itemId}/edit")
public String updateItem(@ModelAttribute("form") BookForm form) {
    itemService.updateItem(form.getId(), form.getName(), form.getPrice());
    return "redirect:/items";
}

 

ItemService

/**
 * 영속성 컨텍스트가 자동 변경
 */
@Transactional
public void updateItem(Long id, String name, int price) {
    Item item = itemRepository.findOne(id);
    item.setName(name);
    item.setPrice(price);
}

 

엔티티 조회 자체는 꼭 영속성 컨택스트 안에서 할 필요는 없지만, 그래도 유연한 설계 및 테스트를 위해 컨트롤러에서 식별자 값만 받아 서비스 안에서 요청을 처리하는 것이 좋다.

상품 주문

@GetMapping(value = "/order")
public String createForm(Model model) {
    List<Member> members = memberService.findMembers();
    List<Item> items = itemService.findItems();
    model.addAttribute("members", members);
    model.addAttribute("items", items);
    return "order/orderForm";
}

@PostMapping(value = "/order")
public String order(@RequestParam("memberId") Long memberId,
		@RequestParam("itemId") Long itemId,
		@RequestParam("count") int count) {
    orderService.order(memberId, itemId, count);
    return "redirect:/orders";
}

 

주문 폼 이동 ( createForm() )

메인 화면에서 상품 주문을 선택하면 /order 를 GET 방식으로 호출

주문 화면에는 주문할 고객정보와 상품 정보가 필요하므로 model 객체에 담아서 뷰에 넘겨줌

 

주문 실행 ( order() )

주문할 회원과 상품 그리고 수량을 선택해서 Submit 버튼을 누르면 /order URL을 POST 방식으로 호출

URL의 쿼리 파라미터 조회: @RequestParam("name") String value