JPA(Java Persistence API) 프로그래밍 - 객체지향 쿼리 언어(고급 문법)

u-nij·2022년 9월 13일

JPA Java

JPA 프로그래밍

목록 보기

10/10

이 글은 김영한님의 자바 ORM 표준 JPA 프로그래밍 - 기본편 강의를 듣고 정리한 글입니다.

경로 표현식

.(점)을 찍어 객체 그래프를 탐색하는 것
필드에 따라 내부적으로 동작하는 방식이 다르기 때문에 세 가지의 차이를 이해해야 함

    select m.username // 상태 필드
    		from Member m 
    				join m.team t // 단일 값 연관 필드
    				join m.orders o // 컬렉션 값 연관 필드
    where t.name = '팀A'

경로 표현식 용어 정리

상태 필드(state field): 단순히 값을 저장하기 위한 필드 (ex: m.username)
연관 필드(association field): 연관관계를 위한 필드
- 단일 값 연관 필드: @ManyToOne, @OneToOne, 대상이 엔티티(ex: m.team)
- 컬렉션 값 연관 필드: @OneToMany, @ManyToMany, 대상이 컬렉션(ex: m.orders)

경로 표현식 특징

특징을 이해하면 JPQL과 SQL의 차이를 명확히 알 수 있음
상태 필드(state field): 경로 탐색의 끝, 그 이상 탐색X

    select m.username from Member m

단일 값 연관 경로: 묵시적 내부 조인(inner join) 발생, 그 이상 탐색O
- SQL은 Member와 Team을 내부 조인해 Team을 SELECT 프로젝션에 나열함
- 실무에서는 묵시적 내부 조인이 발생하지 않도록 조심히 사용해야 함

    select m.team from Member m // 탐색 가능
    select m.team.name from Member m // 경로 탐색의 끝. 상태 필드가 됨.

컬렉션 값 연관 경로: 묵시적 내부 조인 발생, 그 이상 탐색X

    select t.members from Team t // 일대다 관계인 컬렉션(members) 중 어떤 것을 선택할지 난감

FROM 절에서 명시적 조인을 통해 별칭을 얻으면 별칭을 통해 탐색 가능

    select m.username From Team t join t.members m
    // 명시적 조인을 이용해 컬렉션을 가져와 별칭 m을 통해 탐색

상태 필드 경로 탐색

JPQL, SQL:

    select m.username, m.age from Member m

단일 값 연관 경로 탐색

JPQL:

    select o.member from Order o // 💡 o.member

SQL:

    select m.*
    from Orders o
    inner join Member m on o.member_id = m.id // 💡

SQL에서 묵시적 조인이 발생함

명시적 조인, 묵시적 조인

명시적 조인: join 키워드 직접 사용

    select m from Member m join m.team t // 💡 join m.team t

묵시적 조인: 경로 표현식에 의해 묵시적으로 SQL 조인 발생(내부 조인만 가능. 외부 조인 하려면 명시적 조인 사용)

    select m.team from Member m // 💡 m.team

경로 표현식 예제

select o.member.team from Order o // 성공 (단, 문제는 조인이 2번 발생함.)
select t.members from Team // 성공 (컬렉션. 더 이상의 탐색 불가능.)
select t.members.username from Team t // 실패
select m.username from Team t join t.members m // 성공

경로 탐색을 사용한 묵시적 조인 시 주의사항

항상 내부 조인
컬렉션은 경로 탐색의 끝, 명시적 조인을 통해 별칭을 얻어야 .을 통해 탐색을 이어갈 수 있음
경로 탐색은 주로 SELECT, WHERE 절에서 사용하지만 묵시적 조인으로 인해 SQL의 FROM(JOIN) 절에 영향을 줌

실무 조언

가급적 묵시적 조인 대신에 "명시적 조인" 사용
조인은 SQL 튜닝에 중요 포인트
묵시적 조인은 조인이 일어나는 상황을 한눈에 파악하기 어려움

페치 조인(fetch join)

