오늘 포스팅할 내용은 간단히 JPA의 cascade 기능이다. 이전 포스팅 중에 해당 내용에 대해 포스팅한적이 있지만 조금 부족한 것같아서 다시 한번 정리할겸 글을 남긴다.

영속성 전이(cascade)란 쉽게 말해 부모 엔티티가 영속화될때, 자식 엔티티도 같이 영속화되고 부모 엔티티가 삭제 될때, 자식 엔티티도 삭제되는 등 부모의 영속성 상태가 전이되는 것을 이야기한다. 영속성전이의 종류로는 ALL, PERSIST, DETACH, REFRESH, MERGE, REMOVE등이 있다. 이름만 봐도 어디까지 영속성이 전이되는지 확 눈에 보일 것이다. 여기서는 별도로 각각을 설명하지는 않는다.

오늘의 상황 : A와 B라는 엔티티가 존재하고, 두 엔티티의 관계는 @ManyToMany 관계이다. 이 관계는 중간에 Bridge 테이블을 두어 @OneToMany<->@ManyToOne  @OneToMany<->@ManyToOne 관계로 매핑하였다. 그리고 C라는 엔티티는 A엔티티와 @ManyToOne 관계이다. 이렇게 여러개가 조인이 걸려있는 상황에서 cascade를 이용한 PERSIST 예제를 한번 짜보았다.

<AEntity Class>

<BEntity class>

<CEntity class>

<BridgeEntity class>

<A,B Entity Repository class>

테스트 상황 : A,B,C,BridgeEntity 모두 데이터를 persist 하는 상황이다. 그럼 여기서 생각해야 할것이 있다. 우선 C의 부모는 A이다. 즉, A 엔티티가 persist될때 C 자식 엔티티까지 persist되도록 영속성 전이기능을 이용하면 된다. 그렇다면 A,B,Bridge 세개의 관계는 어떻게 될까? 우선 조건이 있다. A,B,Bridge 관계에서 Bridge엔티티가 외래키의 주인이다. 이 말은 즉슨, Bridge 엔티티가 persist 되기 전에 A,B모두가 영속화된 상태여야하는 것이다. 예제는 아래와 같은 시나리오로 테스트했다.

1)B 엔티티 영속화 ->2)A 엔티티의 영속화 + Bridge 엔티티 영속성전이

중요한 것이 있다. 부모 엔티티가 영속화되는 동시에 자식 엔티티가 영속화되게 영속성 전이를 이용하기 위해서는 반드시 자식 객체에 부모객체를 set해주어야 하는 점이다. 만약 부모엔티티를 자식 엔티티에 set해주지 않으면 외래키에 null값이 채워질 것이다.

결과

=>

JPA - 영속성 컨텍스트와 JPQL

쿼리 후 영속 상태인 것과 아닌것

-JPQL의 조회 대상은 엔티티, 임베디드 타입, 값 타입 같이 다양하다. 하지만 엔티티를 조회하면 영속성 컨텍스트에 관리되지만 나머지는 관리되지 않는다. 예를 들어 임베디드 타입만 참조해서 조회했을 경우에 값을 변경해서 플러시 시점에 반영되지 않는다. 하지만 엔티티를 조회하여 엔티티가 가지고 있는 임베디드타입을 변경했을 경우에는 플러시 시점에 변경이 반영이 된다.

JPQL로 조회한 엔티티와 영속성 컨텍스트

JPQL과 플러시 모드

JPQL은 영속성 컨텍스트에 있는 데이터를 고려하지 않고 디비에서 데이터를 조회한다. 따라서 JPQL을 실행하기 전에 영속성 컨텍스트의 내용을 디비에 반영해야한다. 그렇지 않으면 의도하지 않은 결과가 발생할 수 있다.

이 예제는 QueryDSL의 수정 배치 쿼리이다. 이 예제의 결과가 어떻게 될것인가? 결과는 정말 의도치 않게 나오게 된다. QueryDSL의 배치쿼리는 영속성컨텍스트와 관계없이 직접 디비로 요청을 보내게 된다. 이러는 순간 디비와 영속성컨텍스트의 동기화는 깨진것이다. 변경을 완료했고 나는 변경된 이름으로 쿼리를 날렸는데, 이게 뭐람 변경전의 "여성게1"이란 결과가 나오게 된다. 이유는 위에서 설명한 것과 같이 영속성컨텍스트에 이미 존재하기 때문에 디비에서 가져온 엔티티가 데이터가 달라도 식별자 값이 같기 때문에 버려지게 되고 수정전에 이름이 출력되게 되는 것이다.

