JPA #9 값 타입, 컬렉션, 임베디드 타입

JPA에서는 2가지 데이터 타입을 제공한다.

@Entity 는 데이터가 변해도 식별자로 계속 추적이 가능하다. 값이 변경되면 식별자로 인식 가능하다.

기본 값 타입은 @Entity 와 생명주기를 공유하며, String, Integer, int 등을 의미한다.

 

단, 값 타입에 대한 식별자는 따로 존재하지 않으므로 JPA의 변경추적이 불가능하다.

이게 무슨말이냐면, 외부에 값타입을 변경할 수 있는 참조가 있다면 Side-Effect가 발생할 위험이 있다는 말.

• 뭐 사실 자바에서 Primitive Type (int, long)은 참조값 공유가 불가능해서 별 상관이 없다.
• Integer나 String은 래퍼타입은 참조값은 공유가 가능하지만, 변경이 불가능하게 막혀있다. 

 

그래서 이걸 설명하는 이유가 뭐죠? 당연한거 아니에요?

JPA에서 기본값 타입만 사용한다면 아무런 문제가 없다.

값 타입중에는 Embedded Type, Collection Type이 존재하기 때문에, 이 차이를 꼭 알아야한다.

 

📌 r값 타입 - Embedded

값 타입은 @Entity의 생명주기에 의존한다. 즉 Entity가 삭제되면 값도 삭제된다. 당연한 이야기

값 타입은 JPA에서 변경 추적이 불가능하다. 즉 아래와 같은 Side-Effect를 조심해야한다.

이런 경우 큰일날 수 있다.

* 참고로 EmbeddedType 또한 프록시를 이용하기 때문에 기본생성자가 필수적이다.

없으면 JpaSystemException: No default constructor for entity 예외 발생

 

 

EmbeddedType이 뭐였죠?

📌 @Embedded (컴포넌트)

우리가 @Entity를 무지성으로 설계하면 아래와 비슷하게 나온다.

// 임베디드 타입 사용하지 않았을 때
@Entity
public class Member {
  
  @Id @GeneratedValue
  private Long id;
  
  private String name;
  
  // 근무 기간
  LocalDate startDate;
  LocalDate endDate;
  
  // 집 주소 표현
  private String city;
  private String street;
  private String zipcode;
  // ...
}

회원이 위와 같은 데이터를 가진 이유는 아래와 같이 설계하고자 했기 때문이다.

"회원 엔티티는 이름, [ 근무 기간 ], [ 집 주소 ]를 가진다."

 

실제 데이터는 '근무기간', '집 주소'라는 하나의 값으로 다루기에는 까다롭다. 그래서 이런 Entity가 만들어진다.

 

"회원 엔티티는 이름, [근무 시작일, 근무 종료일], [주소 도시, 주소 동호수, 우편 번호]를 가진다."

 

무언가 어색하지 않은가? 회원이 '집 주소'가 필요한거지 '서울', '906호' 이런 값이 단독으로 필요한 경우가 있을까?

 

아니 애초에, [ 집 주소 ] 는 하나의 데이터로 봐야할거 같은데, 여기에 포함된 세부 데이터를 회원이 가지고 있는게 객체지향적으로 좋은 설계인지 고민해볼 필요가 있다. 이는 응집력을 떨어뜨리고, 유지보수를 어렵게 만든다.

 

 

✨ 이를 해결하기 위해 JPA에서는 @Embedded 타입 (컴포넌트)를 제공해준다.

• 임베디드 타입을 사용한다고 해서 DB 테이블이 더 생성되지는 않는다. 기존과 동일하게 매핑해서 사용.
• 한번 만들어두면 다른 곳에서 재사용이 가능하다. (+ 데이터의 응집도가 높아진다)
• Embedded 타입 내부에서 메서드를 통해 의미있는 새로운 값 ( isMan() )을 뽑아낼 수 있다.

// 임베디드 타입 사용
@Entity
public class Member {
  
  @Id @GeneratedVAlue
  private Long id;
  private String name;
  
  @Embedded
  private Period workPeriod;	// 근무 기간
  
  @Embedded
  private Address homeAddress;	// 집 주소
}

 

 

임베디드 타입은 아래와 같이 정의 가능하다.

@Embeddable
public class Address {
  
  @Column(name="city") // 매핑할 컬럼 정의 가능
  private String city;
  
  private String street;
  private String zipcode;
  
