안녕하세요! 좋은 강의 정말 잘 듣고있습니다 감사합니다! 다름이 아니라, 며칠 전 영한님이 찍으신 HTTP 강의를 들었습니다 해당 강의에서 PUT 과 PATCH 사용의 차이점에 대해서도 설명해 주셨는데  결론적으로 Member 리소스의 이름만 변경하는 현재 로직상  PUT 요청보다 PATCH 요청이 HTTP 스팩을 잘 맞춘(?) 설계라고 생각되는데 맞을까요?  또 저는 이렇게 스팩을 정확하게 맞춘 경우에는 (엔티티 데이터 수정시 변경감지를 사용하는 것이 권장되지만) 수정을 할 때 PUT 요청으로 수정이 오는경우, detached 된 엔티티 데이터를 수정하고 merge를 사용하여 업데이트를 하는 방법도 고려할 수 있겠다고 생각했습니다. 그리고 동시에 또 스팩에 너무 발이 묶이는 것도 결국은 비효율적이라는 생각도 들면서 머리가 복잡해지네요 결론적으로, 실무에서는 PUT 과 PATCH 를 HTTP 스팩에 정확히 맞추어 사용하기 보다, PUT으로 통일하여 사용함으로써 개발의 효율을 높이는 경우가 많을까요? 구글링을 하다보니 그런 글들을 본 기억이 있는것 같은데 영한님의 생각도 궁금하네요!  다시 한번 좋은 강의 감사합니다!  :) 

안녕하세요. 좋은 강의 덕분에 업무에 많은 도움이 되고 있습니다.  감사합니다. ^^ 다름이아니라, 강의 예제에 나온 repository에서는 보통 한 종류의 엔터티를 반환하는데요.  예를 들면 OrderRepository 에서는 반환값이 Order, List<Order> ItemRepository에서는 Item, List<Item>을 반환합니다.  하지만 OrderRepository에서 Item, List<Item>을 반환하는 경우는 없더군요. 그런데 여러 테이블간에 조인을 거쳐 최종 조회되는 엔터티가 해당 Repository의 엔터티가 아닌 경우, 이럴 때는 어떻게 하는 게 좋을까요? 예를 들면 엔터티 간의 관계가 아래와 같을 때 Order : OrderItem = 1 : N Item : OrderItem = 1 : N Item : ItemCategory = 1 : N Category : ItemCategory = 1 : N Order Id = 100인 Item의 List<Category>를 조회하고자 하는 경우 OrderRepository에서 각 엔터티들의 조인을 거쳐 List<Category>를 반환하는 게 좋을까요? 아니면 각각의 Repository에서 필요한 엔터티를 반환받아 최종적으로 List<Category>를 찾는 것이 좋은가요? 아니면 제 3의 별도의 Repository를 만드는 것이 좋을까요? 여러개의 테이블을 조인하여 한 번의 쿼리로 데이터를 조회하는 것이 더 성능상 이점이 있을 것 같은데요 반면 Repository에서 서로 다른 유형의 엔터티를 반환해도 유지보수에 문제가 없을지 걱정이 듭니다. 김영한님의 조언 부탁드립니다.

@Entity @DiscriminatorValue("B") @Getter @Setter public class Book extends Item { private String author; private String isbn; public static Book createBook(String name, int price, int stockQuantity, String author, String isbn) { Book book = new Book(); book.setName(name); book.setPrice(price); book.setStockQuantity(stockQuantity); book.setAuthor(author); book.setIsbn(isbn); return book; } } setter들을 최대한 줄이고자 위와 같이 정적 팩토리 메서드를 작성했습니다. 그런데 결국 Book 객체를 만들기 위해선 createBook안에 setter가 필요하게 되더라구요 그래서 setter을 닫으면서 정적 팩토리 메서드를 작성하기 위한 두가지 방법이 생각났는데요 첫 번째는 생성자를 protected으로 만들어놓고 정적 팩토리 메서드에서 setter가 아닌 생성자로 객체를 생성하는 방법이고 두 번째로 setter의 접근 권한을 private으로 설정하여 정적 팩토리 메서드 안에서만 setter을 사용하도록 허가하는 방법입니다. 두 방법 중에 무엇이 더 사용하기 적합한지, 아니면 그 외에 다른 방법엔 어떤 것이 있는지 궁금합니다. /// 추가 강의를 진행하다보니 두 방법 모두 setter의 부재로 변경 감지 방법을 사용하지 못한다는 문제점이 있는 것 같습니다.. 변경 감지 강의에서의 영한님 말씀처럼 setter 대신에 비즈니스 메서드를 만들어서 변경 감지 등의 로직에서 사용하고, 정적 팩토리 메서드에서는 첫 번째 방법처럼 생성자로 객체를 생성하는 방법을 사용하려고 하는데 옳은 방법일까요?

