JPA 기본 정리 #4

임베디드 타입 ( 값 타입 )

• 식별자가 없다.
• 한 엔티티안에 종속되어 라이프 사이클도 종속된다.
  • 엔티티가 삭제되면 함께 삭제된다.
  • CasCadeType.ALL && 고아객체로 설정한 것과 같다.
• 식별자가 없으므로 추적도 불가능 하다.

JPQL

• 객체지향 쿼리언어이다.
• SQL을 추상화한 언어이기 때문에 특정 데이터베이스에 종속되지 않는다.
• 문법은 sql 과 거의 유사하다.

JPQL 문법

• COALESCE : null 값인 경우 반환 값 지정
  • ⇒ coalesce(m.name, ‘이름 없는 회원’)
• NULLIF : 조건에 맞으면 null 반환
  • ⇒ NULLIF(m.name, ‘홍길동’) 이름이 홍길동이면 null 반환
• CONCAT : 문자열 더하기
  • concat(’a’, ‘b’)
• SUBSTRING : 시작위치, 길이 지정하여 문자열 자르기
  • substring(m.name, 2, 3)
• LOCATE : 찾는 문자열의 시작 위치 반환 (1부터 시작)
  • locate(’de’, ‘abcedegf’)

경로 표현

• 상태 필드 : 경로 탐색의 끝. 단순히 값을 저장하는 필드.
• 연관 필드
  • 단일 연관 필드 : 엔티티 안에 있는 엔티티 ⇒ 조회한 엔티티로 계속 탐색 가능
  • 컬렉션 연관 필드 : 엔티티 안에 있는 컬렉션
  • 묵시적 조인 vs 명시적 조인
    • select m.team from Member m 이렇게 쿼리문을 작성하면 묵시적 조인이 일어난다.
    • 명시적 조인 : select t from Member m join m.team t
    • 명시적 조인을 한 경우 지정한 별칭으로 컬렉션 연관 필드에서 계속 탐색 가능하다.
    • 묵시적 조인은 항상 내부 조인만 사용하고, 한 눈에 파악하기 어렵다. 명시적 조인을 사용하자

Fetch Join

• 연관된 엔티티까지 모두 조회가 필요할 때, 앞에서 강조하였던 LAZY 전략은 여러번의 쿼리를 실행하게 되는 문제가 있고, 즉시 로딩은 너무 많은 join으로 인해 성능이 느려질 수 있다는 문제가 있다고 하는데 이때 사용할 수 있는 것이 페치 조인이다.

select m from Member m join fetch m.team

Member 의 연관 필드인 team을 항상 같이 조회할 필요가 있을 때 이렇게 fetch 조인을 통해 명시적으로 조인할 수 있다.

즉시 로딩과 같은 기능을 하지만 명시적으로 join을 한다는 점과 필요한 부분만 join할 수 있다는 점이 다르다.

Fetch Join 문제

• 페치 조인으로도 해결할 수 없는 부분이 있다.
• 일대다 연관관계 매핑인 경우 fetch join을 하게 되면 일에 대해 다 개수만큼 매치가 되면서 결과값이 배로 늘어나게 된다.
• 위의 이유로 페이징 처리를 할 수 없다.
• 이때 BatchSize 옵션을 사용하여 사이즈를 지정해주고 그 사이즈만큼 한 번에 관련 엔티티들을 모두 조회해 와서 성능최적화를 할 수 있다.

Named 쿼리

• 미리 쿼리를 정의해서 사용할 수 있다.
• 애플리케이션 로딩시점에 초기화 시킨다. 미리 파싱을 해놓는다.
  • 쿼리문에 오류가 있다면 컴파일 시점에 발견할 수 있다.

벌크 연산

• 쿼리 한 번으로 여러 테이블의 로우를 변경하는 것을 말한다.
• 벌크 연산은 영속성 컨텍스트가 아닌 데이터베이스에 바로 접근하여 업데이트 한다.
• 그래서 데이터베이스만 변경이 되고 영속성 컨텍스트에서는 변경이 안되기 때문에 문제가 생길 수 있다.
  • 두 개를 동기화 해주기 위해 영속성 컨텍스트에 값이 없는 상태이거나
  • 벌크 연산을 한 후에는 영속성 컨텍스트 clear를 해주는 작업이 꼭 필요하다.

 

- 인프런 김영한님의 JPA 기본편을 듣고 정리한 내용입니다 -