실무에서 정말정말 중요함
SQL 조인 종류X
JPQL에서 성능 최적화를 위해 제공하는 기능
연관된 엔티티나 컬렉션을 SQL 한 번에 함께 조회하는 기능
join fetch 명령어 사용
페치 조인 ::= [ LEFT [OUTER] | INNER ] JOIN FETCH 조인경로

엔티티 페치 조인

회원을 조회하면서 연관된 팀도 함께 조회(SQL 한 번에)
SQL을 보면 회원 뿐만 아니라 팀(T.)*도 함께 SELECT**
JPQL:

    select m from Member m join fetch m.team // 💡 join fetch

SQL:

SELECT M.*, T.* FROM MEMBER M // 💡 T.*
INNER JOIN TEAM T ON M.TEAM_ID=T.ID // 💡 INNER JOIN TEAM T
// 즉시 로딩해서 가져올 때와 같음
// 쿼리로 원하는 어떤 객체 그래프를 조회할건지 명시적으로, 동적인 타이밍에 작성

LEFT JOIN이면 팀이 없는 회원도 나오지만, INNER JOIN이기 때문에 누락됨

페치 조인 사용 코드

페치조인을 사용하지 않았을 경우

String jpql = "select m from Member m"; 
List<Member> members = em.createQuery(jpql, Member.class) 
		.getResultList(); 
for (Member member : members) {
		System.out.println("username = " + member.getUsername() + ", " + 
				"teamName = " + member.getTeam().name()); 
}

Member와 Team의 연관관계가 @ManyToOne(fetch = FetchType.LAZY)이므로, Team이 프록시로 들어오고, 지연로딩이 일어남.
Team이 getName()을 호출하는 시점마다 데이터베이스에 쿼리를 날리게 됨. 영속성 컨텍스트에 조회.
Member 3개를 가지고 온 후,
루프를 돌며 Team을 가져옴.
프록시인 Team이 영속성 컨텍스트에게서 이름을 요청할 때 쿼리가 시작됨.

username = 회원1, teamname = 팀A // 회원1, 팀A(SQL)
username = 회원2, teamname = 팀A // 회원2, 팀A(1차캐시)
username = 회원3, teamname = 팀B // 회원3, 팀B(SQL)

팀이 각기 다른 회원 100명일 경우, N(팀 100개) + 1(회원)개의 쿼리가 날아감.

페치 조인을 사용했을 경우
- getTeam()으로 가져온 Team은 프록시가 아니라, 실제 채워져있는 데이터(엔티티)

    String jpql = "select m from Member m join fetch m.team"; 
    List<Member> members = em.createQuery(jpql, Member.class) 
    		.getResultList(); 
    for (Member member : members) {
    		//페치 조인으로 회원과 팀을 함께 조회해서 지연 로딩X
    		System.out.println("username = " + member.getUsername() + ", " + 
    				"teamName = " + member.getTeam().name()); 
    }

컬렉션 페치 조인

일대다 관계, 컬렉션 페치 조인
JPQL

    select t
    from Team t join fetch t.members // 💡
    where t.name = '팀A' // 반대로, 팀에 관련된 데이터들을 가져옴

    SELECT T.*, M.*
	FROM TEAM T
	INNER JOIN MEMBER M ON T.ID=M.TEAM_ID
	WHERE T.NAME = '팀A'

팀A 입장에서는 하나지만, 멤버가 2명이기 때문에 줄 수가 2개가 됨
DB 입장에서 일대다 관계일 때 데이터가 뻥튀기되기 때문에, 컬렉션일 때 주의해야 함
객체와 RDB와의 차이
- JPA는 팀에 회원이 몇 명 있을지 알 수 없기 때문에 할 수 있는 것이 없음
- DB에서 주는대로 가져와야 함
ID(PK)가 둘 다 1 → 영속성 컨텍스트에 있는 같은 주소 값에 있는 것(0x100)을 씀
fetch join을 했기 때문에 회원1과 회원2

컬렉션 페치 조인 사용 코드

String jpql = "select t from Team t join fetch t.members where t.name = '팀A'" 
List<Team> teams = em.createQuery(jpql, Team.class).getResultList(); 
for(Team team : teams) { 
		System.out.println("teamname = " + team.getName() + ", team = " + team); 
		for (Member member : team.getMembers()) { 
				//페치 조인으로 팀과 회원을 함께 조회해서 지연 로딩 발생 안함
				System.out.println("-> username = " + member.getUsername()+
						", member = " + member); 
		} 
}