안녕하세요 강사님. 테스트를 실행했을 때 강사님께서는 DDL문이 한 줄마다 줄바꿈되어 나오는데,  저는 한줄로 쭉 연결되어 나옵니다. 사실 별 건 아니지만 가독성이 떨어져서 찾아보기가 약간 힘들게 느껴져서 혹시 설정하는 방법이 있는지 여쭤봅니다 ㅠㅠ 현재 H2 버전을 1.4.199를 깔아 사용하고 있는데 이거때문일까요?

수정하려는 엔티티의 키가 10이라고 했을 때, 1. DB에는 아직 수정 전인 엔티티가 들어있음. 이건 영속. 2. Book book = new Book(); 한 후 BookForm의 정보들로 set해줌. 이건 그냥 함수 내에서 new로 만들었을 뿐이니 JPA가 관리하고 있지 않음. 하지만 이 book의 키값인 10은 디비에 저장되어있음. 그래서 이건 준영속. (즉, 10이란 키값을 갖는 엔티티에 대해 영속 엔티티와 준영속 엔티티가 동시에 존재하는 상황.) 3. 여기서 준영속 엔티티 book의 key값으로 검색하여 영속 엔티티 findItem을 가져오고 값을 덮어씌움.  4. 모든 작업 이후에도 book은 여전히 준영속 엔티티이므로 더이상 사용하지 않는 것이 좋음. + 5. 결국 더티체킹 메서드를 직접 만들든, em.merge()를 사용하든 내부적으로는 전부 더티체킹을 사용하여 update하는 것임. (null 업데이트 문제는 제쳐두고) 이런 흐름이 맞나요? merge의 과정보다도 merge 실행 전에 같은 키값의 영속,준영속이 동시에 존재하는 부분이 맞는지가 더 모르겠고 궁금하네요.  감사합니다!ㅡㅡㅡㅡㅡㅡㅡㅡ19:53에서 맨 윗줄에 '재'한적이다 오타 제보드립니다. ㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡ (추가질문) setter를 경계하라는 말씀을 다시 한 번 해주셨는데요. "change()처럼 엔티티에 변경 메서드를 따로 만들면 추적이 쉽다" 라는 말씀에서 이해가 좀 안 가는 부분이 있습니다. setter로 변경을 하더라도 그 setter명으로 역추적하면 변경지점이 어디인지 알 수 있는 것 아닌가요? 혹시 여러 엔티티에서 같은 이름의 멤버변수를 가지는 경우엔 setter이름도 같아져서 찾기 어렵다는 말씀이신가요?

안녕하세요. 영한님은 강의에서 컬렉션 페치 조인으로는 페이징이 불가능하다고 말씀하셨는데요, 빌드와 실행까지는 어쨌든 되니 불가능하다는 표현은 좀 안맞지 않을까요? 다만, 매우 위험하고 의도한 결과를 못낼 수 있기 때문에 사실상 쓰지 않는 것이 좋다 정도로 이해하는 게 적절한 것 같아서 소견을 말씀드리고 여쭙습니다.  _ _;; 읽어 주셔서 감사합니다.

안녕하세요~~!! 김영한 선생님!!  강의를 듣다가 해결이 되지 않아서 질문 하나 드리겠습니다. <질문> ItemRepository 부분의 save 메소드 안에 Item.getId() == null이 "Operator '==' cannot be applied to 'long', 'null'"오류 메세지가 나옵니다.  항상 좋은 강의로 보답 해주셔서 감사합니다. 코로나 조심하시고 다음 강의 기대하겠습니다.

안녕하세요 선생님! 바쁘신데 이곳저곳 여러번 질문드려 죄송합니다. 강의를 복습하다가 정말 궁금한게 생겨서요.. Request Dto는 인자로 받아야돼서 테스트같은 곳에서 직접 생성해야하 되기 때문에 static으로 선언했고, Response Dto 같은 경우에는 그럴 필요가 없기 때문에 non-static으로 선언했다고 이해했습니다. 그런데 이런 경고가 뜨길래 찾아봤더니  이펙티브 자바에서 메모리 문제나 gc 문제 떄문에 바깥 인스턴스에 접근할 일이 없다면 무조건 static을 붙여서 정적멤버 클래스로 만들라고 되어있습니다. 실제 프로젝트나 실무에서는 reponse dto처럼 외부에서 직접 생성할 일이 없어도 static inner class로 선언해야 될까요? 정말 감사합니다.

