안녕하세요, 공부하다 cascade 옵션과 변경 감지에 혼동되는 점이 있어 질문 드립니다. 주문 생성 메서드(order)의 경우, Order -> OrderItem / Order -> Delivery가 Cascade 설정이 되어 있어 orderRepository.save(order)만 하더라도 연관된 OrderItem과 Delivery가 각각 Insert된다고 이해했습니다.(remove, detach 등등 모두 동일) 주문 취소 메서드(cancelOrder)를 보면 orderId를 통해 order를 조회하고(조회된 order는 영속 상태), order.cancel()시 orderItem.cancel()과 그 안의 item.addStock()을 통해 변경감지가 되어 order와 item의 update 쿼리가 실행된다고 하셨습니다. 여기서 제가 헷갈리는 부분은 주문 취소시 item이 변경감지가 되어 update쿼리가 실행되는 부분인데요. item.addStock()을 통해 item의 update 쿼리가 실행됐다는 것은 item이 영속성 컨텍스트에 영속상태가 되었다는 것을 뜻하는데, 단순히 order를 orderRepository로 조회를 하게 되면 order와 연관된 모든 엔티티들이 영속상태가 되는 것인가요? (order 한 개 조회 시-> orderItem... 영속-> item... 영속) 위의 과정이 맞다면 연관된 여러 엔티티의 변경감지는 cascade 설정과는 무관하게 엔티티 조회 시 관련된 엔티티는 모두 영속화 되는 것인지 궁금합니다. (order -> orderItem -> item 의 변경감지를 위해 order->orderItem cascade.ALL 설정 & orderItem->item cascade.ALL 설정이 되어야 orderRepository를 통해 order 조회 시 하위 엔티티들이 모두 영속화 되는 것인가?) 만일 연관관계가 있는 엔티티들이 cascade설정이 되어있어야 모두 영속성 상태로 변하는 것이라면 order->orderItem에는 cascade.ALL 설정이 있으나 orderitem->item에는 cascade.ALL 설정이 없는데 order -> orderItem -> item 순으로 변경감지가 되는지 궁금합니다. 질문이 좀 길어졌는데요 변경감지와 cascade 두 개념에 혼동이 와서... 위 질문에 답변해주시면 감사하겠습니다!
안녕하세요 선생님! 강의를 듣다가 궁금한게 생겨 몇 가지 질문드립니다. 1. @Query를 이용해서 jpql 페치조인을 한 경우, 페이징을 하려할때 다음과 같은 에러가 뜹니다. @Query("select m from Member m join fetch m.team") Page<Member> findFetchJoinTeam(Pageable pageable); @Test void member (){ Team teamA = teamRepository .save( new Team( "teamA" )) ; memberRepository .save( new Member( "member1" , 40 , teamA)) ; memberRepository .save( new Member( "member2" , 40 , teamA)) ; memberRepository .save( new Member( "member3" , 40 , teamA)) ; PageRequest pageRequest = PageRequest. of ( 0 , 3 , Sort. by (Sort.Direction. DESC , "username" )) ; Page<Member> fetchJoinTeam = memberRepository .findFetchJoinTeam(pageRequest) ; } Failed to load ApplicationContext java.lang.IllegalStateException: Failed to load ApplicationContext Caused by: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'memberRepository' defined in com.example.forq.MemberRepository defined in @EnableJpaRepositories declared on JpaRepositoriesRegistrar.EnableJpaRepositoriesConfiguration: Invocation of init method failed; nested exception is java.lang.IllegalArgumentException: Count query validation failed for method public abstract org.springframework.data.domain.Page com.example.forq.MemberRepository.findFetchJoinTeam(org.springframework.data.domain.Pageable)! paging에서 count 부분이 문제인것 같은데 entitygraph로 하면 잘 돼서 제가 뭔가를 놓친건지 궁금합니다 public interface MemberRepository extends JpaRepository<Member , Long> { @Override @EntityGraph (attributePaths = { "team" }) Page<Member> findAll (Pageable pageable) ; } 2. where 등으로 필터링을 하지 않을떄는 countQuery를 분리해서 최적화를 하면된다고 하셨는데 만약 select m from Member m join m.team t where t.name=:name ”같이 조인 대상에 필터링을 하는 경우에는 어떻게 최적화를 할 수 있는지 궁금합니다. 감사합니다!
안녕하세요 ^^ 항상 강의 감사하게 듣고 있습니다! @Autowired public MemberController(MemberServcie service) {} 생성자 방식으로 주입할때 생성자 함수위에 autorwired를 생략해도 동작하던데 실무에서는 생략을 많이 하나요? 그리고 생략을 한다면 설명을 위해서 작성을 하신건가요?
spring 핵심 원리에서 배웠던 DI, interface를 이용해서 추상화하는 방식이 사용되고 있지않고. 그냥 private final ItemService itemService 이런식으로 진행하고 계시는데 jpa 강의라서 이렇게 간단하게 설계 하시는건가요?? 실무에서 프로젝트 사이즈가 커지다보면 자연스레 추상화하게 되나요?? 질문 자체가 이상했으면 죄송합니다..
안녕하세요 강의를 듣던 중 궁금한점이 생겨 질문드리게되었습니다. MemberService에서 @Autowired 를 통해 MemberRepository를 주입시키는 과정에서 MemberRepository가 MemberService 보다 먼저 빈등록이 되어있다면 문제가 없겠지만 MemberRepository가 MemberService 보다 늦게 빈등록이 될경우 문제가 생길것 같은데 어떻게 작동하나요? 즉, 빈등록되는 순서가 궁금합니다. 읽어주셔서 감사합니다
안녕하세요 영한님. 항상 좋은강의 보면서 이미 완강을 하였지만 궁금한점이 이 강의내용에 해당되는것 같아 질문을 남깁니다. 컨트롤러에서 (API) 개발을 할때 Entity를 바로 접근하지 말고 DTO를 권장하셔서 DTO를 사용하던 찰나에 문제가 생겼습니다. Entity에 Setter를 사용하는건 지양한다고 하셔서 생성자로 값을 넣어주고 있는데 DTO에서도 값을 생성자로 넣어줘야 하나요? 백을 먼저 개발하고 프론트를 개발하기위해 타임리프로 하고 있는데 DTO 를 생성자로 만들어 놓으니 값을 계속 못받아와서요. 한참 헤매다가 설마 하고 LOMBOK @Setter 로 하니 값이 넘어오더라고요. DTO는 Setter로 하여도 문제가 없을까요? 제 생각에도 DTO는 단순 값을 전달 받는 Form(?)이라고 생각되어 Entity에서의 Setter를 지양해야하는 문제에 와는 달리 큰 영향은 없을 것 같아서요. 감사합니다.!
안녕하세요 강사님. http, 스프링, jpa 모두 강사님 수업을 듣고 인생 첫 스프링 프로젝트로 게시판 API를 구현 해 보려고 하는 대학생입니다. 그래서 현재 아래와 같이 요청경로와 요청법, 응답 본문, 에러응답 등을 문서화 하고 있습니다. 경로를 올바르게 설계했는지는 잘 모르겠지만, 게시글 정보 반환시 게시글과 댓글관계에 대해 궁금해서 질문 드립니다. GET /boards/{board-id}/posts/{post-id} 으로 요청시 게시글의 작성자id, 제목, 내용등이 반환되는데, 댓글들의 목록도 포함시킬지 고민입니다. 보통 게시글이 댓글을 가지고 있으니깐 처음에는 댓글 요청경로를 빼고 게시글 요청에 당연히 포함시켜야 하지 않나? 생각을 했습니다. 그런데 댓글에 페이징 기능까지 넣으려고 생각하니깐 게시글과 댓글을 분리해서 게시글정보와 댓글 정보를 각각 받아오도록 하는게 좋을 것 같다는 생각이 들었는데, 혹시 현업에서도 댓글과 게시글은 분리해서 각각 따로 가져오게 설계를 하는지 궁금합니다. 추가적으로, 이건 강사님의 HTTP수업과 관련된 질문이긴한데 게시글,유저 등록같은 POST /boards/{id}/posts 의 201 응답 Location 헤더에 생성된 자원의 주소(예를들어 http://localhost:8080/boards/1/posts/1)가 어차피 포함되어 오는데, 응답 본문에 생성된 자원(게시글)을 다시 보내주는게 RESTful API에 더 가까운가요? 생각해보면 생성된 자원의 위치를 어차피 알려주는데 의미없는 오버헤드인 것 같더라구요.
안녕하세요! 강의 너무 잘 보고 있습니다. 스프링 혼자 공부해보려다가 넘 어려워서 안하게 됬는데, 흥미롭게 진행해주시는 강의듣고 조금씩 알아가는 것 같아 스스로도 기쁘고 감사합니다.ㅎㅎ 질문1 [스프링 빈과 의존관계]-[자바 코드로 직접 스프링 빈 등록 하기] 강의 7분 26초 에서 setter 주입 방식의 단점으로 ... 어플리케이션 로딩 시점에 한번 세팅되고 나면 이 멤버변수는 바꿀 일이 없는데 public으로 노출되게 된다는 점이 단점이라고 설명해주셨습니다. 그런데 6분 0초 필드 주입방식을 설명해주실 때 단점으로... 스프링이 시작될 때, 초기에만 설정되고 개발자가 동적으로 바꿀 수 없어서 추천하지 않는 방식이라고 설명해주셨는데요! 질문은! 어플리케이션 로딩 시점에 한번만 세팅되면 되는 거면, 필드 주입방식에서 초기만 설정되고 나중에 바꿀 수 없다는 점이 왜 단점이 되는 건지 이해가 잘 안됩니다! 한번 더 단점을 정리해주실 수 있을까요? 질문2 [스프링 빈과 의존관계]-[자바 코드로 직접 스프링 빈 등록 하기] 강의 2분 40초 에서 memberRepository() 메소드 반환형을 왜 MemoryMemberRepository 타입으로 하지 않고, 인터페이스 타입으로 하신 건지 궁금합니다. + 11분 25초 부분까지 강의를 들으니 알겠네요. ^^상황에 따라 다른 데이터베이스를 연결하는 내용의 리포지토리를 연결할 때, 서비스나 컨트롤러 코드를 변경하지 않고, 아래 파일에서 new 하는 객체만 원하는 리포지토리로 바꿔주면 되니까 그런거군요! package hello.hellospring.service ; import hello.hellospring.repository.MemberRepository ; import hello.hellospring.repository.MemoryMemberRepository ; import org.springframework.context.annotation.Bean ; import org.springframework.context.annotation.Configuration ; @Configuration public class SpringConfig { // @Bean : spring bean 을 등록할 거라는 의미 @Bean public MemberService memberService (){ return new MemberService ( memberRepository ()); } @Bean public MemberRepository memberRepository (){ return new MemoryMemberRepository (); } } 질문3 : 컴포넌트스캔방시과 직접자바설정방식 차이 잘 이해한건지 확인부탁드립니다. 컴포넌트 스캔방식 : 스프링은 @Controller, @Service, @Repository 어노테이션이 붙은 것들을 빈으로 등록해 관리한다. @Autowired로 각 빈들을 연결해준다. 직접자바설정 방식 : @Configuration과 @bean으로 스프링에 빈을 등록한다. @Autowired로 각 빈들을 연결해준다. 그런데, 이 강의에서 직접 자바 config를 만들때, @Service, @Repository, @Autowired는 지웠는데, @Controller 은 지우지 않았습니다. 이유가 무엇인가요?
저는 기존에 spring과 mybatis를 사용하다 강의를 듣게되어서 service와 mapper의 역할이 딱 나뉘어진 코드에 익숙했는데 엔티티에 로직이 들어가니 조금 당황스럽네요 ㅎㅎㅎ... 각설하고 다른 질문들을 보았지만 명쾌하게 이해되지는 않아서 강의 내용과 제가 생각한 내용들로 이해해봤는데 맞는지 확신이 안서서 질문드려요 1. 회원 파트와 주문파트의 엔티티 구성방식이 다른 것(생성메서드,비즈니스 로직등의 유무) 은 회원은 기능구현시 타 엔티티와 상호작용하는 부분이 없어 간단한 구현이라는 판단아래에 별 로직이 없고 주문파트는 상호작용하는 부분(주문 취소시 수량 복구, 주문이라는 행위시 연관되는 엔티티정보들) 이 있기에 많은 로직이 있다는 걸로 받아들이면 될까요? 2. 주문 취소의 경우 서비스 부분에 들어가는게 맞다고 생각했는데 엔티티에 구현하셔서 질문들을 찾아보니 취소가 되기 위해선 주문엔티티의 배달상태의 정보가 바뀌고,수량 복구가 되어야하고 해당하는 정보들이 가장 가까운 Order와 OrderItem엔티티에서 로직을 수행한다는 말씀이시고 이게 객체지향 스럽다? 라고 이해하면 될까요?
JPA 기본편 강의와 같이 듣고 있습니다. 좋은 강의 항상 감사드립니다. (질문 도중 제가 잘못 이해 하고 있는 부분이 있다면 말씀주시기 바랍니다.) 다름 아니라 EntityManager는 요청이 들어올 때 생성되어 사용됬다가 해당 요청이 마무리 되면 삭제된다고 이해 하고 있습니다. 근데 @Repository 를 DI를 통해 생성할 때 @RequiredArgsConstructor 를 통해 EntityManager도 생성해줍니다. 그럼 이 EntityManager 인스턴스는 @RequiredArgsConstructor 위 어노테이션으로 인해 필요할 때 마다 그 때 그 때 생성된다고 볼 수 있을까요? 아니면 싱글톤 객체 안에 필드임으로 그 때 그 때 새로운 값을 할당 받는건가요? 감사합니다, 좋은 하루 되세요~
안녕하세요? 강사님. 항상 강의 잘듣고 있습니다. 다름이 아니라, 이전에 알려주신 내용에서 밑에 처럼 dto로 조회 할때는 new 오퍼레이션을 사용하셨는데, @Query ( "select new study.datajpa.repository.MemberDto(m.id, m.username, t.name) " + "from Member m join m.team t" ) List<MemberDto> findMemberDto () ; 왜 밑(네이티브 쿼리)에서는 dto 를 조회 할때 new 오퍼레이션을 사용을 안하셨나요..? @Query (value = "SELECT m.member_id as id, m.username, t.name as teamName " + "FROM member m left join team t" , countQuery = "SELECT count(*) from member" , nativeQuery = true ) Page<MemberProjection> findByNativeProjection (Pageable pageable) ; 항상 좋은 강의와 답변 감사드립니다!!^^
