꿀맛코딩

값 타입을 하나 이상 저장할 때 사용 @ElementCollection, @CollectionTable 사용 데이터베이스는 컬렉션을 같은 테이블에 저장할 수 없다. 컬렉션을 저장하기 위한 별도의 테이블이 필요함 값 타입 컬렉션의 제약사항 값 타입은 엔티티와 다르게 식별자 개념이 없다. 값은 변경하면 추적이 어렵다. 값 타입 컬렉션에 변경 사항이 발생하면, 주인 엔티티와 연관된 모든 데이터를 삭제하고, 값 타입 컬렉션에 있는 현재 값을 모두 다시 저장한다. 값 타입 컬렉션을 매핑하는 테이블은 모든 컬럼을 묶어서 기본키를 구성해야함 : null입력 x, 중복 저장 x 값 타입 컬렉션 대안 실무에서는 상황에 따라 값 타입 컬렉션 대신에 일대다 관계를 고려 일대다 관계를 위한 엔티티를 만들고, 여기에서 값 타입..

값 타입은 복잡한 객체 세상을 조금이라도 닫순화 하려고 만든 개념이다. 따라서 값 타입은 단순하고 안전하게 다룰수 있어야한다. 값 타입 공유 참조 임베티드 타입 같은 값 타입을 여러 엔티티에서 공유하면 위험함 부작용 발생 값 타입 복사 값 타입의 실제 인스턴스인 값을 공유하는 것은 위험 대신 값(인스턴스)를 복사해서 사용. 객체 타입의 한계 항상 값을 복사해서 사용하면 공유 참조로 인해 발생하는 부작용을 피할 수 있다. 문제는 임베디드 타입처럼 직접 정의한 값 타입은 자바의 기본 타입이 아니라 객체 타입이다. 자바 기본 타입에 값을 대입하면 값을 복사한다. 객체 타입은 참조 값을 직접 대입하는 것을 막을 방법이 없다. 객체의 공유 참조는 피할 수 없다. 불변 객체 객체 타입을 수정할 수 없게 만들면 부작..

새로운 값 타입을 직접 정의할 수 있음 JPA는 임베디드 타입(embedded type)이라 함 주로 기본 값 타입을 모아서 만들어서 복합 값 타입이라고도 함 int, String과 같은 값 타입 사용법 @Embeddable: 값 타입을 정의하는 곳에 표시 @Embedded: 값 타입을 사용하는 곳에 표시 기본 생성자 필수 장점 재사용 높은 응집도 Period.isWork()처럼 해당 값 타임만 사용하는 의미 있는 메소드를 만들 수 있음 임베디트 타입을 포함한 모든 값 타입은 값 타입을 소유한 엔티티에 생명주기를 의존함 임베디드 타입과 테이블 매핑 임베디드 타입은 엔티티의 값일 뿐이다. 임베디드 타입을 사용하기 전과 후에 매핑하는 테이블은 같다. 객체와 테이블을 아주 세밀하게 매핑하는 것이 가능 잘 설계..

프록시 객체는 처음 사용할 때 한 번만 초기화 프록시 객체를 초기화 할 때, 프록시 객체가 실제 엔티티로 바뀌는 것은 아님, 초기화 되면 프록시 객체를 통해서 실제 엔티티에 접근 가능 프록시 객체는 원본 엔티티를 상속 받음, 따라서 타입 체크시 주의 해야함 (== 비교 실패, 대신 instance of 사용) 영속성 컨텍스트에 찾는 엔티티가 이미 있으면, em.getReference()를 호출해도 실제 엔티티 반환 영속성 컨텍스트의 도움을 받을 수 없는 준영속 상태일 때, 프록시를 초기화 하면 문제 발생 프록시와 즉시로딩 주의 - 가급적 지연 로딩만 사용(특히 실무) - 즉시 로딩을 적용하면 예상하지 못한 SQL이 발생 - 즉시 로딩은 JPQL에서 N+1 문제를 일으킨다. - @ManyToOne, @On..

