JPA에러

JPA실습을 위해 준비한 그리고 동시에 api를 만들어보기 위해서 실습하던 JPA 미니 프로젝트에서 에러가 발생했다.

{: .text-center}

{: .text-center}

오류내용

오류는 바로 JPA metamodel must not be empty! 이다.

분명 나는

@EnableJpaAuditing
@SpringBootApplication
public class BoardApplication {

    public static void main(String[] args) {
        SpringApplication.run(BoardApplication.class, args);
    }

}

스프링부트 실행 application 클래스에 JPAAuditing을 추가해주었다.
그리고 MockBean을 전부 넣어줘서 문제가 없다고 생각했는데 어디가 문제인지 알지 못했었다.

JPA는 엔티티 클래스의 LocalDateTime을 자동으로 관리해주는 Auditing 기능이 있다.

이 자동 삽입되는 기능을 쓰려고 Application 클래스에 @EnableJpaAuditing을 삽입했다.

모든 테스트는 이 Application 클래스가 항상 로드되면서 실행이 되는데,

여기에 Auditing 어노테이션이 등록되어 있어서 모든 테스트가 항상 이 JPA관련된 빈을 필요하고 있는 상태가 되는 것이다.

전체 컨텍스트를 로드하면서 빈을 전체 주입받으면 에러가 발생하지 않았지만,
나의 경우는 Controller 테스트를 하기위해 @WebMvcTest를 사용했는데 이 어노테이션은 JPA에 관련된 것들은 로드하지 않는다.

방법

방법은 크게 두가지가 있다.

나중에 또 발견하게 되면 업데이트를 해야겠다.

Configuration 별도 분리

스터디원중에 예전에 한번 지나가면서 얘기했던 것이 있었는데 그것이 바로 방법 첫번째이다.

따로 config라는 별도의 패키지에 Auditing관련 Configuration Class를 만들어 주는 것이다.

import org.springframework.context.annotation.Configuration;
import org.springframework.data.jpa.repository.config.EnableJpaAuditing;

@Configuration
@EnableJpaAuditing
public class JpaAuditingConfiguration {
}

이렇게 따로 빼주었다.

JpaMetaModelMappingContext 클래스 MockBean 추가

이 방법은 할때마다 연관되지 않은 Controller를 추가해줄때마다 즉,
@WebMvcTest를 하는 곳이면 그러면서 Auditing엔 관련없는 그런 Controller에는 다 해야 될것이다.

상당히 귀찮은 작업이므로 1방법이 더 좋다.

이 포스팅을 함으로써 느꼈다.

Application 클래스에 별도의 어노테이션을 삽입하지 말고 따로 분리해서 Configuration을 관리해야겠다.

토이 프로젝트 관련

JPA 스터디를 하면서 배운 내용을 토대로 하여 Spring Data JPA를 더 유연하게 사용하기 위해 토이프로젝트를 진행했다.

이슈사항이 될 수도 있겠다 싶어서 삽질 아닌 삽질을 하다가 알게된 사실이다.

사실, 계속 궁금했다. 🤔

코드로 보면 아래와 같은 궁금증이었다.

@Test
void findById() {
    memberRepository.save(member);
    Optional<Member> result = memberRepository.findById(1L);

    result.ifPresent(m -> {
        assertThat(m.getName()).isEqualTo("홍길동");
    });
}

@Test
void findAll() {
    memberRepository.save(member);
    List<Member> list = memberRepository.findAll();
    assertThat(list.size()).isEqualTo(0);
}

이렇게 두 메서드 이다.

결과부터 보자면

findById

findAll

결과가 다르다. 아무 sql을 출력해주지 않는다.

이유는 findAll을 하면 해당 테이블에 있는 모든걸 가져와야 하니까 update를 해야한다.

이 트랜잭션 밖에서 무슨일이 벌어져서 해당 테이블에 무슨 변화가 있었는지 모른다.

그래서 실행 전에 update도 발생한다❗

현재 트랜잭션 안에서 벌어진 일도 반영하고 select를 해야 현재 가장 최신 상태의 데이터를 가져오는거니까 동기화를 하는 느낌? 이라고 생각하면 될것같다.

