JPA 데이터 타입

entity type

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

 

값타입

• int, Integer, String처럼 단순히 값으로 사용하는 자바 기본 타입이나 객체
• 식별자가 없고 값만 있으므로 변셩시 추적 불가
  10 -> 20으로 변경하면 값이 완전히 대체
•  

값 타입 분류

1. 기본값 타입

• 자바 기본 타입 (int, double)
•  래퍼 클래스 (Integer, Long)
• String
• 특징
  - 생명주기를 엔티티에 의존
  - 값 타입은 공유하면 안됨
    기본 타입은 항상 값을 복사함, 둘은 전혀 다른 주소 공간을 사용 
     ex> 화원 이름 변경시 다른 회원의 이름도 함께 변경되면 안됨 (side effect)
  - Integer같은 래퍼 클래스나 String 같은 특수한 클래스는 공유 가능한 걕체이지만 변경 X
    = 연산자를 통해 주소값(래퍼런스 값)이 넘어가기 때문에 같은 인스턴스를 공유함.
    변경할 수 있다면, 사이드 이팩트 발생할 수 있음

2. 임베디드 타입 (embedded type, 복합 값 타입)

• ex> position(x, y)
• 특징
  - 새로운 값 타입 직접 정의 가능
  - JPA는 임베디드 타입이라 함
  - 주로 기본 값 타입을 모아서 만들어서 복합 값 타입이라고도 함
  - int, String과 같은 값 타입(엔티티가 아님. 추적 불가)
  - 시스템 내에서 공통으로 클래스 타입을 만들어서 쓸 수 있을 때

 

• 사용법
  @Embeddable: 값 타입을 정의하는 곳에 표시
  @Embedded: 값 타입을 사용하는 곳에 표시
  기본 생성자 필수
• 장점
  - 재사용
  - 높은 응집도
  - Period.isWork()처럼 해당 값 타입만 사용하는 의미 있는 메소드를 만들 수 있음
  - 임베디드 타입을 포함한 모든 값 타입은, 값 타입을 소유한 엔티티에 생명주기를 의존함

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

@Entity
public class Member extends BaseEntity {

	@Id
	@GeneratedValue( strategy = GenerationType.IDENTITY )
	@Column( name = "MEMBER_ID" )
	private Long id;

	@Column( name = "USRNAME" )
	private String username;

	@ManyToOne( fetch = FetchType.LAZY ) // member 입장에서는 many, team 입장에서는 1
	@JoinColumn( name = "TEAM_ID" )
	private Team team;

	@Embedded
	private Period workPeriod;

	@Embedded
	private Address homeAdress;

	public Member() {
	}
}

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

 

• 임베디드 타입은 엔티티의 값일 뿐이다. 
• 임베디드 타입을 사용하기 전과 후에 매핑하는 테이블은 같다. 
• 객체와 테이블을 아주 세밀하게(find-grained) 매핑하는 것이 가능
• 잘 설계한 ORM 애플리케이션은 매핑한 테이블의 수보다 클래스의 수가 더 많음
• 한 엔티티에서 같은 값 타입을 사용하면 컬럼 명이 중복됨
  => @AttributeOverrides, @AttributeOverride를 사용해서 컬러 명 속성을 재정의

@Entity
public class Member extends BaseEntity {

	@Id
	@GeneratedValue( strategy = GenerationType.IDENTITY )
	@Column( name = "MEMBER_ID" )
	private Long id;

	@Column( name = "USRNAME" )
	private String username;

	@ManyToOne( fetch = FetchType.LAZY ) // member 입장에서는 many, team 입장에서는 1
	@JoinColumn( name = "TEAM_ID" )
	private Team team;

	@Embedded
	private Period workPeriod;

	@Embedded
	private Address homeAdress;

	@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 workAdress;
}

Member member = new Member();
member.setUsername( "member" );
member.setHomeAdress( new Address( "1", "1", "2" ) );
member.setWorkPeriod( new Period() );

em.persist( member );

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

임베디드 타입과 연관관계

Address address = new Address( "city", "street", "000000" );

Member member1 = new Member();
member1.setUsername( "member1" );
member1.setHomeAdress( address );
member1.setWorkPeriod( new Period() );
em.persist( member1 );

Member member2 = new Member();
member2.setUsername( "member2" );
member2.setHomeAdress( address );
member2.setWorkPeriod( new Period() );
em.persist( member2 );

member1.getHomeAdress().setCity( "new city" );

