JPA 프로그래밍 정리

엔티티 매핑

• 객체와 테이블 매핑
• @Entity, @Table

• 기본 키 매핑
• @Id

• 필드와 컬럼 매핑
• @Column

• 연관관계 매핑
• @ManyToOne, @JoinColumn

@Entity

• JPA를 사용해서 테이블과 매핑할 클래스는 @Entity를 붙여야 한다.

• 속성에는 name이 있는데 기본적으로는 클래스 이름이 그대로 엔티티 이름이 되지만 혹시나 패키지 안에 이름이 같은 엔티티 클래스가 있다면 name을 지정해서 충돌을 막아줘야 한다.

• 주의사항
• 기본 생성자는 필수다. (파라미터 없는 public 또는 protected 생성자)
• final 클래스, enum, interface, inner 클래스에는 사용할 수 없다.
• 저장할 필드에 final을 사용하면 안된다.

@Table

• 엔티티와 매핑할 테이블을 지정한다. 생략할 경우 매핑한 엔티티 이름을 테이블 이름으로 사용한다.

• 속성으로는 name, catalog, schema, uniqueConstraints 가 있다.

• 다만 uniqueConstraints로 유니크 제약조건을 만드는 경우에는 스키마 자동 생성 기능을 사용해서 DDL을 만들 때만 사용된다.

데이터베이스 스키마 자동 생성

• 클래스의 매핑 정보를 통해 어떤 테이블에 어떤 컬럼을 사용하는지 알 수 있기 때문에 이러한 매핑 정보와 데이터베이스 방언을 사용해서 데이터베이스 스키마를 생성한다.

• 이는 yaml에 ddl.auto: create 로 설정할 수 있다. 하지만 이는 운영단계에서는 절대로 쓰면 안된다.

• show_sql 설정을 true로 할 경우에는 콘솔에 DDL을 출력할 수 있다.

• hibernate.hbm2ddl.auto 속성
• create: 기존 테이블을 삭제하고 새로 생성한다. DROP + CREATE
• create-drop: create 속성에 추가로 애플리케이션을 종료할 때 생성한 DDL을 제거한다. DROP + CREATE + DROP
• update: 데이터베이스 테이블과 엔티티 매핑정보를 비교해서 변경 사항만 수정한다.
• validate: 데이터베이스 테이블과 엔티티 매핑정보를 비교해서 차이가 있으면 ‘경고’를 남기고 애플리케이션을 실행하지 않는다. 이 설정은 DDL을 수정하지 않는다.
• none: 자동 생성 기능을 하용하지 않으려면 옵션 자체를 삭제하거나 유효하지 않은 값을 주면 된다. none이라는 옵션은 실제로 존재하는 옵션이 아니고 그냥 유효하지 않은 값을 준 것이다. 관례상 none을 많이 사용한다.

DDL 생성 기능

• 스키마 자동 생성기능을 사용하고 있을 경우에 @Column에 속성을 줘서 제약조건을 걸 수 있다.

• 예를 들어 not null 조건과 길이 조건을 걸고 싶다 하면 @Column(name = "NAME", nullable = false, length = 10)

• 유니크 제약조건을 걸고 싶다면 @Table(name = “MEMBER”, uniqueConstraints = {@UniqueConstraint(name = “NAME_AGE_UNIQUE”, columnNames = {”NAME”, “AGE”})})

• 이런식으로 쓸 수 있긴 한데 우리는 DDL 자동 생성 기능을 사용하지 않기 때문에 이런 제약 조건들이 필요가 없다.

• 하지만 이 기능을 쓴다면 어노테이션만 보고도 테이블 속성들을 확인할 수 있어서 좋은 점도 있다.

기본 키 매핑

• 시퀀스, auto_increment처럼 데이터베이스와 동일한 조건을 주고 싶을 때는 어떻게 할까?

