1\. SQL 쿼리 힌트 사용JPA는 데이터베이스 SQL 힌트 기능을 미제공 => 하이버네이트 직접 사용하이버네이트 쿼리가 제공하는 addQueryHint() 메소드 사용2\. 트랜잭션을 지원하는 쓰기 지연SQL 실행시마다 네트워크 호출할 경우 많은 비용이 소모 =>

많은 데이터의 배치처리가 필요한 상황인 경우, 일반적인 방식으로 엔티티를 계속 조회하면 영속성 컨텍스트에 많은 엔티티가 쌓이면서 메모리 부족 오류가 발생따라서 이런 배치 처리는 적절한 단위로 영속성 컨텍스트 초기화가 필요1) JPA 등록 배치데이터 등록데이터 수정페이징

1\. 성능 최적화의 필요성영속성 컨텍스트에서 엔티티가 관리될 경우장점: 1차 캐시, 변경감지 등단점: 메모리 사용 증가(변경감지를 위해 스냅샷 인스턴스를 보관)단순 조회성인 경우 읽기 전용으로 엔티티 조회하여 메모리 사용량 최적화2\. 쿼리 최적화 방법1) 스칼라 타

N+1 문제(1) 즉시로딩em.find() 메소드로 조회외부조인을 사용해서 한 번의 SQL 실행JPQL 사용시board 조회 => board 수만큼 즉시로딩이 걸려있는 boardReply 조회하기 위해 추가 SQL 실행

JPA는 다양한 쿼리 방법을 지원📌JPQLJPA Criteria📌QueryDSLnative SQLJDBC API를 직접 사용, MyBatis, SpringJdbcTemplate 함께 사용실무에서는 95% JPQL + QueryDSL 사용1\. JPQL 소개📌가장

1\. 기본개념Open Session In View: 하이버네이트Open EntityManager In View: JPA관례상 OSIV라고 명명 2\. OSIV ON\- spring.jpa.open-in-view: true (default)기본값을 뿌리면서 애플리케이션

1\. 엔티티 조회엔티티를 조회해서 그대로 반환: ver1엔티티 조회 후 DTO로 변환: ver2페치조인으로 쿼리 수 최적화: ver3컬렉션 페이징과 한계 돌파: ver3.1컬렉션 페치 조인시 페이징이 불가능하다는 한계가 존재그렇다면 어떻게 해결? (실무에서는 페이징

주문조회 예시(1) ver1: 엔티티를 직접 노출 📌 엔티티의 외부 노출은 지양(2) ver2: 엔티티를 DTO로 변환 📌 연관관계의 경우 마찬가지로 별도의 DTO로 변환 필요 \- 엔티티를 껍데기 DTO로 감싸는 형태도 X 📌 N+1 문제가 발생(지

양방향 연관관계일 경우 무한루프를 방지하기 위해 필드 레벨에서 어노테이션 추가Order 엔티티에서 Member 엔티티 다대일 연관관계Member엔티티에서는 Order 정보를 또 찾지 않도록 @JsonIgnore 처리

주문조회 예시(1) ver1: 엔티티를 직접 노출📌 엔티티를 직접 노출할 경우 양방향 연관관계가 걸린 곳은 꼭! 한곳을 @JsonIgnore 처리 안그러면 양쪽을 서로 호출하면서 무한 루프 발생📌 엔티티의 외부노출은 가급적 지양 => DTO로 변환하여 반환📌 지연

1\. 엔티티에서는 가급적 Setter 사용 지양변경 포인트가 너무 많아져서 유지보수가 어려움2\. 모든 연관관계는 지연로딩(LAZY)으로 설정즉시로딩(EAGER)의 경우 예측이 어렵고 어떤 SQL이 실행될지 추적하기 어려움특히 JPQL 실행시 N+1 문제가 자주 발생

1\. @Getter, @Setter이론적으로는 Setter는 닫아두는 것을 권장데이터가 어디서 변경되었는지 추적하기가 힘들어지기 때문변경 지점이 명확해지도록 비즈니스 메소드를 별도로 제공(유지보수 고려)2\. 엔티티의 식별자엔티티의 식별자는 "id"를 사용하고, PK

1\. spring boot initializrhttps://start.spring.io/이후 IDE에서 import인텔리제이의 경우 import할 때 build.gradle 바로 선택2\. build.gradle3\. 동작 확인기본 테이스케이스 실행스프링부트

기본개념값 타입을 하나 이상 저장할 때 사용@ElementCollection, @CollectionTable 사용데이터베이스는 컬렉션을 같은 테이블에 저장할 수 없다.컬렉션을 저장하기 위한 별도의 테이블이 필요함

값 타입의 경우, 인스턴스가 다르더라도 그 안의 값이 같으면 같은 것으로 봐야함동일성(identity) 비교: 인스턴스의 참조 값을 비교, == 사용'동등성(equivalence) 비교: 인스턴스의 값을 비교, equals() 사용값 타입은 반드시 a.equals(b)

값 타입 공유 참조임베디드 타입 같은 값 타입을 여러 엔티티에서 공유하면 위험(부작용 발생)참조값을 공유하기 때문에 변경된 값이 여러 엔티티에 전부 반영값 타입 복사값 타입의 실제 인스턴스인 값을 공유하는 것은 위험따라서, 값(인스턴스)를 복사해서 사용객체 타입의 한계

1\. 기본개념새로운 값 타입을 직접 정의JPA에서는 임베디드 타입이라고 명명주로 기본값 타입을 모아서 만들기 때문에 "복합값 타입"이라고도 부름int, String 과 같은 값 타입(엔티티X, 변경시 추적 불가)예시)2\. 사용법@Embeddable: 값 타입을 정의

1\. JPA의 데이터 타입 분류1) 엔티티 타입@Entity로 정의하는 객체식별자가 존재 => 데이터가 변해도 지속해서 추적 가능2) 값 타입int, Integer, String과 같이 단순 값으로 사용하는 자바 기본 타입이나 객체식별자가 없음(값만 존재) => 데이

기본개념부모 엔티티와 연관관계가 끊어진 자식 엔티티를 자동으로 삭제orphanRemoval = true컬렉션에서 빠진 첫번째 자식은 DB에서 자동 삭제주의점참조가 제거된 엔티티는 다른 곳에서 참조하지 않는 고아 객체로 보고 삭제되는 기능@OneToOne, @OneToM

기본개념특정 엔티티를 영속상태로 만들 때 연관된 엔티티도 영속상태로 만드는 것