------------------------(맥락)----------------------
: DB 테이블에서 외래키를 통해 연관관계 -> 엔티티 버전의 매핑
: 성능 저하는 데이터를 저장,수정시 아니라 조회할떄 일어난다 -> LAZY를 통해 최적화
: 뒤늦게 생성된 것이 먼저 생성된것에 참조로 걸쇠 건다. 사용을 편리하게 하기 위해 원본에서도 참조 후 cascade, orpahn 설정
멤버는 양방향 x, 오더만
------------------------(스트럭쳐 : 일어나는곳)----------------------
단방향 1:1
1 카트 -> 1 멤버 (일방적 참조)
-
단방향 M:1
멤버 <- M 오더
M 카트아이템 -> 카트
-
M 카트아이템 -> 1카트 -> 1멤버
-
M 카트아이템 -> (특정) 아이템
M 오더아이템 -> (특정) 아이템
M 오더아이템 -> 오더
-
단방향에 양방향 추가
1오더 -> M 오더아이템
-
다대다는 사용하지 않음 : 연결 테이블에는 컬럼을 추가할수없기때문
(semiflow 20)
flush일때 쓰기지연저장소 -> DB 반영
OneToOne / ManyToOne일때 기본전략 = EAGER(즉시로딩)
테스트 시 영속성 컨텍스트를 clear(). cart엔티티를 가지고 올떄 member도 가지고 오는지 보기위해서
@JoinColumn을 사용하는 엔티티에 컬럼이 추가된다
ManyToOne은 기본전략 = LAZY
즉시 로딩은 실무에서 쿼리 성능 저하로 사용하지 않는다
(기능)
테이블 : ORDERS와 ORDER_ITEM 테이블은 ORDER_ID FK 하나로 양방향 조회 가능
엔티티 : 양방향으로 설정시 참조는 둘인데 누가 FK를 관리할지 설정
주인 아닌쪽은 mappedBy 속성값으로 주인 표시, 읽기만 가능
주인은 FK를 가지고 있는곳이며 주인이 FK를 관리(등록, 수정, 삭제)
-
(캐스캐이드 -> 고아 객체 제거)
(cascade)
주인은 오더아이템이지만, 부모는 오더다 -> One이 있는 곳이 부모가 됨
오더에 cascade 설정 후 오더 저장하면 오더아이템도 같이 저장되는 것 테스트
(테스트)
우선 새 아이템이 필요하다. 아이템부터 저장하고 시작.
1 : 아이템 -> 오더아이템 <- 오더
2 : 오더에도 겟오더아이템(리스트) -> add해서 orderItem을 넣어줌
save&flush는 오더만 해주지만 콘솔창에는 order insert 후 담겨져있던 orderitem도 insert됨
-
(고아 객체 제거)
오더아이템은 오더와만 쓰이니까 해당 기능 사용 가능
@OneToMany / @OneToOne 에서 옵션으로 사용하라 == 부모에서 사용
(테스트)
아이템 + 오더아이템3 + 오더 만들고
오더 -> 3개 오더아이템중 1개만 제거 -> flush
오더 엔티티에서만 오더아이템 삭제했지만 콘솔에서는 오더아이템 delete되는 것 확인
*Casecade.REMOVE는 오더 자체를 삭제할때 오더아이템도 삭제되는 것
orphanRemoval = true는 오더 내 오더아이템 삭제시 해당 오더아이템이 삭제되는것
-
(지연 로딩)
오더를 저장하고 오더아이템 아이디를 얻는다
해당 id로 리포지토리 findById시에 오더아이템, 아이템, 오더, 멤버까지 딸려옴
-> 오더아이템에서 아이템과 오더에 fetch를 변경한다
-> 콘솔에서 오더아이템 하나만 나오고
-> 오더는 실제 엔티티 대신에 프록시 객체로 나옴
-> 오더아이템.오더.겟오더데이트 시에 select 쿼리문 실행됨(실제 사용 시점에 사용)