카테고리 없음
JPA 까먹지 말자! (2)
머룽
2023. 4. 23. 14:05
오늘은 저번시간에 이어서 JPA 까먹지 말자! (2) 를 시작해보자. JPA라 했지만 구현체는 hibernate 기준으로 설명하니 다른 구현체들은 조금씩 다를 수도 있으니 참고하면 되겠다. 또한 종종 hibernate 이야기도 있을 수도 있다.
@GeneratedValue strategy
JPA에서는 @GeneratedValue 어노테이션의 strategy 속성으로 기본키 전략을 설정할 수 있다. 물론 직접 기본키를 생성해주는 것도 좋지만 그보다는 자동생성 전략도 나쁘지 않게 생각된다. 필요하다면 비지니스 키를 따로 만들어서 직접 생성해주는 방법도 생각해 볼 수 있다. JPA에서는 기본키의 전략이 3가지가 있다.TABLE, SEQUENCE, IDENTITY 전략이다. AUTO 전략도 있지만 AUTO는 해당 벤더에 따라 위의 세가지중 하나를 선택하게 된다. 3가지의 전략은 따로 설명하지 않겠다.
근데 이때 알아야 할 것은 기본 키 전략이 IDENTITY 일경우에는 쓰기 지연이 동작하지 않는다. 예를들어 다음과 같다.
public class Account {
@Id
@GeneratedValue(strategy = GenerationType.IDENTITY)
private Long id;
//..
}
@Transactional
public void saveAccount() {
Account account = new Account();
account.setName("wonwoo");
entityManager.persist(account);
}
entityManager.persist(account) 이 메서드를 호출 할때 바로 insert 쿼리라 작성되어 DB에 날라간다. 하지만 TABLE전략이나 SEQUENCE 전략은 Transaction이 끝나고 flush 혹은 commit이 호출 될 때 insert 쿼리가 만들어져서 날라 가게 된다. 그 이유는 아마 데이터베이스에서 ID를 가져와야 하므로 insert 쿼리라 먼저 만들어져서 DB에 날라가는 것 같다.
만약 쓰기 지연 효과를 얻고 싶다면 TABLE 또는 SEQUENCE 전략으로 설계를 해야 한다.
@Basic LAZY
JPA 에서는 @Basic 어노테이션이라는 것이 있다. 하지만 우리는 거의 사용하지 않는다. 왜냐하면 사용할 일이 없기 떄문이다.. 기본 타입을 말하는 건데. 굳이 쓰지 않아도 암시적으로 JPA가 이거슨 기본타입이라고 설정해 주기 때문이다.public class Account {
@Id
@GeneratedValue
@Basic
private Long id;
@Basic
private String name;
}
public class Account {
@Id
@GeneratedValue
private Long id;
private String name;
}
fetch 속성이 존재한다. @OneToMany나 @OneToOne 기타 매핑하는 어노테이션에서 사용하는 fetch와 동일하다.
@Basic(fetch = FetchType.LAZY)
@Lob
private String content;
LAZY 설정해 주면 된다. 그럼 실제 content가 사용 될때 쿼리가 작성되어 날라간다.
Account account = entityManager.find(Account.class, 1L);
System.out.println(account.getContent()); //LAZY
select
account0_.id as id1_0_0_,
account0_.name as name3_0_0_
from
account account0_
where
account0_.id=?
select
account_.content as content2_0_
from
account account_
where
account_.id=?
<plugin>
<groupid>org.hibernate.orm.tooling</groupid>
<artifactid>hibernate-enhance-maven-plugin</artifactid>
<version>${hibernate.version}</version>
<executions>
<execution>
<configuration>
<failonerror>true</failonerror>
<enablelazyinitialization>true</enablelazyinitialization>
</configuration>
<goals>
<goal>enhance</goal>
</goals>
</execution>
</executions>
</plugin>
Criteria
요즘의 개발자들은 거의 사용하지 않겠지만 (필자 역시도 요즘개발자라) 예전 개발자분들은 익숙한 클래스일 듯 싶다. 요즘 Criteria 보다는 훨씬 쉬운 Querydsl 이라는게 있어 대부분이 Querydsl을 사용하지 Criteria를 사용하지는 않는 것 같다. Criteria와 Querydsl은 동일하게 JPQL을 편하게 작성하도록 만든 빌더 클래스들이다. Criteria는 JPA표준이고 Querydsl은 비표준이지만 훨씬 간단하고 알아보기 좋고 쉽다. 하지만 이런게 있다고만 알아두면 좋을 것 같다.CriteriaBuilder builder = entityManager.getCriteriaBuilder();
CriteriaQuery<account> criteria = builder.createQuery(Account.class);
Root<account> root = criteria.from(Account.class);
criteria.select(root);
criteria.where(builder.equal(root.get("id"), 1L));
Account account = entityManager.createQuery(criteria).getSingleResult();
root.get("id") 이 부분도 타입세이프하게 만들 수 있다.
참고로 spring data jpa 에서도 Criteria를 사용한다. 당연히 그래야 했을 거고 그럴꺼라고 생각했다.
Proxy
JPA에서는 바로 쿼리를 날려서 가져오는 find 메서드와 나중에, 해당 객체를 사용할 떄 가져오는(Lazy) getReference 메서드가 존재한다.Account account = entityManager.find(Account.class, 1L);
Account account1 = entityManager.getReference(Account.class, 2L);
getReference 를 만들었을까?
예를들어 연관관계를 맺을 경우 account의 엔티티가 필요한 상황이라고 가정해보자. 물론 account의 엔티티들을 사용한다면 프록시 객체가 필요 없겠지만 단지 연관관계를 맺을 목적이라면 굳이 데이터베이스에 쿼리를 날릴 필요가 없다. 그럴 경우 이 프록시 객체를 사용하면 된다.
Account account = entityManager.getReference(Account.class, 2L);
Address address = new Address();
address.setAddress("seoul");
address.setAccount(account);
entityManager.persist(address);
findById 이전버전은 findOne 메서드로 데이터베이스에서 바로 조회했다면 getOne 메서드로 해당 프록시 엔티티를 가져올 수 있다.
FlushMode
hibernate 경우에는 FlushMode 6가지 정도 지원하는데 JPA 스펙에는 2가지가 있다. 하이버네이트 API를 사용한다면 6개 모두 사용할 수 있겠지만 JPA API만 사용한다면 2가지 타입만이 존재한다.COMMIT과 AUTO 가 JPA에서 지원해주는 FlushMode 타입이다.
일반적으로 JPA는 트랜잭션이 commit 되기 직전에 flush도 자동으로 된다. 또 한가지 자동으로 flush 가 될 때가 있는데 그때는 jpql이나 쿼리를 날릴 때 자동으로 flush가 호출 된다.
jpql이나 쿼리를 작성해서 날릴 때 flush 되는 설정이 FlushMode.AUTO 설정이다. 이것은 JPA의 기본값이다. 굳이 아래처럼 명시해주지 않아도 된다.
Account account = new Account();
account.setName("wonwoo");
entityManager.setFlushMode(FlushModeType.AUTO);
entityManager.persist(account);
entityManager.createQuery("select a from Account a", Account.class).getResultList();
insert
into
account
(content, name, id)
values
(?, ?, ?)
select
account0_.id as id1_0_,
account0_.content as content2_0_,
account0_.name as name3_0_
from
account account0_
entityManager.setFlushMode(FlushModeType.COMMIT);
select
account0_.id as id1_0_,
account0_.content as content2_0_,
account0_.name as name3_0_
from
account account0_
insert
into
account
(content, name, id)
values
(?, ?, ?)
@NamedQuery
필자는 잘은 사용하지 않지만 사용하면 나쁘지 않은 기능이다. 정적쿼리를 사용할 때 매우 유용한 어노테이션이다. 매번 동일한 쿼리를 작성하지 않고 해당 Name만 지정해줘서 쿼리를 날리면 된다.@Entity
@NamedQuery(name = "findByname", query = "select a from Account a where name = :name")
public class Account {
//...
}
@NamedQuery 어노테이션을 이용해서 정적 쿼리를 만들 수 있다. 아주 심플하다. 근데 많으면 보기 불편할거 같다.
List<account> accounts = entityManager.createNamedQuery("findByname", Account.class)
.setParameter("name", "wonwoo")
.getResultList();
@NamedQueries 어노테이션을 이용하면 된다.
@Entity
@NamedQueries({
@NamedQuery(name = "findByname", query = "select a from Account a where name = :name"),
@NamedQuery(name = "findByEmail", query = "select a from Account a where email = :email")
})
public class Account {
//...
}
@NamedQuery 어노테이션만 이용해도 된다.
@Entity
@NamedQuery(name = "findByname", query = "select a from Account a where name = :name")
@NamedQuery(name = "findByEmail", query = "select a from Account a where email = :email")
public class Account {
}
@NamedQueries 어노테이션을 사용하는 것보다 @NamedQuery를 사용하는 것이 더 보기에 좋아 보인다. 하지만 JPA 2.2 부터 지원하니 그 전 사용자라면 @NamedQueries를 사용해야 한다.
오늘은 이렇게 JPA에 관련해서 두번째 시간을 가져봤다. 물론 필자도 JPA를 잘 사용하지 못한다. (나도 잘사용하고 싶다고오오..)
계속계속 사용해야 하는데 말이다.