Entity Mapping

앞서 언급한 JPA에서 가장 중요한 것 중 이제 entity mapping에 대해 알아보자.

엔티티 매핑 소개

• 객체와 테이블 매핑

@Entity

@Entity가 붙은 클래스는 JPA가 관리, 엔티티라 한다.
JPA를 사용해서 테이블과 매핑할 클래스는 @Entity 필수

• 주의
  기본 생성자 필수(파라미터가 없는 public 또는 protected 생성자) -> 리플렉싱 등 다양한 기술을 사용하여 객체를 프록싱 하고 이런한 기본 동작 원리에 반드시 필요함.
  final 클래스, enum, interface, inner 클래스 사용X
  저장할 필드에 final 사용 X

협업시 개발자가 entity만 보고도 해당 entity가 DB에 어떻게 들어있구나를 알 수 있도록 모든 제약조건 즉, meta data를 어노테이션으로 다 적어주면 좋다.

@Entity 속성 정리

• 속성: name
• JPA에서 사용할 엔티티 이름을 지정한다.
• 기본값: 클래스 이름을 그대로 사용(예: Member)
• 같은 클래스 이름이 없으면 가급적 기본값을 사용한다

@Table

@Data
@Entity
@Table(name = "DB에 명시되어 있는거")
public class Member {
    @Id
    private Long id;
    private String name;
}

• @Table은 엔티티와 매핑할 테이블 지정

속성	기능	기본 값
name	매핑할 테이블 이름	entity 이름을 사용
catalog	데이터베이스 catalog 매핑
schema	데이터베이스 schema 매핑
uniqueConstraints (DDL)	DDL 생성 시에 유니크 제약 조건 생성

• 필드와 컬럼 매핑

@Column

컬럼 매핑

속성	설명	기본 값
name	필드와 매핑할 테이블의 컬럼 이름	객체의 필드 이름
insertable, updatable	등록, 변경 가능 여부	TRUE
nullable(DDL)	null 값의 허용 여부를 설정한다. false로 설정하면 DDL 생성 시에 not null 제약조건이 붙는다.
unique(DDL)	@Table의 uniqueConstraints와 같지만 한 컬럼에 간단히 유니크 제약조건을 걸 때 사용한다.
columnDefinition (DDL)	데이터베이스 컬럼 정보를 직접 줄 수 있다. ex) varchar(100) default ‘EMPTY'	필드의 자바 타입과 방언 정보를 사용해서 적절한 컬럼 타입
length(DDL)	문자 길이 제약조건, String 타입에만 사용한다.	255
precision, scale(DDL)	BigDecimal 타입에서 사용한다(BigInteger도 사용할 수 있다). precision은 소수점을 포함한 전체 자 릿수를, scale은 소수의 자릿수다. 참고로 double, float 타입에는 적용되지 않는다. 아주 큰 숫자나 정밀한 소수를 다루어야 할 때만 사용한다.	precision=19, scale=2

• 참고로 unique() 는 거의 안 씀 왜냐하면 이 unique 제약조건 명칭이 uuid 처럼 생겨서 실제 운용에서 이 제약조건을 갖다 쓸 수 없기 때문이다.
  

@Temporal

날짜 타입(java.util.Date, java.util.Calendar)을 매핑할 때 사용

• 참고: LocalDate, LocalDateTime을 사용할 때는 생략 가능(최신 하이버네이트 지원)

TemporalType.DATE: 날짜, 데이터베이스 date 타입과 매핑 (예: 2013–10–11)
TemporalType.TIME: 시간, 데이터베이스 time 타입과 매핑 (예: 11:11:11)
TemporalType.TIMESTAMP: 날짜와 시간, 데이터베이스 timestamp 타입과 매핑(예: 2013–10–11 11:11:11)

@Data
@Entity
public class Member {
    @Id
    private Long id;
    @Column(name = "name")
    private String username;
    private Integer age;
    @Enumerated(EnumType.STRING)
    private RoleType roleType;
    @MapKeyTemporal(TemporalType.TIMESTAMP)
    private Date createdDate;
    @Temporal(TemporalType.TIMESTAMP)
    private Date lastModifiedDate;
    
    private LocalDate testLocalDate;
    private LocalDateTime testLocalDateTime;
    
    @Lob
    private String description;
}

@Enumerated

자바 enum 타입을 매핑할 때 사용

속성	설명	기본 값
value	• EnumType.ORDINAL: enum 순서를 데이터베이스에 저장 • EnumType.STRING: enum 이름을 데이터베이스에 저장	EnumType.ORDINAL

• 주의! ORDINAL 사용X => @Enumerated(EnumType.STRING) 이걸 기본으로 생각하자.