이 코드는 실무에서는 사용할 수없는 코드이다. 하지만 직관적으로 영속성 컨텍스트의 값을 수정배치쿼리와 동일하게 변경한것을 보여주기 위해 짠것이다. 이 예제의 결과는 수정배치에서 변경된 값과 동일한 엔티티가 반환되게 된다.

JPA - JPAQuery와 Q클래스

긴 포스팅은 아니지만 예제로 소스를 짜는 도중에 몰랐던 내용을 알게되어서 작성한다. QueryDSL로 예제중 나온 상황이다.

언뜻 보기에는 크게 문제가 없는 듯 싶다. 하지만 이 소스를 실행하면 이러한 예외가 발생한다.

java.lang.IllegalStateException: qMyEntity is already used

즉, 같은 JPAQuery 객체로 같은 Q타입클래스를 사용할 수없는 것이다. 사실 내부를 까보지는 않아서 원인파악은 해보아야겠지만 일단 결론은 그렇다. 그렇기 때문에 소스가 이런식으로 변경되어야한다.

이런식으로 JPAQuery 객체를 만드는 메소드를 하나 정의하는 것이 좋을 것같다.

언젠가는 이런 상황이 닥칠수도 있을 것같아서 포스팅한다..

JPA - NativeQuery ( SQL ) 네이티브 SQL 사용하기!

JPA는 SQL이 지원하는 대부분의 문법과 SQL 함수들을 지원하지만 특정 데이터베이스에 종속적인 기능은 잘 지원하지 않는다. 하지만 때론 특정 데이터베이스에 종속적인 기능이 필요할 수도 있다. 다양한 이유로 JPQL을 사용할 수 없을 때, JPA는 SQL을 직접 사용할 수 있는 기능을 제공하는데 이것을 네이티브 SQL(네이티브쿼리)라고 한다. 즉, 사용자가 직접 데이터베이스에 날리는 쿼리를 작성하는 것이다. 그렇다면 JPA가 지원하는 네이티브 SQL과 JDBC API를 직접 사용하는 것에는 어떤 차이가 있냐? 그것은 바로 네이트브 쿼리는 엔티티를 조회할 수 있고 JPA가 지원하는 영속성 컨텍스트의 기능을 그대로 사용할 수 있다는 것이다!

Native Query API

1. //결과 타입 정의
2. public Query createNativeQuery(String sqlString, Class resultClass) {}
3. //결과 타입을 정의할 수 없을 때
4. public Query createNativeQuery(String sqlString) {}
5. //엔티티 타입이 아닌 결과 값일때
6. public Query createNativeQuery(String sqlString
7.                         ,String resultSetMapping) {}

 이렇게 세가지의 오버로딩된 메소드를 사용한다.

1. /*
2.  * 네이티브쿼리는 위치기반 파라미터 바인딩만 지원한다.(구현체중 일부는 이름기반 파라미터 바인딩도 지원함)
3.  */
4. public void nativeQuery() {
5.         String sql = "SELECT MEMBER_JPQL_ID,USERAGE,USERNAME,TEAM_ID FROM MEMBER_JPQL WHERE USERAGE> ?";
6.         
7.         Query nativeQuery = em.createNativeQuery(sql,MemberJPQL.class).setParameter(1, 35);
8.         
9.         List<MemberJPQL> resultList = nativeQuery.getResultList();
10.         
11.         System.out.println("====================nativeQuery=====================");
12.         
13.         for(MemberJPQL m : resultList) {
14.                 System.out.println(m.toString());
15.         }
16.         
17.         System.out.println("====================nativeQuery=====================");
18. }

리턴타입이 엔티티일 경우이다. em.createNativeQuery(SQL문장,리턴타입클래스)로 Query객체를 만들어낸다. 위의 예제를 보면 JPQL과 다를 것은 쿼리를 직접작성하냐 안하냐의 차이지 대부분의 로직은 비슷하다.(JPA가 자동으로 생성해주는 SQL를 사용자가 직접 작성한 것뿐 더이상의 차이는 거의없다.)

그리고 Native Query에서는 반환타입이 명시되어도 Query 객체로 반환받는다는 점을 유의하자.