똑같은 팀A가 출력됨

페치 조인과 DISTINCT

SQL의 DISTINCT는 중복된 결과를 제거하는 명령
- 이것만으로 중복을 전부 제거할 수 없음
JPQL의 DISTINCT 2가지 기능 제공
- 1. SQL에 DISTINCT를 추가
- 1. 애플리케이션에서 엔티티 중복 제거

참고: 일대다 관계일때, 조인하면서 데이터 뻥튀기 차이

페치 조인을 사용하지 않을 경우
select distinct t
from Team t
size = 2

페치 조인을 사용할 경우
select distinct t
from Team t join fetch t.members
size = 3

참고: 다대일 관계일 때는 뻥튀기되지 않음

select distinct t // 💡 distinct
from Team t join fetch t.members
where t.name = '팀A'

SQL에 DISTINCT를 추가하지만 데이터가 다르므로 SQL 결과에서 중복제거 실패
DISTINCT가 추가로 애플리케이션에서 중복 제거시도
같은 식별자를 가진 Team 엔티티 제거

페치 조인과 일반 조인의 차이

일반 조인 실행시 연관된 엔티티를 함께 조회하지 않음
여기서는 팀 엔티티만 조회하고, 회원 엔티티는 조회X
JPQL

    select t
    from Team t join t.members m
    where t.name = '팀A'

    SELECT T.* // 💡 T.*
    FROM TEAM T
    INNER JOIN MEMBER M ON T.ID=M.TEAM_ID 
    WHERE T.NAME = '팀A'

일반 조인은 SELECT 절에서 Team만 가져옴
JPQL은 결과를 반환할 때 연관관계 고려X
단지 SELECT 절에 지정한 엔티티만 조회할 뿐
페치 조인을 사용할 때만 연관된 엔티티도 함께 조회(즉시 로딩)
페치 조인은 객체 그래프를 SQL 한번에 조회하는 개념

페치 조인 실행 예시

페치 조인은 연관된 엔티티를 함께 조회함
JPQL

    select t
    from Team t join fetch t.members m // 💡 join fetch
    where t.name = '팀A'

    SELECT T.*, M.* // 💡 T.*, M.*
    FROM TEAM T
    INNER JOIN MEMBER M ON T.ID=M.TEAM_ID 
    WHERE T.NAME = '팀A'

페치 조인의 특징과 한계

