@JoinColumn 질문 :]

DB 테이블 기준으로 생각하시면 됩니다.MEMBER 테이블의 외래키 TEAM_ID 컬럼을 선택하는거예요. 자바 클래스와는 무관합니다

벌크 연산, 영속성 컨텍스트 후 member.getAge() 조회 결과 질문드립니다!

Member member1 = memberRepository.findById(memberId) // 멤버의 age는 0 em.createQuery("update ~~") // 벌크 업데이트 em.clear() //영속성 컨텍스트 초기화 System.out.println(member1.getAge()) // 0 출력이런 상황으로 이해하면 될까요?

연관관계 주인 관련 질문 드립니다.

1. 가장 기본적인 문제는 테이블 정의부터가 제대로 안 됩니다.이해하신 것처럼 DB는 외래키 하나로 양방향이 가능한데, 객체는 단방향 참조 두 개로 이를 흉내냅니다.반대로 양방향으로 연결되도록 엔티티를 설계하면 DB입장에서는 이게 하나의 연관관계를 양방향으로 흉내낸건지 두 개의 연관관계가 필요한건지 모르게 됩니다. 실제로 강의에 나온 Member와 Team 예제에 있어서, mappedBy를 넣지 않고 ddl-auto crreate로 돌려보시면 team -> member 일대다 연관관계를 맵핑하기 위한 테이블이 하나 더 추가로 생성됩니다. Hibernate: create table member (member_id bigint not null, team_id bigint, primary key (member_id))Hibernate: create table team (team_id bigint not null, primary key (team_id))Hibernate: create table team_team (team_team_id bigint not null, team_member_id bigint not null 연관관계의 주인 개념이 있어야 우리가 설정한 양방향 관계가 TABLE 개념에서의 연관관계 하나임을 보장할 수 있습니다.2. 영속성 컨텍스트 변경감지 기준member.setTeam(), team.addMember()를 모두 허용하게 되면 영속성 컨텍스트가 너무 복잡해집니다. 경우에 따라서 update 쿼리가 두 번 나가게 될 수 있고 (양쪽 연관관계가 모두 업데이트 된 경우), 이를 최적화하기 위한 추가적인 연산도 많을 것 입니다. 또한 양쪽 연관관계가 모순되는 경우에는 어떻게 처리할지에 대한 규약도 훨씬 복잡해집니다.예컨대 team.members에는 member1이 있는 상태에서 member1.setTeam(null) 을 한 경우 어느쪽을 따라야 하는가? 등등..

지연 로딩 update 시

JPA와 하이버네이트의 구현과는 관계 없이 일반적으로 지연로딩은 조회와 깊은 관련이 있는 개념입니다. 말 그대로 조회가 필요한 시점까지 조회를 늦추겠다는 개념이기 때문입니다. 조회한 객체를 수정하는 것은 지연로딩과는 관련이 없는 개념으로, 지연로딩이든 아니든 영속성 컨텍스트 변경감지는 똑같이 이루어집니다. 마지막으로, update 쿼리는MEMBER에밖에 나갈 수 없는 구조입니다. MEMBER가 TEAM의 외래키를 들고 있기 때문입니다. (TEAM쪽에 update를 해서 member와의 연관관계를 규정할 방법이 없습니다)연관관계에 대한 영속성 컨텍스트의 변경감지는 연관관계의 주인 쪽에서만 일어납니다.MEMBER가 주인이라면 member.setTeam 이 update 쿼리를 발동시킬것이고, TEAM이 주인이라면 team.addMember()가 update 쿼리를 발동시킬 것입니다.연관관계의 주인 강의를 보시면 이해가 가실거예요

연관관계 주인 위배?

연관관계의 주인 개념은 영속성 컨텍스트에게 어느쪽이 연관관계를 관리하는 주인 역할을 하는지 알려주는 개념이고, CASCADE는 PERSIST, REMOVE 등의 특정 액션이 엔티티에 걸릴 때 자식 엔티티에도 같은 액션을 "전파"시켜주는지만 신경쓰는 개념입니다. 강의에 나온 Member와 Team을 예시로 하겠습니다. Team team = new Team(); team.add(new Memeber()); em.persist(team); 위 코드만 있을 시 CASCADE 옵션이 없다면 연관관계가 TEAM 쪽으로 잡혀있다고 하더라도 멤버는 영속성 컨텍스트에 등록되지 않습니다. CASCADE 옵션이 위 코드에서 하는 역할은 em.persist(team)을 해줬을때 team 객체 안의 자식객체들을 찾아서 자식객체 또한 자동으로 persist를 해주는 것일 뿐입니다. 개념적으로는 이렇게 연관관계와는 별개의 개념이지만, CASCADE 옵션을 그냥 마구잡이로 편한대로 쓰다보면 DB관리가 크게 잘못될 수 있기 때문에 생명주기가 명확한 객체끼리 붙이게 되고, 그러다보니 연관관계 개념과 섞여서 혼동스러울 수 있는 개념인 것 같습니다.