객체지향, 관계형 데이터베이스 패러다임의 불일치로 인해 우리는 추가적인 작업을 해야한다. 객체를 관계형 데이터베이스에 저장하고 꺼내오기 위해서는 객체를 테이블로, 테이블을 객체로 매핑하는 작업이다. 이런 매핑 작업은 크게 의미있지도 않고, 시간도 오래 걸리고, 지루하다
엔티티 매니저 팩토리는 하나만 생성해서 애플리케이션 전체에서 공유엔티티 매니저는 쓰레드간에 공유X (사용하고 버려야 한다). JPA의 모든 데이터 변경은 트랜잭션 안에서 실행JPQL을 이용해 Member 전체를 조회하는 코드 JPA를 사용하면 엔티티 객체를 중심으로 개
엔티티를 영구 저장하는 환경”이라는 뜻영속성 컨텍스트는 논리적인 개념눈에 보이지 않는다.엔티티 매니저를 통해서 영속성 컨텍스트에 접근영속성 컨텍스트와 전혀 관계가 없는 새로운 상태영속성 컨텍스트에 관리되는 상태영속성 컨텍스트에 저장되었다가 분리된 상태영속 상태의 엔티티
객체와 테이블 매핑 @Entity @Entity가 붙은 클래스는 JPA가 관리한다. JPA를 사용해서 테이블과 매핑할 클래스는 @Entity는 필수!! 기본값은 클래스 이름을 그대로 사용(예: Member)한다. 같은 클래스 이름이 없으면 가급적 기본값을 사용한다.
주로 MySQL, PostgreSQL, SQL Server, DB2에서 사용 (예: MySQL의 AUTO\_ INCREMENT) -> 데이터베이스가 기본 키를 자동으로 생성IDENTITY 전략은 AUTO_INCREMENT처럼 데이터베이스에 값을 저장하고 나서야 기본 키
Member 엔티티와 Order 엔티티현재 방식은 객체 설계를 테이블 설계에 맞춘 방식테이블의 외래키를 객체에 그대로 가져옴객체 그래프 탐색이 불가능 참조가 없으므로 UML(분석하고, 디자인하고 프로그래밍하는 것)도 잘못됨try 문에서 다음과 같이 ID로 멤버를 찾게
Team 엔티티에 List<Member> 컬렉션만 추가해주면 됨테이블에 양방향 연관관계는 FK 하나로만 설정할 수 있다. 그러나 객체에서의 양방향 연관관계는 서로다른 단방향 관계를 두 개 설정한다고 생각하면 된다.회원 -> 팀 연관관계 1개(단방향)팀 -> 회원
관계형 데이터베이스는 상속 관계X슈퍼타입 서브타입 관계라는 모델링 기법이 객체 상속과 유사상속관계 매핑: 객체의 상속과 구조와 DB의 슈퍼타입 서브타입 관계를 매핑각각 테이블로 변환@Inheritance(strategy = InheritanceType.JOINED)테이
공통 매핑 정보가 필요할 때 사용(id, name)상속관계 매핑X엔티티X, 테이블과 매핑X부모 클래스를 상속 받는 자식 클래스에 매핑 정보만 제공 조회, 검색 불가(em.find(BaseEntity) 불가)직접 생성해서 사용할 일이 없으므로 추상 클래스 권장Member
em.find() vs em.getReference() em.find(): 데이터베이스를 통해서 실제 엔티티 객체 조회 em.getReference(): 데이터베이스 조회를 미루는 가짜(프록시) 엔티티 객체 조회 프록시 객체는 원본 엔티티를 상속받음, 따라서 타
지연로딩 지연 로딩 LAZY을 사용해서 프록시로 조회 member1.getTeam().getName() ==> 실제 team을 사용하는 시점에 초기화(DB 조회) 즉시로딩 Member조회시 항상 Team도 조회(프록시가 아니라 진짜 엔티티를 가져옴) N+1문제
특정 엔티티를 영속 상태로 만들 때 연관된 엔티티도 함께 영속 상태로 만들도 싶을 때예) 부모 엔티티를 저장할 때 자식 엔티티도 함께 저장.영속성 전이는 연관관계를 매핑하는 것과 아무 관련이 없음엔티티를 영속화할 때 연관된 엔티티도 함께 영속화하는 편리함 을 제공할 뿐
• @Entity로 정의하는 객체• 데이터가 변해도 식별자로 지속해서 추적 가능• 예)회원엔티티의 키나 나이 값 을변경해도 식별자로 인식가능• int, Integer, String처럼 단순히 값으로 사용하는 자바 기본 타입이나 객체• 식별자가 없고 값만 있으므로 변경시
임베디드 타입 같은 값 타입을 여러 엔티티에서 공유하면 위험함 대신 값(인스턴스)를 복사해서 사용 값 타입 컬렉션 값 탑입 컬렉션 저장 ![](https://velog.