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을 사용하는 경우(낙관적 락은 아직 모름)
궁금한 것 : Entity(table)에 column이 많다고 판단하는 기준 - 30개?
대략 15개 이상의 필드가 있다면 정규화가 잘못된 것일 가능성이 큼
Author And Source
이 문제에 관하여(TIL-211027), 우리는 이곳에서 더 많은 자료를 발견하고 링크를 클릭하여 보았다 https://velog.io/@pro-park-gation/TIL-211027저자 귀속: 원작자 정보가 원작자 URL에 포함되어 있으며 저작권은 원작자 소유입니다.
우수한 개발자 콘텐츠 발견에 전념 (Collection and Share based on the CC Protocol.)