TIL-211027

1. JPA 벌크 연산

• 벌크 연산은 영속성 컨텍스트를 조회하지 않고 DB에 직접 쿼리문 실행
• 벌크 연산후, 영속성 컨텍스트를 먼저 조회하는 JPQL의 결과와 다를 수 있음

벌크연산시 주의할 점

2. HTTP Method - Put VS Patch

• Put : 자원을 생성/전체 교체. 자원의 모든 필드가 필요
  • idemotent : 멱등성
  • RESTful 방식에서는 자원 생성은 주로 POST를 사용
• Patch : 자원의 일부를 교체.
  • 멱등성 만족이 필수는 아님
  • json에 null이 있을 경우
    • null로 update하거나
    • 무시

// 출처 : https://www.baeldung.com/http-put-patch-difference-spring

@RequestMapping(value = "/heavyresource/{id}", method = RequestMethod.PATCH, consumes = MediaType.APPLICATION_JSON_VALUE)
public ResponseEntity<?> partialUpdateGeneric(
  @RequestBody Map<String, Object> updates,
  @PathVariable("id") String id) {
    
    heavyResourceRepository.save(updates, id);
    return ResponseEntity.ok("resource updated");
}

변경할 필드마다 다른 custom DTO를 만들 필요없이, Map으로 부분 update 가능

http-put-patch-difference-spring

3. JPA @DynamicUpdate

• JPA with Hibernate(update의) 기본 동작 : 모든 Entity의 CRUD 쿼리를 만들고 캐싱함(모든 속성(column)을 update 쿼리에 포함)
• Entity의 모든 속성이 쿼리에 포함됨
• 일부 속성(column)만 변경하고 싶을 때 @DynamicUpdate를 사용
• JPA Entity에 적용되는 class-level annotation
• 단점
  • 쿼리를 캐싱하지 않고 매 update마다 속성(column)에 따라 생성
  • 변경된 column을 알기 위해 Hibernater가 Entity의 상태를 track/비교 -> overhead
• 사용예
  • Entity에 많은 속성이 있고, 그 중 소수의 column만 자주 변경되는 상황
  • version-less Optimistic Lock을 사용하는 경우(낙관적 락은 아직 모름)

spring-data-jpa-dynamicupdate

궁금한 것 : Entity(table)에 column이 많다고 판단하는 기준 - 30개?
대략 15개 이상의 필드가 있다면 정규화가 잘못된 것일 가능성이 큼

JPA save()