김찬진의 개발 블로그

그렇다 최대한 단방향 연관관계 매핑만으로 연관관계 매핑을 끝낸 것이다. 만약 개발하다가 양방향 연관관계 매핑이 필요하다면 그 때 하면 된다. @Entity public class Member { @Id @GeneratedValue(strategy = GenerationType.AUTO) @Column(name = "MEMBER_ID") private Long id; @Column(name = "USERNAME") private String username; @ManyToOne // 단방향 연관관계 매핑 @JoinColumn(name = "TEAM_ID") private Team team; } 양방향 연관관계 매핑은 필요할 때 추가하면 된다 @Entity public class Team { @Id @Gen..

예제 코드 출처는 김영한 님의 JPA 강의 1편입니다. 아니다. 그렇지 않다 주인이 아닌 도메인 객체가 값을 쓰지 않도록 하는 것이 JPA 스럽지는 않을 수 있겠지만 주인인 도메인 객체가 값을 쓰고, 주인이 아닌 도메인 객체도 값을 쓰는 것이 오히려 객체지향스럽다고 말할 수 있다 하지만 주인인 도메인 객체가 값을 쓰고, 주인이 아닌 도메인 객체가 값을 쓰는 것은 까먹을 수 있기 때문에 연관관계 편의 메서드를 생성하자 일단 상황부터 설명하고 차근차근 정리해보자 하나의 Team 객체에 여러 개의 Member 객체가 달려있을 수 있다. 즉 Member 와 Team 의 연관관계 매핑은 N:1 이어야 한다. public class JpaMain { public static void main(String[] arg..

그렇지 않다. 만약 id 필드가 PK로써 IDENTITY전략을 사용했다면 엔티티 매니저의 1차 캐시 기능은 사용 불가한 것이 맞다. 왜냐하면 DB에 INSERT 쿼리를 날린 이후에야 비로소 id값을 알아낼 수 있기 때문이다. 하지만 id 필드가 PK로써 SEQUENCE전략을 사용한다면 DB에 INSERT 쿼리를 날릴 필요까지는 없고 DB의 시퀀스에게 다음 id값을 물어봐서 가져온 이후에 엔티티 매니저의 1차 캐시에 저장(영속화)할 수 있다. 물론 쓰기 지연 SQL 저장소 기능도 사용할 수 있기 때문에 flush()가 호출될 때(flush() 직접 호출 || 트랜잭션 커밋 || JPQL 쿼리 실행) 한꺼번에 쿼리를 DB에 날린다. 추가로, 영속화할 때마다 DB의 시퀀스에게 다음 id값을 매번 물어보면 리소..

그렇다. 원래 지금까지 JPA의 영속성을 배웠던 바에 따르면, em.persist(memberA) 호출하면 멤버 객체 memberA가 엔티티 매니저의 1차 캐시에 저장된다고 했다. 이 때 1차 캐시에 저장되는 형태는 key는 id이고 value는 객체이다. 근데 만약 개발자가 id를 직접 지정하는 것이 아니라 DB에서 데이터가 저장될 때마다 자동으로 증가하는 IDENTITY 전략을 사용한다면 1차 캐시에 저장될 때에는 key에 id를 넣는 것이 불가능하다. 왜냐하면 1차 캐시에 저장(영속화)될 때 id값이 정해지는 것이 아니라 DB에 반영되고난 이후 비로소 데이터의 순서에 따라 id값이 정해지기 때문이다. 즉, IDENTITY 전략이 JPA의 패러다임과 맞지 않게 되는 문제가 발생한다. 이 문제를 어떻게..