  public boolean isMetropolitanCity (City city) {
  // .. 값 타입을 위한 메서드를 정의할 수 있다
  }
}

 

당연히 임베디드 타입 안에서 다른 임베디드 타입을 사용할 수 있다.

그래서 잘 설계된 JPA Entity는 보통 DB 테이블보다 더 많은 수의 객체를 가지는게 일반적이다.

 

재밌는건 Embedded 타입이 Entity를 가질 수도 있다. (그냥 쓰는 거랑 똑같다.)

실제 테이블은 Member 하나이다.

---

// 임베디드 타입 사용
@Entity
public class Member {
  
  @Id @GeneratedVAlue
  private Long id;
  private String name;
  
  @Embedded // @Embedded 생략하더라도 JPA에서 알아서 찾아주지만, 쓰는 걸 권장한다.
  private Period workPeriod;	// 근무 기간
  
  @Embedded
  private Address homeAddress;	// 집 주소
}

@Embeddable
public class Address {
  
  @Column(name="city") // 매핑할 컬럼 정의 가능
  private String city;
  
  private String street;
  private String zipcode;
  
  public boolean isMetropolitanCity (City city) {
  // .. DB에 존재하지않는 의미있는 새로운 값을 만들 수 있다.
  }
}

 

한번 더 말하지만, Embedded 타입은 객체에서만 존재할 뿐 테이블에는 아무런 영향이 없다.

DB는 똑같다.

참고로 아래와 같이 @Embedded 타입 자체가 null이면, 내부에도 전부 null이 들어가게 된다.

@Embedded
private Address homeAddress = null;
// Address 객체안의 있는 칼럼 값이 전부 null로 매핑됨

 

 

✔ 한 Entity에서 같은 값 타입을 여러개 사용하고 싶다면?

Embedded 타입은 객체에서만 사용하는 것일 뿐, 매핑하는 테이블은 변화가 없다고 했다.

그래서 아래와 같이 같은 Embedded 타입을 여러번 사용하면 DB 칼럼명이 중복되어 매핑이 불가능하다. (예외 발생)

@Entity
public class Member {

    @Embedded
    private Address homeAddress;

    @Embedded
    private Address companyAddress;

}

이 경우에는 @AttributeOverrides를 이용해서 직접 테이블과 수동으로 매핑시켜주면 된다.

@Embedded
@AttributeOverrides({
    @AttributeOverride(name="city", column=@Column("WORK_CITY"))
    @AttributeOverride(name="street", column=@Column("WORK_STREET")),
    @AttributeOverride(name="zipcode", column=@Column("WORK_ZIPCODE")),
})
private Address homeAddress;

@Embedded
private Address companyAddress;

 

 

📌 값 타입과 불변 객체(final)

값 타입의 실제 인스턴스 (값 그 자체)를 공유하는건 매우 위험하다.

값 타입은 반드시 복사해서 사용해야한다.

그러나 객체는 참조를 전달하는건 실수하기 쉽다. 공유 참조 자체를 막는 방법은 없기 때문이다.

int a = 5;
int b = a; // 값 복사
b = 4 // 아무런 문제 없음.

Address a = new Address();
Address b = a; // 🧨 참조를 전달함. 값 복사가 아님
b.setCity("New") // 🧨 a도 함께 변경됨!

 

이렇게 외부의 Side-Effect로 발생하는 버그는 찾기 정말 어렵다.

이를 방지하기 위해서는 값 타입을 불변 객체 (immutable object)로 설계해야 한다.

 

즉 생성자로만 값을 설정하고, Setter를 다 없애버려야한다.

 

 

📌 값 타입 - Collection

객체에는 컬렉션이 있지만, DB에는 컬렉션이라는 개념이 없다. 컬렉션을 저장하기 위한 별도의 테이블이 필요하다.

또한 Entity가 아닌 [값 타입]은 PK를 따로 사용할 수 없기 때문에, 모든 칼럼을 묶어 PK로 사용해야한다.

null 입력을 막고 중복 저장을 막아야 하기 때문.

MEMBER_ID를 외래키로 가지고 [모든 값을 PK]로 사용함.

 

@Entity의 경우 1:N 관계로 지정해주면 됐었다.

@Entity
public class Member{ ... }


@OneToMany(mappedBy="team")
private List<Member> members = nwe ArrayList<>();

 

값 타입의 경우 @ElementCollection, @CollectionTable을 사용하면 된다.

