JPA (98) 썸네일형 리스트형 default_batch_fetch_size 이해 default_batch_fetch_size 는 지연로딩이 작동할때 작동하는 옵션으로 Collection 형태의 필드를 fetch join으로 즉시로딩해서 가져올때 일단 toMany를 join하기 때문에 결과값이 뻥튀기 되고 중복값을 제거하기 위해서 distinct가 필요하다. 거기다 페이징도 되지않게된다. 그래서 fetch join을 하지않고 collection을 지연로딩시키게 되는데 이 지연로딩이 발생할때 그 지연로딩 필드를 가진 엔티티 list를 받아오게 될것인데 그 엔티티에 id값을 모두 가져와 한번 지연로딩할때 IN절에 그 엔티티 ID 값들을 모두 넣고 지연로딩을 하게 된다. 이 역활을 해주는게 default_batch_fetch_size 이다. 이렇게 하면 지연로딩은 발생해서 쿼리는 한번 더 .. 3월 7일 JPA OSIV 와 성능최적화 Open Session In View = 하이버네이트 Open Entity Manager In View = JPA 관계형 OSIV라 한다 기본값 Spring , JPA , Open-in-view : true 이 기본값을 뿌리면서 애플리케이션 시작시점에 warm 로그를 남기는 이유가 있다. 기본적으로 JPA가 언제 DB커넥션을 가지고 오고 언제 DB커넥션을 반환하는지가 문제 영속성이 사용되려면 DB가 필수적으로 있어야한다. DB트랜잭션이 시작할때 JPA가 DB커넥션을 가져온다. DB에 커넥션을 돌려주는 시점은 차이가 있는데 open session in view가 켜져있으면 트랜잭션이 끝나도 반환을 하지 않는데 이유는 LAZY로딩이 일어날대 DB커넥션이 살아 있어야 하기 때문 Open Session in v.. 3월 6일 JPA API 개발 고급 정리 엔티티를 조회 엔티티 그대로 client에 반환은 위험하다 , 꼭 DTO로 변환해서 반환 fetch 조인으로 쿼리 최적화 collection fetch join 사용시 페이징 사용불가 ToOne은 fetch Join으로 쿼리수 최적화 ToMany collection은 지연로팅을 유지해준다. hibernate.default_batch_fetch_size나 @BatchSize로 최적화 엔티티의 경우 IN절을 사용 IN절에 id값을 한번에 넣어 가져온다. DTO직접조회 컬렉션 조회 최적화 일대다 관계형 컬렉션은 IN을 사용해 최적화 플렛 데이터 최적화 JOIN 결과를 모두 조회후 애플리케이션에서 작업 권장순서 1.엔티티 조회 방식 우선 접근(최우선 , 문제 해결이 간단하다) -페치 조인으로 쿼리수 최적화 -컬.. 3월 6일 JPA 주문조회 V6 jpa에서 DTO로 직접조회 , 플릿데이터 최적화 @GetMapping("/api/v6/orders") public List ordersV6(){ List flats = orderQueryRepository.findAllByDto_flat(); return flats.stream() .collect(groupBy(o -> new orderQueryDto(o.getOrderId(), o.getItem(),o.getOrderDate(),o.getOrderStatus(),o.getAddress()), Mapping( o -> new OrderItemQueryDto(o.getOrderId() , o.getItemName(), o.getOrderPrice(), o.getCount().toList())) )).en.. 3월 6일 JPA 주문조회 V5 JPA에서 DTO직접 조회 , 컬렉션 조회 최적화 V4에 문제였던 쿼리 n+1 문제 개선 @GetMapping("/api/v5/orders") public List ordersV5(){ return orderQuertRepository.findAllByDto_Optimization(); } 1.order 가져오기 public List findORders(){ return em.createQuery( "select new jpabook~orderQueryDto(o.id , m.name , o.orderDate , o.status , d.address)" + "from order o "+ "join o.member m" + "join o.delivery d" , orderQueryDto.class ) .ge.. 3월 3일 JPA 주문조회 v4 JPA에서 DTO 직접 조회(collection 있을 경우) @GetMapping("/api/v4/orders") public List ordersV4(){ return orderQueryRepository.findOrderQueryDtos(); } order와 그 Collection을 받을 DTO //order @Data public class OrderQueryDTO{ private Long orderId; private String name; private LocalDateTime orderDate; private OrderStatus orderStatus; private Address address; private List orderItems; } public OrderQueryDto (Long .. 2월 27일 주문조회 V3.1 엔티티를 DTO로 변환 - 페이징과 한계돌파 fetch join을 하면 페이징을 사용하지 못하는 문제를 해결해보자. 문제 -컬렉션을 페치조인하면 페이징이 불가능하다. -개발자 관점에서 from 기준의 결과를 원하는데 fetch join이 기준이 되어 버린다. 데이터가 예측할수 없이 증가되어 버린다. -from을 기준으로 페이징을 생성하는게 목적인데 collection fetch join을 기준으로 row가 생성되는게 문제이다.(페이징이 안되는 이유) -이 경우 하이버네이트는 경고로그를 남기고 모든 DB데이터를 읽어서 메모리에서 페이징을 시도한다. 최악의 경우 장애 발생 해결방법 -먼저 ~ToOne(@ManyToOne , @OneToOne) 관계를 모두 페치조인한다. ~ToOne 관계는 row수를 증가시키.. 2월 27일 JPA 주문조회 V3 엔티티를 DTO로 반환 - 페치조인 최적화 @GetMapping("/api/v3/orders") public List orderV3(){ List orders = orderRepository.findAllWithItem(); List collect = orders.stream() .map(o -> new orderDTO(o)) .collect(collections.toList()); return collect; //여기 까진 v2와 동일 } public List findAllWithItem(){ return em.createQuery( "select o from Order o "+ " join fetch o.member m" + " join fetch o.delivery d" + " join fetch .. 이전 1 2 3 4 ··· 13 다음
