JPA 에서 DB 생성시 joincolumn 을 지정해 놓은 것을 foreign key 로 생성해 준다고 하셨는데요. 혹시 설정을 통해 제어할 수 있나요? 전체적으로 생성을 못하게 한다든지어떤 column 은 FK 로 잡아주고 어떤 column 은 무시하고개별적으로도 설정이 가능한지 궁금합니다.^^ 좋은 강의 감사드립니다.

여러테이블을 페치조인한 정적쿼리인 경우는 @Query를 이용해서 리포지토리에서 직접 작성하고 동적쿼리만 QueryDSL사용을 권장하는 건가요?

안녕하세요. 기본편 수강마치고 강의 듣는 중에 의문점이 있어 질문드립니다. 기본편의 페치조인의 한계 강의에서는 "페치조인의 대상에는 별칭을 줄 수 없다." 고 하셨는데 지금 예제는 별칭을 포함하고 있어서요. (o.member m 과 o.delivery d) 제가 검색조건을 추가해서 테스트해보니 정상적으로 쿼리수행이 되었습니다. 아래는 제가 테스트해본 코드입니다. public List<Order> findAllWithMemberDelivery(OrderSearch orderSearch) { return em.createQuery("select o from Order o " + "join fetch o.member m " + "join fetch o.delivery d " + "where (:status is null or o.status = :status) " + "and (:name is null or m.name like :name)", Order.class) .setParameter("status", orderSearch.getOrderStatus()) .setParameter("name", orderSearch.getMemberName()) .getResultList(); } 그리고 기본편의 강의에서는 페치조인에 별칭을 주는것의 위험성도 설명해주셨는데요. 지금같이 검색조건을 주는 경우에는 페치조인에 별칭을 줄 수 밖에 없는게 아닌지 궁금합니다. 기본편 강의를 다시 보니 OneToMany 에 대해서만 페치조인 별칭이 위험한 것으로 이해됩니다. 지금예제의 Order와 Member 관계처럼 ManyToOne 에서는 문제가 되지 않는 것인지.. 제가 이해한게 맞는지 확인 부탁드리겠습니다.

안녕하세요! @EntityGraph 는 기본적으로 left join을 하는 것 같은데 혹시 inner 나 right 조인도 @EntityGraph 에서 가능한지 궁금합니다. 아니면 이때는 jpql을 작성해야 할까요? 그리고 늦은 시간에 질문이라 죄송하고 😭 늘 좋은 강의 정말 감사드립니다! 😄

초보적인 질문일지 모르겠지만  EntityManager를 @Autowired로 받아와도 결과가 같던데 @PersistenceContext로 받아오시는 이유가 혹시 있으신가요?

쿼리 성능 최적화를 위해서 OrderRepository에 쿼리를 한방에 날리기 위해 fetch join을 사용하는건 이해가 됐습니다. 그렇다면 API스펙이 바뀔때마다 OrderRepository에 새롭게 fetch join을 사용하여 메소드를 생성해야되는 건가요?

선생님의 강의를 보면서 정말 실무에서 몰랐으면 고생했을 내용을 많이 알게되어서 도움이 많이되었습니다.^^ OSIV같은 성능 최적화를 위한 설정 부분에 대해서 알게 되어서 너무나도 기쁩니다. 사실 다름이아니고 전부터 궁금했던 부분인데 @Transactional(read only =true) 로 설정하면 읽기 전용으로 설정이되어서 CRUD에서 R을 제외한 나머지 작업은 안되는걸로 알고있는데 정확하게 어떻게 동작하는지 메커니즘이 궁금합니다. 제가 찾아봤을때는 read only = true로 설정하면  트랜잭션 커밋 직전에 영속컨텍스트에서  플러시를 호출하지 않는 걸로아는데 ... 이게 정확한 정보인지 궁금합니다. 

A라는 엔터티와 B라는 엔터티가 있고, 이것의 관계가 1:N이라는 관계에 있다고 가정했을 때 repository를 생성할 때 , ARepository만 만들거나, BRepository를 만들거나, ARepositry 와 BRepository를 만드는 경우가 있을 거 같은대요. 혹시 각각의 경우에 대해서 알려주실 수 있을까요? 전 무의적으로 각각의 Entity에대해서 Repository를 만드는 것 같아서요 ㅎㅎ;

강의를 역시나 재미나게 보고 있습니다 ㅎㅎ 가끔 블로그를 보면 entity에 Serializable을 붙이는 경우가 있는데 이것에 대한 설명 부탁드립니다. 제가 아는 한에서 Serializable은 객체를 다른 서버로(ip가 다른) 보낼 때 객체로는 보낼 수 없어서 스트림으로 만들기 위해 Serializable을 사용하는 것으로 이해하고 있는데. 보통 dto로 매핍을 받으니 entity 객체가 다른 곳으로 이동할 일이 옶다고 보거든요. 오히려 서로 다른 ip로 되어 있는 서버에  보내기 위해서는 dto객체를 serializable로 만드는게 맞지않을까 생각합니다

