qwef

값타입은 복잡한 객체 세상을 조금이라도 단순화하려고 만든 개념. 따라서, 값타입은 단순하고 안전하게 다룰 수 있어야 함. 우리가 int, String 같은 건 써도 크게 신경을 안쓰지만, 객체는 신경쓴다. 왜냐하면 객체는 주소를 넘기는 것 이기 때문에. 근데, 앞서 봤겠지만, 임베디드는 자바입장에서는 클래스임. 그래서 사실 공유가 가능하게 됨. 그래서 이 임베디드를 여러 엔티티에서 공유하게 될 수도 있어서 위험함. Address address = new Address("city1", "street1", "zip1"); Member member1 = new Member(); member1.setName("memberA"); member1.setHomeAddress(address); member1.setPe..

임베디드 타입 새로운 값 타입을 직접 정의할 수 있다. 주로 기본값 타입을 모아서 만들어서 복합 값 타입이라고도 한다. 신기한 점은, int나 String 같이 추적되는 것이 아니라 바꾸면 끝나는 그런거다. 예시 이렇게 회원 엔티티 있을 때, 뭔가 공통적으로 묶어서 할 수 있다. 예를 들어 이렇게. 아예 주소와 날짜는 묶어서 취급한다. 그냥 클래스 하나 더 만들어서 취급하는 거랑 비슷하긴 하다. 이렇게 임베디드 타입 사용법은 @Embeddable : 값 타입을 정의한 곳 @Embedded : 값 타입을 사용한 곳. 기본 생성자 필수임. 임베디드 타입 장점 재사용 가능 높은 응집도 메소드 만들 수 있음. 임베디드를 포함한 모든 값 타입은, 값타입을 소유한 엔티티의 생명주기에 의존. 엔티티의 생명주기에 의존..

