[JPA] 값 타입

JPA의 최상위 데이터 타입 분류(2가지)

1. 엔티티 타입

   • @Entity로 정의하는 객체
   • 데이터가 변해도 식별자로 지속해서 추적이 가능하다.
   • ex) 회원 엔티티의 키,나이 값을 변경해도 식별자로 인식이 가능하다.

2. 값 타입

   • int, Integer, String처럼 단순히 값으로 사용하는 자바 기본 타입니다 객체
   • 식별자가 없고 값만 있으므로 변경시 추적이 불가능하다.
   • ex) 숫자 100을 200으로 변경하면 완전히 다른 값으로 대체된다.

값 타입 분류 (3가지)

1. 기본값 타입
   • 자바 기본 타입 (int, double)
   • 래퍼 클래스 (Integer, Long)
   • String
2. 임베디드 타입 (embedded type, 복합 값 타입)
   • 반드시 JPA에서 정의하여 사용해야 한다.
   • ex) 좌표의 경우, Position Class
3. 컬렉션 값 타입 (collection value type)
   • 반드시 JPA에서 정의하여 사용해야 한다.
   • 컬렉션에 기본값 또는 임베디드 타입을 넣은 형태이다.

기본 값 타입

특징

• 생명 주기를 엔티티에 의존한다.
  • ex) 회원을 삭제하면 이름, 나이 필드도 함께 삭제된다.
• 값 타입은 공유하면 안된다.
  • (중요) Side Effect가 발생할 수 있기 때문이다
  • ex) 회원 이름 변경시 다른 회원의 이름도 함께 변경되면 안된다.

※ 자바의 기본 타입은 절대 공유 X

int, double 같은 기본 타입(primitive type)은 절대 공유가 안된다.

• 자바의 기본 타입은 공유되지 않는다.

  int a = 20;
  int b = a; // 20이라는 값을 복사
  b = 10; 

• Integer같은 래퍼 클래스나 String과 같은 특수한 클래스는 공유 가능한 객체이지만 변경은 불가능하다.

  Integer a = new Integer(10);
  Integer b = a; // a의 참조를 복사 

  // side Effect 발생으로 아래 코드는 실행되지 않는다.(변경 불가)
  a.setValue(20); 

* Java에서는 변경 자체를 불가능(Immutable)하게 만들어서 Side Effect를 막는다.

---

임베디드 타입(복합 값 타입)

• 새로운 값 타입을 직접 정의할 수 있다.
• JPA는 임베디드 타입(embedded type, 내장 타입)이라고 한다.
• 주로 기본 값 타입을 모아서 만들기 때문에 복합 값 타입이라고도 한다.

예시

• 회원 엔티티는 이름, 근무 시작일, 근무 종료일, 주소 도시, 주소 번지, 주소 우편번호를 가진다.
  • startDate, endDate / city, street, zipcode 는 공통 필드로 사용 가능
• 회원 엔티티는 이름, 근무기간, 집주소 가진다.
  • 실 생활에서는 위와 같이 추상화해서 쉽게 표현한다.
  • 즉, 위와 같이 묶을 수 있는 것이 임베디드 타입이다.
• 임베디드 타입으로 구현한 형태
  • 클래스를 새로 뽑는다.

특징 및 장점

• 재사용이 가능하다.
• 클래스 내에서의 응집도가 높다.
• Period.isWork() 처럼 해당 값 타입만 사용하는 의미 있는 메소드를 만들 수 있다.
  • 객체지향적인 설계가 가능하다.
• 임베디드 타입도 int, String과 같은 값 타입이다. (중요!)
  • 엔티티가 아니다. 엔티티의 값일 뿐이다.
  • 추적이 되지 않기 때문에 변경하면 끝난다.
  • 임베디드 타입을 포함한 모든 값 타입은 값 타입을 소유한 엔티티에 생명주기를 의존한다.
• 임베디드 타입의 값이 null 이라면 매핑한 컬럼 값은 모두 null로 저장된다.

기본 사용법

• 기본 생성자는 필수이다.
• @Embeddable
  • 값 타입을 정의 하는 곳에 표시한다.
• @Embedded
  • 값 타입을 사용하는 곳에 표시한다.
• c.f. @Embeddable, @Embedded 중 하나만 명시하면 되지만, 둘 다 적는 것을 권장한다.

임베디드 타입과 테이블 매핑