order 엔티티를 조회했을때 프록시 초기화를 통해서 컬렉션 과 나머지 엔티티들을 조회하는것을 알겠는데 postman에서 조회화면결과에서  TotalPrice 컬럼은 어떻게 나오는건가요? 아무리봐도  Order 클래스파일에는 public int getTotalPrice() 메소드로 정의된거 말고는 없는데 이 부분이 궁금해서 질문드립니다.

영한님 안녕하세요~ 오늘도 또 하나의 질문을 들고 왔습니다. 예전 MyBatis 방식에서는 보통 수정 처리의 경우, 업데이트 문 한번으로 처리가 가능했는데요. (내가 수정하고자 하는 일부 항목들만 정의된 Update SQL 문 작성) JPA 방식에서는 Find 를 먼저 하지 않고 바로 업데이트 하기에는 어려움이 있는 듯 합니다. 예를 들어 Member 객체에 패스워드가 포함되어 있는데 패스워드만 수정을 해야 되는 경우라면 MyBatis 방식에서는 별도의 select 없이 패스워드만 update 를 하면 됐었는데 JPA 에서는 Find 를 통해 객체에 초기셋팅을 한번 한 뒤에 @DynamicUpdate 활용해야 Password 만 변경되는  SQL 을 수행시킬 수가 있는 거 같습니다. 즉, Update 를 위해서는 항상 Select 절이 따라 붙어야 한다는 건데 JPA 장점을 위해 이런 부분은 감수해야 되는 부분이라고 생각해야 되겠죠?? 

영한님 안녕하세요. 강좌들으면서 실무에서 직접 해보고 있는데 풀리지 않는 오류가 하나 등장했습니다. ManyToOne 단방향 맵핑한 영역이 있습니다. (MemberWebUser / MemberCompany) (다만,  PK 가 아닌 Unique 한 다른 필드로 Join 을 설정했고요..) 저장까지는 문제없이 잘 됩니다. (FK 도 원하는 필드로 저장됐구요) 그런데 이후 QueryDsl 로 두 개를 조인해서 Many 쪽의 객체만 가져오는 Select Repository 를 아래와 같이 작성했는데 .... 해당 리파지토리 실행 시점에 ClassCastException : MemberCompany cannot be cast to java.io.Serializle at org.hibernate.type.ManyToOneType.hydate(ManyToOneType.java) 에러가 발생합니다. 원인을 모르겠어요 ㅜ

연관관계 편의 메서드에 이점을 느끼고 있습니다만...이를 이해하는데 있어서 상당히 어려움을 느끼고 있습니다. 상품 주문 시 1. 주문한 member 를 조회2. 주문한 item을 조회3. 주문한 member address를 통해 delivery 생성4. 주문한 item, 가격, 상품수를 인자로 주문상품 생성5. 주문한 member,delivery,orderitem을 인자로 주문생성 주문상품 orderitem은 FK로 item, order를 가지나주문생성에는 orderItem이 필요하기 때문에주문상품 생성 시 order를 인자로 전해주지못하고주문 생성 시 생성된 order를 연관관계 편의메서드를 통해주문상품 order의 빈자리를 채워주고 있습니다. 주문생성 연관관계 편의 메서드를 보면양방향 관계인 member, delivery, orderitem을 모두함께 셋팅해주는데요. 1.member 생성 시 order와는 관계를 맺을 수 없으니연관관계 메서드 필요없음 2. delivery는 주문 생성 시 함꼐 생성되므로 order 또는 delivery에 연관관계 메서드 생성 3. orderitem은 order가 생성되어야 이후에 fk로 셋팅이가능하기 떄문에 order에 연관관계 메서드 생성 일단 이렇게  이해를 하고있는데요. 좀더 명확하게 연관관계 메서드가 위치해야하는곳이어디인가? 라는 물음에 케바케인가 싶기도 하구요.어느부분을 중점으로 봐야할까요?김영한님 책도 있긴한데 참고할 부분이 있을까요? 진짜 양방향은 왠만하면 안쓰는게 맞다는 말이 조금은 이해가 됩니다. 1부 빨리 끝내고 2부 들으러 가야겠습니다 ㅋㅋ 추가로JPA 이후에 계획하고 계신 강의가 있을까요?

entity에는 Setter가 존재하면 안된다는 글을 많이 보았습니다. 때문에 생성자를 통해서만 entity가 만들어지도록 샘플프로젝트를 만들어왔었는데요. 물론  교육이라 setter를 사용하신다고 생각하는데요 실무에서  setter를 entity 내 만들어쓰시는지 생성자를 통해서 해결하시는지 또는 private 처리로 생성 메서드만 노출하는지 궁금합니다. 연관관계 편의 메서드와 생성 메서드 예를 들어주실수 있으실까요? 감사합니다~