다음은 결과 매핑 사용 예제이다.

1. @Entity
2. @Table(name = "MEMBER_JPQL")
3. //@Getter
4. //@Setter
5. @ToString
6. @SqlResultSetMapping(name = "memberWithOrderCount",
7.                                         entities = {@EntityResult(entityClass = MemberJPQL.class)},
8.                                         columns = {@ColumnResult(name = "ORDER_COUNT")})
9. public class MemberJPQL {....}

1. /*
2.  * ResultMapping
3.  */
4. public void nativeQuery2() {
5.         String sql = "SELECT M.MEMBER_JPQL_ID AS ID,USERAGE AS AGE,USERNAME,TEAM_ID,I.ORDER_COUNT "
6.                                 + "FROM MEMBER_JPQL M JOIN  "
7.                                                 + "(SELECT IM.MEMBER_JPQL_ID, COUNT(*) AS ORDER_COUNT "
8.                                                 + "FROM ORDER_JPQL O, MEMBER_JPQL IM "
9.                                                 + "WHERE O.MEMBER_JPQL_ID = IM.MEMBER_JPQL_ID) I "
10.                                 + "ON M.MEMBER_JPQL_ID = I.MEMBER_JPQL_ID";
11.                                 
12.         Query nativeQuery = em.createNativeQuery(sql,"memberWithOrderCount");
13.         
14.         List<Object[]> resultList = nativeQuery.getResultList();
15.         
16.         System.out.println("====================nativeQuery2=====================");
17.         
18.         for(Object[] m : resultList) {
19.                 System.out.println(m[0].toString());
20.                 System.out.println(m[1]);
21.         }
22.         
23.         System.out.println("====================nativeQuery2=====================");
24. }

특별한 것은 없다. 엔티티클래스에 네이티브 쿼리로 받을 반환 타입을 명시해주었고, 네이티브 쿼리를 사용한 쪽에서는 반환타입을 엔티티클래스에 작성한 반환타입 이름 값을 문자열로 넘겨주었다. 그래서 반환된 Object[]에서 Object[0]은 회원엔티티로 매핑되고, Object[1]은 스칼라타입으로 ORDER_COUNT를 담고있다.

어노테이션을 보면 속성 값이 entities,columns로 된것으로 보아 여러개의 엔티티,칼럼을 매핑할 수 있다. 그리고 @SqlResultSetMappings 어노테이션이 있기 때문에 여러개의 매핑타입을 만들 수 있다.

그런데 대부분 엔티티 클래스의 id클래스의 필드명은 "id"로 거의 동일하게 하는 경우도 많다. 그래서 조회를 하면 칼럼명이 중복나는 경우가 생기게 된다. 그때는 필드매핑까지 포함하여서 조회가능하다.

1. @Entity
2. @Table(name = "MEMBER_JPQL")
3. //@Getter
4. //@Setter
5. @ToString
6. @SqlResultSetMappings({
7.         @SqlResultSetMapping(name = "memberWithOrderCount",
8.                         entities = {@EntityResult(entityClass = MemberJPQL.class)},
9.                         columns = {@ColumnResult(name = "ORDER_COUNT")}
10.         )
11.         ,@SqlResultSetMapping(name = "memberInfo",
12.                         entities = {
13.                                         @EntityResult(entityClass=MemberJPQL.class,
14.                                         fields = {
15.                                                         @FieldResult(name = "id",column = "member_id")
16.                                                         ,@FieldResult(name = "age",column = "client_age")
17.                                         })
18.                         }
19.         )
20.         
21. })
22. public class MemberJPQL {...}

1. public void nativeQuery3() {
2.         String sql = "select MEMBER_JPQL_ID as member_id,USERAGE as client_age "
3.                         + "from member_jpql where USERNAME = '여성게1'";
4.         
5.         Query nativeQuery = em.createNativeQuery(sql,"memberInfo");
6.         
7.         List<MemberJPQL> resultList = nativeQuery.getResultList();
8.         
9.         System.out.println("====================nativeQuery3=====================");
10.         
11.         for(MemberJPQL m : resultList) {
12.                 System.out.println(m.toString());
13.         }
14.         
15.         System.out.println("====================nativeQuery3=====================");
16. }

부득이하게 조회할 컬럼명을 별칭으로 주었을 경우, 엔티티 클래스와 매핑이 되지 않는다. 그럴때 엔티티클래스에 필드매핑을 이용한다.