@Transact ional의 사용 이유에 대해서는 이해가 되었습니다만,  왜 굳이 Service에서 그 처리를 해주는지 이유를 모르겠습니다. 개인적인 생각으로는 직접적으로 em을 사용하는 Repository에서 해주는 게 더 적절하지 않을까 싶습니다. Service에서 사용해야만 하는 특별한 이유가 있을까요?

안녕하세요 김영한 스승님. JPA를 공부하다가 갑자기 궁금한게 생겨서  질문드립니다. 객체 중심의 테이블 설계와 데이터 중심의 테이블 설계가 차이점이 어떤것인가요? RDB도 객체처럼 테이블을 만들 수 있는데 그러면 굳이 객체중심으로 테이블을 설계할 필요가 없는거 아닌가요? 이 부분이 너무 헷갈려서 질문드렸습니다...

안녕하세요. 강의를 듣던 중 테스트 메소드 접근 제어자에 궁금한점이 생겨서 질문드립니다. [회원 리포지토리 테스트] @Test public void save() { ... } [서비스 테스트] @Test void join() { ... } 이전 회원 리포지토리 테스트 코드에서는 위 코드와 같이 public로 선언했었지만, 이번 강의에서 Create Test 단축키로 생성한 테스트 메소드들은 public가 아닌 default로 선언되었습니다. default로 메소드를 선언했을 때 테스트를 수행하는데 문제가 없었는데 강의 코드에서 public으로 메소드를 선언하는 이유는 무엇인가요?

1) Optional<Member> result = memberRepository.findByName(member.getName()); 2) Member result = memberRepository.findByName(member.getName()).get(); 1. 위 코드에서 2번의 방법보다 1번 같은 사용법을 권장한다고 하셨습니다. 1) memberRepository.findByName(member.getName()) .ifPresent( m -> { throw new IllegalStateException("이미 존재하는 회원입니다."); }); 2) Optional<Member> result = memberRepository.findByName(member.getName()); result.ifPresent( m -> { throw new IllegalStateException("이미 존재하는 회원입니다."); }); 2. 또한 바로 위의 코드에서도 2번의 방법보다 1번의 방법 사용을 권장한다고 말씀하셨습니다. 위 방법들이 권장되는 이유가 궁금합니다. 또 권장되는 Optional 사용법 같은게 따로 문서로 존재하는건가요?

안녕하세요, 공부하다 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); @Testvoid 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를 생략해도 동작하던데 실무에서는 생략을 많이 하나요? 그리고 생략을 한다면 설명을 위해서 작성을 하신건가요?

안녕하세요 강의 정말 재미있게 스프링핵심 원리, JPA 잘 듣고 있습니다.  주문 목록 검색 form 태그에 action 속성이 없는데 submit을 할경우 어떤식으로 작동하는지 이해가 잘 안가여 질문드립니다.

thymeleaf가 URI is not registered가 뜹니다 스프링부트 생성 때 의존성추가 했고 마켓플레이스에서는 thymeleaf를 검색해도 나오지 않는데 무엇을 잘못했을까요?ㅠㅠ 스프링은 2.4.3 자바 11입니다

spring 핵심 원리에서 배웠던 DI, interface를 이용해서 추상화하는 방식이 사용되고 있지않고. 그냥 private final ItemService itemService 이런식으로 진행하고 계시는데 jpa 강의라서 이렇게 간단하게 설계 하시는건가요?? 실무에서 프로젝트 사이즈가 커지다보면  자연스레 추상화하게 되나요?? 질문 자체가 이상했으면 죄송합니다..  

안녕하세요 @Repository가 MemberRepository를 구현한 MemoryMemberRepository에 붙어있는데요 만약  MemberRepository를 구현한 DBMemberRepository라는 클래스가 하나 더있고 여기에도 @Repository가 붙어있다면 MemberService에서는 어떤 Repository를 주입시켜주나요? 읽어주셔서감사합니다.

안녕하세요 강의를 듣던 중 궁금한점이 생겨 질문드리게되었습니다. MemberService에서 @Autowired 를 통해 MemberRepository를 주입시키는 과정에서 MemberRepository가 MemberService 보다 먼저 빈등록이 되어있다면 문제가 없겠지만 MemberRepository가 MemberService  보다 늦게 빈등록이 될경우 문제가 생길것 같은데 어떻게 작동하나요? 즉, 빈등록되는 순서가 궁금합니다. 읽어주셔서 감사합니다