근데 findById는 한건에 대한 데이터고, 그 한 건이 현재 트랜잭션 안에서 변경중인 데이터이다. 그래서 해당 변경 사항은 이미 영속성 컨텍스트가 관리하는 중이었기 때문에 findAll처럼 update나 select가 발생할 필요없이, 영속성 컨텍스트 안에서 캐싱하고 있던 객체를 찾아주기 때문에 update와 select 모두 발생하지 않은것 처럼 보인다. 근데 해당 코드가 테스트가 아니라 일반 애플리케이션 코드였으면 트랜잭션 끝나고 update가 발생한다.

이게 왜 발생한다고 말을 할 수 있냐면 실제로 한 메서드 내의 트랜잭션에서 save를 빼고 다른 트랜잭션에서 save를 해주고 findById만 조회하면 또 잘나오게 된다.

JPA를 사용함에 있어서 트랜잭션 정말 중요하다는걸 또 한번 깨닫는다❗

데이터를 원하는 조건에 맞게 추출하게 로직을 구현하는건 중요하지만 그 전에 트랜잭션 관리가 최우선이다. 앞으로 더 참고해서 개발해보도록 하자 😁

네이티브 SQL

JPQL은 표준 SQL이 지원하는 대부분의 문법과 SQL함수를 지원한다.
근데 특정 DB의 방언과 같은 종속적 기능은 지원하지 않는다.

• 특정 DB만 지원하는 함수, 문법, SQL 쿼리 힌트
• 인라인 뷰(from절 서브쿼리), UNION, INTERSECT
• 스토어드 프로시저

종속적인 기능을 지원하는 방법은

• 특정 DB만 사용하는 함수
  • 특정 JPQL에서 네이티브 SQL 함수를 호출할 수 있다.
  • Hibernate는 DB 방언에 각 DB에 종속적 함수를 정의했다. 그리고 직접 호출할 함수를 정의하기도 가능하다.
• 특정 DB만 지원하는 힌트
  • Hibernate를 포함한 몇몇 JPA구현체가 지원한다.
• 인라인 뷰(from절 서브쿼리), UNION, INTERSECT
  • JPA구현체들이 지원한다. Hibernate는 지원 ❌
• 스토어드 프로시저
  • JPQL에서 호출 가능
• 특정 DB만 지원하는 문법
  • 너무 유니크한 쿼리 문법은 지원하지 않는데, 이때 네이티브 SQL사용. 근데 이걸 사용할까...?

네이티브 SQL을 사용하면 엔티티를 조회할 수 있고, JPA가 지원하는 영속성 컨텍스트의 기능을 그대로 사용할 수 있다.

네이티브 SQL 사용

네이티브 쿼리 API는 3가지가 있다.

• 결과 타입을 정의
• 결과 타입을 정의할수 없을 때
• 결과 매핑 사용

엔티티 조회

    @Test
    @DisplayName("네이티브 SQL 엔티티 조회")
    void nativeQueryTest() {
        String sql = "select id, name, price from item where price > ?";
        Query nativeQuery = em.createNativeQuery(sql, Item.class).setParameter(1, 100);

        List<Item> items = nativeQuery.getResultList();
    }

jdbc 사용할때와 똑같은 느낌이 든다.
근데 가장 중요한점은
SQL만 직접 사용할 뿐, JPQL을 사용할 때와 같다. 조회한 엔티티도 영속성 컨텍스트에서 관리 된다.

값 조회

값으로 조회하려면 엔티티 조회처럼 class를 같이 넣어주는게 아니라
em.createNativeQuery(sql) 를 사용하면 된다.
대신 이때 nativeQuery.getResultList() 는 Object 배열을 반환하므로
List<Object[]> 로 반환을 받아야한다.
더욱 더 JDBC같이 생겼다.

결과 매핑 사용

결과 매핑을 사용하면 엔티티 자체에 너무 많은 어노테이션 설정을 해야되므로 보편적으로 사용하지 않을 것 같다는 나의 생각이 들어있다.
그래도 정리를 해보도록 하겠다.

String sql = "select M.ID, AGE, NAME, TEAM_ID, I.ORDER_COUNT FROM MEMBER M " +
"LEFT JOIN (SELECT IM.ID, COUNT(*) AS ORDER_COUNT FROM ORDERS O, MEMBER IM " +
"WHERE O.MEMBER_ID = IM.ID) I ON M.ID = I.ID";