@FieldResult(name = "id",column = "member_id")

name이 엔티티클래스의 필드명이고, column이 조회하였을 때 반환되는 컬럼명이다.

마지막으로 이전에 다루었던 정적쿼리(@NamedQuery)처럼 네이티브 쿼리로 정적쿼리처럼 엔티티클래스에 정의할 수 있다.

▶︎▶︎▶︎JPA - @NamedQuery , 정적 쿼리

1. @Table(name = "MEMBER_JPQL")
2. //@Getter
3. //@Setter
4. @ToString
5. @SqlResultSetMappings({
6.         @SqlResultSetMapping(name = "memberWithOrderCount",
7.                         entities = {@EntityResult(entityClass = MemberJPQL.class)},
8.                         columns = {@ColumnResult(name = "ORDER_COUNT")}
9.         )
10.         ,@SqlResultSetMapping(name = "memberInfo",
11.                         entities = {
12.                                         @EntityResult(entityClass=MemberJPQL.class,
13.                                         fields = {
14.                                                         @FieldResult(name = "id",column = "member_id")
15.                                                         ,@FieldResult(name = "age",column = "client_age")
16.                                         })
17.                         }
18.         )
19.         
20. })
21. @NamedNativeQueries({
22.         @NamedNativeQuery(name = "Member.memberSQL",
23.                                                 query = "select member_jpql_id,userage,username,team_id "
24.                                                                 + "from member_jpql "
25.                                                                 + "where username = ?",
26.                                                 resultClass=MemberJPQL.class)
27.         ,@NamedNativeQuery(name = "Member.memberSQL2",
28.                         query = "select MEMBER_JPQL_ID as member_id,USERAGE as client_age "
29.                                         + "from member_jpql where USERNAME = ?",
30.                         resultSetMapping = "memberInfo")
31. })
32. public class MemberJPQL {}

1. public void nativeQuery4() {
2.         
3.         Query nativeQuery = em.createNamedQuery("Member.memberSQL",MemberJPQL.class)
4.                         .setParameter(1, "여성게1");
5.         
6.         List<MemberJPQL> resultList = nativeQuery.getResultList();
7.         
8.         System.out.println("====================nativeQuery4=====================");
9.         
10.         for(MemberJPQL m : resultList) {
11.                 System.out.println(m.toString());
12.         }
13.         
14.         System.out.println("====================nativeQuery4=====================");
15. }
16. public void nativeQuery5() {
17.         
18.         Query nativeQuery = em.createNamedQuery("Member.memberSQL2")
19.                         .setParameter(1, "여성게1");
20.         
21.         List<MemberJPQL> resultList = nativeQuery.getResultList();
22.         
23.         System.out.println("====================nativeQuery5=====================");
24.         
25.         for(MemberJPQL m : resultList) {
26.                 System.out.println(m.toString());
27.         }
28.         
29.         System.out.println("====================nativeQuery5=====================");
30. }

em.createNativeQuery()에서 다루던 것을 어노테이션으로 다 가져다 놓았다고 보면된다. 그리고 조금 특이한 것은 @NamedQuery와 같이 em.createNamedQuery()를 사용한다는 것이다.

JPA - QueryDSL, JPQL Query Builder Class

이전 포스팅에서 다뤘던 JPA Criteria는 문자가 아닌 코드로 JPQL을 작성하도록 도와주는 쿼리빌더였기 때문에 문법 오류를 컴파일 단계에서 잡을 수 있고 IDE툴을 이용하여 자동완성 기능의 도움을 받을 수 있기 때문에 여러가지 장점이 있었다. 하지만 Criteria의 가장 큰 단점은 코드양이 줄지도 않고 너무 복잡하며 바로바로 쿼리를 예상하기가 쉽지 않았다. 하지만 이번에 다룰 QueryDSL은 Criteria와 같이 문자가 아닌 코드로 쿼리를 작성하며, 쉽고 간결하고 빌더로 작성된 모양도 쿼리와 비슷해 쉽게 예상이 가능하다. 오히려 Criteria보다 사용하기 편하다. 하지만 큰 문제라고는 할 수 없지만 Criteria는 JPA가 지원하는 표준이고, QueryDSL은 표준은 아니고 그냥 오픈소스이다. 

▶︎▶︎▶︎JPA - Criteria Query(객체지향 쿼리 빌더), JPQL Query Builder Class

