JPA

연관관계 매핑시 고려사항 3가지 다중성 다대일: @ManyToOne 일대다: @OneToMay 일대일: @OneToOne 다대다: @ManyToOne 단방향, 양방향 테이블 외래 키 하나로 양쪽 조인 가능 객체 참조용 필드가 있는 쪽으로만 참조 가능 한쪽만 참조하면 단방향 양쪽이 서로 참조하면 양방향 연관관계 주인 테이블은 외래키 하나로 두 테이블이 연관관계를 맺음 객체 양방향 관계는 A → B, B → A 처럼 참조가 2군데 존재해야한다. 객체 양방향 관계는 참조가 2군데 있음. 둘 중 테이블의 외래키를 관리할 곳을 지정해야한다. 연관관계 주인이 외래키를 관리하는 참조이다. 주인의 반대편: 외래 키에 영향을 주지 않는다. 단순히 조회만 가능 ※ Source Entity / Target Entity 해당..

값 타입 복사 값 타입의 실제 인스턴스인 값을 공유하는 것은 위험하다 대신 값(인스턴스)를 복사해서 사용 객체 타입의 한계 항상 값을 복사해서 사용하면 공유 참조로 인해 발생하는 부작용을 피할 수 있다. 문제는 임베디드 타입처럼 직접 정의한 값 타입은 자바의 기본 타입이 아니라 객체 타입이다. 자바 기본 타입에 값을 대입하면 값을 복사한다. 객체 타입은 참조 값을 직접 대입하는 것을 막을 방법이 없다. 객체의 공유 참조는 피할 수 없다. 기본 타입과 객체 타입 비교 //기본 타입(primitive type) int a = 10; int b = a; //기본 타입은 값을 복사 b = 4; //객체 타입 Address a = new Address("Old"); Address b = a; //객체 타입은 참조..

JPA 에서 데이터 타입을 최상위 분류로 구분하면 엔티티 타입과 값 타입이 있다. 엔티티 타입 @Entity로 정의하는 객체 데이터가 변해도 식별자로 지속해서 추적 가능 ex) 회원 엔티티의 키나 나이 값을 변경해도 식별자로 인식 가능 값 타입 int, Integer, String 처럼 단순히 값으로 사용하는 자바 기본 타입이나 객체 식별자가 없고 값만 있으므로 변경시 추적 불가 ex) 숫자 100을 200으로 변경하면 완전히 다른 값으로 대체 값 타입 분류 기본값 타입 자바 기본 타입 (int, double) 래퍼 클래스(Integer, Long) String 임베디드 타입 embedded type 복합 값 타입 컬렉션 값 타입 collection valaue type 기본 값 타입 ex) String..

영속성 전이: CASCAED 특정 엔티티를 영속 상태로 만들 때 연관된 엔티티도 함께 영속 상태로 만들고 싶을 때 ex) 부모 엔티티를 저장할 때 자식 엔티티도 함께 저장 cascade = CasecadeType.ALL @Entity public class Parent { public List getChildList() { return childList; } public void setChildList(List childList) { this.childList = childList; } @OneToMany(mappedBy = "parent", cascade = CascadeType.ALL) private List childList = new ArrayList(); } @Entity public class..

지연 로딩 멤버 에서 팀 정보가 잘 사용되지 않을 경우 지연 로딩 (LAZY)을 사용해서 프록시 조회 fetch = FetchType.LAZY //Team을 프록시 객체에서 조회 @ManyToOne(fetch = FetchType.LAZY) @JoinColumn(name = "TEAM_ID") private Team team; Team team = new Team(); team.setName("teamA"); em.persist(team); Member member1 = new Member(); member1.setUsername("member1"); member1.setTeam(team); em.persist(member1); em.flush(); em.clear(); Member m = em.find..

프록시 프록시 사용하는 이유 비즈니스 로직에서 Member와 Team을 같이 조회해야할 지는 상황에 따라 달라진다. 만약 회원과 팀을 함께 출력해야하면 회원 정보를 조회할 때 Team 정보도 같이 조회하는게 좋지만, 회원 정보만 필요한 경우 Team 정보까지 필요하지 않다. em.find(Member.class, 1L)에서 team도 조회할지 회원 정보만 조회할지 상황에 따라 달라진다 이런 문제를 지연 로딩과 프록시로 해결할 수 있다. 프록시 기초 em.find() vs get.Refernece() em.find(): 데이터베이스를 통해서 실제 엔티티 객체 조회 em.getReference(): 데이터베이스 조회를 미루는 가짜(프록시) 엔티티 객체 조 try { Member member = new Mem..

상속관계 매핑 관계형 데이터베이스는 상속관계가 아니다. 슈퍼타입 서브타입 관계라는 모델링 기법이 객체 상속과 유사 상속관계 매핑: 객체의 상속과 구조와 db의 슈퍼타입 서브타입 관계를 매핑 슈퍼타입 서브타입 논리 모델을 실제 물리 모델로 구현하는 방법은 3가지가 있다. 조인 전략: 각각 테이블로 변환 단일 테이블 전략: 통합 테이블로 변환 구현 클래스마다 테이블 전략: 서브타입 테이블로 변환 주요 어노테이션 @Inheritance(strategy=InheritanceType.XXX) JOINED: 조인 전략 SINGLE_TABLE: 단일 테이블 전략 TABLE_PER_CLASS: 구현 클래스마다 테이블 전략 @DiscriminatorColumn(name=“DTYPE”) @DiscriminatorValue..

양방향 연관관와 연관관계의 주인 양방향 매핑을 보면 테이블을 단방향 매핑과 사진이 동일한데 객체는 Team에 members 라는 리스트가 추가 되었다. 테이블은 외래키 하나로 Member테이블에서 TEAM_ID와 Team테이블의 TEAM_ID를 조인해서 Member테이블에서든 Team테이블에서든 서로의 테이블을 조회할 수 있는데 객체는 Team 객체에 필드를 추가해 줘야한다. 객체의 양방향 관계는 사살 양방향 관계가 아니라 서로 다른 단방향 관계 2개다. Member 객체에 Team필드 Team 객체에 List members 필드 객체 연관관계를 단방향에서 양방향으로 바꿔보자 @Entity public class Team( @Id @GeneratedValue private Long id; private ..

예제 시나리오 연관관계 매핑을 하기 위해 다음의 예제를 가지고 진행 회원과 팀이 테이블이 있고, 회원은 하나의 팀에만 소속 될 수 있다. 회원과 팀을 다대일 관계이다 (N:1) 회원 테이블에 팀 pk를 넣는다. 객체를 테이블에 맞추어 모델링 위 사진처럼 연관관계 없는 객체 @Entity public class Member { @Id @GeneratedValue private Long id; @Column(name = "USERNAME") private String name; @Column(name = "TEAM_ID") private Long teamId; ... } @Entity public class Team( @Id @GeneratedValue private Long id; private Strin..