Query nativeQuery = em.createNativeQuery(sql, "memberWithOrderCount");
List<Object[]> members = nativeQuery.getResultList();

아래는 매핑 정의 코드이다.

@Entity
@SqlResultSetMapping(name = "memberWithOrderCount",
    entities = {@EntityResult(entityClass = Member.class) },
    columns = {@ColumnResult(name = "ORDER_COUNT")}
}
public class Member {...}

id, age, name, team_id 는 Member 엔티티로 매핑을 시키고 order_count 는 단순 칼럼으로 매핑했다.
이렇게 여러 컬럼들을 매핑해서 추출할 수 있다.

@NamedNativeQuery

Named 네이티브 SQL을 사용하여 정적 SQL도 작성이 가능하다.
엔티티 클래스에

@NamedNativeQuery(
    name = "Member.memberSQL",
    query = "select 조회 쿼리문",
    resultClass = Member.class
)

로 등록해주고 사용하고자 하는 곳에서

TypedQuery<Member> nativeQuery = em.createNamedQuery("@NamedNativeQuery의 name", Member.class)
//파라미터가 있을 때
.setParameter();

네이티브 SQL은 휴먼에러를 발생할 확률이 QueryDSL보다 굉장히 높을 것으로 예상한다.
그래서 웬만하면 QueryDSL로 하지만 한방쿼리가 적절하게 필요할때만 사용하도록 해야할듯? 싶다. 😅
아직 실무에서 제대로 사용하지 않아서 이런 실무에서의 타협점은 점차 늘려가야 될것으로 보인다.

이번 포스팅에서는 조인에 대해 알아볼 것이다.

조인

조인은 innerJoin(join), leftJoin, rightJoin, fullJoin을 사용할 수 있고 추가로 JPQL의 on과 성능 최적화를 위한 fetchJoin을 사용할 수 있다.

jpaQueryFactory.selectFrom(item).join(조인할 쿼리클래스).fetch();

연관관계가 있으면 그냥 join만 사용해도 되지만 지금은 on이 추가되어 on() 절로 연관관계 없이 조인도 가능하다.

jpaQueryFactory.selectFrom(item).join(chair).on(chair.name.eq(item.name)).fetch();

from절에 여러 조건을 사용해서 세타조인도 가능하다.

서브 쿼리

서브 쿼리는 예전 버전에서는 JPASubQuery를 사용했지만 업데이트가 되어 현재 버전에서는 JPAExpressions 를 사용하여 서브쿼리를 작성한다.

@Test
@DisplayName("subQuery 테스트")
void subQueryTest() {
    jpaQueryFactory.selectFrom(item)
                   .where(item.name.eq(String.valueOf(JPAExpressions.selectFrom(chair).where(chair.name.eq("item3")))))
                   .fetch();
}

전 직장에서 근무하였을때 서브쿼리로 너무 많은것들을 처리했던 레거시 쿼리가 상당히 많아서
서브쿼리를 사용할때는 항상 생각해보고 쿼리를 짜야 좋을것 같다.
이게 다른 조회를 여러번 하는것이나 Join을 사용할때 보다 느린것 같다. 자세하게 속도를 비교해보면서 포스팅을 한번 했었어야 했는데 이게 안되서 개인적으로는 아쉬운 부분이다.😅

프로젝션

프로젝션 대상이 하나라면 해당하는 타입으로 결과를 받아야 한다.

List<String> list = jpaQueryFactory.select(item.name).from(item).orderBy(item.name.desc()).fetch();

그렇지만 대상이 여러개라면?
반환값이 Tuple인 객체를 반환하기 때문에 이렇게 사용해야 한다.

List<Tuple> list = jpaQueryFactory.select(item.name, item.price).from(item).orderBy(item.name.desc()).fetch();

가만보니까 이렇게 특정 칼럼만 받아서 쓰는 서비스 로직이 따로 있을거란 생각이 든다.
그때 그냥 DTO를 써주면 어떨까?

빈 생성

• 프로퍼티 접근(Setter)
• 필드 접근
• 생성자 사용
  객체를 생성하는 방법 3가지 이다. 이것을 통해 그리고 Projections를 사용하여 dto객체를 생성해주면 될듯 하다.