값 타입과 불변 객체

두 번의 UPDATE 쿼리 발생

• 임베디드 타입 같은 값 타입을 여러 엔티티에서 공유하면 위험함 (공유를 하려면 엔티티를 써야 함)
• 부작용(side effect) 발생
• 값 타입의 실제 인스턴스인 값을 공유하는 것은 위험
• 대신 값(인스턴스)를 복사해서 사용해야 함

Address address = new Address( "city", "street", "000000" );

Member member1 = new Member();
member1.setUsername( "member1" );
member1.setHomeAdress( address );
member1.setWorkPeriod( new Period() );
em.persist( member1 );

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

Member member2 = new Member();
member2.setUsername( "member2" );
member2.setHomeAdress( copyAddress );
member2.setWorkPeriod( new Period() );
em.persist( member2 );

member1.getHomeAdress().setCity( "new city" );;

객체 타입의 한계

• 항상 값을 복사해서 사용하면 공유 참조로 인해 발생하는 부작용을 피할 수 있다. 
• 문제는 임베디드 타입처럼 직접 정의한 값 타입은 자바의 기본(primitive) 타입이 아니라 객체 타입이다. 
• 자바 기본 타입에 값을 대입하면 값을 복사한다. 
• 객체 타입은 참조 값을 직접 대입하는 것을 막을 방법이 없다. 
• 객체의 공유 참조는 피할 수 없다.

기본 타입(primitive type) VS 객체 타입 

int a = 10; 
int b = a;//기본 타입은 값을 복사
b = 4;

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

 

객체 타입을 수정할 수 없게 만들면 부작용을 원천 차단

• 값 타입은 불변 객체(immutable object)로 설계해야함
  
• 불변 객체: 생성 시점 이후 절대 값을 변경할 수 없는 객체
  
• 생성자로만 값을 설정하고 수정자(Setter)를 만들지 않으면 됨
  
• 참고: Integer, String은 자바가 제공하는 대표적인 불변 객체

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

 

값 타입의 비교

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

@Override
public int hashCode() {
	return Objects.hash( this.city, this.street, this.zipcode );
}

@Override
public boolean equals( final Object obj ) {
	if ( this == obj ) {
		return true;
	}
	if ( ( obj == null ) || ( getClass() != obj.getClass() ) ) {
		return false;
	}
	Address other = (Address) obj;
	return Objects.equals( this.city, other.getCity() ) && Objects.equals( this.street, other.getStreet() ) && Objects.equals( this.zipcode, other.getZipcode() );
}

Address address1 = new Address( "city", "street", "000000" );
Address address2 = new Address( "city", "street", "000000" );

System.out.println( "address1 == address2: " + ( address1 == address2 ) );
System.out.println( "address1 equals address2: " + ( address1.equals( address2 ) ) );

 

3. 컬렉션 값 타입 (collection value type)

값 타입을 컬렉션 안에 담아서 쓰는 것

• 값 타입을 하나 이상 저장할 때 사용
• @ElementCollection, @CollectionTable 사용

@Entity
public class Member extends BaseEntity {
	// ....

