[김영한_자바 ORM 표준 JPA 프로그래밍 - 기본편] 8. 값 타입

🌠 값 타입

JPA의 데이터 타입 분류

• 엔티티 타입 (@Entity로 정의하는 객체 → 데이터가 변해도 식별자로 지속해서 추적 가능)
• 값 타입

값 타입 분류

• 기본값 타입 (Ex. int, double, Integer, Long, String, ···)
• 임베디드 타입 (복합 값 타입 → 직접 정의 가능)
• 컬렉션 값 타입 (Ex. Set, List, ···)

 

🌠 임베디드 타입

임베디드 타입은 새로운 값 타입을 직접 정의할 수 있다. 주로 기본 값 타입을 모아서 만들기 때문에 '복합 값 타입'이라고도 한다. 임베디드 타입은 int, String과 같은 '값 타입'으로써 엔티티가 아니고, 한번 값을 변경하면 추적이 불가능하다.

 

임베디드 타입은 언제 사용할까?

DB의 회원 테이블에 근무 시작일, 근무 종료일, 주소의 도시, 주소의 도로명, 주소의 우편번호가 있는 상황을 생각해보자.

객체 관점에서 보았을 때, 근무 시작일과 종료일을 Period로, 주소 관련 속성들을 Address로 묶어서 별도의 클래스를 만들면 좋지 않을까? 이렇게 하면 클래스 재사용이 가능해지고 Period.isWork() 같은 의미있는 메소드를 만들 수 있게 된다.

 

 

 

임베디드 타입 사용 방법을 알아보자.

@Embeddable은 값타입을 정의하는 곳에 표시하고, @Embedded는 값타입을 사용하는 곳에 표시한다. 그리고 값타입을 정의하는 곳에 반드시 기본생성자를 만들어야 한다.

 

코드 예시:

@Entity
public class Member {

@Embedded
private Period workPeriod;

@Embedded
private Address homeAddress;

@Embeddable
public class Period {

    private LocalDateTime startDate;
    private LocalDateTime endDate;

    public Period() {

    }

@Embeddable
public class Address {

    private String city;
    private String street;
    private String zipcode;

    public Address() {

    }

 

실행 결과:

Member member = new Member();
member.setUsername("shj");
member.setHomeAddress(new Address("서울", "와우산로", "94"));
member.setWorkPeriod(new Period(LocalDateTime.now(), LocalDateTime.now().plusYears(1L)));
em.persist(member);
transaction.commit(); // 커밋

 

참고로 임베디드 타입 안에 엔티티를 넣는 것도 가능하다. (Ex. Member가 Address 임베디드 타입을 참조하고 Address 임베디드 타입이 House 엔티티를 참조하는 것이 가능)

 

만약, 한 엔티티에서 같은 값타입을 여러번 사용하고 싶으면 어떻게 해야할까? 아래와 같이 사용하고 싶을 수 있을 것이다. 그럴 때는 @AttributeOverrides, @AttributeOverride를 쓰면 된다.

@Entity
public class Member extends BaseEntity {

    @Id @GeneratedValue(strategy = GenerationType.IDENTITY)
    @Column(name = "MEMBER_ID")
    private Long id;   
    
    @Embedded
    @AttributeOverrides({
            @AttributeOverride(name = "city", column = @Column(name = "HOME_CITY")),
            @AttributeOverride(name = "street", column = @Column(name = "HOME_STREET")),
            @AttributeOverride(name = "zipcode.zip", column = @Column(name = "HOME_ZIP")),
            @AttributeOverride(name = "zipcode.plusFour", column = @Column(name = "HOME_PLUS_FOUR")),
    })
    private Address homeAddress;

    @Embedded
    @AttributeOverrides({
            @AttributeOverride(name = "city", column = @Column(name = "COMPANY_CITY")),
            @AttributeOverride(name = "street", column = @Column(name = "COMPANY_STREET")),
            @AttributeOverride(name = "zipcode.zip", column = @Column(name = "COMPANY_ZIP")),
            @AttributeOverride(name = "zipcode.plusFour", column = @Column(name = "COMPANY_PLUS_FOUR")),
    })
    private Address companyAddress;
}

@Embeddable
public class Address {

    private String city;
    private String street;

    @Embedded
    private Zipcode zipcode;
}

@Embeddable
public class Zipcode {