▶︎▶︎▶︎QueryDSL Reference 번역 By 최범균

▶︎▶︎▶︎JPQL(객체지향쿼리),Java Persistence Query Language

QueryDSL이 지원하는 프로젝트

JPA - Criteria Query(객체지향 쿼리 빌더), JPQL Query Builder Class

Criteria 쿼리는 JPQL을 자바 코드로 작성하도록 도와주는 빌더 클래스 API이다. Criteria를 사용하면 문자가 아닌 코드로 JPQL를 작성하므로 문법 오류를 컴파일 단계에서 잡을 수 있고 문자 기반의 JPQL보다 동적 쿼리를 안전하게 생성할 수 있다. 하지만 이번에 Criteria를 간단하게만 다루려고 한다. 이유는 실제 Criteria를 사용해서 개발하다보면 코드가 복잡하고 장황하며 직관적으로 이해하기 힘들다는 단점이 있기때문이다. 다음 포스팅에서는 코드로 쿼리를 작성할 수 있고 간단한 QueryDSL을 다음에 자세히 다뤄볼 예정이기에 이번 포스팅은 몇가지 간단하게만 다뤄본다.

Criteria 기초

이렇게  Criteria쿼리를 완성하고 나면 다음 순서는 기존의 JPQL과 같다. em.createQuery(query)에 완성된  Criteria쿼리를 넣어주면 된다.

다음으로는 검색조건,정렬조건을 정의하는 부분이다. 위와 같이 where절에 들어가는 부분은 Predicate 클래스로, orderBy에 들어가는 부분은 Order 클래스로 정의해준다. 위와 같이 객체로 정의하여도 되지만

