CH04 엔티티 매핑
Last updated
Last updated
이번 장은 제목 그대로 엔티티 레벨에서 매핑을 어떻게 시키는지에 관한 이야기이다. 여기서 나는 '매핑' 이라는 단어의 의미를 짚어보고 싶다. 왜 여기서 '매핑' 이라는 단어를 사용 한 것일까?
현재 JPA 를 학습하고 있고 JPA 는 자바 진영의 ORM 기술 명세이다. ORM 의 의미에 대해서 먼저 잠깐 짚어보자. 아래는 백기선님 강의 노트에 내가 적은 필기의 일부이다.
의 의미에 대해서 정의된 자료는 많았지만 강의에서 말하고 있는 의미와 가장 유사하고 내가 생각하기에 가장 적절한 표현이라고 생각되는 것은 아래와 같다.
Object-relational mapping (ORM) is a programming technique in which a metadata descriptor is used to connect object code to a relational database. Object code is written in object-oriented programming (OOP) languages such as Java or C#. ORM converts data between type systems that are unable to coexist within relational databases and OOP languages.
다시 말해, ORM 은 우리가 데이터를 영속화 할 때 RDBMS를 이용하고 싶은 상황인데 코드는 객체 지향 언어로 작성을 해야할 경우 이를 해결해주는 기술 이라고 말할 수 있는 것이다.
ORM 은 메타 데이터를 통해서 특정한 object와 특정한 RDBMS 의 테이블(relational) 을 매핑해주고, 같은 맥락에서 특정한 object 의 특정한 필드와 특정한 테이블의 특정한 컬럼을 매핑해주는 기술인 것이다.
여기서 말하는 메타 데이터란 @Table, @Column 등으로 사용했던 코드들을 의미한다.
위와 같은 의미에서 Object 와 Relational 의 사이에 '매핑' 이 필요한 것이다. 그리고 매핑의 기준이 되는 것은 메타데이터이다. 이 장에서는 엔티티 레벨에서의 매핑을 위해서 어떤 메타데이터들이 어떤식으로 작동되어 결국 매핑에 사용되는지를 학습한다.
테이블과 매핑할 클래스라는 것을 JPA 에 인식 시키는 메타 데이터이다. 속성으로 name 이 있는데 기본값으로 클래스 명을 사용한다. 사실 엔티티의 이름이 무엇인지는 경험상 하나도 중요하지 않았다. 엔티티의 이름은 결국 아래에서 알아볼 @Table 의 name 설정에 사용된다. 기본적으로 @Table 의 name 은 따로 설정해주지 않으면(Implicit Naming Strategy) 엔티티의 name 을 스네이크 케이스로 변환하는 전략을 사용한다.
기억해야할 가장 중요한 부분은 엔티티로 설정된 클래스는 기본 생성자가 반드시 필요하다는 것이다. JPA 가 엔티티를 생성할 때 리플랙션을 사용하기 때문에 기본 생성자를 반드시 만들어 줘야한다. 사실 만들지 않으면 이미 컴파일 에러가 나기 때문에 무조건 만들게는 되어 있는데 이유를 알고 있도록 하자.
이와 관련해서 에도 아래와 같이 근거가 있다.
The no-argument constructor, which is also a JavaBean convention, is a requirement for all persistent classes. Hibernate needs to create objects for you, using Java Reflection. The constructor can be private. However, package or public visibility is required for runtime proxy generation and efficient data retrieval without bytecode instrumentation.
@Entity 의 name 값은 디폴트로 클래스 명이 사용되며 이는 @Table 의 name 을 Implicit Naming Strategy 로 정할 경우 스네이크 케이스로 변환되어 사용된다.
JPA는 엔티티 생성시 리플랙션을 이용하므로 @Entity 로 설정해주는 클래스는 반드시 기본 생성자가 필요하다.
name 속성이 어떻게 정해지는지에 관해서는 @Entity 에서 이미 알아보았다. 나는 개인적으로 명시적으로 드러내어 적어주는 것을 더 선호한다.
uniqueConstraints 속성으로 유니크 제약조건을 만들 수 있다. 개인적으로 대리키를 사용하는 경우 굳이 두 컬럼 이상을 복합키로 설정할 필요성을 느꼈던 적은 없다.
책에서는 언급되지 않았는데 indexes 속성을 통해서 인덱스 설정을 할 수 있다. 아래는 인덱스 설정 예시이다.
회사에서는 운영 DB 에 접속할때 어플리케이션에서 사용하는 계정이 DDL 권한 자체가 없었어서 사실 운영환경에서는 해당 속성이 큰 의미가 없었다. 하지만 그럼에도 validate 와 같은 속성은 유용하게 사용될 수 있기도 하고, 회사 규모가 작다면 권한에 자유도가 크기 때문에 ddl-auto 속성에 대해서 세세하게 알고 있는 것이 좋다.
create
DROP + CREATE 이다. 만들어야 되니까 기존에 혹시 있으면 drop 을 시킨다.
create-drop
DROP + CREATE + DROP
update
데이터베이스 테이블과 엔티티를 비교해서 변경사항만 수정한다. 없던 컬럼이 생기면 추가는 해주는데 있던 컬럼이 엔티티 상에서 없어졌다고 해서 컬럼을 삭제하진 않는다.
validate
데이터베이스 테이블과 엔티티를 비교해서 차이가 있으면 어플리케이션을 실행하지 않는다. 체크만 하고 어떤 DDL도 발생하지 않는다.
none
기본 값으로 속성을 아예 명시적으로 설정하지 않으면 적용되는 값이다. ddl-auto 행위 자체를 아무 것도 하지 않는다.
기본 키 생성 전략으로 직접 할당하는 방식과 자동 생성하는 방식 두 가지를 사용할 수 있다. 직접 할당은 말 그대로 PK 값을 개발자가 직접 설정하는 것이도 자동 생성은 개발자가 개입하지 않고 자동으로 생성되도록 하는 방식이다. 그래서 직접 할당은 특별히 정리할 부분은 없고 자동 생성 방식에서 여러 옵션들을 살펴보자.
직접 할당: 기본 키를 개발자가 직접 할당한다.
자동 생성: 대리 키 사용 방식
IDENTITY: 기본 키 생성을 데이터베이스에 위임한다.
SEQUENCE: 데이터베이스 시퀀스를 사용해서 기본 키를 할당한다.(시퀀스 지원하는 벤더만 사용 가능)
TABLE: 키 생성 테이블을 사용한다.(모든 벤더 사용 가능)
PK 로 사용할 컬럼은 @Id 라는 메타데이터만 설정해주면 되는데, 여기서 그치면 직접 할당을 사용하겠다는 것이고 @GeneratedValue 까지 설정해주면 자동 생성 전략을 사용하겠다는 것이다. 그리고 strategy 속성을 설정해주면 된다.
아무튼 기본 키 생성을 데이터베이스에 위임하는 전략이다. MySQL 의 경우 auto_increament 로 동작한다. 내가 실무에서 가장 많이 사용한 전략이다.
이미 알아보았지만 이 전략을 사용할 경우 1차 캐시 저장을 위해서 insert 가 발생한다. 쓰기 지연이 발생하지 않는다는 것이다. 왜냐하면 1차 캐시 저장을 위해서는 PK 를 채번해야하고 PK 생성은 데이터 베이스에 위임되어 있으므로 결국 데이터베이스에 insert 가 당장 실행되어야 하기 때문이다.
시퀀스를 지원하는 벤더에서 사용이 가능한 전략이다. 아래 예시 코드 처럼 사용이 가능하다.
IDENTITY 와 가장 큰 차이는 영속화시에 insert 가 발생하지 않는다는 것이다. 위에서 이미 살펴보았듯이 IDENTITY 는 PK 채번이 insert 를 해야 발생한다. 반면 시퀀스에서는 PK를 시퀀스의 nextval 로 채번할 수 있다. 그래서 insert 가 발생하지 않고 시퀀스를 사용해서 PK를 조회하여 영속성 컨택스트에 저장한다.
또 한가지 알아둘 것은 @SequenceGenerator 의 allocationSize 의 기본 값이 50이라는 것이다. 위 코드에서는 1이라고 일부러 설정해줬으나 기본 값이 50이다.
1이 아니라 50인 이유는 성능 때문인데 최대한 시퀀스에 접근하는 횟수를 줄이고자 한 번 접근 했을때 증가시키는 양 및 가져오는 시퀀스의 양을 많이 잡아두는 것이다. 그리고 한번 접근해서 가져온 50개를 가지고 영속성 컨텍스트에 저장하거나 할 때 메모리 상에서 PK 를 할당하는 방식이다.
시퀀스 전략과 유사하다. 시퀀스 대신 키값을 제공하는 테이블을 만들어서 그 테이블에서 키값을 채번한다. 그래서 시퀀스를 지원하지 않는 데이터베이스에서도 사용할 수 있다. 책에는 사용법이 자세하게 정리되어 있으나 쓸 일이 없으니 이 부분은 스킵한다.
위에서 살펴본 IDENTITY, SEQUENCE, TABLE 중 데이터베이스 방언에 따라 자동으로 선택되어 사용되게 하는 옵션이다. 결론적으로 쓰지 말자.
필드와 컬럼 매핑시 기준이 되는 메타데이터(어노테이션) 들에 대해서 학습했다. 특별히 정리할만한 내용은 없었다. 일반적인 내용 말고 가볍게 내가 인지하고 넘어갈 만한 내용만 어노테이션 별로 정리한다.
만약 유니크 제약을 걸어야 한다면 @Column 속성 중 unique 를 사용하면 간편하게 걸 순 있지만 네이밍을 컨벤션에 따라 걸지 못하기 때문에 @Table 의 uniqueConstraints 를 사용하도록 하자.
그리고 책이 좀 오래되어서 그런지 @Comment 에 대한 언급이 없다. 반드시 채워주도록 하자.
주석에 설명이 매우 깔끔하게 잘 되어있다.
value 는 ORDINAL 은 절대로 사용하지 말자. 코드 내 ENUM 선언 순서에 데이터가 종속되게 된다. 쓰는 것을 본 적도 없다. STRING 이 기본값이 왜 아닐까, 아마 데이터베이스 성능 때문에 기본값을 ORDINAL 로 해놓지 않았을까 싶다.
Temporal 자체가 '시간의' 라는 뜻이 있다. 나는 개인적으로 LocalDateTime 과 같은 자바 형식을 사용했고, 이 어노테이션은 실무에서 사용한 적이 없다. 책에서는 아래와 같이 사용 예를 소개하고 있다.
당연한 이야기지만 위와 같이 처리하면 DDL 에서 형식이 순서대로 date, time, timestamp 로 잡힌다.
Transient 자체가 '일시적인'이라는 뜻이 있다. 도메인 객체에서 컬럼으로 만들고 싶지는 않지만 상태값으로 필드가 필요한 경우에 사용한다. 가급적 쓰지 않는게 좋은 것 같다. 예전에 실무에서 필요에 의해서 사용했던 적이 있지만 지금 생각해보면 그렇게 처리했던게 썩 좋은 방법은 아닌 것 같다.
필드로 반드시 남아야하는 것이면 컬럼이 되었을 것이고, 임시로 체류해야하는 상태값이라면 서비스 레이어에서 상태값을 관리하고 도메인 객체에는 멱등성 있는 함수만 선언해서 사용하는 것이 더 좋은 처리였을 것 같다.
그동안 이 용어 자체에 대해서 고민 없이 사용했는데, 이번 기회로 검색을 좀 해봤다. 이제보니 이라는 용어 자체가 특정 벤더에만 적용되는 용어가 아니고 '데이터베이스에 의해서 자동으로 증가되는 값의 컬럼' 이라는 범용적 의미를 가진 용어였다.(이것도 아직은 그런 것 같다 정도의 추측이다. 명확한 레퍼런스가 없다)