@Enumerated(EnumType.STRING)
private RoleType roleType;

why? => 기본다입 ORDINAL을 사용해버리면 enum 이 그냥 단순히 int 로 들어가는데 이러게 되버리면 enum의 순서가 바뀐다든지 값이 바뀌었을 때 데이터 무결성이 깨질 위험이 굉장히 높기 때문이다.

@Lob

데이터베이스 BLOB, CLOB 타입과 매핑

@Lob에는 지정할 수 있는 속성이 없다.
매핑하는 필드 타입이 문자면 CLOB 매핑, 나머지는 BLOB 매핑

CLOB: String, char[], java.sql.CLOB
BLOB: byte[], java.sql. BLOB

@Transient

특정 필드를 컬럼에 매핑하지 않음(매핑 무시)

필드 매핑X
데이터베이스에 저장X, 조회X
주로 메모리상에서만 임시로 어떤 값을 보관하고 싶을 때 사용 => DB랑 관계없이 비즈니스 로직에 중간 계산 값으로 갖고있고 싶을 때 사용.

@Transient
private Integer temp;

• 기본 키 매핑

@Id

직접 할당: @Id만 사용

@GeneratedValue

자동 생성: @GeneratedValue

1. IDENTITY

기본 키 생성을 데이터베이스에 위임
주로 MySQL, PostgreSQL, SQL Server, DB2에서 사용(예: MySQL의 AUTO_ INCREMENT)

여기서 발생하는 문제는 앞서 설명했듯 영속성 콘텍스트가 id값을 키값으로 갖는다는 것이다.
하지만 IENDTITY 전략은 DB에 넣기 전까지 해당 값을 가져올 수 없다는 문제점이 존재한다.

그래서 IDENTITY 전략에서만 JPA는 보통 트랜잭션 커밋 시점에 INSERT SQL 실행한다.
AUTO_ INCREMENT는 데이터베이스에 INSERT SQL을 실행한 이후에 ID 값을 알 수 있음
IDENTITY 전략은 em.persist() 시점에 즉시 INSERT SQL 실행하고 DB에서 식별자를 조회

2. SEQUENCE

데이터베이스 시퀀스 오브젝트 사용, ORACLE ( @SequenceGenerator 필요 )

데이터베이스 시퀀스는 유일한 값을 순서대로 생성하는 특별한 데이터베이스 오브젝트(예: 오라클 시퀀스)
오라클, PostgreSQL, DB2, H2 데이터베이스에서 사용

• 각 테이블(entity) 별 다른 시퀀스 전략을 사용하고 싶을 때

@Entity
@SequenceGenerator(
	name = “MEMBER_SEQ_GENERATOR",
    sequenceName = “MEMBER_SEQ", //매핑할 데이터베이스 시퀀스 이름
    initialValue = 1, allocationSize = 1)