• JPA의 기본 키 생성 전략
• 직접 할당
• 자동 생성 (@GeneratedValue 이용)
• IDENTITY: 기본 키 생성을 데이터베이스에 위임
• SEQUENCE: 데이터베이스 시퀀스를 사용해서 기본 키 할당
• TABLE: 키 생성 테이블 이용

• 직접 할당은 거의 안쓰니 패스

IDENTITY 전략

• 주로 MySQL, PostgreSQL, SQL Server, DB2에서 사용한다.

• IDENTITY 전략을 사용하면 JPA가 기본 키 값을 얻어오기 위해 데이터베이스를 추가로 조회한다.

• 본 전략과 최적화 문제
• 데이터베이스에 INSERT를 한 후에 기본 키 값을 조회할 수 있는 전략이기 때문에 엔티티에 기본 키 식별자 값을 할당하려면 JPA는 엔티티 생성 후에 추가로 데이터베이스를 조회하게 된다. 하지만, 하이버네이트는 JDBC3에서 추가된 Statement.getGeneratedKeys()를 사용하여 데이터 저장과 동시에 생성된 기본키값도 가져온다.
• 엔티티가 영속화 되려면 식별자가 무조건 있어야 한다고 앞서 말했다. IDENTITY 전략은 엔티티를 데이터베이스에 저장을 해야 데이터베이스의 전략에 따라 식별자를 가져올 수 있기 때문에 em.persist()를 하는 즉시 INSERT SQL이 날라간다. 이 때문에 트랜잭션을 지원하는 쓰기 지연이 동작하지 않는 전략이다…

SEQUENCE 전략

• 시퀀스는 유일값을 순서대로 생성하는 데이터베이스 오브젝트다.

@Entity
@SequenceGenerator(name = "BOARD_SEQ_GENERATOR", 
sequenceName = "BOARD_SEQ", // 매핑할 데이터베이스 시퀀스 이름
initailValue = 1, allocationSize = 1)
public class Board {
	@Id
	@GeneratedValue(strategy = GenerationType.SEQUENCE, generator = "BOARD_SEQ_GENERATOR")
	private Long id;
}

• 이 전략의 경우에는 em.persist()로 엔티티를 저장할 때, 데이터베이스의 시퀀스를 통해 식별자를 먼저 조회한 후에 엔티티를 영속성 컨텍스트에 저장하기 때문에 트랜잭션을 커밋해서 em.flush()가 일어날 때 엔티티가 데이터베이스에 저장된다.

• ** allocationSize의 기본 옵션은 50이기 때문에 데이터베이스의 시퀀스는 1씩 증가한다면 꼭 설정해주어야 하는 부분이다.

Table 전략 생략

AUTO 전략(기본값이다.)

• 데이터베이스 방언에 따라 IDENTITY, SEQUENCE, TABLE 전략 중 하나를 자동으로 선택해 준다.

• 이걸 쓰면 자동이기 때문에 데이터 소스가 달라져도 수정할 필요가 없다는 장점이 있다.

기본 키 매핑 정리

• 영속성 컨텍스트는 엔티티를 식별자 값으로 구분하기 때문에 엔티티를 영속 상태로 만들려면 식별자 값이 반드시 있어야 한다고 했다.

• em.persist() 호출한 직후에 발생하는 일을 식별자 할당 전략별로 정리하면 아래와 같다.
• 직접 할당: 영속화 호출 전에 직접 할당을 해주지 않으면 예외가 발생한다.
• SEQUENCE: 데이터베이스 시퀀스에서 식별자 값을 획득한 이후 영속성 컨텍스트에 저장한다.
• TABLE: 데이터베이스 시퀀스 생성용 테이블에서 식별자 값을 획득한 후 영속성 컨텍스트에 저장한다.
• IDENTITY: 데이터베이스에 엔티티를 저장해서 식별자 값을 획득한 후 영속성 컨텍스트에 저장한다.

필드와 컬럼 매핑

@Column