주의❗️ 빈 생성자를 무조건적으로 넣어줘야 한다.

기본값이 빈 생성자라서 명시적으로 넣어주지 않았는데
다음과 같은 에러가 발생한다. 😱

protected 생성자 넣었을때 또 protected 에러를 발생시킨다.

그래서 lombok의 @NoArgsConstructor를 넣어주었더니 정상 실행이 된다.
public 접근제어자여야 한다.

@Test
@DisplayName("projection dto")
void dtoTest() {
        List<ItemDto> result = jpaQueryFactory.select(
        Projections.bean(ItemDto.class,item.name.as("name"), item.price))
        .from(item).fetch();
}

프로퍼티 접근 방식인데 여기선 Projections.bean을 사용한다. 이것이 setter 메소드를 사용해서 값을 채우는 방식이다.

필드 직접 접근 방식은 Projections.fields()를 사용하면 된다.

생성자 접근 방식은 Projections.constructor()를 사용하는데 지정한 프로젝션과 파라미터 순서가 같은 생성자여야 잘 동작한다.

수정, 삭제 배치 쿼리

이부분은 그냥 영속성 컨텍스트에서 삭제, 수정 해주는것이 더 편리할것 같아서 따로 정리하지는 않고 읽는 단계로 넘어가겠다.

동적 쿼리

여기가 내가 많이 생각했고 어떻게 해야 조건문으로 쿼리를 처리할지에 대한 고민을 했던게 이 부분인것 같다.

@Test
@DisplayName("동적 쿼리")
void 동적쿼리_Test() {
    SearchParam param = new SearchParam();
    param.setName(null);
    param.setPrice(200);

    BooleanBuilder booleanBuilder = new BooleanBuilder();
    if (!ObjectUtils.isEmpty(param.getName())) {
        System.out.println(param.getName());
        booleanBuilder.and(item.name.eq(param.getName()));
    }

    if (!ObjectUtils.isEmpty(param.getPrice())) {
        System.out.println(param.getPrice());
        booleanBuilder.and(item.price.eq(param.getPrice()));
    }

    List<Item> result = jpaQueryFactory.selectFrom(item).where(booleanBuilder).fetch();
}

BooleanBuilder를 사용하여 조건에따른 조건을 할당해서 조회해줄수가 있다.
이것을 할줄 몰라서 Mybatis를 고집했던 이유도 없지않아 있는것 같다.

JPQL이 기본인 CRUD보다 훨씬 중요하고 이것을 알아야 원하는대로 select 쿼리를 날려줄 수가 있다.
그러면서 동시에 이 QueryDSL을 쿼리로 만드는게 복잡하고 어렵다고 생각해서 mybatis에서 또는 그냥 @Query에서 못벗어난? 것 같다. 😭

여기에 리팩토링을 추가한다면 조건문 하나당 로직을 메서드로 분리하여 수행해주면 편할것이다.

QueryDSL

Criteria의 단점 너무 복잡하고 어렵다는 것 그래서 JPQL이 어떻게 생성되는지 파악이 어렵다.
그래서 나온게 이 QueryDSL이다.. 코드로 작성하는데 간결하고 알아보기 쉽다.

QueryDSL은 오픈소스 프로젝트이다. 단순 CRUD보다는 이름에 걸맞게 데이터를 조회 그러니까 통계형 쿼리를 짤때 적합하지 않을까 생각한다.

QueryDSL Setting

build.gradle

buildscript {
    ext {
        ...
        querydslVersion = '1.0.10'
    }

    dependencies {
        ....
        classpath "gradle.plugin.com.ewerk.gradle.plugins:querydsl-plugin:$querydslVersion"
    }
}

subprojects {
    apply plugin: 'com.ewerk.gradle.plugins.querydsl'

    ext {
        querydslDir = "$buildDir/generated/querydsl"
    }

    dependencies {
        ...
        implementation 'com.querydsl:querydsl-jpa'
    }

    querydsl {
        jpa = true
        querydslSourcesDir = querydslDir
    }

    sourceSets {
        main.java.srcDir querydslDir
    }

    configurations {
        querydsl.extendsFrom compileClasspath
    }

    compileQuerydsl {
        options.annotationProcessorPath = configurations.querydsl
    }
}

