@Entity
public class Employee {
@Id
@GeneratedValue(strategy = GenerationType.IDENTITY)
private Long id;
private String name;
private double salary;
@Formula("(SELECT COUNT(*) FROM Employee e WHERE e.salary > salary)")
private int higherSalaryCount;
// Getter and setter methods for properties
// Constructors
}
@DynamicUpdate / @DynamicInsert
@DynamicUpdate : JPA 구현체들은 기본적으로 변경이 발생할 경우 변경되지 않은 값들까지 모두 업데이트 처리하는데 변경한 것만 처리 하도록 설정 할 수 있다.
@DynamicInsert : null이 아닌 필드만을 포함하는 INSERT SQL 문을 동적으로 생성한다.
만약 기본값으로 null 을 칼럼에 넣어야 한다면 사용 할 수 없다.
@Entity
@DynamicUpdate
@DynamicInsert
public class MyEntity {
@Id
private Long id;
private String a;
private String b;
private String c;
// getter와 setter...
}
## @Immutable
- 엔티티에 대한 조회 기능만 필요할 경우 사용한다. (변경불가)
``` java
@Entity
@Immutable
public class MyEntity {
@Id
private Long id;
private String name;
// ... 다른 필드 및 메소드 ...
}
:question: 질문
## @Immutable 는 조회만 필요한 경우에 사용 가능합니다. 그렇다면 이 엔티티는 영속 상태로 관리가 됩니까? 그리고 조회 용도로만 사용할 경우 JPA를 사용하지 않고 일반적인 쿼리를 사용하는 것은 어떨까요?
`@Immutable` 어노테이션을 사용한 엔티티는 조회 목적으로만 사용되며, 변경되지 않을 것으로 예상됩니다. 그럼에도 불구하고, 이러한 엔티티도 JPA에서 영속 상태로 관리될 수 있습니다. 다만, 영속 상태에서의 관리는 엔티티의 변경 감지나 라이프사이클 콜백 등과 같은 JPA의 특정 기능들이 적용되지 않거나, 적용되어도 변경사항이 데이터베이스에 반영되지 않는다는 점에서 일반적인 영속 엔티티와는 다를 수 있습니다.
### 영속 상태 관리의 의미
- `@Immutable` 엔티티는 영속성 컨텍스트에 의해 관리될 수 있으며, 이를 통해 JPA의 캐싱, 지연 로딩, 쿼리 최적화 등의 이점을 활용할 수 있습니다.
- 변경 감지(Dirty Checking)와 같은 기능은 `@Immutable` 엔티티에 적용되지 않거나, 적용되더라도 변경사항이 데이터베이스에 반영되지 않습니다.
### JPA 대신 일반적인 쿼리 사용 고려
- 조회 목적으로만 사용되는 경우, 특히 복잡한 비즈니스 로직이나 객체 관계 매핑이 필요하지 않다면, JPA 대신 직접 SQL 쿼리를 사용하는 것도 합리적인 선택이 될 수 있습니다.
- 직접 쿼리를 사용하면 JPA의 오버헤드를 피할 수 있고, 때로는 더 세밀한 쿼리 최적화가 가능할 수 있습니다.
- 그러나 JPA를 사용할 때의 장점 중 하나는 데이터베이스와의 상호작용을 추상화하고, 객체 지향적인 접근을 제공한다는 점입니다. 이를 통해 개발자는 데이터베이스의 구체적인 세부사항보다는 비즈니스 로직에 더 집중할 수 있습니다.
### 결론
`@Immutable` 엔티티를 사용하는 경우, 그 엔티티가 JPA의 영속 상태로 관리되는 것이 효율적일 수 있습니다. 하지만 단순 조회용도의 경우, 직접 쿼리를 사용하는 방식도 고려해볼 만합니다. 선택은 어플리케이션의 요구사항, 성능 요구사항, 개발 편의성 등 다양한 요소를 고려하여 결정해야 합니다.
@Subselect
엔티티 클래스에 대한 매핑을 하위 쿼리(subselect) 결과에 기반하여 정의한다.
하위 쿼리는 SQL 문법만 사용가능. (이식성 주의)
생성된 엔티티는 변경할 수 없으며, 주로 읽기 전용 데이터를 위한 목적으로 사용한다.
(데이터베이스의 실제 테이블에 직접 매핑되지 않기 때문에, 이 엔티티의 필드 값을 변경하는 것은 의미가 없다.)
@Immutable 과 함께 사용하여 의도를 더 명확히 할 수 있다.
@Entity
@Subselect("SELECT e.id, e.name, d.name as departmentName FROM Employee e JOIN Department d ON e.department_id = d.id")
public class EmployeeSummary {
@Id
private Long id;
private String name;
private String departmentName;
// getter와 setter...
}
@Formula
특정 벤더에 종속적인 SQL 문법을 사용하지 않도록 한다.(이식성 문제)
@DynamicUpdate / @DynamicInsert
@DynamicUpdate
: JPA 구현체들은 기본적으로 변경이 발생할 경우 변경되지 않은 값들까지 모두 업데이트 처리하는데 변경한 것만 처리 하도록 설정 할 수 있다.@DynamicInsert
: null이 아닌 필드만을 포함하는 INSERT SQL 문을 동적으로 생성한다. 만약 기본값으로 null 을 칼럼에 넣어야 한다면 사용 할 수 없다.:question: 질문
## @Immutable 는 조회만 필요한 경우에 사용 가능합니다. 그렇다면 이 엔티티는 영속 상태로 관리가 됩니까? 그리고 조회 용도로만 사용할 경우 JPA를 사용하지 않고 일반적인 쿼리를 사용하는 것은 어떨까요? `@Immutable` 어노테이션을 사용한 엔티티는 조회 목적으로만 사용되며, 변경되지 않을 것으로 예상됩니다. 그럼에도 불구하고, 이러한 엔티티도 JPA에서 영속 상태로 관리될 수 있습니다. 다만, 영속 상태에서의 관리는 엔티티의 변경 감지나 라이프사이클 콜백 등과 같은 JPA의 특정 기능들이 적용되지 않거나, 적용되어도 변경사항이 데이터베이스에 반영되지 않는다는 점에서 일반적인 영속 엔티티와는 다를 수 있습니다. ### 영속 상태 관리의 의미 - `@Immutable` 엔티티는 영속성 컨텍스트에 의해 관리될 수 있으며, 이를 통해 JPA의 캐싱, 지연 로딩, 쿼리 최적화 등의 이점을 활용할 수 있습니다. - 변경 감지(Dirty Checking)와 같은 기능은 `@Immutable` 엔티티에 적용되지 않거나, 적용되더라도 변경사항이 데이터베이스에 반영되지 않습니다. ### JPA 대신 일반적인 쿼리 사용 고려 - 조회 목적으로만 사용되는 경우, 특히 복잡한 비즈니스 로직이나 객체 관계 매핑이 필요하지 않다면, JPA 대신 직접 SQL 쿼리를 사용하는 것도 합리적인 선택이 될 수 있습니다. - 직접 쿼리를 사용하면 JPA의 오버헤드를 피할 수 있고, 때로는 더 세밀한 쿼리 최적화가 가능할 수 있습니다. - 그러나 JPA를 사용할 때의 장점 중 하나는 데이터베이스와의 상호작용을 추상화하고, 객체 지향적인 접근을 제공한다는 점입니다. 이를 통해 개발자는 데이터베이스의 구체적인 세부사항보다는 비즈니스 로직에 더 집중할 수 있습니다. ### 결론 `@Immutable` 엔티티를 사용하는 경우, 그 엔티티가 JPA의 영속 상태로 관리되는 것이 효율적일 수 있습니다. 하지만 단순 조회용도의 경우, 직접 쿼리를 사용하는 방식도 고려해볼 만합니다. 선택은 어플리케이션의 요구사항, 성능 요구사항, 개발 편의성 등 다양한 요소를 고려하여 결정해야 합니다.@Subselect