TIL-211027

4180 단어 TILTIL

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()

좋은 웹페이지 즐겨찾기