프로그래밍 노트/JPA

JPA에서 골치아픈 N+1 문제 해결방법을 몇가지 정리한다. N+1 문제 => ORM에서 많이 발생하는 문제 Entity에 대해 하나의 쿼리로 N개의 레코드를 가져왔을 때, 연관관계 Entity를 가져오기 위해 쿼리를 N번 추가적으로 수행하는 문제 N+1 문제에 대해 흔히들 하는 오해 N+1 문제는 EAGER Fetch 전략때문에 발생한다? X, LAZY로 설정했더라도 연관 Entity를 참조하면 그 순간 추가적인 쿼리가 수행됨 findAll()메서드는 N+1 문제를 발생시키지 않는다? Fetch전략을 적용해서 연관 Entity를 가져오는 것은 오직 단일 레코드에 대해서만 적용 단일 레코드 조회가 아닌 경우(JPQL을 수행하는 경우, findAll() 메서드 역시 이 경우) 해당 JPQL을 먼저 수행(E..

2019/10/27 - [프로그래밍 노트/JPA] - [JPA] 다양한 연관관계_일대다(1:N) 일대다(1:N) 단뱡향 관계일 경우, 일대다 단방향관계보단 다대일 양방향관계를 사용해야한다는 포스팅을 한적이있다. 이에관련한 내용을 더 알아보자. member 테이블과 member_detail 테이블은 N:1 관계이다. 다대일(N:1) 단방향관계일때 엔티티를 저장해보자 MemberDetail : Member = N : 1 Member.java @Getter @Setter @Entity public class Member { @Id private Long memberId; private String name; private LocalDateTime createDate; } MemberDetail.java @Ge..

SELECT * FROM TABLE WHERE REPLACE(column_name, ' ', '') = 'val'; 위의 replace 함수를 QueryDsl에서는 어떻게 사용할까? 1번 Expressions.stringTemplate("replace({0},' ','')", column_name) 2번 StringExpression se = StringTemplate.create("replace({0}, ' ', '')", column_name); return select().from(o).where(se.eq('aaa')).list(o);

일대다 (1:N) 일대다 관계는 엔티티를 하나 이상 참조할 수 있으므로 자바 컬렉션인 Collection, List, Set, Map 중에 하나를 사용해야 한다. 일대다 단방향 하나의 팀은 여러 회원을 참조할 수 있다. 팀 : 회원 = 1 : N 일대단 단방향의 특이한 점은 보통 자신이 매핑할 테이블의 외래키를 관리하는데, 이 매핑은 반대쪽 테이블에 있는 외래 키를 관리한다.(일대다 고나계에서 외래 키는 항상 다쪽 테이블에 존재) public class Member { public Member(String id, String username){ this.id = id; this.username = username; } @Id @Column(name = "MEMBER_ID") private String i..

엔티티의 연관관계를 매핑할 때 고려해야할 점 다중성(@ManyToOne, @OneToMany, @OneToOne ...) 단방향, 양방향 연관관계의 주인 단방향, 양방향 테이블은 외래 키 하나로 조인을 사용해서 양방향으로 쿼리가 가능하므로 사실상 방향이라는 개념이 없다. 객체는 참조용 필드를 가지고 있는 객체만 연관된 객체를 조회할 수 있기 대문에, 한 쪽만 참조하는 것을 단방향, 양쪽 서로 참조하는 것을 양방향 관계라 한다. 연관관계의 주인 데이터베이스는 외래 키 하나로 두 테이블의 연관관계를 맺는다. 따라서 테이블의 연관관계를 관리하는 포인트는 외래키 하나다. 반면에 엔티티를 양방향으로 매핑하면 A→B, B→A 2곳에서 서로를 참조한다. 따라서 객체의 연관관계를 관리하는 포인트는 2곳이다. JPA는 ..

객체 관계 매핑(ORM)에서 가장 어려운 부분이 객체 연관관계와 테이블 연관관계를 매핑하는 일이다. 연관관계를 매핑할 때 다음 3가지를 고려해야 한다. 방향(Direction) [단방향, 양방향] 존재 회원, 팀 관계가 있을 때 회원 → 팀 또는 팀 → 회원 둘 중 한 쪽만 참조한다면 단방향 회원 → 팀, 팀→ 회원 양쪽 모두 서로 참조하는 것은 양방향 관계 방향은 객체관계에만 존재하고, 테이블은 항상 양방향 다중성(multiplicity) [다대일(N:1), 일대다(1:N), 일대일(1:1), 다대다(N:M)] 존재 회원, 팀 관계가 있을 때 여러 회원은 한팀에 속하므로 회원 : 팀 = N : 1 한팀에 여러 회원에 속하므로 팀 : 회원 = 1 : N 연관관계의 주인(owner) 객체를 양방향 연관관계..

Table에 추가적인 데이터를 Json 문자열로 저장하기 위해, JPA Converter를 이용하려고한다. 즉, 서비스단에서는 bean으로 사용을하고, DB에 저장될 때는 이 bean을 Json 문자열로 자동 파싱하여 저장하기 위해서이다. 일단 샘플로 Student 클래스를 만들자 @Entity @Getter @Setter public class Student { @Id private String key; private String name; private int age; private AdditionalData additionalData; } Student는 추가데이터(additionalData)를 갖고 있으며, 이 데이터는 additionalData라는 컬럼에 Json 형태로 들어갈 것이다. @Get..

1.준영속 영속 → 준영속 상태 변화를 알아보자. 준영속 : 영속성 컨텍스트가 관리하는 영속 상태의 엔티티가 영속성 컨텍스트에서 분리(detached)된 것을 준영속 상태라 한다. 준영속 상태의 엔티티는 영속성 컨텍스트가 제공하는 기능을 사용할 수 없다. 준영속상태로 만드는 방법 em.detach(entity) : 특정 엔티티만 준영속 상태로 전환한다. em.clear() : 영속성 컨텍스트를 완전히 초기화한다. em.close() : 영속성 컨텍스트를 종료한다. 1-1. 엔티티를 준영속 상태로 전환 : detach() public void testDetached(){ ... // 비영속 상태 Member member = new Member(); member.setId("corn"); member.set..

영속성 컨텍스트의 특징 영속성 컨텍스트와 데이터베이스 저장 JPA는 보통 트랜잭션을 커밋하는 순간 영속성 컨텍스트에 새로 저장된 엔티티를 데이터베이스에 반영한다. 이것을 플러시(flush)라고 한다. 영속성 컨텍스트가 엔티티를 관리할때 장점 1차 캐시 동일성(identity) 보장 트랜잭션을 지원하는 쓰기 지연(transactional write-behind) 변경 감지(Dirty Checking) 지연 로딩(Lazy Loading) 1. 엔티티 조회 영속성 컨텍스트는 내부에 캐시를 가지고 있다. 이 캐시를 1차 캐시라 하며 영속 상태의 엔티티는 모두 이곳에 저장된다. 1차 캐시 영속성 컨텍스트 내부에 Map이 존재하며, 키는 @Id, 값은 엔티티 인스턴스이다. // 엔티티 생성(비영속) Memeber ..

영속성 관리 JPA가 제공하는 기능 엔티티와 테이블을 매핑하는 설계부분 매핑한 엔티티를 실제 사용하는 부분 매핑한 엔티티를 엔티티 매니저(Entity Manager)를 통해 어떻게 사용하는것일까? 엔티티 매니저는 엔티티를 저장하고, 수정하고, 삭제하고, 조회하는 등 엔티티와 관련된 모든 일을 처리한다. ⇒ 엔티티를 관리하는 관리자 1. 엔티티 매니저 팩토리와 엔티티 매니저 // Factory, 비용이 많이듬 EntityManagerFactory emf = Persistence.createEntityManagerFactory("jpabook"); // Factory에서 엔티티 매니저 생성, 비용이 거의 안듬 EntityManager em = emf.createEntityManager(); EntityMan..