전에 1번 완강했었는데다시 반복 강의 들을때 문제생겨서 올립니다. 3시반30분의 삽질끝에..결국 찾아낸 ㅠㅠ저같은 분이 없으시길.. 이러한 에러가 나오실거에요.. [ 사진 크게 보시려면 아래처럼 마우스 오른쪽키 ] [ 새 탭에서 이미지 열기 ] --------------------------------------------------------- 2.1.9버전까지는 잘됬었습니다 그런데 이번에 2.1.10버전이 나왔더군요.. 그걸 모르고 그냥 이전처럼 맨뒤에 버전으로 받아서 했더니.,. 후... 2.1.10버전은 안됩니다.. 2.1.9버전 이하로 하시면 잘됩니다..

1. 실무에서 프로젝트 구현시 보통 폴더 구조를 어떤식으로 하시나요? 프로젝트를 하는데 폴더 구조를 어떻게 해야 좋을지 궁금합니다. 강의와 같이 api 패키지를 하나 만들고 Controller 클래스 안에 static 클래스로 dto를 만드시나요? 아니면 api 패키지 안에서 다시 패키지들로 나누시나요? 2. 별도 강의들에 대한 일정이 혹시 있으신가요? 있으시다면 언제쯤 강의를 들을 수 있을까요? 좋은 강의 올려주셔서 너무 잘 듣고 있습니다. 감사합니다.

컬랙션 패치 조인은 1번만 사용해야한다고 하셨는데 A라는 테이블에 컬렉셕 B, C가 았을때 B,C 를 모두 fetch조인하지 말라는건지 아님 A에 컬렉션B、B테이블에 컬렉션 C가 있을 때 a에서 b를 패치조인하고 b에서 c를 또 패티조인하지 말아야하는건지 궁금합니다

JsonIgnore는 json으로 변환할 때 문제가 발생해서 붙인 것 같은데요 . 그럼 엔터티가 아닌 dto로 변환해서 반환할 때는 양방향관계가 없으니 jsonIgnore를 안붙여도 되는것인다요?

업데이트 후에 쿼리하는 부분에서 실제로 쿼리를 날리지 않는 것은 1차 캐시에서 엔티티를 가져오기 때문인가요? 추가로 꿀강의 정말 감사합니다! ㅎㅎ

안녕하세요 영한님 기다리던 2편도 어제부터 너무 즐겁게 보고 있습니다 항상 좋은 강의 감사드립니다 테스트 코드 작성 중 2가지 질문이 있어 질문 드립니다 기본편 패치조인 한계편 초반에 보면 fetch join 시 별칭을 줄 수 없다고 되어 있습니다 그 이유는 별칭을 준 이후 on 에서 별칭으로 조건을 주면 OneToMany 관계에서 Collection 형태로 조회되는 데이터가 전부 조회되지 않고 일부만 나오기 때문에 문제가 생길 수 있다는 설명도 이해를 했습니다 이 과정에서 2가지 질문이 있습니다 1. 테스트를 해보면 fetch join JPQL에 on 조건을 주면 무조건 에러가 발생합니다 (with-clause not allowed on fetched association)    fetch 조인 시 on 조건을 넣는 것 자체가 안된다고 생각해도 되는 것인가요? Member -> Team @ManyToOne Team -> Member @OneToMany 2. 1번 질문에서 만약 fetch 조인 시 on 조건 자체가 불가능하게 설계 되었다면 Collection의 값이 항상 보장되는 쿼리는 실행이 되어야 하지 않을까 해서 설계상의 원칙인지 제가 놓치고 있는 부분이 있는지 궁금합니다    ex) Select t from Team t join fetch t.member m on m.name=:memberName           (memeber 컬렉션이 전부 조회되지 않기 때문에 실행 불가능 한 것을 이해)    ex) Select t from Team t join fetch t.member m on t.name=:teamName          (Team을 기준으로 조건을 주었기 때문에 member Collection에는 영향이 없어 문제가 없지 않을까? 라고 생각합니다) 3. fetch 조인 시 where문 사용 의견     fetch 조인 시 where 조건은 동작하는 것을 테스트에서 확인했습니다     1) OneToMany 조건에서 where 조건을 Collection이 아닌 조건에만 사용 하는 것     ex) Select t from Team t join fetch t.member m where t.name=:teamName     2) ManyToOne, OneToOne에서 where 조건을 양쪽 모두 사용 하는 것     ex) Select m from Member m join fetch  m.team t where m.name=:memberName            Select m from Member m join fetch  m.team t where t.name=:teamName    위처럼 사용하는 것에 대한 의견 부탁드립니다        그리고 QueryDSL 강의 기다리고 있습니다 ^^