JPA의 데이터 타입 분류

Entity 타입

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

값 타입

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

값 타입 분류

• 자바 기본 타입(int, double)
• 래퍼 클래스(Integer, Long)
• String
• 임베디드 타입(embedded type, 복합 값 타입)
• 컬렉션 값 타입(collection value type)

기본 값 타입

• ex) String name, int age

생명주기를 엔티티의 의존하고( ex) 회원을 삭제하면 이름, 나이 필드도 함께 삭제된다.)
, 값 타입은 공유하면 안 된다.( ex) 회원 이름 변경시 다른 회원의 이름도 함께 변경되면 안된다.)

참고 : 자바의 기본 타입은 절대 공유가 안 됨, 기본 타입은 항상 값은 복사함, Integer같은 래퍼 클래스나 String 같은 특수한 클래스는 공유 가능한 객체이지만 변경X

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

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

ex) 회원 엔티티는 이름, 근무 시작,종료일 주소 도시, 주소 번지, 주소 우편번호를 가진다.

private Long id;
private String name;
private LocalDateTime startDate;
private LocalDateTime endDate;
private String city;
private String stret;
private String zipcode;

이러면 너무 복잡하고, 적어야 할 코드들이 많아진다.

임베디드 타입

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

이 처럼 추상화를 해서 코드를 적어본다면

private Long id;
private String name;
private Period workPeriod;
private Address homeAddress;

클래스를 따로 만들어서 이렇게 적을 수 있다.

임베디드 타입 사용법

• @Embeddable : 값 타입을 정의하는 곳에 표시
• @Embedded : 값 타입을 사용하는 곳에 표시
• 기본 생성자는 필수

@Embeddable

@Embeddable
public class Period {
	
    private LocalDateTime startDate;
	private LocalDateTime endDate;
    
    .
    .
    이하 getter, setter, 기본 생성자
}

@Embedded

@Entity
public class Member{

	private Long id;
	private String name;
    
    @Embedded
    private Period workPeriod;
}

임베디드 타입 장점

재사용성이 높고, 높은 응집도를 가진다.
Period.isWork() 처럼 해당 값 타입만 사용하는 의미 있는 메서드를 만들 수 있다.
임베디드 타입을 포함한 모든 값 타입은, 값 타입을 소유한 엔티티에 생명주기를 의존한다.

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

• 임베디드 타입은 엔티티의 값일 뿐이다.
• 임베디드 타입을 사용하기 전과 후에 매핑하는 테이블은 같다.
• 객체와 테이블을 아주 세밀하게(find-grained) 매핑하는 것이 가능하다.
• 잘 설계한 ORM 애플리케이션은 매핑한 테이블의 수보다 클래스의 수가 더 많다.

@AttributeOverride : 속성 재정의

만약에 한 엔티티에서 같은 값 타입을 사용한다면?
컬럼 명이 중복된다.

이 때 @AttributeOverrides, @AttributeOverride 사용해서 컬럼 명 속성을 재정의한다.

예를 들어 Member 클래스에 주소라는 것이 홈주소와 워크주소가 두 개가 있다고 가정해보자

@Embedded
private Address homeAddress;

@Embedded
private Address workAddress;

이렇게 되면 같은 값 타입을 사용하기에 컬럼명이 중복이 될 것이다.

@Embedded
private Address homeAddress;

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

이렇게 코드를 작성하면 컬럼명 중복을 피할 수 있다.

임베디드 타입과 null

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

값 타입과 불변 객체

값 타입 공유 참조

• 임베디드 타입 같은 값 타입을 여러 엔티티에서 공유하면 side effect가 발생할 위험이 있다.

Address address = new Address("oldCity", "street", "1000");


Member member1 = new Member();
member1.setHomeAddress(address)
em.persist(member1)

Member member2 = new Member();
member2.setHomeAddress(address);
em.persist(member2)

member1.getHomeAddress().setCity("newCity");