JPA의 데이터 타입 분류 엔티티 기본 타입 이렇게 최상위에서는 2가지 있고, 엔티티타입은 내가 엔티티의 뭔가를 변경해도 추적이 가능하다. 엔티티는 객체니 주소로 추적이 가능. 값타입은 그냥 값 타입이다. 값이 100에서 200으로 바뀌면 그냥 완전히 새로 바뀌는 거지 추적 불가. 그냥 객체로 콜바이 레퍼런스 콜 바이 벨류 그런 시선으로 보면 될 듯 하다. 값타입을 약간 더 세세하게 분류해 보자면 기본값타입 - 기본타입 (int, double 등) - 래퍼 클래스(Integer, Long 등) - String 임베디드 타입 - 복합값 타입, 그러니까 클래스 같은것들. 컬렉션 타입 - 리스트 등 이렇게 3가지이고, 기본값 타입은 생명주기를 엔티티에 의존하고(엔티티 삭제하면 얘가 가지고 있던 기본값타입 다 ..

뭐 일단 기본은, ManyToOne 쪽이 주인이라는 것과, 일단 그렇게 단방향으로 다 설계하고, 필요에 따라서 양방향, 그리고, 또 중요한 것이 모두 지연로딩으로. @xToOne은 기본이 즉시로딩이므로, fetch=FetchType.LAZY 해서 모두 지연로딩으로 바꿔줘야 한다. 뭐 그냥 다 지연로딩으로 하면 된다. 이번같은 경우 주문이랑 배송이랑은 거의 짝꿍이고, 생명주기도 같아보이므로, 영속성 전파를 사용할 것이다. 주문과 주문상품도, 주문에 완전히 종속적이기에, 고아객체와 영속성 전파를 모두 사용하는 것도 괜찮아 보인다. @Entity @Table(name="ORDERS") public class Order extends BaseEntity{ @Id @GeneratedValue @Column(nam..

영속성(persist) 전이는 말 그대로 특정 엔티티 persist 하면 연관된 엔티티들도 persist 하는 말 그대로 영속성을 전이시키는 거임. 그러니까, Member에 필드로 Team이 있으면, 이 영속성 전이 기능을 사용하면 member만 persist 해도 Team도 persist 되는거임. 코드 @Entity public class Parent { @Id @GeneratedValue private Long id; private String name; @OneToMany(mappedBy = "parent", cascade = CascadeType.ALL) private List children = new ArrayList(); } 간단하다. 그냥 같이 persist 하고 싶은 연관관계에 casc..

지연로딩 LAZY 사용방법 @Entity public class Member { public Member() { } @Id @GeneratedValue @Column(name = "MEMBER_ID") private Long id; @Column(name="USERNAME", nullable = false) private String name; @ManyToOne(fetch = FetchType.LAZY) @JoinColumn(name = "TEAM_ID") private Team team; @OneToOne Locker locker; } 연관관계에서, fetch = FetchType.LAZY 해 놓으면 프록시로, team을 프록시로 일단 가져온다. Team team1 = new Team(); team1..

Member를 조회할 때 Team도 함께 조회 해야 할까? 뭐, 말 그대로 상황에 따라 다르다. Member와 Team을 짝꿍처럼 쓴다면 함께 가져와야 하고, Team을 사용하는 경우가 있다, 정도라면 Member만 조회해서 가져오는 게 낫다. 말 그대로 어떤 경우엔 Member만 가져오고(사용하지도 않는 Team을 가져오는 것은 성능 낭비니까) 어떤 경우엔 둘 다 가져오고 싶은 것이다. EntityManager는 조회할 때, em.find 뿐 아니라 em.getReference라는 것도 있다. 사용방법은 똑같다. 무슨 차이일까? 코드상에서 설명 하겠다. 먼저 em.find() Member member = new Member(); member.setName("memberA"); em.persist(mem..

일단 이거는 전에 배웠던 상속관계 매핑과는 별로 관계가 깊지 않다. 이거는 뭐냐면, 그러니까 좀 완전 다른? 다른 테이블인데, 객체상에서만 속성만 상속 받아서 쓰고 싶은 경우. 뭐 이런 경우.. Member Seller 완전 다른 테이블이지만, 객체상에서는 상속 받아서 쓰고 싶다. 왜냐하면 저렇게 id나 name같은 거 중복 있으면 저런 게 여러 개 있으면 귀찮으니까. 그러니까, 뭐 상속받는다 그런 거 보다는, 공통적인 것을 사용하고 싶을 때. 공통적인 매핑 정보가 있을 때 사용한다. 꽤 자주 사용하는 모양이다. 뭐 하긴 게임오브젝트로 생각하면 유용할 것 같기는 하다. 코드 @MappedSuperclass public abstract class BaseEntity { private String creat..

객체의 상속관계를 테이블에선 어떻게 표현할 수 있고, JPA에서는 어떻게 지원을 할까? 예전에도 설명했듯이, RDB에는 상속관계가 없다. 가장 유사한 것이 슈퍼타입과 서브타입이라는 모델링 기법을 통해 구현해 낸게 가장 유사하다. JPA에서 상속관계 매핑은 이 객체의 부모 자식 상속 구조와 테이블의 슈퍼타입, 서브타입의 관계를 매핑하는 것이다. 왼쪽이 논리모델, 오른쪽이 물리모델. 여튼, 저 슈퍼타입, 서브타입 논리 모델을 실제 물리모델로 구현하는 방법은 3가지 방법이 있다. 각각 테이블로 변환 -> JOIN 통합 테이블로 변환 -> 단일 테이블 전략 서브타입 테이블로 변환 -> 구현 클래스 마다 테이블 먼저 JOIN전략 타입을 구분하는 열을 하나 둬서 JOIN으로 가져오는 방식이라고 한다. 가장 정규화 ..

여러가지 연관관계를 표현해 보기 위해 만듦. 다대다 쓰지 말라고 했지만 그래도 JPA 공식 스팩이라 해본다고 함. ERD(Entity Relationship Diagram) 보면 카테고리와 아이템은 사실상 Item이 다 카테고리가 1 관계가 맞는 듯. 저걸 토대로 객체 필드를 짜 보면 member Long id String name String city String street String zipcode orders Long id Member member Delivery delivery LocalDateTime orderDate OrderStatus status delivery Long id String city String street String zipcode DeliveryStatus status ..