• 값 타입 / 임베디드 타입에 상관없이 DB 회원 테이블의 형태는 동일하다.
• 하지만 객체의 경우는 데이터 뿐만 아니라 그에 맞는 기능(메서드)를 가지고 있기 때문에 공통으로 묶은 임베디드 타입으로 구성하면 이점이 있다.

• 예시

@Entity
public class Member {
  ...
  @Embedded
  private Address homeAddress;
  @Embedded
  private Address workAddress;
  ...
}

@Embeddable
@NoArgsConstructor
public class Address {
  private String city;
  private String street;
  private String zipcode;
  ...
}

@Embeddable
@NoArgsConstructor
public class Period {
  private LocalDateTime startDate;
  private LocalDateTime endDate;
  ...
}

임베디드 타입의 장점!

1. 임베디드 타입을 사용하기 전과 후에 매핑하는 테이블은 같다.
   • 임베디드 타입은 엔티티의 값일 뿐이다.
2. 객체와 테이블을 아주 세밀하게 매핑하는 것이 가능하다.
3. 잘 설계한 ORM 어블리케이션은 매핑한 테이블의 수보다 클래스의 수가 더 많다.
4. 용어/코드를 공통으로 관리할 수 있다.

임베디드 타입과 연관관계

• 임베디드 타입은 임베디드 타입을 가질 수 있다.
  • ex) Address «Value» 임베디드 타입은 Zipcode «Value» 라는 임베디드 타입을 가진다.
• 임베디드 타입은 엔티티 타입을 가질 수 있다.
  • ex) PhoneNumber «Value» 임베디드 타입이 PhoneEntity «Entity» 를 가질 수 있다.
  • FK만 가지면 되기 때문이다.
    Q. 한 Entity 안에서 같은 값 타입을 2개 이상 가지면 어떻게 될까?

 @Entity
  public class Member {
  ...
  @Embedded
  private Address homeAddress; // 주소 
  @Embedded
  private Address workAddress; // 주소 

        ---> 에러발생 : 컬럼명 중복(MappingException: Repeatedcolumn Error)
  }

@AttributeOverride : 속성 재정의

• @AttributeOverride, @AttributeOverrides를 사용해서 컬럼 명 속성을 재정의하여 중복을 피할 수 있다.