- 공통 매핑 정보가 필요할 때 사용(id, name) 상속관계 매핑 X 엔티티X, 테이블과 매핑X 부모 클래스를 상속 받는 자식 클래스에 매핑 정보만 제공 조회, 검색 불가 (em.find(BaseEntity) 불가) 직접 생성해서 사용할 일이 없으므로 추상 클래스 권장 테이블과 관계없고, 단순히 엔티티가 공통으로 사용하는 매핑 정보를 모으는 역할 주로 등록일, 수정일, 등록자, 수정자 같은 전체 엔티티에서 공통으로 적용하는 정보를 모을 때 사용. 참고: @Entity 클래스틑 엔티티나 @MappeddSuperclass 로 지정한 클래스만 상속가능

1. 상속관계 매핑 - 관계형 데이터베이스는 상속 관계 x - 슈퍼 타입 서브타입 관계라는 모델링 기법이 객체 상속과 유사 - 상속관계 매핑: 객체의 상속과 구조와 DB의 슈퍼타입 서브타입 관계를 매핑 슈퍼타입 서브타입 논리 모델을 실제 물리 모델로 구현하는 방법 각각 테이블로 변환 -> 조인 전략 통합 테이블로 변환 -> 단일 테이블전략 서브 타입 테이블로 변환 -> 구현 클래스마다 테입르 전략 2. 주요 어노테이션 - @Inheritance(strategy=InheritanceType.XXX) JOINED: 조인 전략 SINGLE_TABLE: 단일 테이블 전략 TABLE_PER_CLASS: 구현 클래스마다 테이블 전략 TABLE_PER_CLASS 를 사용시 Abstract class로 생성해 주어야 ..

연관관계 매핑시 고려사항 3가지 다중성 다대일 : @ManyToOne 일대다: @OneToMany 일대일: @OneToOne 다대다: @ManyToMany 단방향, 양방향 테이블 외래 키 하나로 양쪽 조인가능 사실 방향이라는 개념이 없음 객체 참조용 필드가 있는 쪽으로만 참조 가능 한쪽만 참조하면 단방향 양쪽이 서로 참조하면 양방향 연관관계의 주인 테이블은 외래 키 하나로 두 테이블이 연관관계를 맺음 객체 양방향 관계는 A->B, B->A 처럼 참조가 2군데 객체 양방향 관계는 참조가 2군데 있음. 둘중 테이블의 외래 키 를 관리할 곳을 지정해야함지정해야함 연관관계의 주인: 외래 키를 관리하는 참조 주인의 반대편: 외래 키에 영향을 주지 않음, 단순 조회만 가능

객체를 테이블에 맞추어 데이터 중심으로 모델링 하면, 협력 관계를 만들 수 없다. - 테이블은 외래 키로 조인을 사용해서 연관된 테이블을 찾는다. - 객체는 참조를 사용해서 연관된 객체를 찾는다. - 테이블과 객체 사이에는 이런 큰 간격이 있다. 단방향 연관관계 객체 지향 모델링 (객체 연관관계 사용) 객체 지향 모델링 (객체의 참조와 테이블의 외래 키를 매핑 ) @Entity public class Member { private Long id; @Column(name = "USERNAME") private String name; private int age; @Column(name = "TEAM_ID") private Long teamId; @ManyToOne @JoinColumn(name = "TEA..

@Entity - @Entity가 붙은 클래스는 JPA가 관리, 엔티티라 한다. - JPA를 사용해서 테이블과 매핑할 클래스는 @Entity 필수 주의 - 기본 생성자 필수 - final 클래스, enum, interface, inner 클래스 사용 x - 저장할 필드에 final 사용 x 데이터베이스 스키마 자동 생성 개발단계에서 Application 로딩 시점에 테이블 생성 기능이 있음 - DDL(Data Definition Language)을 어플리케이션 실행 시점에 자동 생성 - 테이블 중심 -> 객체중심 - 데이터베이스 방언을 활용해서 데이터베이스에 맞는 적절한 DDL 생성 - 이렇게 생성된 DDL은 개발 장비에서만 사용 - 생성된 DDL은 웅영서버에서는 사용하지 않거나, 적절히 다담은 후에 사..

- 영속 -> 준영속 - 영속 상태의 엔티티가 영속성 컨테스트에서 분리(detached) - 영속성 컨텍스트가 제공하는 기능을 사용 못함 준영속 상태로 만드는 방법 - em.detach(entity) 특정 엔티티만 준영속 상태로 전환 - em.clear() 영속성 컨테스트를 완전히 초기화 - em.close() 영속성 컨테스트를 종료 김영한 선생님 강의 복습 용도 메모