    private String zip;
    private String plusFour;
}

 

🌠 객체 타입의 한계, 불변 객체

임베디드 타입은 값 타입이고 객체 타입이다. 객체 타입은 자바의 기본 타입(Ex. int, double)과 다르게 '=' 연산을 할 때 값을 복사하는 것이 아니라 참조를 전달한다.

 

따라서, 아래와 같은 코드를 작성할 경우, b의 주소만 바꾸려는 원래의 의도와 다르게 a의 주소까지 바뀌게 된다.

Address a = new Address(“Old”); 
Address b = a; // 객체 타입은 참조를 전달
b.setCity(“New”);

이런 부작용을 막기 위해서는 ⭐️값 타입을 불변 객체로 설계⭐️해야 한다. 불변 객체로 만드는 가장 쉬운 방법은 setter()를 만들지 않는 것이다. ⭐️생성자로만 값을 설정⭐️할 수 있게 만들면 된다. 값을 수정하고자 할 경우 새로운 객체를 생성하면 된다. 참고로 Integer, String은 자바가 제공하는 대표적인 불변 객체이다.

 

🌠 값 타입의 비교

값 타입의 비교는 == 으로 하면 안되고, equals() 메소드를 적절하게 재정의해서 사용해야 한다. (주로 모든 필드를 비교함) 참고로 인텔리제이는 'Generate equals() and hashCode()' 기능을 제공하고 있다.

 

🌠 값 타입 컬렉션

값 타입 컬렉션은 값 타입을 컬렉션에 담아서 쓰는 것을 말한다.

그런데 일반적으로 DB에는 컬렉션을 담을 수 있는 타입이 없다. 따라서, 일대다 개념처럼 별도의 테이블로 만들어야 한다.

 

예를 들어, Set<String> favoriteFoods 컬렉션은 Member 테이블에 저장되는 것이 아니라 FAVORITE_FOOD라는 별도의 테이블을 만든다.

그리고 FAVORITE_FOOD의 PK는 모든 컬럼들의 조합이다. 즉, FK인 MEMBER_ID + FOOD_NAME 모두의 조합이 PK가 된다.

 

다시 말하자면, 값 타입 컬렉션은 별도의 테이블로 만들며, 별도의 식별자 없이 테이블의 외래 키와 다른 컬럼들을 조합해 PK로 쓴다. (별도의 식별자가 존재한다면 엔티티와 다를 게 없으니까.)

 

코드 예시:

@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<>();
    ...
}

 

값 타입 컬렉션 저장

이제 값 타입 컬렉션을 저장해보자.

아래 코드에서 볼 수 있듯이 FavoriteFoods와 AddressHistory에 대해서는 em.persist();를 하지 않고 Member에 대해서만 em.persists(member);를 해도 DB에 6개의 행 모두가 저장된다. (Member와 라이프사이클을 함께한다.)

⭐️즉, 값 타입 컬렉션은 영속성 전이(cascade=CascadeType.ALL)와 고아 객체 제거 기능(orphanRemoval=true)을 필수로 가진다.⭐️

Member member = new Member();
member.setUsername("member1");
member.setHomeAddress(new Address("homeCity", "street", "10000"));

member.getFavoriteFoods().add("치킨");
member.getFavoriteFoods().add("족발");
member.getFavoriteFoods().add("피자");

member.getAddressHistory().add(new Address("old1", "street1", "10001"));
member.getAddressHistory().add(new Address("old2", "street2", "10002"));

em.persist(member);

 

값 타입 컬렉션 조회

또한, 값 타입 컬렉션은 디폴트로 지연로딩 전략을 사용한다. 따라서 Member를 조회하면 FavoriteFoods와 AddressHistory 테이블까지 불러오는 것이 아니라, 이후 FavoriteFoods와 AddressHistory를 조회할 때 쿼리문이 나간다.

 

값 타입 컬렉션 수정

위에서 언급했다시피 값 타입은 불변이다. 따라서 값 타입 컬렉션을 수정하고자 한다면, 새로운 객체를 생성해야 한다. (set 함수 사용 X)

예시 1(값 타입):

Member findMember = em.find(Member.class, member.getId());

// homeCity -> newCity 
// findMember.getHomeAddress().setCity("newCity"); // 틀린 방법 

Address address = findMember.getHomeAddress();
findMember.setHomeAddress(new Address("newCity", address.getStreet(), address.getZipCode())); // 새로 생성

예시2(값 타입 컬렉션):

Member findMember = em.find(Member.class, member.getId());

// 족발 -> 햄버거
findMember.getFavoriteFoods().remove("족발");
findMember.getFavoriteFoods().add("햄버거");

+값 타입 컬렉션 요소를 지울 때 equals 함수가 제대로 구현되어 있는 것이 중요하다.

 

값 타입 컬렉션의 제약사항

⭐️값 타입 컬렉션에 변경사항이 발생하면, 주인 엔티티와 관련된 모든 데이터를 삭제하고, 값 타입 컬렉션에 있는 현재값을 모두 다시 저장한다.⭐️

예를 들어 아래의 예시에서는 ADDRESS 테이블에 있던 기존의 모든 데이터("another city", "old city")를 삭제하고, 기존에 있던 "another city"를 다시 저장하고 "new city"를 저장한다.

Member findMember = em.find(Member.class, member.getId());

// 현재 ADDRESS 테이블에는 "another city", "old city" 존재
// old city -> new city
findMember.getAddressHistory().remove(new Address("old city", "street", "12345"));
findMember.getAddressHistory().add(new Address("new city", "street", "12345"));
// 이제 "another city", "new city" 존재

 

그래서... 결론은?

이런 저런 제약사항이 많은 값 타입 컬렉션은 실무에서 사용하지 않는다. (업데이트나 추적할 필요 없는 단순한 상황일 때만 사용)

대신에, 엔티티로 감싸서(wrapping) 일대다 관계로 우회한다.

예시:

 

AddressEntity

@Entity
@Table(name = "ADDRESS")
public class AddressEntity {
    @Id
    @GeneratedValue
    private Long id;

    private Address address; // 엔티티로 감싼 모습
}

Member

@Entity
public class Member {
    ...
    @OneToMany(cascade = CascadeType.ALL, orphanRemoval = true)
    @JoinColumn(name = "MEMBER_ID")
    private List<AddressEntity> addressHistory = new ArrayList<>();
    ...
}