@Entity
public class Member {
  ...
  @Embedded
  private Address homeAddress;
  @Embedded
  @AttributeOverrides({ // 새로운 컬럼에 저장 (컬럼명 속성 재정의)
    @AttributeOverride(name="city", column=@Column(name = "WORK_CITY"),
    @AttributeOverride(name="street", column=@Column(name = "WORK_STREET"),
    @AttributeOverride(name="zipcode", column=@Column(name = "WORK_ZIPCODE")})
  private Address workAddress;
  ...
}

임베디드 타입과 NULL

임베디드 타입의 값이 NULL이면 매핑한 컬럼 값은 모두 NULL이다.

---

값 타입과 불변 객체

값 타입은 복잡한 객체 세상을 조금이라도 단순화하려고 만든 개념이다. 따라서 값 타입은 단순하고 안전하게 다룰 수 있어야 한다.

값 타입 공유 참조

• 임베디드 타입 같은 값 타입을 여러 엔티티에서 공유하면 위험하다.
• 부작용(side effect) 발생

 Address address = new Address("city", "street", "10000");
  // 
  Member member = new Member();
  member.setUsername("member1");
  member.setHomeAddress(address);
  em.persist(member);
  // 
  Member member2 = new Member();
  member2.setUsername("member2");
  member2.setHomeAddress(address);
  em.persist(member2);
 
  // 첫 번째 member의 Address(city) 속성만 변경하고 싶다.
  member.getHomeAddress().setCity("new city");
            ---> member, member2 모두가 [UPDATE Query] 된다.
  tx.commit(); // UPDATE Query 2번 

값 타입 복사

• 위의 예시처럼 값 타입의 실제 인스턴스인 값을 공유하는 것이 굉장히 위험하다.
• 대신 값(인스턴스)를 복사해서 사용한다.

Address address = new Address("city", "street", "10000");
  // 
  Member member = new Member();
  member.setUsername("member1");
  member.setHomeAddress(address);
  em.persist(member);
  // Address 객체 복사
  Address copyAddress = new Address(address.getCity(), address.getStreet(), address.getZipcode());
  // 
  Member member2 = new Member();
  member2.setUsername("member2");
  member2.setHomeAddress(copyAddress); // 복사한 것을 넣는다.
  em.persist(member2);

  // 첫 번째 member의 Address(city) 속성만 변경된다.!
  member.getHomeAddress().setCity("new city");

객체 타입의 한계

1. 항상 값을 복사해서 사용하면 공유 참조로 인해 발생하는 부작용을 피할 수 없다.
2. 문제는 임베디드 타입처럼 직접 정의한 값 타입은 자바의 기본 타입이 아니라 객체 타입이다.
3. 자바 기본 타입에 값을 대입하면 값을 복사한다.
4. 객체 타입은 참조 값을 직접 대입하는 것을 박을 방법이 없다.
   • 객체 타입은 타입이 같으면 그냥 대입(=)해서 넣을 수 있다.
   • ex) 누군가 실수로 복사하지 않은 address를 그대로 넣었다면 컴파일 단계에서 알 수 있는 방법이 없다. member2.setHomeAddress(address)
5. 객체의 공유 참조는 피할 수 없다.

---

불변 객체(Immutable Object)

불변이라는 작은 제약으로 부작용이라는 큰 재앙을 막을 수 있다.

• 값 타입은 불변 객체(immutable object)로 설계해야 한다.
  • 객체 타입을 수정할 수 없게 만들면 부작용(Side Effect)을 원천 차단할 수 있다.
  • 불변이라는 작은 제약으로 부작용이라는 큰 재앙을 막을 수 있다
• 불변 객체란
  • 생성 시점 이후 절대 값을 변경할 수 없는 객체
  • 생성자로만 값을 설정하고 Setter를 만들지 않으면 된다.
  • c.f. Integer, String은 자바가 제공하는 대표적인 불변 객체이다.
• Q. 원래 값 객체의 필드를 실제로 바꾸고 싶으면?
• A. Address 를 통으로 변경해야 한다.

Address address = new Address("city", "street", "10000");
    
  Member member = new Member();
  member.setUsername("member1");
  member.setHomeAddress(address);
  em.persist(member);
    
  Address newAddress = new Address("NewCity", address.getStreet(), address.getZipcode());
  member.setHomeAddress(newAddress); // 통으로 변경해 주어야 한다.
    
  tx.commit();

---

값 타입의 비교

• 값 타입은 인스턴스가 달라도 그 안에 값이 같으면 같은 것으로 봐야 한다.

    int a = 10;
    int b = 10;
    System.out.println("a == b: " + (a == b)); // true

• 객체 타입은 값이 같아도 주소가 다르기 때문에 == 비교 시 false를 반환한다.

    Address address1 = new Address("서울시");
    Address address2 = new Address("서울시");
    System.out.println("address1 == address2: " + (address1 == address2)); // false

• 동일성(identity) 비교
  • 인스턴스의 참조 값을 비교한다.
  • == 사용
  • primitive 타입
• 동등성(equivalence) 비교
  • 인스턴스의 값을 비교한다.
  • equals() 사용
  • 임베디드 타입
  • ex) address1.equals(address2) => false
    • equals()를 재정의 해주어야한다.
    • equals()에 맞게 hashCode()도 재정의 해줘야 한다.

---

값 타입 컬렉션

• 값 타입을 컬렉션에 담아서 쓰는 것을 말한다.
  • 연관관계 매핑에서 엔티티를 컬렉션으로 사용하는 것이 아니라 값 타입을 컬렉션에 쓰는 것이다.
• 값 타입 컬렉션은 값 타입을 하나 이상 저장할 때 사용한다.
• @ElementCollection, @CollectionTable 사용
• 컬렉션을 저장하기 위한 별도의 테이블이 필요하다.

• 예시

@Entity
public class Member {
    ...
    @ElementCollection
    @CollectionTable(
        name = "FAVORITE_FOOD",
        joinColumns = @JoinColumn(name = "MEMBER_ID"))
    @Column(name = "FOOD_NAME") // 컬럼명 지정 (예외)
    private Set<String> favoriteFoods = new HashSet<>();

    @ElementCollection
    @CollectionTable(
        name = "ADDRESS",
        joinColumns = @JoinColumn(name = "MEMBER_ID"))
    private List<Address> addressHistory = new ArrayList<>();
    ...
}

• @ElementCollection, @CollectionTable 어노테이션을 사용한다.
• Member 클래스에 값 타입 컬렉션을 추가한다.
• addressHistory는 임베디드 타입이므로 컬럼명들을 그대로 사용하면 된다.
• favoriteFoods는 String 하나(내가 만든 것이 아님)에 대한 Set이기 때문에 컬럼명을 지정해준다.
• memberId를 외래키로 지정한다.
  • 어떤 memberId에 소속되는지 알아야하기 때문에 연관 관계가 필요하다.