JPA의 데이터 타입 분류 엔티티 타입 @Entity로 정의하는 객체 데이터가 변해도 식별자로 지속해서 추적 가능 예) 회원 엔티티의 키나 나이 값을 변경해도 식별자로 인식 가능 값 타입 int, Integer, String처럼 단순히 값으로 사용하는 자바 기본 타입이나 객체 식별자가 없고 값만 있으므로 변경시 추적 불가 예) 숫자 100을 200으로 변경하면 완전히 다른 값으로 대체 종류로는 기본값 타입, 임베디드 타입, 컬렉션 값 타입이 존재 기본값 타입 String name, int age 등 이며, 생명주기를 엔티티의 의존한다. (회원을 삭제하면 이름, 나이도 함께 삭제됨) 값 타입은 공유하면 안된다. 회원 이름 변경 시 다른 회원의 이름도 함께 변경되면 안됨 자바의 기본 타입은 절대 공유가 안된..
프록시 기초 em.find() : 데이터베이스를 통해서 실제 엔티티 객체 조회 em.getReference() : 데이터베이스 조회를 미루는 가짜(프록시)엔티티 객체 조회 em.getReference()로 가져온 member의 getClass를 해볼 경우 Member가 아닌 Member@DFnadjwProxy 식으로 매핑이 되어 있다. 값 또한 null로 아직 아무것도 없는 상태다. 이럴때 값에 접근하려고 getName() 해면 그때 영속성 컨텍스트에 초기화를 요청하여 DB에서 객체를 생성한다. 특이한 점은 바로 객체를 리턴하지 않고 연결만 시켜줘서 값을 읽어 온다는 점이다. 즉, getName()을 하더라도 class는 Member가 아니라는 점이다. 프록시의 특징 프록시 객체는 처음 사용할 때 한 번..
벌크 연산 쿼리 한 번으로 여러 테이블 로우 변경(엔티티) executeUpdate()의 결과는 영향받은 엔티티 수 반환 update, delete 지원 insert(insert into .. select, 하이버네이트 지원) String qlString = "update Product p" + "set p.price = p.price * 1.1 " + "where p.stockAmount < :stockAmount"; int rsCnt = em.createQuery(qlString) .setParameter("stockAmount", 10) .executeUpdate(); int rsCnt = em.createQuery("update Member m set m.age = 20") .executeUpda..
페치 조인 @Entity public class Member { 중략.. @ManyToOne(fetch = FetchType.LAZY) //Member, Team 관계를 나타내는 다:1(N:1) @JoinColumn(name = "TEAM_ID") private Team team; } Member 조회 때 여러 연관관계가 걸릴 수 있는데 그냥 매핑을 할 경우 모든 테이블에 join이 걸리므로 성능이 떨어지는걸 막고자 연관관계 매핑 시 Lazy 로딩을 사용하게 된다. 그러면 Team을 바로 join하지 않고 프록시 상태로 갖고 있다가 값을 참조하는 순간에 select 쿼리가 발생된다. 그런데 아래와 같이 사용할 경우 최악의 성능이 생길 수 있다. Team teamA = new Team(); teamA.se..
공통 매핑 정보가 필요할 때 사용(id, name) 같은 정보가 계속 반복될 때 속성만 공통으로 사용하는 것 @MappedSuperclass public abstract class BaseEntity { private String createdBy; private LocalDateTime createdDate; private String modifiedBy; private LocalDateTime modifiedDate; } public class Member extend BaseEntity { } 상속관계 매핑X 엔티티X, 테이블과 매핑X 부모 클래스를 상속 받는 자식 클래스에 매핑 정보만 제공 조회, 검색 불가(em.find(BaseEntity)불가) 직접 생성해서 사용할 일이 없으므로 추상 클래스 ..
단방향 연관관계 객체지향 모델링 하나의 팀이 여러 개의 멤버를 가질 때 보통 Member에서 team_id를 갖고 있는 설계를 많이 하게된다. 하지만 객체지향에서는 외래키 대신 객체 자체를 들고 있는 형태가 되어야 한다. 그래서 위와 같은 내용으로 Member쪽에 이렇게 설정을 해야한다. @Entity public class Member { 중략.. @ManyToOne(fetch = FetchType.LAZY) //Member, Team 관계를 나타내는 다:1(N:1) @JoinColumn(name = "TEAM_ID") private Team team; } 이런식으로 단방향 매핑을 한 뒤에 member를 find 할 경우 매핑된 Team의 정보까지 같이 join되어 불러온다. Member findMem..
@Entity public class Member { @Id private Long id; private String name; } 위와 같이 작성을 할 경우 JPA에서 자동으로 DDL을 애플리케이션 실행 시점에 생성해준다. 이렇게 만들 경우 4가지 옵션으로 사용이 가능하다. ddl-auto : create, update, validate, none 옵션 설명 create 기존 테이블 삭제 후 다시 생성 update 변경분만 반영 validate 엔티티와 테이블이 정상 매핑되었는지만 확인 none 사용하지 않음 개발 환경(로컬)에서는 create나 update를 사용해도 되나, 스테이징과 운영에서는 절대 사용해선 안된다. 스테이징과 운영은 validate, none을 권장 왜냐하면 create는 데이터 ..
플러시 영속성 컨텍스트의 변경 내용을 데이터베이스에 반영 영속성 컨텍스트를 플러시 하는 방법 em.flush() -> 직접호출 트랜잭션 커밋, JPQL 쿼리 실행 -> 플러시 자동 실행 직접 호출할 땐 영속성 컨텍스트를 비우지 않음 영속 컨텍스트 내 '쓰기 지연 SQL 저장소' 의 내용만 미리 반영됨, 영속성 컨텍스트를 비우지 않 준영속 영속 > 준영속 이므로 영속 상태의 엔티티가 영속성 컨텍스트에서 분리되는 것. 영속성 컨텍스트에서 제공되는 기능 사용 못함 준영속 상태로 만드는 방법 em.detach(entity) - 특정 엔티티만 준영속 전환 em.clear() - 영속성 컨텍스트를 완전히 초기화 em.close() - 영속성 컨텍스트를 종료 출처 : https://www.inflearn.com/co..