jpa

오랜만에 프로젝트를 진행하다보니 복습도 되고 참 좋은 것 같다. 무엇보다 그동안 공부한 내용이 있기에 이전의 로직을 더 발전시켜 작성할 수 있게 되었다.그런데 프로젝트를 진행하다가 문제를 하나 맞닥뜨리게 되었다. 비즈니스적으로는 동작을 잘 하지만 최적화의 문제였다.  그것은 바로 JPA를 사용하면서 엔티티 조회를 한 번만 했지만 쿼리가 따로 나가는 문제이다.이 문제를 해결하는 과정을 기록해 두기로 했다.  문제의 원인 알아보고 해결하기 이것이 현재 상황을 나타낸 ERD이다.코딩테스트 문제를 불러오면 테스트 케이스와 그림을 같이 불러올 수 있도록 구성했다.위에서 쿼리가 세 번 나간 이유도 엔티티가 세 개여서 그런 것 같다. @Getter@NoArgsConstructor(access = AccessLevel..

들어가기 order-service에서 주문 내역을 저장하는 부분을 JPA와 Kafka Connect를 이용한 두 가지 방법으로 구현했었다. Kafka를 사용했을 때의 장점은 카프카가 DB로의 저장 요청을 대신 수행하므로 어플리케이션에서는 Kafka로 요청을 보내고 클라이언트에게 바로 응답을 할 수 있다는 점이다.  OrderJpaService@Service@Transactional@RequiredArgsConstructorpublic class OrderJpaService implements OrderService { private final OrderRepository orderRepository; private final OrderProductRepository orderProductRep..

프로젝트를 진행하면서 강의 때 잠깐 사용해 본 Query DSL과 Slice를 사용해 보기로 했다. 지금 프로젝트에서 매장을 검색해야 하는데 검색과 카테고리 선택 후 목록을 보여주는 부분이 전부 따로 만들기에는 기능상 굉장히 흡사해서 계속 새로운 내용을 추가하는 것보다는 동적으로 쿼리를 작성해보고자 했다.  Controller @Builder@Getterpublic class StoreSearchCondition { Integer categoryId; String storeName; String regionCode; public void setRegionCode(String regionCode) { this.regionCode = regionCode; }} @Slf..

오늘 몇 가지 기능을 테스트 하다가 위와 같은 에러가 발생했다. StoreRepository 타입의 Bean을 찾지 못했다고 하는데... @DataJpaTestclass StoreServiceImplTest { private final StoreService storeService; private final CategoryService categoryService; private final StoreRepository storeRepository; private final CategoryRepository categoryRepository; @Autowired public StoreServiceImplTest(StoreRepository storeRepository, Ca..

엔티티를 조회할 때 지연로딩 전략을 사용하면 연결되어 있는 엔티티를 직접 fetch 조인으로 가져오거나 자동으로 엔티티를 불러오는 방법 외에도 엔티티 그래프를 사용하는 방법이 있다. 엔티티 그래프를 사용하면 JPQL은 fetch 조인을 사용하지 않은 상태로 두고 마치 fetch 조인을 사용한 것처럼 엔티티들을 한꺼번에 조회할 수 있다.  준비  테이블 간의 관계는 위와 같다. @NamedEntityGraph(name = "withUserRole", attributeNodes = { @NamedAttributeNode("userRole")})// 어노테이션 생략@Entity@Table(name = "users")public class User extends BaseDateTimeEntity {..

OSIV란? OSIV란 Open Session In View의 약자로, 뷰 계층에서도 JPA의 지연로딩 전략을 사용할 수 있게 해주는 기술이다. JPA는 기본적으로 트랜잭션 안에서 동작한다. 즉, 영속성 컨텍스트의 생명주기는 트랜잭션의 생명주기와 같다. 트랜잭션이 시작될 때 영속성 컨텍스트가 만들어지고, 트랜잭션이 커밋되거나 롤백될 때 영속성 컨텍스트가 종료된다. 그렇기 때문에 일반적으로 비즈니스 로직이 위치한 서비스 계층에서 트랜잭션이 시작되고 종료된다. 영속성 컨텍스트도 서비스 계층에서만 유효하기 때문에 컨트롤러에서는 영속성 컨텍스트로 관리되었던 준영속 상태의 객체를 지연 로딩할 수 없다. 트랜잭션과 영속성 컨텍스트가 모두 이미 종료되었기 때문이다. 이런 문제를 OSIV를 사용하면 쉽게 해결할 수 있..