• 속성 정리
• name: 필드와 매핑할 테이블 컬럼 이름
• nallable(DDL 생성 시 적용): false로 설정하면 not null 조건이 붙는다.
• unique: 딱 한 컬럼에만 unique 제약조건을 걸고 싶을 때 쓸 수 있다. 이것도 DDL 생성 시 적용.
• length: String 타입에만 걸 수 있고 문자 길이 제약 조건을 줄 수 있다.
• precision, scale: BigDecimal, BigInteger 타입에 사용가능. precision은 소수점 포함 전체 자리수, scale은 소수 자리수를 지정할 수 있다.

@Enumerated

• EnumType.String

• EnumType.ORDINAL

@Temporal

• java.util.Date, Calendar를 사용할 때 쓰는데 1.8 이후로 어차피 안쓰고 spring-data-jpa쓰면 @CreatedDate 같은걸로 쓰니까 생략

@Lob

• 매핑하는 필드 타입이 문자면 CLOB이 되고 나머지는 BLOB이 된다.

@Transient

• 데이터베이스와 매핑하지 않는 필드를 만들 때.

• 객체에 임시로 어떤 값을 보관하고 싶을 때 만들어 쓴다.

@Access

• JPA가 엔티티에 접근하는 방식 지정

• AccessType.FIELD: 필드가 private이어도 필드로 접근가능.

• AccessType.PROPERTY: getter를 써서 접근.

• 이것도 딱히 쓸 일 없음.

(초 중요!) 연관관계 매핑 기초

• 연관관계 매핑이란 객체의 참조와 테이블의 외래 키를 매핑하는 것이다.

• 방향: 단방향, 양방향 (방향이 있는 것은 객체관계에만 해당하고 테이블 관계는 항상 양방향이다.)

• 다중성: 다대일, 일대다, 일대일, 다대다

• 연관관계의 주인: 객체를 양방향 연관관계로 만들 때 연관관계의 주인을 정해주어야 한다.

단방향 연관관계

• 다대일 단방향 관계
• 회원 테이블과 팀 테이블이 있다.
• 회원은 하나의 팀에만 소속될 수 있다.
• 회원과 팀은 다대일 관계다.
• 객체 연관관계
• 멤버 객체는 Member.team 필드로 팀 객체와 연관관계를 맺는다.
• 회원 객체에서는 팀을 알 수 있지만 팀 객테에서는 회원 객체를 알 수 없다. 따라서 단방향 관계이다.
• 이 때 객체는 참조로 연관관계를 맺는다. team의 주소를 가지고 참조를 하는 것이다.
• 서로 양방향으로 참조하고 싶으면 양쪽에 필드를 추가해주어야 한다.
• 테이블 연관관계
• 멤버 테이블은 TEAM_ID 외래 키로 팀 테이블과 연관관계를 맺는다.
• 멤버 테이블과 팀 테이블은 양방향 관계이다. 서로 외래키를 통해 참조할 수 있기 때문이다.(JOIN)

객체 관계 매핑

@Entity
public class Member {
	...
	...
	@ManyToOne
	@JoinColumn(name = "TEAM_ID")
	private Team team;
	
// 연관관계 설정
	public void setTeam(Team team) {
		this.team = team;
	}
	
}


@Entity
public class Team {
	...
	
}

@JoinColumn의 속성

• name: 매핑할 외래 키 이름 (기본값: 필드명 + _ + 참조하는 테이블의 PK명)

• referencedColumnName: 외래 키가 참조하는 대상 테이블의 컬럼명

@ManyToOne의 속성

• optional: false로 설정하면 연관 엔티티가 항상 있어야 함.

• fetch: 글로벌 페치 전략 설정 (FetchType.EAGER, LAZY)

• cascade: 영속성 전이 기능 설정

연관관계 사용

• 저장
• 아까 만들어둔 setTeam을 통해 연관관계를 설정하고 em.persist()해주면 끝.

• 조회
• 객체 그래프 탐색과 JPQL의 2가지 방법이 있다.
• 객체 그래프 탐색: member.getTeam()
• JPQL