이렇게 설정을 해주었는데 중요한 부분은 subproject.ext.querydslDir 부분이다.
$buildDir이 뜻하는 것은 우리의 스터디는 일단 모듈을 나누어서 한사람당 모듈을 사용하고 있다.
그래서 의존성을 구분해놓았는데 여기서의 $buildDir은 모듈의 빌드된 폴더
build/를 의미하며 build/generated/querydsl 폴더에 Entity클래스 앞에 Q가 붙은 클래스가 빌드되어 있다.
이것으로 QueryDSL을 세팅해주는 것이다.

QuerydslConfig.java

@Configuration
public class QuerydslConfig {
    @PersistenceContext
    private EntityManager entityManager;

    @Bean
    public JPAQueryFactory jpaQueryFactory() {
        return new JPAQueryFactory(entityManager);
    }
}

전에 말했듯 JavaEE환경에서는 @PersistenceContext를 활성화하면 알아서 주입받는다.
JPAQueryFactory 가 QueryDSL을 사용하기 위해서 구현해야 하는 것이다.

이렇게 설정해주면 QueryDSL을 사용할 수가 있다.

이제 테스트 코드를 작성해 보자.

@DataJpaTest
public class QuerydslTest {
    @PersistenceUnit
    EntityManagerFactory emf;
    EntityManager em;
    EntityTransaction tx;
    JPAQueryFactory jpaQueryFactory;

    private Member member;

    @BeforeEach
    void setUp() {
        em = emf.createEntityManager();
        tx = em.getTransaction();
        jpaQueryFactory = new JPAQueryFactory(em);
        tx.begin();
        Address address = Address.builder()
                .city("city")
                .street("street")
                .zipcode("zipcode")
                .build();

        Address comAddress = Address.builder()
                .city("cocity")
                .street("costreet")
                .zipcode("cozipcode")
                .build();

        Period period = Period.of("20210714", "20210714");

        member = Member.builder()
                .name("kim")
                .age(26)
                .period(period)
                .homeAddress(address)
                .companyAddress(comAddress)
                .build();

        em.persist(member);
        em.flush();
    }

    @Test
    @DisplayName("QueryDSL 시작")
    void querydslTest() {
        QMember qMember = new QMember("m"); //생성된 별칭
        List<Member> members = jpaQueryFactory.selectFrom(qMember)
                .where(qMember.name.eq("kim")).orderBy(qMember.id.desc()).fetch();

        assertThat(members.get(0).getName()).isEqualTo("kim");
        assertThat(members.get(0).getAge()).isEqualTo(26);
    }
}

책에서는 orderBy(qMember.id.desc()).list(qMember); 로 사용했는데
버전이 바뀌면서 list 메소드는 없어졌다고 한다.
그래서 공식문서를 찾아보니까

QueryDSL로 select 조회 쿼리를 만들었을때 로그이다.

이상한점 이라고 느낄수 있다면 어? 하고 코드상에는 jpaQueryFactory.from으로 시작하기 때문에 이것이 어떤 CRUD인지 모를 수 있다.fetch()를 해주면 반환이 List인데 그래도 타입은 캐스팅을 해주어야 한다.
자동으로 뭔가 Q클래스를 맞춰줄줄 알았다.

🤣

ㅋㅋㅋㅋㅋㅋㅋ 아니었다..... 그냥 기본값이 select가 아니라 list(qMember) 를 해주던 버전에서는 이 list 메소드가 엔티티 타입을 맞춰서 List에 넣어주었는데 지금은 selectFrom(qMember)를 해주면 이것이 List 타입을 맞춰준다.
이렇게 또 하나 깨달음을 얻는다 👍

페이징 정렬

@Test
void 페이징_테스트() {
    QItem item = QItem.item;
    List<Item> result = jpaQueryFactory.selectFrom(item).where(item.price.lt(500))
                                           .orderBy(item.price.desc(), item.name.desc())
                                           .offset(1).limit(3).fetch();

    result.forEach(r -> System.out.println(r.toString()));
}

여기서 where 조건에 lt는 부등호로 < 이고, gt는 >이다. orderBy절에서는 쿼리 타입인(Q)에서 asc(), desc()를 지원해준다. 페이징은 offset 과 limit 을 조합해서 사용하면 된다.
이렇게해서 얻은 결과이다.