@ElementCollection // 기본 값 타입
@CollectionTable (name = "FAVORITE_FOOD", joinColumns = @JoinColumn(name="MEMBER_ID") )
private Set<String> favoriteFoods = new HashSet<>();


@ElementCollection // 임베디드 값 타입
@CollectionTable (name = "FAVORITE_FOOD", joinColumns = @JoinColumn(name="MEMBER_ID") )
private List<Address> favoriteFoods = new ArrayList<>();

 참고로 @ElementCollection(fetch = LAZY)가 기본값이다. 값 타입을 즉시로딩으로 쓰면 정말 큰일난다.

 

 

✔ 값 타입 컬렉션의 특징

• 값 타입은 Entity와 다르게 식별자 개념이 없다.
• 생명주기가 Entity에 묶여있다. 따로 영속화 할 수 없고 부모 Entity를 persist()하면 함께 반영된다.
• 값 타입 컬렉션에 일부가 변경되면, 수정이 아니라 모든 데이터를 삭제하고 다시 저장해야한다.
  그렇게 하지 않고 값타입을 불변하지 않게 만들고 수정한다면 Side-effect가 발생한다.

Member member = em.find(Member.class, 1L);

// 🧨 SideEffect 발생!! 변경 추적이 불가능하다.
member.getHomeAddress().setCity("new city"); ❌

// 이렇게 값 객체를 아예 새로 만들어 교체해야한다. 중복되더라도 어쩔 수 없다.
member.setHomeAddress( new Address("new city","street","postcode") ); ⭕

em.persist(member);

Member member = em.find(Member.class, 1L);

// 컬렉션도 마찬가지. 값을 수정하는 개념은 없다. 새로운 값 추가 or 기존 값 삭제.
member.getFavoriteFoods().remove("치킨")
member.getFavoriteFoods().add("한식")

em.persist(member);

 

 

✔ DB 쿼리도 그렇다. 업데이트를 하는게 아니라 교체를 해버린다.

@OrderColumn 을 이용해서 테이블 초기화가 아닌 업데이트 쿼리가 나가게 할 수는 있지만.. null이 위험하고 번거롭다.

차라리 Entity (AddressEntity)로 바꿔서 사용하자.

member.getAddresshistory().add( new Address( "old1", "city" ) );
member.getAddresshistory().remove( new Address( "old1", "city" ) );
member.getAddresshistory().add( new Address( "new1", "citty" ) );

// 결과적으로 남아있는 Address = 총 2개
// 실제 쿼리도 테이블을 날려버리고, 새로운 Address를 2개 추가한다.

 

기대한대로 동작은 하지만.. Address 테이블을 날려버리고 다 새롭게 넣었다. (식별자가 없어서 변경추적이 안됨)

 

 

✔ 값 타입은 반드시 equals()와 hashcode()를 적절하게 정의해주자

JPA는 값 타입의 equals()와 hashcode() 를 이용해서 특정 값을 찾아서 삭제할 수 있다.

member.getValues().remove(3) // 이런 건 당연히 된다.
member.getValues().add(4)

// 이런 것도 가능하다. JPA가 equals와 hashcode 메서드를 이용해서 비교 후 삭제한다.
member.getValues().remove( new Address("old1", "street", "10000") );

그래서 아래와 같이, 값 타입을 만들 땐 equals와 hashcode를 제대로 구현하도록 하자.

이렇게 값 타입(Address)에 제대로 정의가 되어있지 않으면, remove가 제대로 동작하지 않는다.

 

➡ 그래서 굳이 값 타입 Collection 을 사용하는 것 보다 Entity로 전환하는게 더 나을 수 있다.

앞에서 말한 Cascade ALL + Orphan Removal 을 이용하면 Entity를 값 타입 컬렉션처럼 이용할 수 있다.

 

 

 

📌 값 타입은, 정말 '값'일 때에만 사용하자.

➡ 값 타입 Collection 을 사용하는 것 보다 @OneToMany Entity로 전환하는게 더 나을 수 있다.

앞에서 말한 Cascade ALL + Orphan Removal 을 이용하면 Entity를 값 타입 컬렉션처럼 이용할 수 있다.

식별자가 필요하고 지속해서 변경을 추적해야한다면 (교체가 아니라 일부 수정됨을 추적해야 한다면) 그건 값이 아닌 엔티티임을 명심하자.

 

 

 

참고로 값 타입은 엔티티 도메인 모델에서 아래와 같이 그릴 수 있다.

Address <<Value Type>>