자바 ORM 표준 JPA 프로그래밍 - 기본편

• JPA : Java Persistence API

• ORM : Object Relational Mapping

• em.persist(member) 할때는 insert sql 안보내고 transaction.commit() 할 때 모아서 보낸다

• em.createQuery("select m from Member as m", Member.class) : 대상이 객체

• em.remove() : 실제로 db에서 delete 하고싶을때

• 영속성 컨텍스트

  • JPA에서 가장 중요한 2가지
    1. 객체와 관계형 데이터베이스 매핑하기
    2. 영속성 컨텍스트 : 엔티티를 영구 저장하는 환
  • EntityManagerFactory가 EntityManager 생성
  • em.persist(entity) : db 저장이 아니라 영속성 컨텍스트 하는 것
  • EntityManager를 통해 영속성 컨텍스트 접근
  • 비영속 : 객체를 생성한 상태 (세팅만), jpa랑 전혀 관계 X
  • 영속 : 객체를 저장한 상태
  • 1차 캐시에서 조회(없으면 DB에서 조회하고 1차캐시에 저장)
  • 영속 엔티티의 동일성 보장
  • 스냅샷 : 최초로 영속성 컨텍스트에 들어온 상태를 저장
    • commit 하기전에 스냅샷과 비교

• 플러시

  • 영속성 컨텍스트의 변경내용을 데이터베이스에 반영
  • 플러시 발생
    • 변경 감지
    • 수정된 엔티티 쓰기 지연 SQL 저장소에 등록
    • 쓰기지연 SQL 저장소의 쿼리를 데이터베이스에 전송
  • 플러시 하는 방법
    • em.flush()
    • 트랜잭션 커밋
    • JPQL 쿼리실행
  • 영속성 컨텍스트를 비우지 않음!
  • 영속성 컨텍스트의 변경내용을 DB에 동기화
  • 트랜젝션이라는 작업 단위가 중요!! → 커밋 직전에만 동기화하면 됨

• 준영속 상태

  • 영속 상태의 엔티티가 영속성 컨텍스트에서 분리(detached)
  • 영속성 컨텍스트가 제공하는 기능 사용 불가

• 객체와 테이블 매핑

  • 엔티티 매핑 소개
    • 객체와 테이블 매핑 : @Entity, @Table
      • @Entity가 붙은 클래스는 JPA가 관리(엔티티)
        • 기본 생성자 필수(파라미터가 없는 public, protected 생성자)
        • final 클래스, enum, interfacem inner 클래스 사용X
        • 저장할 필드에 final 사용 X
      • @Table은 엔티티와 매핑할 테이블 지정
    • 필드와 컬럼 매핑: @Column
    • 기본키 매핑: @Id
    • 연관관계 매핑 : @ManyToOne, @JoinColumn

• 필드와 칼럼 매핑

  • @Column : 칼럼 매핑
    • name : 필드와 매핑할 테이블 칼럼 이름
    • insertable, updatable : 수정했을때 insert, update 반영 할지 말지
    • nullable = false → not null
  • @Temporal : 날짜 타입 매핑
  • @Enumerated : enum 타입 매핑
    • value ⇒ ORDINAL(순서를 DB에 저장), STRING(이름을 DB에 저장)
  • @Lob : BLON, CLOB 매핑
  • @Transient : 메모리에만 DB에는 X

• 기본키 매핑

  1. @Id : 직접 할당
  2. @GeneratedValue
     1. identity 전략 : id에 값을 넣으면 안됨! null로 들어오면 그때 디비에서 값을 세팅
        1. 이 전략은 persist할 때 쿼리 날림!

• 연관관계 매핑

  • 연관관계 주인
    • 주인 아닌쪽은 읽기만
    • 주인은 mappedBy 사용 X
  • 양방향 매핑시 가장 많이 하는 실수
    • 연관관계의 주인에 값을 입력하지 않는 실수
    • Controller에서는 entity 반환하지 말것!
  • 테이블 : 외래키 하나로 양쪽 조인 가능
  • 객체 : 참조용 필드가 있는 쪽으로만 참조가능 (양쪽이 서로 참조해야 양방향)
  • 일대 → 대상 테이블에 외래키 불가능X
  • 대상 테이블에 외래키 양방향 → 무조건 즉시로딩
  • 다대다 매피의 한계
    • 단순히 연결만 하고 끝나지 않음 → 주문시간, 수량 같은 데이터가 더 들어와야되는데 다대다에서는 쓸수 없음
    • 다대다 → 일대다, 다대일로 풀어서