전체 데이터 수를 알고 싶을때는

listResults()를 사용한다.

이것 역시 바뀌었다.
SearchResults<T> 가 아니라 버전이 바뀌면서 QueryResults<T>로 변경되었다.

listResults() 가 아니라 fetchResults()로 바뀌게 되었다.

@Test
@DisplayName("조회 결과 테스트")
void listResultsTest() {
    QueryResults<Item> result = jpaQueryFactory.selectFrom(item).where(item.price.lt(500))
                .orderBy(item.price.desc(), item.name.desc())
                .offset(1).limit(3).fetchResults();

    long total = result.getTotal(); //500보다 작은수 총 count
    long limit = result.getLimit(); //limit 3
    long offset = result.getOffset(); // offset 1
    List<Item> results = result.getResults();

    assertThat(total).isEqualTo(4L);
    assertThat(limit).isEqualTo(3L);
    assertThat(offset).isEqualTo(1L);

    results.forEach(r -> System.out.println(r.toString()));
}

getTotal은 오류의 여지가 있어보인다. 왜냐면 저 QueryDSL 전체를 시켰을때의 count가 아니라 count가 먼저 실행되기 때문에 where() 조건까지 수행한 count가 나온다.

결과의 조회는 QueryResults의 getResults()를 사용하여 페이징 정렬할때처럼의 결과를 얻을수가 있다.

그룹

그룹은 groupBy를 사용하고 그 다음에 조건을 해주려면 having을 사용하면 된다.

List<Item> results = jpaQueryFactory.selectFrom(item)
                                    .groupBy(item.price)
                                    .having(item.price.lt(500))
                                    .fetch();

깃허브 바로가기
책의 내용이 너무많아 계속 분리해서 작성하게 된다.
이번 포스팅에서는 서브 쿼리부터 내용을 다뤄보도록 하겠다.

서브 쿼리

JPQL도 SQL처럼 서브 쿼리를 지원하는데, 여기서는 몇 가지 제약사항이 있다.
서브 쿼리를 WHERE, Having 절에서만 사용할 수 있고 select, from 절에서는 사용할 수 없다.

서브쿼리 함수

• [NOT] EXISTS 서브쿼리
  • 서브쿼리에 결과가 존재하면 참. NOT은 반대
• {ALL | ANY | SOME} 서브쿼리
  • 비교 연산자와 같이 사용한다.
    • ALL: 조건을 모두 만족하면 참
    • ANY or SOME : 둘은 같은 의미이다. 조건을 하나라도 만족하면 참
• [NOT] IN 서브쿼리
  • 서브쿼리의 결과 중 하나라도 같은 것이 있으면 참. 참고로 IN은 서브쿼리가 아닌 곳에서도 사용한다.

조건식

연산자 우선 순위

1. 경로 탐색 연산(.)
2. 수학 연산 : 단항 연산자: +, -, 사칙연산 : *, /, +, -
3. 비교 연산 : =, >=, >, 등, <>(다름), Between, Like, In, Is Null, Is Empty, Exists
4. 논리 연산 : NOT, AND, OR

Between

where m.age between 10 and 20
where 뒤에 식으로 작성할 수 있다. Member의 나이가 10~20인 사람 찾기

In

In에는 서브쿼리를 사용할 수 있다. in절의 조건이 하나라도 있으면 참이다.

Like

문자표현식과 패턴을 비교한다.

• % : 아무 값들이 입력되어도 된다. (값이 없어도 됨)
• _ : 한 글자는 아무 값이 입력되어도 되지만 값이 있어야 한다.

NULL

Null 인지 비교한다. Null은 =으로 비교하면 안되고 is null을 사용해야 한다.

컬렉션 식

컬렉션에만 사용하는 특별한 기능이다. 컬렉션은 컬렉션 식 이외에 다른 식은 사용할 수가 없다.

Is Empty

컬렉션에 값이 비었으면 참이다.

스칼라 식

위의 수학 연산에 더해 아래와 같은 문자함수도 있다.

날짜 함수는 아래와 같다.

• Current_Date: 현재 날짜
• Current_Time: 현재 시간
• Current_TimeStamp: 현재 날짜 시간