페치 조인 대상에는 별칭을 줄 수 없다.
- 하이버네이트는 가능, 가급적 사용X
```
    select t from Team t join t.members as m // X
    select t from Team t join t.members as m where m.age > 10 // X
```
- 페치 조인은 연관된 것들을 모두 끌고 오는 기능이므로, 따로 조회해야 한다.
- 팀의 멤버 중 5명을 조회 싶을 경우, 별칭을 이용해 팀에서 멤버를 가져오는 것보다 처음부터 멤버를 5개 조회하는 쿼리를 따로 날려야 한다.
```
    @Entity
    public class Team {
        @OneToMany(mappedBy = "team")
        private List<Member> members = new ArrayList<>();
    }
```
- JPA에서 객체 그래프를 탐색한다는 것은 Team에서 Members를 조회할 경우, Members의 모든 것이 다 나온다는 것을 가정하고 설계되어 있음.
- 똑같은 팀A를 조회했을 때 한 쪽에서는 100개 중 5개만 조회하고 다른 쪽에서는 100개 전부 조회했을 때, 영속성 컨텍스트에서 컨트롤을 보장할 수 없다.
둘 이상의 컬렉션은 페치 조인 할 수 없다.
- Team-Members, Team-Orders가 있을 경우. 일대다대다(곱)가 되어버리므로 데이터가 예상하지 못하게 늘어날 수 있다.
- 페치 조인의 컬렉션은 하나만 지정할 수 있다.
컬렉션을 페치 조인하면 페이징 API(setFirstResult, setMaxResults)를 사용할 수 없다.
- 일대일, 다대일 같은 단일 값 연관 필드들은 페치 조인해도 페이징 가능(데이터 뻥튀기가 되지 않음)
- 일대다에서 데이터 뻥튀기가 되어 데이터가 예상하지 못하게 조작될 수 있다.
- 하이버네이트는 경고 로그를 남기고 메모리에서 페이징(매우 위험)
- JPA 객체 그래프 탐색 설계에 따라 DB에서 팀에 대한 데이터를 다 끌고 옴. (쿼리를 보면 페이징을 하지 않음)
- 방법1) 방향을 뒤집기
```
    select t from Team t join fetch t.members m // 일대다를
    select m from Member m join fetch m.team t // 다대일로
```
- 방법2) @Batchsize
```
	String query27 = "select t from Team t";
	List<Team> resultList19 = em.createQuery(query27, Team.class)
			.setFirstResult(0)
			.setMaxResults(2)
			.getResultList();

	System.out.println("result = " + resultList19.size());

	for (Team team : resultList19) {
			System.out.println("username = " + team.getName() + " | team = " + team);
			for (Member member : team.getMembers()) {
					System.out.println("-> username = " + member.getUsername() +
							", member = " + member);
			}
	}
```
- Team에서 Members를 가져올 때 지연 로딩이기 때문에, 팀을 불러오는 쿼리 1개 + 각 팀과 연관된 멤버들에 쿼리 N개 ⇒ N+1 문제(성능 저하)
- 페치 조인을 사용하거나, 컬렉션일 경우 @Batchsize를 통해 N+1 문제 해결 가능
```
	@Batchsize(size = 100) // 한번에 인쿼리로 100개씩 넘김
	@Entity
	public class Team {
	    @OneToMany(mappedBy = "team")
	    private List<Member> members = new ArrayList<>();
	}
```
- @Batchsize를 통해 팀A, 팀B와 연관된 멤버들을 한꺼번에 가져올 수 있다.
- 팀A, 팀B이기때문에 ?가 2개임
- persistence.xml에 작성해 글로벌 세팅 가능
```
    <property name="hibernate.default_batch_fetch_size" value="100" />
```
- 방법3) DTO로 쿼리 작성
연관된 엔티티들을 SQL 한 번으로 조회해 성능 최적화
엔티티에 직접 적용하는 글로벌 로딩 전략보다 우선함
- @OneToMany(fetch = FetchType.LAZY) //글로벌 로딩 전략
실무에서 글로벌 로딩 전략은 모두 지연 로딩
최적화가 필요한 곳은 페치 조인 적용(N+1 문제가 발생하는 곳)

정리

모든 것을 페치 조인으로 해결할 수 는 없음
페치 조인은 객체 그래프를 유지할 때 사용하면 효과적
여러 테이블을 조인해서 엔티티가 가진 모양이 아닌 전혀 다른 결과를 내야 하면, 페치 조인보다는 일반 조인을 사용하고 필요한 데이터들만 조회해서 DTO로 반환하는 것이 효과적
페치 조인에 대해 100% 이해가 필수

다형성 쿼리

TYPE

조회 대상을 특정 자식으로 한정
예) Item 중에 Book, Movie를 조회해라
JPQL

    select i from Item i
    where type(i) IN (Book, Movie)

    select i from i
    where i.DTYPE in (‘B’, ‘M’)

TREAT(JPA 2.1)

자바의 타입 캐스팅과 유사
상속 구조에서 부모 타입을 특정 자식 타입으로 다룰 때 사용
FROM, WHERE, SELECT(하이버네이트 지원) 사용
예) 부모인 Item과 자식 Book이 있을 때
JPQL

    select i from Item i
    where treat(i as Book).auther = 'kim'
    // 다운캐스팅

    select i.* from Item i
    where i.DTYPE = 'B' and i.auther = 'kim'

엔티티 직접 사용

기본키 값

JPQL에서 엔티티를 직접 사용하면, SQL에서 해당 엔티티의 기본키 값을 사용
엔티티 자체가 DB로 넘어가면 구분하는 것이 PK 값이기 때문
JPQL

    select count(m.id) from Member m // 엔티티의 아이디를 사용
    select count(m) from Member m // 엔티티를 직접 사용