• 고급매핑

  • 상속관계 매핑
    • 관계형 DB는 상속관계X
    • 슈퍼타입 서브타입 관계라는 논리 모델링 기법이 그나마 객체 상속과 유사
    • 조인전략
      • ITEM 테이블과 ALBUM/MOVIE/BOOK 테이블을 조인으로 묶어서
        • 장점
          • 테이블 정규화
          • 외래 키 참조 무결성 제약조건 활용가능
          • 저장공간 효율화
        • 단점
          • 조회시 조인 많이 사용 → 성능 저하
          • 조회 쿼리 복잡
          • 데이터 저장시 insert sql쿼리 2번 호출
    • 단일 테이블 전략
      • 하나의 테이블로 다 때려박는거
      • 기본적으로 DTYPE 들어있다
      • 조인 필요 X
        • 장점
          • 조인 X → 조회 성능이 좋다
          • 조회 쿼리 단순
        • 단점
          • 자식 엔티티가 매핑한 컬럼은 모두 null 허용
          • 테이블이 커짐 → 성능이 느려질 수도 있다.
    • 구현 클래스마다 테이블 전략
      • ITEM 테이블 속성을 다른 테이블들이 각각 다 들고있는거
      • 중복 속성 낭비된다
      • 부모 클래스로 조회할때 테이블 전체 뒤져봐야됨
      • 얘는 차리리 쓰지않는게 낫다!
    • 주요 어노테이션
      • @Inheritance(strategy=InheritanceType.XXX)
      • XXX = JOINED, SINGLE_TABLE, TABLE_PER_CLASS
      • @DiscriminatorColumn : 엔티티 명이 DTYPE으로 (default) / 싱글테이블 전략에서는 꼭 필요!
      • @DiscriminatorValue : 자식 엔티티한테 다는거
    • 조인전략을 기본으로 하되 너무 단순하면 단일 테이블전략 사용해도 괜
  • @MappedSuperclass
    • 공통 매핑 정보가 필요할 때 사용(ex. id, name)
    • 상속관계 매핑 X
    • 엔티티 X, 테이블과 매핑 X
    • 부모 클래스를 상속받는 자식클래스에 매핑 정보만 제공
    • 조회, 검색 불가 (em.find(BaseEntity) 불가)
    • 직접 생성할 일 X → 추상 클래스
    • 테이블과 관계 X, 단순히 엔티티가 공통으로 사용하는 매핑 정보만 모으는 역할
    • 등록일, 수정일, 등록자, 수정자 같은 전체 엔티티에서 공통적으로 적용하는 정보 모을때 사용
    • 참고 : @Entity 클래스는 엔티티나 @MappedSuperclass로 지정한 클래스만 상속 가능

• 프록시

  Q. Member 조회 시 Team도 함께 조회해야 할까??

  • 프록시
    • em.find() : 데이터베이스를 통해서 실제 엔티티 객체 조회
    • em.getReference() : 데이터베이스 조회를 미루는 가짜(프록시) 엔티티 객체 조회 → 호출 시점에는 쿼리 안나가고, 실제 사용될 때 쿼리 나감
    • 실제 클래스를 상속받아서 만들어짐 → 겉모양이 같다, 타입 체크시 주의! ( == 비교 대신, instance of 사용)
    • 사용하는 입장에서는 진짜 객체인지 프록시 객체인지 구분하지 않고 사용하면 됨
    • 프록시 객체 호출하면 프록시 객체는 실제 객체의 메소드 호출
    • 프록시 객체의 초기화 : 영속성 컨텍스트를 통해 실제 entity 생성 / 프록시 객체가 실제 엔티티로 바뀌는건 X, 프록시 객체를 통해서 실제 엔티티에 접근 가능
    • 프록시 객체는 처음 사용할 때 한번만 초기화
    • 프록시 인스턴스 초기화 여부 확인 → emf.getPersistenceUnitUtil.isLoaded(Object entity)
    • org.hibernate.Hibernate.initialize(entity) → 프록 강제 초기화