이렇게 내가 member1의 city만 바꾸고 싶어서 해당 코드 처럼 작성하게 되면
address를 member1, member2 가 같은 참조 값을 바라보기에 두 member의 city가 바뀌게 되는 side effect가 발생한다.

그래서 이런 것을 해결하기 위해 값(인스턴스)을 복사해서 사용하는 방법이 있다.

Address address = new Address("oldCity", "street", "1000");


Member member1 = new Member();
member1.setHomeAddress(address)
em.persist(member1)

Address copyAddress = new Address(address.getCity(), address.getStreet(), address.getZipcode);

Member member2 = new Member();
member2.setHomeAddress(copyAddress);
em.persist(member2)

member1.getHomeAddress().setCity("newCity");

이렇게 하면 두 번째 멤버는 복사한 값을 사용하기에 값이 바뀌지 않는다.
그래서 항상 값을 복사해서 사용하면 공유 참조로 인해 발생하는 부작용은 피할 수 있다.

그러나 별로 좋아보이지 않는다.

임베디드 타입처럼 직접 정의한 값 타입은 자바의 기본 타입이 아니라, 객체 타입이다.
객체 타입은 참조 값을 직접 대입하는 것이기에, 직접 대입 하는 것을 막기가 어렵다.
객체의 공유 참조는 피할 수 없다.

그래서 이런 문제점을 극복하기 위해서는 애초에 객체 타입을 수정할 수 없게 만들면 사이드 이펙트를 원천 차단을 할 수 있다.

불변 객체

• 값 타입은 불편 객체(Immutable object)로 설계하자
• 불변 객체는 생성 시점 이후 절대 값을 변경할 수 없는 객체이다.
• 생성자로만 값을 설정하고, 수정자(setter)를 만들지 말자

참고 : Integer, String은 자바가 제공하는 대표적인 불변 객체이다.

만약 값을 바꾸고 싶다면?

Address address = new Address("oldCity", "street", "1000");


Member member1 = new Member();
member1.setHomeAddress(address)
em.persist(member1)


Address newAddress = new Address("NewCity", address.getStreet(), address.getZipcode());

Member member2 = new Member();
member2.setHomeAddress(newAddress)
em.persist(member2)

이렇게 바꾸거나 copy 메서드를 따로 만들어 바꾸면 된다.

값 타입의 비교

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

• 동일성(identity) 비교 : 인스턴스의 참조 값을 비교, == 사용
• 동등성(equivalence) 비교 : 인스턴스의 값을 비교, equals() 사용
• 값 타입은 a.equlas(b)를 사용해서 동등성 비교를 해야 함
• 값 타입의 equlas() 메서드를 적절하게 재정의(주로 모든 필드 사용)

값 타입 컬렉션

말 그대로 값 타입을 컬렉션에 넣어서 사용하는 것을 값 타입 컬렉션이라 한다.

@Embedded
private Address address; // 값 타입

@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")
) // ADRESS 값 타입의 속성을 사용하기에 @Column이 없음
private List<Address> addressHistory = new ArrayList<>();

• 값 타입을 하나 이상 저장할 때 사용한다
• @ElementCollection, @CollectionTable 사용
• 데이터베이스는 컬렉션 같은 테이블에 저장할 수 없다.
• 컬렉션을 저장하기 위한 별도의 테이블이 필요하다.

값 타입 저장

Member member = new Member();
member.setHomeAddress(new Address("city1", "street", "10000"));

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

member.getAddressHistory().add(new Address("old1", "street", "10000"));
member.getAddressHistory().add(new Address("old2", "street", "10000"));

em.persist(member);

tx.commit();

값 타입 컬렉션을 퍼시스트 하지 않고, 멤버 엔티티만 퍼시스트 해도 homeAddress, favoritefoods, addresshistory에 값이 들어가게 된다.

member에 속한 값 타입 컬렉션의 라이프 사이클은 member 엔티티에 의존하게 된다.
일대다 연관관계에서 cascade all과 orphanremoval = true로 둔 경우와 비슷하다.

값 타입 조회

