JPQL - 경로 표현식
경로 표현식 : .(점)을 찍어 객체 그래프를 탐색하는 것을 경로 표현식이라고 한다.
ex)
select m.username -> 상태 필드(엔티티 안에서 값을 바로 찍음)
from Member m
join m.team t -> 단일 값 연관 필드(엔티티에서 엔티티를 찍음)
join m.orders o -> 컬렉션 값 연관 필드(엔티티에서 컬렉션을 찍음)
where t.name = '팀A'
상태 필드(state field) : 단순히 값을 저장하기 위한 필드
연관 필드(association field) : 연관관계를 위한 필드
- 단일 값 연관 필드 : @ManyToOne, @OneToOne, 대상이 엔티티
- 컬렉션 값 연관 필드 : @OneToMany, @ManyToMany, 대상이 컬렉션
**상태 필드는 엔티티 상태값을 나타내는 필드이고, 단일 값과 컬렉션 값은 엔티티에 연관관계가 있는 값을 나타낸다. 그래서 상태필드는 탐색이 당연히 안된다. ++ 단일값은 값 한개짜리, 컬렉션 값은 값 여러개짜리
경로 표현식의 특징
상태 필드(state field) : 경로 탐색의 끝, 탐색 X
단일 값 연관 경로 : 묵시적 내부 조인(inner join)이 발생, 탐색 O
컬렉션 값 연관 경로 : 묵시적 내부 조인(inner join)이 발생, 탐색 X
- FROM 절에서 명시적 조인을 통해 별칭을 얻으면 별칭을 통해 탐색이 가능하다.
상태필드의 값을 테스트해보자.
Member member1 = new Member();
member1.setUsername("관리자1");
em.persist(member1);
Member member2 = new Member();
member2.setUsername("관리자2");
em.persist(member2);
em.flush();
em.clear();
String query = "select m.username From Member m";
List<String> resultList =
em.createQuery(query, String.class).getResultList();
for (String s : resultList) {
System.out.println("s = " + s);
}
tx.commit();Hibernate:
/* select
m.username
From
Member m */ select
m1_0.username
from
Member m1_0
s = 관리자1
s = 관리자2
내가 원하는 쿼리가 날아간 것을 확인할 수 있다.
하지만 m.team으로 단일 값 연관경로를 설정한다면 어떻게 될까??
Member member1 = new Member();
member1.setUsername("관리자1");
em.persist(member1);
Member member2 = new Member();
member2.setUsername("관리자2");
em.persist(member2);
em.flush();
em.clear();
String query = "select m.team From Member m";
List<String> resultList =
em.createQuery(query, String.class).getResultList();
for (String s : resultList) {
System.out.println("s = " + s);
}
tx.commit();Hibernate:
/* select
m.team
From
Member m */ select
t1_0.id,
t1_0.name
from
Member m1_0
join
Team t1_0
on t1_0.id=m1_0.TEAM_ID
결과를 보면 m.team을 함으로써 조인이 발생되게 되었다.
객체 입장에서야 .을찍어 가면 되지만 DB입장에서는 조인이 발생되어야 한다.
--> 이렇듯 단일 값 경로로 가게 되면 묵시적인 조인이 발생하게 된다.
실무에서는 묵시적 조인을 최대한 배제해야 한다.
만약 컬렉션 값을 받을땐 어떻게 될까?(현재 Team 값이 없기 때문에 따로 결과가 출력되진 않는다.)
Member member1 = new Member();
member1.setUsername("관리자1");
em.persist(member1);
Member member2 = new Member();
member2.setUsername("관리자2");
em.persist(member2);
em.flush();
em.clear();
String query = "select t.members From Team t";
Collection result =
em.createQuery(query, Collection.class).getResultList();
for (Object s : result) {
System.out.println("s = " + s);
}
tx.commit();Hibernate:
/* select
t.members
From
Team t */ select
m1_0.id,
m1_0.age,
t1_0.id,
t1_0.name,
m1_0.type,
m1_0.username
from
Team t1_0
join
Member m1_0
on t1_0.id=m1_0.TEAM_ID
-> 컬렉션의 어떤 값을 가리키는지 알 수 없다.
--> 컬렉션에서는 필드를 찍을 수 있거나 무언가를 탐색해서 갈 수 없기 때문에 탐색이 불가능하다.(컬렉션 자체를 가리키기 때문에 size정도밖에 사용하지 못한다.)
하지만 From 절에서 명시적으로 조인을 사용하여 별칭을 얻게되면 별칭을 통해 탐색이 가능하다.
** 결론적으로 묵시적 JOIN은 발생하지 않게 쿼리를 짜는 것이 좋다. 실무에서는 DB가 한두개만 맞물려서 돌아가는 것이 아니라 여러개가 맞물려 돌아가기 때문에 찾기도 어렵고, 문제가 발생하기 때문이다. **
select o.member.team from Order o -> 성공
select t.members from Team -> 성공
select t.members.username from Team t -> 실패
select m.username from Team t join t.members m -> 성공
실무 TIP
1. 가급적 묵시적 조인 대신에 명시적 조인 사용
2. 조인은 SQL 튜닝에 중요 포인트
3. 묵시적 조인은 조인이 일어나는 상황을 한눈에 파악하기 어렵다.
페치 조인 1 - 기본
페치 조인은 실무에서 정말 중요하다. 페치 조인을 모르는 상태에서는 실무 진행이 불가능 할 정도로 중요도가 높다.
페치 조인(fetch join)
- 페치 조인은 SQL 조인의 종류가 아니다.
- JPQL에서 성능 최적화를 위해 제공하는 기능이다.
- 연관된 엔티티나 컬렉션을 SQL 한번에 함께 조회하는 기능이다.
- join fetch 명령어 사용
- 페치 조인 ::= [LEFT [OUTER] | INNER] JOIN FETCH 조인경로
엔티티 페치 조인
- 회원을 조회하면서 연관된 팀도 함께 조회하고 싶을 때(SQL을 한번에)
- SQL을 보면 회원 뿐만 아니라 팀(T.*)도 함께 SELECT
- [JPQL]
select m from Member m join fetch m.team
- [SQL]
SELECT M.*, T.* FROM MEMBER M INNER JOIN TEAM T ON M.TEAM_ID=T.ID
Team teamA = new Team();
teamA.setName("팀A");
em.persist(teamA);
Team teamB = new Team();
teamB.setName("팀B");
em.persist(teamB);
Member member1 = new Member();
member1.setUsername("회원1");
member1.setTeam(teamA);
em.persist(member1);
Member member2 = new Member();
member2.setUsername("회원2");
member2.setTeam(teamA);
em.persist(member2);
Member member3 = new Member();
member3.setUsername("회원3");
member3.setTeam(teamB);
em.persist(member3);
em.flush();
em.clear();
String query = "select m From Member m";
List<Member> result = em.createQuery(query, Member.class).getResultList();
for (Member member : result) {
System.out.println("member = " + member.getUsername()+ ", " + member.getTeam().getName());
}
tx.commit();위와 같은 코드가 있다고 가정해보자. 위 코드는
우선 Member와 Team의 연관관계가 ManyToOne이고 fetch의 타입이 LAZY이다.
여기서 SELECT MEMBER를 하게 되면 TEAM은 Proxy로 들어오게 된다. 이후 실제로 member.getTeam().getName()을 호출하는 시점마다 DB에 쿼리를 날리게 된다.
Hibernate:
select
t1_0.id,
t1_0.name
from
Team t1_0
where
t1_0.id=?
member = 회원1, 팀A
member = 회원2, 팀A
Hibernate:
select
t1_0.id,
t1_0.name
from
Team t1_0
where
t1_0.id=?
member = 회원3, 팀B
--> TeamA를 찾았을때, TeamB를 찾았을 떄 나옴
DB에 있는걸 영속성 컨텍스트로 끌어올려야 하기 때문
//회원 1, 팀A -> SQL
//회원 2, 팀A -> 1차캐시
//회원 3, 팀B -> SQL
//회원이 100명일 시 -> N+1
재수가 없으면 쿼리가 정말 많이 나갈 수 있다. 이러한 문제를 해결하기 위해 fetch join을 사용한다.
String query = "select m From Member m join fetch m.team";
join을 할 때 team을 한번에 같이 긁어 오라고 할 수 있다.
Hibernate:
/* select
m
From
Member m
join
fetch
m.team */ select
m1_0.id,
m1_0.age,
t1_0.id,
t1_0.name,
m1_0.type,
m1_0.username
from
Member m1_0
join
Team t1_0
on t1_0.id=m1_0.TEAM_ID
member = 회원1, 팀A
member = 회원2, 팀A
member = 회원3, 팀B
JOIN으로 한방쿼리가 나간 후 1차캐시에 올라온 실제 값들을 iter로 조회되는 것을 관찰할 수 있다.
** 지연로딩으로 설정을 하여도 fetch join이 항상 우선순위를 가진다. **
Team teamA = new Team();
teamA.setName("팀A");
em.persist(teamA);
Team teamB = new Team();
teamB.setName("팀B");
em.persist(teamB);
Member member1 = new Member();
member1.setUsername("회원1");
member1.setTeam(teamA);
em.persist(member1);
Member member2 = new Member();
member2.setUsername("회원2");
member2.setTeam(teamA);
em.persist(member2);
Member member3 = new Member();
member3.setUsername("회원3");
member3.setTeam(teamB);
em.persist(member3);
em.flush();
em.clear();
String query = "select t From Team t join fetch t.members";
List<Team> result =
em.createQuery(query, Team.class).getResultList();
for (Team team : result) {
System.out.println("team.getName() = " + team.getName() + " |members" + team.getMembers().size());
//회원이 100명일 시 ->
}
tx.commit();
컬렉션 페치 조인
- 일대다 관계, 컬렉션 페치 조인
-[JPQL]
select t
from Team t join fetch t.members
where t.name = '팀A'
-[SQL]
SELECT T.*, M.*
FROM TEAM T
INNER JOIN MEMBER M ON T.ID=M.TEAM_ID
WHERE T.NAME = '팀A'
Team team1 = new Team();
team1.setName("팀A");
em.persist(team1);
Team team2 = new Team();
team2.setName("팀B");
em.persist(team2);
Member member1 = new Member();
member1.setUsername("회원1");
member1.setTeam(team1);
em.persist(member1);
Member member2 = new Member();
member2.setUsername("회원2");
member2.setTeam(team1);
em.persist(member2);
Member member3 = new Member();
member3.setUsername("회원3");
member3.setTeam(team2);
em.persist(member3);
em.flush();
em.clear();
String query = "select t From Team t join fetch t.members";
List<Team> result = em.createQuery(query, Team.class)
.getResultList();
for (Team team : result) {
System.out.println("member = " + team.getName()+"|members=" + team.getMembers().size());
}
//flush -> commit, query
tx.commit();Hibernate:
/* select
t
From
Team t
join
fetch
t.members */ select
t1_0.id,
m1_0.TEAM_ID,
m1_0.MEMBER_ID,
m1_0.city,
m1_0.street,
m1_0.zipcode,
m1_0.INSERT_MEMBER,
m1_0.createdDate,
m1_0.UPDATE_MEMBER,
m1_0.lastModifiedDate,
m1_0.username,
t1_0.name
from
Team t1_0
join
Member m1_0
on t1_0.id=m1_0.TEAM_ID
member = 팀A|members=2
member = 팀B|members=1
페치 조인과 일반 조인의 차이
- 일반 조인 실행 시 연관된 엔티티를 함께 조회하지 않음
- JPQL은 결과를 반환할 떄 연관관계를 고려하지 않는다.
- 단지 SELECT 절에 지정한 엔티티만 조회할 뿐이다.
- 여기서는 팀 엔티티만 조회하고, 회원 엔티티는 조회하지 않는다.
- 페치 조인을 사용할 떄만 연관된 엔티티도 함께 조회된다(일회적인 즉시로딩)
- 페치 조인은 객체 그래프를 SQL 한번에 조회하는 개념이다.
-[JPQL]
select t
from Team t join t.members m
where t.name = '팀A'
-[SQL]
SELECT T.*
FROM TEAM T
INNER JOIN MEMBER M ON T.ID = M.TEAM_ID
WHERE T.NAME = '팀A'
페치 조인의 특징과 한계
- 페치 조인 대상에는 별칭을 줄 수 없다.
- 하이버네이트는 가능하지만 가급적으론 사용하지 말자.
String query = "select t From Team t join fetch t.members as m";
- 둘 이상의 컬렉션은 페치 조인 할 수 없다.
- 컬렉션을 페치 조인하면 페이징 API(setFirstResult, setMaxResults)를 사용할 수 없다.
- 일대일, 다대일 같은 단일 값 연관 필드들은 페치 조인해도 페이징 가능하다.
** but일대다는 데이터 뻥튀기가 될 수 있기 때문에 안된다.
- 하이버네이트는 경고 로그를 남기고 메모리에서 페이징한다(매우 위험하다.)
- 연관된 엔티티들을 SQL 한번으로 조회 - 성능 최적화
- 엔티티에 직접 적용하는 글로벌 로딩 전략보다 우선함
- @OneToMany(fetch = FetchType.LAZY) //글로벌 로딩 전략
- 실무에서 글로벌 로딩 전략은 모두 지연로딩이다.
- 최적화가 필요한 곳은 페치 조인을 적용한다.
페치 조인 - 정리
1. 모든 것을 페치 조인으로 해결할 수는 없다.
2. 페치 조인은 객체 그래프를 유지할 때 사용하면 효과적이다.
3. 여러 테이블을 조인해서 엔티티가 가진 모양이 아닌 전혀 다른 결과를 내야 하면, 페치 조인보다는 일반 조인을 사용하고 필요한 데이터들만 조회해서 DTO로 반환하는 것이 효과적이다.
JPQL - 다형성 쿼리
TYPE
- 조회 대상을 특정 자식으로 한정할 수 있다.
- 예) Item 중에 Book, Movie를 조회해라
-[JPQL]
select i from Item i
where type(i) IN(Book, Movie)
-[SQL]
select i from i
where i.DTYPE in ('B', 'M')
TREAT(JPA 2.1)
- 자바 타입 캐스팅과 유사하다.
- 상속 구조에서 부모 타입을 특정 자식 타입으로 다룰 때 사용한다.
- FROM, WHERE, SELECT(하이버네이트 지원)에서만 사용한다.
-ex) 부모인 Item과 자식 Book이 있다.
-[JPQL]
select i from Item i
where treat(i as Book).author = 'kim'
-[SQL]
select i.* from Item i
where i.DTYPE = 'B' and i.author = 'kim'
JPQL - 엔티티 직접 사용
- JPQL에서 엔티티를 직접 사용하면 SQL에서 해당 엔티티의 기본키 값을 사용
-[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
String query = "select m From Member m where m = :member ";
Member findMember = em.createQuery(query, Member.class)
.setParameter("member", member1)
.getSingleResult();
System.out.println("findMember = " + findMember);
member를 파라미터로 넘겨도 결과는 마찬가지이다. 엔티티라는것 자체가 DB에 넘어가면 DB의 PK값이기 때문에 member 객체가 그대로 넘어가던, PK값인 memberId가 넘어가든 값이 일치하기 때문이다.
엔티티 직접 사용 - 키본 키 값
엔티티를 파라미터로 전달
String jpql = "select m from Member m where m = :member";
List resultList = em.createQuery(jpql).setParameter("member", member).getResultList();
String query = "select m From Member m where m.id = :memberId ";
Member findMember = em.createQuery(query, Member.class)
.setParameter("memberId", member1.getId())
.getSingleResult();
System.out.println("findMember = " + findMember);엔티티 직접 사용 - 외래 키 값
파라미터로 넘긴 team은 PK이고 m.team은 FK이기 때문에 다음과 같이 성립한다.
String query = "select m From Member m where m.team = :team ";
List<Member> members = em.createQuery(query, Member.class)
.setParameter("team", teamA)
.getResultList();
for (Member member : members) {
System.out.println("member = " + member);
}
JPQL Named 쿼리 - 정적 쿼리
Named쿼리는 엔티티에다 쿼리를 미리 선언해 놓는 것이다.
named 쿼리는 쿼리에 이름을 부여할 수 있다.
- 미리 정의해서 이름을 부여해두고 사용하는 JPQL
- 정적 쿼리
- 어노테이션, XML에 정의
- 애플리케이션 로딩 시점에 초기화 후 재사용 -> 애플리케이션 로딩 시점에 하이버네이트가 이걸 SQL로 파싱해서 캐시하고 있게 된다.(코스트가 적다)
- 애플리케이션 로딩 시점에 쿼리를 검증 -> 쿼리 오류시 컴파일 에러를 낼 수 있다.
@Entity
@NamedQuery(
name = "Member.findByUsername",
query = "select m from Member m where m.username = :username"
)
public class Member {
...
}List<Member> result = em.createQuery("Member.findByUsername", Member.class)
.setParameter("username", "회원1")
.getResultList();
for (Member member : result) {
System.out.println("member = " + member);
}
JPQL - 벌크 연산
만약 재고가 10개 미만인 모든 상품의 가격을 10% 상승하려면 어떻게 해야할까?
** JPA 변경 감지 기능으로 실행하려면 너무 많은 SQL을 실행해야 할 것이다.
(재고가 10개 미만 상품 리스트 조회 -> 상품 엔티티 가격 10% 증가 -> 트랜잭션 커밋 시점에 변경감지 동작)
>>>> 만약 변경된 데이터가 100건이라면 update쿼리라 100개가 날아가야 한다
벌크 연산 : 벌크 연산은 쿼리 한번으로 여러 테이블 로우를 변경하는 것이다.
- executeUpdate()의 결과는 영향받은 엔티티 수 반환
- UPDATE, DELETE 지원
- INSERT(insert into .. select, 하이버네이트 지원)
int resultCount = em.createQuery("update Member m set m.age = 20")
.executeUpdate();
System.out.println("resultCount = " + resultCount);위 코드를 보면 executeUpdate를 통해 나오는 값이 int인것을 확인할 수 있다.
executeUpdate를 통해 변경된 튜플의 갯수를 반환하기 때문이다.
Hibernate:
/* update
Member m
set
m.age = 20 */ update Member
set
age=20
resultCount = 3
지금은 member가 3개이고, 셋 다 age를 지정해주지 않았기때문에 executeUpdate를 통해 모두 변경되었다.
벌크 연산 주의
1. 벌크 연산은 영속성 컨텍스트를 무시하고 데이터베이스에 직접 쿼리한다.
벌크 연산 실행 순서는 다음과 같다.
벌크 연산을 먼저 실행 -> 벌크 연산 수행 후 영속성 컨텍스트 초기화.
// em.flush();
// em.clear();
//FLUSH 자동 호출 commit, query, 강제 호출
int resultCount = em.createQuery("update Member m set m.age = 20").executeUpdate();
System.out.println("resultCount = " + resultCount);
System.out.println("member1.getAge() = " + member1.getAge());
System.out.println("member2.getAge() = " + member2.getAge());
System.out.println("member3.getAge() = " + member3.getAge());위와 같은 코드를 보자.
벌크 연산은 영속성 컨텍스트를 무시하고, 데이터베이스에 직접 쿼리하기 때문에 DB에서의 age 값은 20이나, 영속성 컨텍스트엔 20이 반영되지 않는다.
Hibernate:
/* update
Member m
set
m.age = 20 */ update Member
set
age=20
resultCount = 3
member1.getAge() = 0
member2.getAge() = 0
member3.getAge() = 0
SELECT * FROM MEMBER;
AGE TEAM_ID ID TYPE USERNAME
| 20 | 1 | 1 | null | 회원1 |
| 20 | 1 | 2 | null | 회원2 |
| 20 | 2 | 3 | null | 회원3 |
Flush하는 시점에는 age가 모두 셋팅이 되어있지 않은 상태이기 때문이다.
흐름은 다음과 같다.
insert할 시 값 세팅을 해주지 않았기 때문에 0으로 insert -> update를 통해 DB에 직접 20으로 초기화 -> 벌크연산은 영속성 컨텍스트를 무시하고 업데이트 하기때문에 영속성 컨텍스트에는 아직 0
Flush한다고 해서 영속성 컨텍스트가 지워지는 것은 아니기 때문이다.
// em.flush();
// em.clear();
//FLUSH 자동 호출 commit, query, 강제 호출
int resultCount = em.createQuery("update Member m set m.age = 20").executeUpdate();
Member findMember = em.find(Member.class, member1.getId());
System.out.println("findMember = " + findMember.getAge());em.find를 통해 가져와도 망한다.
em.find는 영속성 컨텍스트에 있는 값을 우선적으로 찾은 후 없을 시 DB에서 가져와 영속성 컨텍스트에 올리기 때문이다.
아직 영속성 컨텍스트에서 지워지지 않은 상태이기 때문에 지금 이 상태의 결과는
Hibernate:
/* update
Member m
set
m.age = 20 */ update Member
set
age=20
findMember = 0
여전히 0인 것을 볼 수 있다.
그렇기에 항상 벌크연산 수행 후엔 영속성 컨텍스트를 초기화 해주는 것이 중요하다.
// em.flush();
// em.clear();
//FLUSH 자동 호출 commit, query, 강제 호출
int resultCount = em.createQuery("update Member m set m.age = 20").executeUpdate();
em.clear();
Member findMember = em.find(Member.class, member1.getId());
System.out.println("findMember = " + findMember.getAge());Hibernate:
select
m1_0.id,
m1_0.age,
m1_0.TEAM_ID,
m1_0.type,
m1_0.username
from
Member m1_0
where
m1_0.id=?
findMember = 20
'공부 > JPA' 카테고리의 다른 글
| 객체지향 쿼리 언어1 - 기본 문법 (0) | 2024.12.30 |
|---|---|
| 값 타입 (0) | 2024.12.23 |
| 프록시와 연관관계 정리 (0) | 2024.12.21 |
| JPA 고급 매핑 (2) | 2024.12.08 |
| 다양한 연관관계 매핑 (0) | 2024.12.03 |