~.where(builder.equal(m.get("username"),"여성게1"); 

-->이런식으로 where절에 바로 넣어주어도 된다.

조회(한건,여러건) - Criteria

크게 어려울 부분은 없을 것같다. select()는 단일조회, select2()는 다중값 조회이다. 하지만 여기서 JPQL을 생각해보면 여러 값의 조회를 하나의 DTO클래스로 반환받았던 것이 기억날 것이다. Criteria 역시 NEW 명령어 쿼리를 지원한다.

NEW 명령어를 이용하여 다중값 특정 객체 매핑이후 반환 - Criteria

JPQL과 비교하여 달라진 점이 좀있다. 문자기반이 아니라 코드기반으로 쿼리를 다루다보니 DTO클래스를 풀 패키지명으로 안써도 되는 것이다. 이런것들을 생각하면 문자열을 잘못넣어서 오류날 일은 거의 없을듯 싶다. 하지만 아직까지도 문자열을 쓰는 부분은 조금 남아있다.

Java Map과 비슷한 TupleQuery - Criteria

만약 반환값이 여러개라면 위처럼 DTO로 받을 수도 있지만 마치 Map과 같은 객체처럼 느껴지는 Tuple이라는 객체를 이용해서도 다중 값 쿼리가 가능하다.

코드만 봐도 조금은 직관적으로 보인다. Tuple의 key가 될 값을 반환value.alias(key값)로 지정해준다. 그런다음 결과를 꺼낼때 Tuple객체에서 키값과 반환타입을 넘겨 꺼낸다. 위의 주석에도 있듯이 스칼라타입의 필드말고 엔티티를 전체로 튜플의 값으로도 설정해줄수 있다.

결론적으로 튜플은 이름 기반이므로 순서 기반의 Object[]로 반환받는 것보다 훨씬 안전하다. 그리고 tuple.getElements() 같은 메소드를 사용해서 현재 튜플의 별칭과 자바 타입도 조회가능하다.

조인(Join & Fetch Join) - Criteria

JPQL에서 다루었던 조인과 패치조인이다. 크게 어려울 부분은 없을 것같아 몇가지만 설명하려고 한다. 

Join<MemberJPQL, TeamJPQL> t =m.join("team",JoinType.INNER);

->JPQL과 비교하면 ~ [inner] join m.team t 와 비슷한 구문이라고 보면된다.

그리고 튜플로 반환받기위해 두개의 엔티티 모두에게 별칭을 주었고 마지막 결과를 출력하는 부분에 별칭을 이용하여 객체를 얻어왔다.

그 다음은 패치조인이다.

m.fetch("team"/*,JoinType.LEFT*/);

-> 

일반 조인과는 다르게 반환값을 받아서 사용하지 않는다. 즉, 조회의 결과로 나오는 회원엔티티의 team필드에 값이 세팅되서 나오는 것이다. 그래서 결과값을 받을 경우 회원엔티티로만 받고 그 회원엔티티의 팀엔티티 필드에서 값을 꺼내 사용한다.(사실 Criteria에서 패치조인을 이용하여 두개의 결과값을 받을 수 있는지는 확실히 모르겠다. 혹시 아시는 분은 댓글부탁드립니다.)

Parameter Binding

query.select(m).where(builder.equal(m.get("username")

 ,builder.parameter(String.class,"username")));

-> 이름기반 파라미터 정의를 해준다. (Predicate 객체로 선언해도되지만 이렇게 where절에 바로 넣어도된다.)

TypedQuery<MemberJPQL> query2 = em.createQuery(query)

.setParameter("username", param);

->JPQL과 동일하게 setParameter메소드를 호출해서 세팅해준다.

Criteria Meta Code Generate

지금까지 간단하게 Criteria 쿼리를 설명했다. 확실히 그냥 JPQL을 사용할때 보다 문자열을 사용하여 쿼리를 작성하는 부분이 확 줄었다. 그렇지만 그렇다고 100% 문자열을 사용하지 않는 것은 아니다. 그 말은 100% 실수하지 않으리라는 보장이 없는 것이다. 이때 사용할 수 있는 것이 Meta Code를 생성하여서 위에서 조금 사용한 문자열마저 사용하지 않는 것이다. Meta Code를 생성하면 각 엔티티 클래스마다 메타정보를 가진 자바파일들이 생성되게 된다.

<pom.xml>

이렇게 두개를 설정해준다. 첫번째 의존 라이브러리를 내려받아주고, 두번째는 Meta Code를 생성하기 위한 플러그인 설정을 해주는 것이다.

->Run As..->Run Configuration 에 들어가서 해당 프로젝트의 메이븐 빌드 Goals를 입력하고 Run을 해준다.

->빌드가 완료되었다면 target->generated-sources에 Meta Code들이 생성되어 있을 것이다. 이 다음은 과정은 각자의 IDE환경에 따라 다르다. 만약 target>generated-sources가 자동으로 클래스패스로 잡힌다면 문제가 없지만 만약 클래스패스로 잡히지 않는다면 직접 등록해주어야한다. 클래스패스가 디폴트로 잡히지 않는다는 가정하에 진행한다.

-> 첫 이미지처럼 반드시 패키지명직전까지를 패스로 잡아야한다. 그래서 Meta Code생성시 package관련 에러가 뜨지 않는다. 마지막으로 Apply를 누르면 방금생성된 메타코드가 클래스패스에 들어가있을 것이다(기존의 target부분에는 코드가 없어짐). 혹시나 에러표시가 프로젝트에 계속 난다면 maven update를 하길바란다.

Criteria Meta Code 적용후 쿼리

m.get(MemberJPQL_.username)

->여기에서 사용하던 문자열이 없어졌다. 이제 조금은 에러가 줄것 같다.

지금까지 간단하게 Criteria를 다뤄봤습니다. 사실 개인적인 생각으로는 이것이 편해진것인가...? 하는 생각이 조금 들었습니다. 문자기반으로 작성하지 않을 뿐이고 오히려 코드는 그냥 JPQL을 쓸때보다 복잡해진것같기도 하는 생각이 듭니다.(개인적인 생각입니다. 물론 런타임시점에 에러를 발견해야하는 큰 문제를 해결해준 것만으로도 엄청난 가치가 있다고 생각듭니다.) 그래서 다음 포스팅에서는 쉽고, 간단하고, 코드로 쿼리를 다룰 수 있는 QueryDSL을 이용하여 JPA쿼리를 다뤄보겠습니다.

JPA - JPQL(객체지향쿼리)

jpa-study.zip

(예제소스파일/ jpql package참조)

JPQL은 가장 중요한 객체지향 쿼리 언어이다. Criteria나 QueryDSL은 결국 JPQL을 편리하게 사용하도록 도와주는 기술이므로 JPA로 데이터베이스 엑세스를 다룬다면 JPQL은 꼭 필수라고 생각이 든다. SQL과 꼭 닮은 쿼리 언어이며 SQL은 데이터 중심의 쿼리라고 하면 JPQL은 엔티티를 대상으로 하는 쿼리 언어라고 할 수 있다. 결국 JPA에서 해당 JPQL을 분석한 다음 적절한 SQL로 변환해주어서 데이터베이스에서 데이터를 가져오는 것이다.

JPA 영속성 관리 - persistence context(영속성컨텍스트)

JPA가 제공하는 기능은 크게 엔티티와 테이블을 매핑하는 설계부분과 매핑한 엔티티를 실제 사용하는 부분으로 나눌 수 있다.

엔티티 매니저 팩토리와 엔티티 매니저

EntityManager는 엔티티를 저장하고, 수정하고, 삭제하고, 조회하는 등 엔티티와 관련된 모든 일을 처리한다. 이름 그대로 엔티티를 관리하는 관리자다. 개발자 입장에서 엔티티 매니저는 엔티티를 저장하는 가상의 데이터베이스로 생각하면 될 듯 싶다.

그러면 엔티티 매니저 팩토리란 무엇인가? 바로 이 엔티티 매니저를 생성해주는 공장역할을 하는 객체이다. 보통 엔티티 매니저 팩토리는 생성비용이 크게 때문에 하나만 생성해서 모든 스레드가 공유할 수 있도록 설계되었고, 엔티티 매니저는 사용할 때마다 새로 생성하면 된다. 즉, 엔티티 매니저는 데이터베이스 커넥션과 관련이 있는 객체이기에 스레드간 공유가 되서는 안되는 객체이다. 이 엔티티 매니저는 데이터베이스와 커넥션을 맺지만 꼭 필요할 때 커넥션을 맺는다.(트랜잭션이 시작되었을 경우) 

Ex) EntityManagerFactory emf = Persistence.createEntityManagerFactory("persist"); -> "persist"는 persistence.xml에 생성한 persistence unit 명이다.

      EntityManager em = ema.createEntityManager();