private static void queryLogicJoin(EntityManager em) {
	String jpql = "select m from Member m join m.team t where t.name = :teamName";
	List<Member> resultList = em.createQuery(jpql, Member.class)
		.setParameter("teamName", "팀1");
		.getResultList();
}

• sql 처럼 JPQL을 만들어서 조회할 수 있다.

• 수정
• setTeam()을 통해 새로운 team을 설정해주면 플러시가 일어날 때 자동으로 반영된다.

• 제거

private static void deleteRelation(EntityManager em) {
	Member member1 = em.find(Member.class, "member1");
	member1.setTeam(null);
}

setTeam을 null로 설정해주면 연관관계가 삭제된다.
** 연관된 엔티티를 삭제하고 싶다면 기존의 연관관계를 먼저 끊어야 한다. (외래 키 제약조건 때문) 연관관계를 모두 제거한 후 em.remove()를 통해 엔티티를 삭제할 수 있다.
 

양방향 연관관계

• 위의 예제에서 팀에서도 멤버를 참조할 수 있게 해주면 양방향 연관관계가 된다.

• 이렇게 설정하면 이제 회원과 팀은 다대일, 팀과 회원은 일대다 관계가 된다.

• 일대다 관계는 team 하나에 여러 member가 관계를 맺고 있을 수 있으므로 컬렉션 타입이 되어야 한다.

@Entity
public class Member {
	...
	...
	@ManyToOne
	@JoinColumn(name = "TEAM_ID")
	private Team team;
	
// 연관관계 설정
	public void setTeam(Team team) {
		this.team = team;
	}
	
}


@Entity
public class Team {
	...
	@OneToMay(mappedBy = "team")
	private List<Member> members = new ArrayList<Member>();
	
}

• Team 객체에 OneToMany를 추가했다.

• mappedBy에는 연관된 반대편 객체의 필드명을 넣어주면 된다.

연관관계의 주인

• mappedBy를 쓰는 이유이다.

• 객체에는 사실 양방향 관계가 없고 단방향 두 개를 동시에 썼을 뿐이다.

• 따라서 이 관계를 관리하는 포인트가 2곳이 되버린다.

• 객체의 참조는 둘이지만 외래 키는 하나인 문제가 발생하기 때문에 이 외래키를 어느 쪽에서 관리할 지를 정해주는 옵션이 mappedBy이다.

• 따라서 연관관계의 주인만이 데이터베이스 연관관계와 매핑되고 외래 키를 관리할 수 있다. 주인이 아닌 쪽은 읽기만 가능하다.

• 주인은 mappedBy 속성을 사용하지 않는다. 주인이 아닌 쪽에 mappedBy 속성을 사용해서 주인을 지정해주어야 한다.

• 위의 예제에서는 회원과 팀 관계의 주인은 회원이다. 주인은 테이블 상에 실제로 외래키가 있는 쪽을 주인으로 잡아주는 것이 옳다.

• MEMBER 테이블에는 실제로 TEAM_ID 외래키가 있다. TEAM을 주인으로 잡아버리면 자기 테이블에 있지도 않은 외래키를 관리해야 한다.

• member.setTeam()은 동작하지만 team.getMembers().add()는 동작하지 않는다.

• 하지만 어차피 동작하지 않기 때문에 양쪽에다가 필드값을 다 집어넣는 게 속이 편하다.

연관관계 편의 메소드

• 근데 양쪽에 관계를 설정하다보면 실수할 수도 있기 때문에 아예 아래 코드처럼 주인 쪽에서 한번에 연관관계를 설정해주는 게 좋다.

public class Member {
	private Team team;

	public void setTeam(Team team) {
		this.team = team;
		team.getMembers().add(this);
	}
}


//하지만 위와 같이 코드를 짜면 연관관계가 변경될 경우 기존 연관관계가 계속 조회되는 문제가 있다.
//따라서 아래와 같이 바꿔줘야 한다.
public void setTeam(Team team) {
	if (this.team != null) {
		this.team.getMembers().remove(this);
	}
	this.team = team;
	team.getMembers().add(this);
}