	@ElementCollection
	@CollectionTable( name = "FAVORITE_FOOD", joinColumns = @JoinColumn( name = "MEMBER_ID" ) )
	@Column( name = "FOOD_NAME" )
	private final Set<String> favoriteFoods = new HashSet<String>();

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

@JoinColumn을 설정해주면, 그 컬럼을 외래키로 잡아서 조인.

 

컬랙션을 위한 별도의 ADDRESS, FAVORITE_FOOD table 생성

Member member = new Member();
member.setUsername( "member1" );

member.setHomeAdress( new Address( "new city1", "new street1", "00000" ) );

member.getFavoriteFoods().add( "딸기" );
member.getFavoriteFoods().add( "떡볶이" );
member.getFavoriteFoods().add( "포도" );

member.getAddressHistory().add( new Address( "old city1", "old street1", "00001" ) );
member.getAddressHistory().add( new Address( "old city2", "old street2", "00003" ) );

em.persist( member );

em.persist(member); 하나의 코드로 모든 데이타 INSERT 쿼리 실행

embedded type뿐만 아니라 모든 collection type이 member와 같은 라이프 사이클을 가짐

• 데이터베이스는 컬렉션을 같은 테이블에 저장할 수 없다. => 1:다로 풀어서 별도의 테이블로 만들어내서, join key를 설정해줘야 한다. (ADDRESS 와 같이.. )
• 컬렉션을 저장하기 위한 별도의 테이블이 필요함 (개념적으로는 1:N)
• 값 타입 컬랙션 지연로딩 사용

값 타입 수정

// findMember.getHomeAdress().setCity("new city"); // 절대 안됨 사이드 이펙트 발생
Address oldAddress = findMember.getHomeAdress();
findMember.setHomeAdress( new Address( "new city", oldAddress.getStreet(), oldAddress.getZipcode() ) );

값 타입 컬렉션 수정 1 

findMember.getFavoriteFoods().remove( "포도" );
findMember.getFavoriteFoods().add( "사과" );

값 타입 컬렉션은 Member에 의존관계를 맡기고 persist, update 등 멤버의 속성일 뿐이다.

멤버의 라이프 사이클을 따르는 멤버 소속의 단순한 값일 뿐이다.

 

값 타입 컬렉션 수정 2

컬렉션 마다 다르긴 한데, 기본적으로 Object 비교 시에 equals() 메소드를 사용한다.

이러한 이유로 hashCode()와 equals()를 반드시 override 받아 제대로 구현되어 있어야 한다.

findMember.getAddressHistory().remove( new Address( "old city2", "old street2", "00003" ) );
findMember.getAddressHistory().add( new Address( "new city2", "old street2", "00003" ) );

=> DELETE query로 모든 ADDRESS를 삭제한 뒤, 다시 INSERT query로 기존 데이터들을 다시 추가한다.

• 값 타입은 엔티티와 다르게 식별자 개념이 없다. 
• 값은 변경하면 추적이 어렵다. 
• 값 타입 컬렉션에 변경 사항이 발생하면, 주인 엔티티와 연관된 모든 데이터를 삭제하고, 값 타입 컬렉션에 있는 현재 값을 모두 다시 저장한다. 
• 값 타입 컬렉션을 매핑하는 테이블은 모든 컬럼을 묶어서 기본
  키를 구성해야 함: null 입력X, 중복 저장X

@Entity
@Table( name = "ADDRESS" )
public class AddressEntity {

	@Id
	@GeneratedValue
	private Long id;

	private Address address;

	public AddressEntity() {
	}
	
    public AddressEntity( final String city, final String street, final String zipCode ) {
		this.address = new Address( city, street, zipCode );
	}


}

member.getAddressHistory().add( new AddressEntity( "old city1", "old street1", "00001" ) );
member.getAddressHistory().add( new AddressEntity( "old city2", "old street2", "00003" ) );

=> id(값타입이 아닌 엔티티임)와 외래키(MEMBER_ID)가 추가됨

 

값 타입 컬렉션 대안

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

 

엔티티 타입의 특징

• 식별자O 
• 생명 주기 관리
• 공유

값 타입의 특징

• 식별자X 
• 생명 주기를 엔티티에 의존
• 공유하지 않는 것이 안전(복사해서 사용) 
• 불변 객체로 만드는 것이 안전

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

 

@Override
public int hashCode() {
	final int prime = 31;
	int result = 1;
	result = ( prime * result ) + ( ( getCity() == null ) ? 0 : getCity().hashCode() );
	result = ( prime * result ) + ( ( getStreet() == null ) ? 0 : getStreet().hashCode() );
	result = ( prime * result ) + ( ( getZipcode() == null ) ? 0 : getZipcode().hashCode() );
	return result;
}

@Override
public boolean equals( final Object obj ) {
	if ( this == obj ) {
		return true;
	}
	if ( !( obj instanceof Address ) ) {
		return false;
	}
	Address other = (Address) obj;
	if ( getCity() == null ) {
		if ( other.getCity() != null ) {
			return false;
		}
	} else if ( !getCity().equals( other.getCity() ) ) {
		return false;
	}
	if ( getStreet() == null ) {
		if ( other.getStreet() != null ) {
			return false;
		}
	} else if ( !getStreet().equals( other.getStreet() ) ) {
		return false;
	}
	if ( getZipcode() == null ) {
		if ( other.getZipcode() != null ) {
			return false;
		}
	} else if ( !getZipcode().equals( other.getZipcode() ) ) {
		return false;
	}
	return true;
}

필드에 직접 접근하면 Proxy일 때에는 계산이 안된다. getter를 호출해야 직접 값에 접근하기 때문에, equals / hashCode 외에도 getter를 통해 접근하는 것이 안전한다.