영속성 컨텍스트란?

영속성 컨텍스트란 JPA에서 가장 중요한 용어 중 하나이다. 이것을 한글로 표현하면 "엔티티를 영구 저장하는 환경"이라고 표현해도 좋을 것 같다. 즉, 엔티티 매니저로 엔티티를 저장하거나 조회하면 엔티티 매니저는 영속성 컨텍스트에 엔티티를 보관하고 관리한다.

em.persist(entity)는 실제로 데이터베이스에 회원 엔티티를 저장하는 것이 아니고, 엔티티 매니저를 사용해 엔티티를 영속성 컨텍스트에 저장하는 것이다.

엔티티의 생명주기

비영속 : 영속성 컨텍스트와 전혀 관계가 없는 상태이다.

영속: 영속성 컨테스트에 저장된 상태

준영속: 영속성 컨텍스트에 저장되었다가 분리된 상태

삭제: 삭제된 상태

비영속 상태를 예를 들면 엔티티 객체를 생성한 상태이다.

Member m = new Member(); -> 지금 이 상태는 순수한 객체 상태이며, 아직 저장하지 않은 것이라서 영속성 컨텍스트나 데이터베이스와는 전혀 관련이 없는 것이다.

영속 상태를 예를 들면 em.persist(entity) 혹은 em.find(entity) 등을 호출한 상태이며, 이 상태는 영속성 컨테스트가 관리하는 엔티티가 되었다 라는 뜻이다. 

준영속 상태는 영속성 컨텍스트가 관리하던 영속 상태의 엔티티를 영속성 컨텍스트가 관리하지 않는 상태를 말한다. 예를 들면, em.detach(),em.close(),em.clear() 등 분리,닫기,초기화 등의 메소드를 호출하게 되면 영속된 엔티티들은 모두 준영속 상태가 된다.

삭제 상태는 말그대로 영속성 컨텍스트(+데이터베이스)에서 상태가 되는 것이다. em.remove(entity)

영속성 컨텍스트의 특징

1)영속성 컨텍스트와 식별자 값 - 영속성 컨텍스트는 엔티티를 식별자 값(@Id로 테이블의 기본키와 매핑한 값)으로 구분한다. 즉, 영속상태에 있으려면 반드시 식별자 값이 존재해야한다. 만약 식별자 값이 없다면 예외가 발생하게 된다.

2)JPA는 보통 트랜잭션을 커밋하는 순간 영속성 컨텍스트에 새로 저장된 엔티티를 데이터베이스에 반영하는 데, 이것을 Flush라고 한다.