public class Member {
	@Id
    @GeneratedValue(strategy = GenerationType.SEQUENCE,
    generator = "MEMBER_SEQ_GENERATOR")
    private Long id; 
    ...
    

• @SequenceGenerator

속성	설명	기본 값
name	식별자 생성기 이름	필수
sequenceName	데이터베이스에 등록되어 있는 시퀀스 이름	hibernate_sequence
initialValue	DDL 생성 시에만 사용됨, 시퀀스 DDL을 생성할 때 처음 1 시작하는 수를 지정한다.	1
allocationSize	시퀀스 한 번 호출에 증가하는 수(성능 최적화에 사용됨 데이터베이스 시퀀스 값이 하나씩 증가하도록 설정되어 있으면 이 값 을 반드시 1로 설정해야 한다	50
catalog, schema	데이터베이스 catalog, schema 이름

• 주의: allocationSize 기본값 = 50

대충 동작 과정은
1. JPA가 생성 전략이 SEQ라는 것을 확인한다.
2. db에서 값을 얻어와서 멤버 id의 값에 넣어준다. => ( 이때 값을 가져올 때 allocationSize를 사용하여 성능을 향상. )
3. 영속성 컨텍스트를 저장한다.

따라서 버퍼로 모아서 commit 하는 기능이 가능하다.
=> 그런데 사실 이 기능이 성능이 그렇게 많이 차이나진 않는다고 한다.

3. TABLE

키 생성용 테이블 사용, 모든 DB에서 사용 ( @TableGenerator 필요 )

• 테이블 전략
  키 생성 전용 테이블을 하나 만들어서 데이터베이스 시퀀스를 흉내내는 전략 => 어떤 db는 auto increment, 혹은 sequence가 있어서 이 둘 중 하나를 선택해야하는데 이는 그럴 필요가 없다.

장점: 모든 데이터베이스에 적용 가능
단점: 성능 => 운용에서 사용하기 부담스럽다.

create table MY_SEQUENCES (
	sequence_name varchar(255) not null,
    next_val bigint,
    primary key ( sequence_name )
)

@Entity
@TableGenerator(
 name = "MEMBER_SEQ_GENERATOR",
 table = "MY_SEQUENCES",
 pkColumnValue = “MEMBER_SEQ", allocationSize = 1)
public class Member {
	@Id
    @GeneratedValue(strategy = GenerationType.TABLE,
    generator = "MEMBER_SEQ_GENERATOR")
    private Long id; 

• @TableGenerator

속성	설명	기본 값
name	식별자 생성기 이름	필수
table	키생성 테이블명	hibernate_sequences
pkColumnName	시퀀스 컬럼명	sequence_name
valueColumnNa	시퀀스 값 컬럼명	next_val
pkColumnValue	키로 사용할 값 이름	엔티티 이름
initialValue	초기 값, 마지막으로 생성된 값이 기준이다.	0
allocationSize	시퀀스 한 번 호출에 증가하는 수(성능 최적화에 사용됨)	50
catalog, schema	데이터베이스 catalog, schema 이름
uniqueConstraints(DDL)	유니크 제약 조건을 지정할 수 있다.

4. AUTO

방언에 따라 자동 지정, 기본값

권장하는 식별자 전략
• 기본 키 제약 조건: null 아님, 유일, 변하면 안된다.
• 미래까지 이 조건을 만족하는 자연키(비즈니스 적으로 의미를 갖는 주민등록번호, 핸펀번호 등)는 찾기 어렵다. 대리키(대체키)를 사용하자.
• 예를 들어 주민등록번호도 기본 키로 적절하기 않다.
• 권장: Long형 + 대체키 + 키 생성전략 사용

• 데이터베이스 스키마 자동 생성

JPA의 강력한 기능중 하나로 DB에 table이 한개도 없더라고 spring application이 뜰 때 DDL을 애플리케이션 실행 시점에 자동 생성해준다.
이는 테이블 중심개발 방식을 객체 중심 개발방식으로 바꿀 수 있다.
이때, persistance.xml 에 명시해둔 데이터베이스 Dialog를 활용해서 데이터베이스에 맞는 적절한 query문 생성을 해준다.
다만, 이렇게 생성된 DDL은 개발 장비에서만 사용 운용에서 사용하면 안 된다.
생성된 DDL은 운영서버에서는 사용하지 않거나, 적절히 다듬은 후 사용해아한다.

데이터베이스 스키마 자동 생성 옵션 - 속성

<property name="hibernate.hbm2ddl.auto" value="create" />

옵션	설명	참고
create	기존테이블 삭제 후 다시 생성 (DROP + CREATE)
create-drop	create와 같으나 종료시점에 테이블 DROP	주로 testcase를 작성할 때 사용.
update	변경분만 반영(운영DB에는 사용하면 안됨)	alter table 하여 테이블을 업데이트 하고 싶을 때 (domain에서 속성을 추가만 되지 지우는건 안 됨.)
validate	엔티티와 테이블이 정상 매핑되었는지만 확인
none	사용하지 않음

데이터베이스 스키마 자동 생성 - 주의

운영 장비에는 절대 create, create-drop, update 사용하면 안 된다.
개발 초기 : create 또는 update
테스트 서버 : update 또는 validate
스테이징과 운영 서버 : validate 또는 none

그런데 영한쌤이 권장하는 방법은 update도 그냥 자동 생성이 아닌 query문을 직접 작성하여 적용하는 것을 권장하신다.
왜냐하면 update 도 그냥 잘못 실행해버리면 alter query가 날아가서 db가 락이 걸리기 때문이다.

DDL 생성 기능

@Data
@Entity
@Table(uniqueConstraints = {@UniqueConstraint( name = "NAME_AGE_UNIQUE", columnNames = {"NAME", "AGE"} )})
public class Member {
    @Id
    private Long id;
    @Column(nullable = false, length = 10)
    private String name;
}

예를들어 제약조건 추가를 다음과 같이 한다면 " 회원 이름은 필수, 10자 초과X " => " @Column(nullable = false, length = 10) "

혹은 " 유니크 제약조건 추가 " => "@Table(uniqueConstraints = {@UniqueConstraint( name = "NAME_AGE_UNIQUE", columnNames = {"NAME", "AGE"} )})"

• DDL 생성 기능은 DDL을 자동 생성할 때만 사용되고 JPA의 실행 로직에는 영향을 주지 않는다