SQL(JPQL 둘다 같은 SQL 실행)

    select count(m.id) as cnt from Member m // SQL에서 기본키 값으로 바뀜

엔티티를 파라미터로 전달

    String jpql = "select m from Member m where m = :member"; // 💡 m = :member
    List resultList = em.createQuery(jpql) 
    		.setParameter("member", member) // 💡
    		.getResultList();

식별자를 직접 전달

    String jpql = "select m from Member m where m.id = :memberId"; // 💡 m.id = :memberId
    List resultList = em.createQuery(jpql) 
    		.setParameter("memberId", member.getId()) // 💡
    		.getResultList();

실행된 SQL

	select m.* from Member m where m.id=? // 💡 m.id = ?

외래키 값

Team team = em.find(Team.class, 1L); // 💡 team
String qlString = "select m from Member m where m.team = :team"; // 💡 m.team = :team
List resultList = em.createQuery(qlString) 
 .setParameter("team", team) // 💡 team
 .getResultList();

파라미터로 넘긴 team은 PK이고, m.team은 DB 입장에서 FK와 매핑되어 외래키로 인정됨
m.team은 member가 team에 대한 외래키 값을 들고 있는 것
객체 입장에서는 PK든 FK이든 객체. DB 입장에서는 식별자.

String qlString = "select m from Member m where m.team.id = :teamId"; // 💡 m.team.id = :teamId
List resultList = em.createQuery(qlString) 
 .setParameter("teamId", teamId) // 💡 teamId
 .getResultList();

실행된 SQL

	select m.* from Member m where m.team_id=? // 💡 m.team_id=?

Named 쿼리

정적 쿼리

미리 정의해서 쿼리에 이름을 부여해두고 사용하는 JPQL
정적 쿼리만 가능
어노테이션, XML에 정의
애플리케이션 로딩 시점에 초기화 후 재사용할 수 있다
애플리케이션 로딩 시점에 쿼리를 검증할 수 있다
- 어노테이션에 등록되어 있기 때문에 로딩시점에 JPA가 쿼리를 SQL로 파싱한다
- 오타가 발생했을 경우 컴파일 에러를 발생시켜 문법 오류를 즉각적으로 파악할 수 있다

어노테이션

@Entity
@NamedQuery( // 💡
	name = "Member.findByUsername",
	query="select m from Member m where m.username = :username")
public class Member {
	// ...
}

List<Member> resultList = 
	em.createNamedQuery("Member.findByUsername", Member.class)
	.setParameter("username", "회원1")
	.getResultList();

XML에 정의

META-INF/persistence.xml

<persistence-unit name="jpabook">
    <mapping-file>META-INF/ormMember.xml</mapping-file>

META-INF/ormMember.xml

<?xml version="1.0" encoding="UTF-8"?>
<entity-mappings xmlns="http://xmlns.jcp.org/xml/ns/persistence/orm" version="2.1">
    <named-query name="Member.findByUsername">
    	<query><![CDATA[
    		select m
    		from Member m
    		where m.username = :username
    	]]></query>
    </named-query>
    <named-query name="Member.count">
    	<query>select count(m) from Member m</query>
    </named-query>
</entity-mappings>

Named 쿼리 환경에 따른 설정

XML이 항상 우선권을 가진다.
애플리케이션 운영 환경에 따라 다른 XML을 배포할 수 있다
- 예를 들어, 특정 상황마다 다른 쿼리가 나가야할 경우

Spring Data JPA의 이름 없는 Named 쿼리
Spring Data JPA에서는 인터페이스 메소드 위에 바로 선언할 수 있다. JPA에서는 이 방법을 이용해 NamedQuery로 등록해 사용할 수 있다. 애플리케이션 로딩 시점에 쿼리를 파싱한다.
(참고: Spring Data JPA 레퍼런스)

벌크 연산