이렇게 보면 DB에서 사용하는 함수가 거의 다 문법이 비슷하게 사용되는 것을 볼 수 있다.

CASE식은 생략하고 추후에 내가 사용할 때 다시 정리해야 겠다.

다형성 쿼리

JPQL로 부모 엔티티를 조회하면 자식 엔티티도 조회된다. Item의 자식으로 Book, Album, Movie 가 있다고 한다면 조회를 했을때 Item을 상속받는 Book, Album, Movie도 조회한다.

이걸 단일 테이블 전략을 사용하면 SQL이 select * from Item 이 되는데
조인 전략을 가져가면 left outer join이 세번 걸리게 된다.

TYPE

TYPE은 엔티티의 상속 구조에서 조회 대상을 특정 자식 타입으로 한정할 때 주로 사용한다.

TREAT

자바의 타입 캐스팅과 빗슷함. 상속 구조에서 부모 타입을 특정 자식 타입으로 다룰 때 사용.
JPA 표준은 FROM, Where 절에서 사용할 수 있지만, Hibernate는 Select 절에서도 Treat를 사용할 수 있다.

사용자 정의 함수 호출

JPA2.1 버전부터 사용자 정의 함수를 지원한다.
문법은 다음과 같다.
function_invocation::= FUNCTION(function_name {, function_arg}*)
예) select function('group_concat', i.name) from Item i

Hibernate 구현체를 사용하면 방언클래스를 상속해서 구현하고 사용할 DB함수를 미리 등록해야 한다.

spring.jpa.hibernate.dialect: org.hibernate.dialect.H2Dialect

방언에따라 dialect 뒤를 해당 SQL로 바꿔서 등록한다.
그렇게 이 구현체를 사용하면 해당하는 함수를 바로 사용할 수 있다.

기타 정리

• enum은 =비교 연산만 지원한다.
• 임베디드 타입은 비교를 지원하지 않는다.

Empty String

JPA표준은 ''을 길이가 0인 Empty String으로 정했지만 DB에 따라 ''를 Null로 사용하는 DB가 있으므로 확인하고 사용해야 한다.

Null 정의

• 조건을 만족하는 데이터가 하나도 없으면 Null
• Null은 알수 없는 값이다. Null과의 모든 수학적 계산 결과도 Null이 된다.
• Null == Null 은 알수 없는 값이다.
• Null is Null은 참이다.

엔티티 직접 사용

기본 키 값

객체 인스턴스는 참조 값으로 식별하고 테이블 로우는 기본 키 값으로 식별한다.
JPQL에서 엔티티 객체를 직접 사용하면 SQL에서는 해당 엔티티의 기본 키값을 사용한다.

Named 쿼리 : 정적 쿼리

• 동적 쿼리: em.createQuery("") 처럼 JPQL을 문자로 완성해서 직접 넘기는 것을 동적 쿼리라고 한다. 런타임에 특정 조건에 따라 JPQL을 동적으로 구성할 수 있다.
• 정적 쿼리: 미리 정의한 쿼리에 이름을 부여해서 필요할 때 사용할 수 있는데 Named 쿼리라고 한다. Named쿼리는 한번 정의하면 변경할 수 없는 정적인 쿼리다.

Named쿼리는 애플리케이션 로딩 시점에 JPQL 문법을 체크하고 미리 파싱해둔다. 그래서 오류를 빨리 확인할 수 있고, 사용하는 시점에 결과를 재사용하므로 성능상의 이점도 있다.
Named 쿼리는 정적 SQL이 생성되기 때문에 DB의 성능 최적화에 도움이 된다.
Named 쿼리는 @NamedQuery 를 사용하여 자바 코드에 작성하거나 XML문서에 작성할 수 있다.

• lockMode: 쿼리 실행 시 락을 건다.
• hints: 여기서의 힌트는 SQL 힌트가 아니라 JPA 구현체에게 제공하는 힌트이다. 2차 캐시를 다룰때 사용한다.

하나 이상의 NamedQuery를 사용하려면 @NamedQueries 어노테이션 사용할 것.

Named 쿼리를 XML에 정의하는 부분은 XML 대신에 Java에서 많이 하려고 노력하자.