객체와 테이블 매핑
@Entity
- @Entity가 붙은 클래스는 JPA가 관리한다.
- JPA를 사용해서 테이블과 매핑할 클래스는 @Entity 필수
주의점
- 기본 생성자 필수(파라미터가 없는 public 또는 protected 생성자)
- DB에 저장할 필드에 final 사용 불가
- final 클래스, enum, interface, inner 클래스는 @Entity로 맵핑할 수 없음
@Entity 속성 name
@Entity(name="anotherMember")- JPA에서 사용할 엔티티 이름을 지정
- 기본값은 클래스 이름을 그대로 사용(예: Member)
- 중복되는 클래스 이름이 없으면 가급적 기본값을 사용한다.
@Table
@Table은 엔티티와 매핑할 테이블 지정
|
속성
|
기능
|
기본값
|
|
name
|
매핑할 테이블 이름
|
엔티티 이름을 사용
|
|
catalog
|
데이터베이스 catalog 매핑
|
|
|
schema
|
데이터베이스 schema 매핑
|
|
|
uniqueConstraints (DDL)
|
DDL 생성 시에 유니크 제약 조건 생성
|
데이터베이스 스키마 자동 생성
- DDL을 애플리케이션 실행 시점에 자동 생성
- 데이터베이스 방언을 활용해서 데이터베이스에 맞는 적절한 DDL 생성
- 이렇게 생성된 DDL은 개발 장비에서만 사용
- 생성된 DDL은 운영서버에서는 사용하지 않거나, 적절히 다듬 은 후 사용
속성
hibernate.hbm2ddl.auto 프로퍼티에 value 부분에 아래와 같은 옵션을 줄 수 있음
| 옵션 | 설명 |
|
create
|
기존테이블 삭제 후 다시 생성 (DROP + CREATE)
|
|
create-drop
|
create와 같으나 종료시점에 테이블 DROP, 테스트 시 마지막에 깔끔하게 모두 날릴 때 사용 가능
|
|
update
|
변경분만 반영(운영DB에는 사용하면 안됨)
필드를 추가하면 추가된 필드만 ALTER 문으로 반영됨 필드를 삭제했다면 DB상에는 아무일도 일어나지 않음 |
|
validate
|
엔티티와 테이블이 정상 매핑되었는지만 확인
필드를 추가하고 실행시 현재 상태와 DB 컬럼이 맞지 않으므로 에러 발생함 |
|
none
|
데이터베이스 스키마 자동생성 사용하지 않음
|
주의점
- 운영 장비에는 절대 create, carete-drop, update 사용하면 안됨
- 개발 초기 단계는 create 또는 update(로컬에서만 쓸 때)
- 테스트 서버는 update 또는 validate (여러 개발자들과 함께 쓸 때)
- 스테이징과 운영 서버는 validate 또는 none
- 테스트 서버도 validate만 권장
- 스크립트를 가급적 직접 만들어서 로컬db에 테스트해보고 문제없으면 운영 서버에 반영하는 것 권장
- 로그에 나오는 쿼리를 좀 수정해서 직접 다듬어서 쓰는 것은 OK
DDL 생성 기능
DB 컬럼에 제약조건 추가 : 회원 이름은 필수, 10자 초과X
@Column(nullable = false, length = 10)
- DDL 생성 기능은 DDL을 자동 생성할 때만 사용되고 JPA의 실행 로직에는 영향을 주지 않음
필드와 컬럼 매핑
요구사항
- 회원은 일반회원과 관리자로 구분해야 한다.
- 회원가입일과 수정일이 있어야한다.
- 회원을 설명할 수 있는 필드가 있어야 한다.이 필드는 길이 제한이 없다.
package hellojpa;
import javax.persistence.*;
import java.time.LocalDate;
import java.time.LocalDateTime;
import java.util.Date;
@Entity
public class Member {
@Id
private Long id;
@Column(name = "name")
private String username;
private Integer age;
@Enumerated(EnumType.STRING)
private RoleType roleType;
@Temporal(TemporalType.TIMESTAMP)
private Date createdDate;
@Temporal(TemporalType.TIMESTAMP)
private Date lastModifiedDate;
@Lob
private String description;
}
매핑 어노테이션 정리
hibernate.hbm2ddl.auto
|
어노테이션 설명
|
|
기본 값
|
|
@Column
|
컬럼 매핑
|
|
|
@Temporal
|
날짜 타입(java.util.Date, java.util.Calendar) 매핑, java8 이상 최신버전에서는 필요가 없음 LocalDate(연월 -> DB에서 date 타입으로 생성), LocalDateTime(연월일 -> DB에서 timestamp 타입으로 생성)을 사용할 때는 생략 가능
과거 버전은 TemporalType.DATE: 날짜 -> 데이터베이스 date 타입과 매핑(예: 2013–10–11)
TemporalType.TIME: 시간 -> 데이터베이스 time 타입과 매핑 (예: 11:11:11) TemporalType.TIMESTAMP -> 날짜와 시간, 데이터베이스 timestamp 타입과 매핑
(예: 2013–10–11 11:11:11) |
|
|
@Enumerated
|
enum 타입 매핑,
|
EnumType .ORDINAL |
|
@Lob
|
BLOB, CLOB 매핑
@Lob에는 지정할 수 있는 속성이 없다.
매핑하는 필드 타입이 문자면 CLOB 매핑, 나머지는 BLOB 매핑
CLOB: String, char[], java.sql.CLOB BLOB: byte[], java.sql. BLOB |
|
|
@Transient
|
특정 필드를 컬럼에 매핑하지 않음(매핑 무시)
데이터베이스에 저장X, 조회X
주로 메모리상에서만 임시로 어떤 값을 보관하고 싶을 때 사용 |
|
@Column
|
속성
|
설명
|
기본값
|
|
name
|
필드와 매핑할 테이블의 컬럼 이름
|
객체의 필드 이름
|
|
insertable, updatable
|
등록, 변경 가능 여부
|
TRUE
|
|
nullable(DDL)
|
null 값의 허용 여부를 설정한다.
false로 설정하면 DDL 생성 시에 not null 제약조건이 붙는다. |
|
|
unique(DDL)
|
@Table의 uniqueConstraints와 같지만 한 컬럼에 간단히 유니크 제약조건을 걸 때 사용
위 방법은 제약 조건 이름이 랜덤으로 들어가서 @Table(uniqueConstraints = {@UniqueConstraint( name = "NAME_AGE_UNIQUE",
columnNames = {"NAME", "AGE"} )})
|
|
|
columnDefinition (DDL)
|
데이터베이스 컬럼 정보를 직접 줄 수 있다.
ex) varchar(100) default ‘EMPTY'
|
필드의 자바 타입과 방언 정보를 사용해
|
|
length(DDL)
|
문자 길이 제약조건, String 타입에만 사용한다.
|
255
|
|
precision, scale(DDL)
|
BigDecimal 타입에서 사용한다(BigInteger도 사용할 수 있다).
precision은 소수점을 포함한 전체 자 릿수를, scale은 소수의 자릿수다. 참고로 double, float 타입에는 적용되지 않는다. 아주 큰 숫자나 정 밀한 소수를 다루어야 할 때만 사용한다. |
precision=19,
scale=2 |
기본 키 매핑
@Id
@GeneratedValue(strategy = GenerationType.AUTO)
private Long id;
직접 할당 : @Id만 사용
예) 이것 저것 조합해서 Id를 만들어 쓸 경우
자동 생성 : @GeneratedValue도 같이 사용
@GeneratedValue 속성 종류
IDENTITY : 난 모르겠고 DB 너가 알아서 해줘
- 기본 키 생성을 데이터베이스에 위임
- 주로 MySQL, PostgreSQL, SQL Server, DB2에서 사용
- JPA는 보통 트랜잭션 커밋 시점에 INSERT SQL 실행
- AUTO_ INCREMENT는 데이터베이스에 INSERT SQL을 실행한 이후에 ID 값을 알 수 있음
- JPA에서는 예외적으로 커밋하는 시점이 아닌 persist 함수 호출시 바로 DB에 INSERT 쿼리가 날라가고, ID를 영속성 컨택스트에 저장함
- 버퍼링을 쓸 수 없음
SEQUENCE
데이터베이스 시퀀스 오브젝트 사용
: 유일한 값을 순서대로 생성하는 특별한 데이터베이스 오브젝트(예: 오라클 시퀀스)
- 오라클, PostgreSQL, DB2, H2 데이터베이스에서 사용
- @SequenceGenerator 필요
@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;
persist 함수 호출하는 시점에
call next value for 시퀀스_이름시퀀스 정보를 가져와서 영속성 컨택스트에 저장하고, 실제 쿼리는 나가지 않음
-> 버퍼링 가능
@SequenceGenerator 속성
|
속성
|
설명
|
기본값
|
|
name
|
식별자 생성기 이름
|
필수
|
|
sequenceName
|
데이터베이스에 등록되어 있는 시퀀스 이름
|
hibernate_sequence
|
|
initialValue
|
DDL 생성 시에만 사용됨, 시퀀스 DDL을 생성할 때 처음 시작하는 수를 지정한다.
|
1
|
|
allocationSize
|
시퀀스 한 번 호출에 증가하는 수(성능 최적화에 사용됨 데이터베이스 시퀀스 값이 하나씩 증가하도록 설정되어 있으면 이 값 을 반드시 1로 설정해야 한다.
메모리에서 미리 땡겨온 시퀀스 개수만큼 쓰는 방법 |
50
|
|
catalog, schema
|
데이터베이스 catalog, schema 이름
|
TABLE : 키 생성용 테이블 사용, @TableGenerator 필요
- 키 생성 전용 테이블을 하나 만들어서 데이터베이스 시퀀스를 흉 내내는 전략
- 장점: 모든 데이터베이스에 적용 가능
- 단점: 성능
@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;위 코드 실행시 아래와 같은 테이블이 생성된다.
create table MY_SEQUENCES (
sequence_name varchar(255) not null,
next_val bigint,
primary key ( sequence_name )
)
@TableGenerator 속성
| 속성 | 설명 | 기본값 |
|
name
|
식별자 생성기 이름
|
필수
|
|
table
|
키생성 테이블명
|
hibernate_sequences
|
|
pkColumnName
|
시퀀스 컬럼명
|
sequence_name
|
|
valueColumnNa
|
시퀀스 값 컬럼명
|
next_val
|
|
me pkColumnValue
|
키로 사용할 값 이름
|
엔티티 이름
|
|
initialValue
|
초기 값, 마지막으로 생성된 값이 기준이다.
|
0
|
|
allocationSize
|
시퀀스 한 번 호출에 증가하는 수(성능 최적화에 사용됨)
|
50
|
|
catalog, schema
|
데이터베이스 catalog, schema 이름
|
|
|
uniqueConstraint s(DDL)
|
유니크 제약 조건을 지정할 수 있다.
|
AUTO : 방언에 따라 자동 지정, 기본값
권장하는 식별자 전략
- 기본 키 제약 조건: null 아님, 유일, 변하면 안된다.
- 미래까지 이 조건을 만족하는 자연키는 찾기 어렵다. 대리키(대체키)를 사용하자.
- 예를 들어 주민등록번호도 기본 키로 적절하기 않다.
- 권장: Long형 + 대체키 + 키 생성전략 사용
- 비즈니스 관련 내용을 키로 갖고 오는것은 권장하지 않음
'JPA' 카테고리의 다른 글
| 05. 연관관계 매핑 기초 (0) | 2024.04.28 |
|---|---|
| [JPA 프로그래밍] - 03. 영속성 관리 (0) | 2024.03.02 |