• 지연로딩 & 즉시로딩

  • fetch = FetchType.LAZY : 프록시로 조회 (실제 안땡겨오고 사용할 때 땡겨옴)
  • fetch = FetchType.EAGER : 한번에 다 가져온다! 쿼리 한번만 나감
  • 지연로딩만 사용해라!!!!
  • 즉시로딩은 JPQL에서 N+1 문제 발생
  • @ManyToOne, OneToOne ⇒ 기본이 즉시로딩이므로 LAZY로 설정

• 영속성 전이 : CASCADE

  • 특정 엔티티를 영속 상태로 만들 때 연관된 엔티티도 함께 영속 상태로 만들고 싶을 때
  • 자동으로 자식도 persist 해주는거 / 지연,즉시로딩과 관련 전혀 X

• 값 타입

  • JPA 데이터 타입 분류
  1. @Entity로 정의하는 객체
     1. 데이터각 변해도 식별자로 지속 추적 가능
     2. 회원 엔티티의 키나 나이값을 변경해도 식별자로 인식 가능
  2. 값 타입
     1. int, Integer, String 처럼 단순 값으로 사용하는 자바 기본타입이나 객
  3. 임베디드 타입
     1. @Embeddable : 값 타입을 정의하는 곳에 표시
     2. @Embedded : 값 타입을 사용하는 곳에 표

• 질문(11/21)

  💡 질문 (11/21)

  • Q. flush와 transaction commit의 차이는?

    flush는 쿼리를 전송하는 역할이고 commit은 내부적으로 flush를 수행한 뒤 트랜잭션을 끝내는 역할 / flush로 전송된 쿼리는 rollback할 수 있지만 commit은 트랜잭션을 끝내므로 rollback X

    • 그럼 flush는 어떻게 발생시킬까?
      • em.flush()
      • 트랜잭션 커밋
      • JPQL 쿼리실행 (em.createQuery("select m from Member as m", Member.class))

  • Q. 준영속 상태는 영속성 컨텍스트가 제공하는 기능 사용이 가능하다 (O, X)

    X! 사용불가

    • 준영속 엔티티를 수정하는 두가지 방법은?
      1. 변경감지
      2. 머지 사용
      • 을/를 사용하면 원하는 속상만 선택해서 변경할 수 있지만, 을/를 사용하면 모든 속성이 변경 (빈칸을 채워주세용)
        • 변경감지, 병합 ⇒ 최대한 변경 감지를 사용하자!
        • 변경감지 기능을 사용할 때 setter를 사용하면 추적하기 어려우므로 setter 보다는 메서드를 사용하여 변경을 확실하게 알 수 있게 하자!

• 질문(11/28)

  • 양방향 매핑시 가장 많이 하는 실수
    • 연관관계의 주인에 값을 입력하지 않는 실수
    • Controller에서는 entity 반환하지 말것!
  • 조인시 테이블과 객체는 어떻게 다를까?
    • 테이블 : 외래키 하나로 양쪽 조인 가능
    • 객체 : 참조용 필드가 있는 쪽으로만 참조가능 (양쪽이 서로 참조해야 양방향, 사실 단방향이 2개인거긴 함)

• 질문(12/19)

  • 조인전략과 단일테이블 전략의 장단점을 비교하시오/ 조회성능은 누가 더 좋을까?
    • 조인전략 ex) ITEM 테이블과 ALBUM/MOVIE/BOOK 테이블을 조인으로 묶어서
      • 장점
        • 테이블 정규화
        • 외래 키 참조 무결성 제약조건 활용가능
        • 저장공간 효율화
      • 단점
        • 조회시 조인 많이 사용 → 성능 저하
        • 조회 쿼리 복잡
        • 데이터 저장시 insert sql쿼리 2번 호출
    • 단일 테이블 전략
      • 하나의 테이블로 다 때려박는거
      • 기본적으로 DTYPE 들어있다
      • 조인 필요 X
        • 장점
          • 조인 X → 조회 성능이 좋다
          • 조회 쿼리 단순
        • 단점
          • 자식 엔티티가 매핑한 컬럼은 모두 null 허용
          • 테이블이 커짐 → 성능이 느려질 수도 있다.
  • @MappedSuperclass 를 사용할때 BaseEntity로 조회 가능하다 (O, X)
    • 조회, 검색 불가 (em.find(BaseEntity) 불가)
    • 부모 클래스를 상속받는 자식클래스에 매핑 정보만 제공