PK 한 건에 대한 것을 제외한 UPDATE문과 DELETE문
재고가 10개 미만인 모든 상품의 가격을 10% 상승하려면?
JPA 변경 감지 기능으로 실행하려면 너무 많은 SQL을 실행
- 1. 재고가 10개 미만인 상품을 리스트로 조회한다.
- 1. 상품 엔티티의 가격을 10% 증가한다.
- 1. 트랜잭션 커밋 시점에 변경감지가 동작한다.
변경된 데이터가 100건이라면 100번의 UPDATE SQL 실행

예제

쿼리 한 번으로 여러 테이블 로우 변경(엔티티)
executeUpdate()의 결과는 영향받은 엔티티 수 반환
UPDATE, DELETE 지원
INSERT(insert into .. select, 하이버네이트 지원)

String qlString = "update Product p " +
	"set p.price = p.price * 1.1 " + 
	"where p.stockAmount < :stockAmount"; 
int resultCount = em.createQuery(qlString) 
	.setParameter("stockAmount", 10) 
	.executeUpdate();

다른 예제

int resultCount = em.createQuery("update Member m set m.age = 20")
	.executeUpdate();
System.out.println("resultCount = " + resultCount);

주의

벌크 연산은 영속성 컨텍스트를 무시하고 데이터베이스에 직접 쿼리를 날리기 떄문에 잘못하면 순서가 꼬인다
FLUSH가 자동호출된다. FLUSH가 나가고 UPDATE문이 나가기 때문에 영속성 컨텍스트에 있는 것에 대해 고민하지 않아도 된다.
- FLUSH는 commit, query가 나갈 때 자동호출하거나 강제호출해 사용할 수 있다.
해결책1) 영속성 컨텍스트에 작업하기 전에 벌크 연산을 먼저 실행
해결책2) 벌크 연산 수행(JPQL이 실행되는 것이기 때문에 flush가 됨) 후 영속성 컨텍스트만 초기화
- 옛날에 조회했던 회원의 연봉이 5천만원이었을 때, 벌크 연산으로 6천만원이 됐을 경우
- DB에는 6천만원, 애플리케이션에는 5천만원으로 남아있음
- 이 경우에 영속성 컨텍스트를 초기화한 후에 다시 조회하면 똑같은 상태가 된다.

Member member = new Member();
member.setAge(0);
em.persist(member);

// em.flush();
// em.clear();

// 벌크연산
// flush() 자동 호출 & DB에 강제로 업데이트
int resultCount = em.createQuery("update Member m set m.age = 20")
                    .executeUpdate();
// DB에만 업데이트된 상태
System.out.println("resultCount = " + resultCount);
// 영속성컨텍스트에는 반영되어 있지 않음
System.out.println("member.getAge() = " + member.getAge());

// 영속성 초기화 후 다시 값 불러옴
em.clear();
Member memberInit = em.find(Member.class, member1.getId());
System.out.println("memberInit.getAge() = " + memberInit.getAge());

Spring Data JPA에서도 벌크 연산을 사용할 수 있다.

u-nij

삶은 달걀이다

이전 포스트

JPA(Java Persistence API) 프로그래밍 - 객체지향 쿼리 언어(고급 문법)

JPA 프로그래밍

경로 표현식

경로 표현식 용어 정리

경로 표현식 특징

상태 필드 경로 탐색

단일 값 연관 경로 탐색

명시적 조인, 묵시적 조인

경로 표현식 예제

경로 탐색을 사용한 묵시적 조인 시 주의사항

실무 조언

페치 조인(fetch join)

엔티티 페치 조인

페치 조인 사용 코드

컬렉션 페치 조인

컬렉션 페치 조인 사용 코드

페치 조인과 DISTINCT

페치 조인과 일반 조인의 차이

페치 조인 실행 예시

페치 조인의 특징과 한계

정리

다형성 쿼리

TYPE

TREAT(JPA 2.1)

엔티티 직접 사용

기본키 값

외래키 값

Named 쿼리

정적 쿼리

어노테이션

XML에 정의

Named 쿼리 환경에 따른 설정

벌크 연산

예제

주의

JPA(Java Persistence API) 프로그래밍 - 객체지향 쿼리 언어(기본 문법)

0개의 댓글