Member member = new Member();
member.setHomeAddress(new Address("city1", "street", "10000"));

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

member.getAddressHistory().add(new Address("old1", "street", "10000"));
member.getAddressHistory().add(new Address("old2", "street", "10000"));

em.persist(member);

em.flush();
em.clear();

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


tx.commit();

조회를 하게 되면 쿼리는 member만 찾아오는 쿼리를 보낸다.(+ homeAddress 값 타입 포함)

값 타입 컬렉션은 지연 로딩이 디폴트 값이다.

값 타입 수정

Member member = new Member();
member.setHomeAddress(new Address("city1", "street", "10000"));

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

member.getAddressHistory().add(new Address("old1", "street", "10000"));
member.getAddressHistory().add(new Address("old2", "street", "10000"));

em.persist(member);

em.flush();
em.clear();

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

// homeaAddress 값 타입 수정
// city1 -> city2
// findMember.getHomeAddress().setCity("city2") // 값 타입은 불변 해야하기에 setter를 사용 하면 안 된다.


Address a = findMember.getHomeAddress();
findMember.setHomeAddress(new Address("city2", a.getStreet(), a.getZipcode()));



// 값 타입 컬렉션 수정
findMember.getFavoriteFoods().remove("치킨");
findMember.getFavoriteFoods().add("한식");

// 기본적으로 컬렉션은 대상을 찾을 때 equlas로 대상을 찾는다.
// equals(), hashcode() 메서드가 제대로 오버라이딩 되어 있어야한다.
// 그렇지 않으면 remove() 를 할시에 제대로 삭제되지 않는 상황이 발생한다.
findMember.getAddressHistory().remove(new Address("old1", "street", "10000"));
findMEmber.getAddressHistory().add(new Address("new1", "street", "10000"));


tx.commit();

이렇게 실행했을 때, member에 소속된 address의 모든 값은 지우고, 새롭게 old2와 new1을 다시 넣게 된다.

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

값 타입 컬렉션 제약 사항

• 값 타입은 엔티티와 다르게 식별자 개념이 없어서 값을 변경하면 추적이 어렵다
• 값 타입 컬렉션을 매핑하는 테이블은 모든 컬럼을 묶어서 기본 키를 구성해야 함: null 입력X, 중복 저장X

값 타입 컬렉션 대안

• 상황에 따라 값 타입 컬렉션 대신에 일대다 관계를 고려하는 것이 좋다.
• 일대다 관계를 위한 엔티티를 만들고, 여기에서 값 타입을 사용
• 영속성 전이(Cascade) + 고아 객체 제거를 사용해서 값 타입 컬렉션 처럼 사용한다.

여러 Address를 담을 AddressEntity를 따로 만든다.

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

AddressEntity를 일대다 관계로 매핑한다.

/*
ElementCollection
@CollectionTable(name = "ADDRESS", 
				joinColumns = @JoinColumn(name = "MEMBER_ID")
) // ADRESS 값 타입의 속성을 사용하기에 @Column이 없음
private List<Address> addressHistory = new ArrayList<>();
*/

@OneToMany(cascade = CascadeType.ALL, orphanRemoval = true)
// 일대다 관계로 매핑(영속성 전이(Cascade) + 고아 객체 제거)
@JoinColumn(name = "MEMBER_ID")
private List<AddressEntity> addressHistory = new ArrayList<>();

엔티티 타입의 특징

• 식별자가 있다.
• 생명 주기가 관리된다.
• 공유할 수 있다.

값 타입의 특징

• 식별자가 없다
• 생명 주기를 엔티티에 의존한다
• 공유하지 않는 것이 좋다.
• 공유 되더라도 변경 될 수 없게 불변 객체로 만들어야한다.

값 타입은 정말 값 타입이라 판단될 때만 사용
엔티티와 값 타입을 혼동해서 엔티티를 값 타입으로 만들면 안됨
식별자가 필요하고, 지속해서 값을 추적, 변경해야 한다면 그것은 값 타입이 아닌 엔티티