안녕하세요 선생님! 혼자 복습하다가 문득 호기심이 생겨, 상품 서비스의 테스트를 진행해보다 . @SpringBootTestclass ItemServiceTest { @Autowired private ItemService itemService; @Test void 상품_등록() { Book book = new Book(); book.setName("jpa"); book.setPrice(10000); Long itemId = itemService.saveItem(book); Assertions.assertThat(book).isEqualTo(itemService.findOne(itemId)); }} 이렇게 되면 테스트가 실패하는데 그 이유가 객체 타입이 달라서 그런건가요? 테스트 코드의 객체는 Book이고 service 계층에서의 반환형은 Item이라 생각하여 Repository 계층과 Service 계층의 반환형을 모두 Book으로 해도 테스트가 실패합니다. 혹시 이유를 알 수 있을까요?

강사님께서 동영상에서 알려주신거처럼 복사해서 쓰려고 하니 위 캡처처럼 safeTransferFrom 에서 소스 오류가 발생합니다. 혹시 이유를 알수 있을까요? ㅠ

강의 중 통합 테스트도 좋지만 단위테스트가 더좋다고 하셨는데 Service에 대한 테스트 케이스를 작성할 때, 의존성이 있는 각각의 Repository 도  MockRepository를 생성해서 Service 자체만 테스트 하는게 더 좋은 방향일까요?

강의중, 연관관계 편의 메서드는 연관관계의 주인으로 설정된 엔티티에서 형성하는 것이 좋다고 하셨는데 Order 엔티티에 //연관관계 메서드public void setMember(Member member) { this.member = member; member.getOrders().add(this);}public void addOrderItem(OrderItem orderItem) { orderItems.add(orderItem); orderItem.setOrder(this);}public void setDelivery(Delivery delivery) { this.delivery = delivery; delivery.setOrder(this);} 이렇게 메서드를 구성했습니다. 그러나 Order - OrderItem 두 엔티티가 갖는 연관관계에서 주인은 OrderItem입니다. 그렇다면 Order에 .addOrderItem()을 없애고 OrderItem 엔티티에 public void setOrder(Order order){ this.order = order; order.getOrderItems().add(this);} 위와 같은 편의 메소드를 추가하는것이 맞지 않을까 질문합니다!

안녕하세요. 비전공자로써 국비지원 학원을 수료한 취준생입니다. 학원에서 만들었던 프로젝트가 포트폴리오로 내세우기에는 너무나도 부족해서 선생님의 강의를 들으며 프로젝트를 새로 만들 계획입니다. 프로젝트를 만드는 과정에서 무척 궁금한 부분이 생겼는데 바로 '이미지 첨부'에 관한 것입니다. 학원에서 프로젝트를 만들 때는 모르는 부분이 있으면 구글링하고 이것저것 헤딩해보면서 하다보니 그때 사용했던 방법은 Multipart를 통해 이미지를 프로젝트 파일 내에 있는 폴더에 저장하는 방식을 사용했습니다. 하지만 돌이켜 생각해보니 이미지를 많이 사용하는 사이트를 만든다고 했을 때, '프로젝트 파일의 용량이 너무 불어나면 안 좋지 않을까?' 하는 생각이 들었고, 또한, 기왕에 프로젝트 제대로 만들어 볼 거 AWS Free tier를 활용해서 배포까지 해야 취업에 유리하지 않을까 싶어서 배포단계까지 가는 것을 목표로 하고 있는데요. 그렇다고 했을 때, 배포 중인 애플리케이션의 이미지 첨부 기능에 에러사항이 있지는 않을까, 하는 걱정이 앞섭니다. (아직 애플리케션을 배포해 본 경험은 없습니다...) 사실, 구글 클라우드 스토리지라는 것이 있다기에 연동은 해봤지만 제대로 활용해보지는 못했습니다. 필요하다고 하면 다시 제대로 배워 볼 생각입니다. 이하 각설하고 제 질문은, 1. 실무에서 이미지 첨부 기능을 주로 어떤 스토리지 방식에 의존하는지 2. 작은 규모의 프로젝트이지만 이미지가 약 100장(+이미지 첨부 게시판) 정도일 때 어떤 스토리지 방식을 채택하는 것이 좋을지 입니다. 이게 참... 강의 주제에 벗어나는 질문이지만 너무 궁금한 부분이고, 비전공자이다보니 주변에 실무 종사자 분들이 없어서 실례를 무릅쓰고 이런 질문을 올려보게 되었습니다. 혹시라도 다른 실무 종사자 분들의 조언이 또 있다면 감사히 받겠습니다.

안녕하세요 강사님.  강의 보며 많이 배우고 있습니다. 강의 내용대로 쭉 따라가며 진행하고 있는데 회원가입 부분에서  회원가입 제출 누르면 홈으로 리다이렉트가 안되고 403에러와 화이트라벨 페이지로 이동하게 됩니다. create 메서드에 로그를 찍어도 안찍히는걸 보니 해당 post 매핑이 잘못되었나 하여 준비해주신 자료에 있는 소스를 복사해 똑같이 붙여넣기해도 마찬가지네요... 혹시 원인이 무엇일까요..ㅠㅠ

안녕하세요 14:57초 쯤에서 진행하는 테스트에서 에러가 나는데 확인해주실 수 있을까요? 에러메시지는 아래와 같이 나옵니다. Could not write standard input to Gradle Test Executor 3. java.io.IOException: 파이프가 닫히는 중입니다 at java.base/java.io.FileOutputStream.writeBytes(Native Method) at java.base/java.io.FileOutputStream.write(FileOutputStream.java:354) at java.base/java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:81) at java.base/java.io.BufferedOutputStream.flush(BufferedOutputStream.java:142) at org.gradle.process.internal.streams.ExecOutputHandleRunner.forwardContent(ExecOutputHandleRunner.java:68) at org.gradle.process.internal.streams.ExecOutputHandleRunner.run(ExecOutputHandleRunner.java:53) at org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:64) at org.gradle.internal.concurrent.ManagedExecutorImpl$1.run(ManagedExecutorImpl.java:48) at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) at org.gradle.internal.concurrent.ThreadFactoryImpl$ManagedThreadRunnable.run(ThreadFactoryImpl.java:56) at java.base/java.lang.Thread.run(Thread.java:834) > Task :test FAILED Error: Could not find or load main class worker.org.gradle.process.internal.worker.GradleWorkerMain Caused by: java.lang.ClassNotFoundException: worker.org.gradle.process.internal.worker.GradleWorkerMain FAILURE: Build failed with an exception. * What went wrong: Execution failed for task ':test'. > Process 'Gradle Test Executor 3' finished with non-zero exit value 1 * Try: Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. Run with --scan to get full insights. * Get more help at https://help.gradle.org BUILD FAILED in 3s 4 actionable tasks: 1 executed, 3 up-to-date

안녕하세요. 이번 강의 내용에서 추가적인 요구사항을 적용해보는 중, 설계상 궁금증이 생겨 질문하게 되었습니다. jpashop에서는 환불제도 악용 회원의 주문을 일정 기간동안 금지할 수 있다는 요구사항을 추가했습니다. 이 변경된 요구사항을 위해, MemberStatus라는 VO를 Member 클래스에 추가했습니다.  결과적으로, Order 클래스를 생성함에 있어서 MemberStatus의 로직(다른 애그리거트의 Value Object)을 필요로 합니다. 이 때, 선택할 수 있는 생성 방식이 여러개가 떠올라서, 이들의 선택 기준에 대한 조언을 듣고 싶습니다. 첫번째 방식. 정적 팩토리 메서드의 매개변수로 추가 첫번째 방식은 생성시 필요한 정보를 가진 객체(MemberStatus)들을, 정적 팩토리 메서드의 매개변수로 전달합니다. 선택 기준은  객체(Order)를 생성함에 있어서, 특정 객체(MemberStatus)가 필요함을 명시적으로 알릴 수 있습니다. 생성로직을 해당 클래스가 전적으로 제어하는 것이 생성 로직을 한 곳에 더 응집시킬 수 있습니다. 이 두가지를 고려했습니다. 이 방식에서는 회원 차단에 따른동작 분기는 정적 팩토리 메서드 내에서 이루어집니다. 다만, Order를 생성하는데 있어서 MemberStatus 이외에도 협력해야 할 애그리거트들이 많이 존재하는 경우 Order 클래스가 너무 많은 의존성을 가지게 될 수 있다는 점이 우려됩니다. 두번째 방식. 생성을 위한 정보/로직을 가지고 있는 클래스가 생성을 담당 선택 기준은  Member가 Order를 생성하기 위한 로직(회원 차단 여부)을 제공합니다. 위 내용을 고려했습니다. 이 방식에서는 검증 통과 여부에 따른 동작 분기는 Member의 메서드 내에서 이루어집니다. 다만, 이 방식은 Member —> Order로의 불필요한 의존성을 만들어낼 수 있다고 우려했습니다 특히, 생성에 대한 책임을 맡는다는 것은 내부에 어떤 데이터를 가지고 있는지 전부 알아야 한다는 점에서 생각보다 과도한 의존성을 부여하고 있는 것 같습니다. 또한 협력해야 할 애그리거트가 많아질 수록, Member가 생성과 관련된 다른 클래스들에 대한 많은 의존성을 감당해야 한다는 점이 우려됩니다. 세번째 방식. 애그리거트를 생성하는 Domain Service를 만든다. 선택기준은 많은 의존성을 가져야 하는 생성 로직을 서비스에 담음으로서, 엔티티가 불필요한 의존성을 가지는 것을 방지합니다. 위 내용을 고려했습니다. 다만, 조금만 복잡해져도 도메인 서비스를 사용하고자 하는 유혹이 생겨서, 자칫하면 다른 로직들도 Domain Service로 구현해, Entity 자체의 응집성이 작아지는게 아닌가 우려스럽습니다. 질문 내용 정리 1. 각 생성 방식을 선택함에 있어서 미흡한 선택 기준에 대해서 조언 해주 실 수 있나요? 2. 또 첫번째, 두번째 방식이 우려하는 사항들은 현재의 사례에서는 잘 드러나지 않는 '잠정적인' 우려사항들인데, 실제로 이 우려사항들이 나타나기 전까지는 가장 간단한 구현(첫번째 혹은 두번째)을 그대로 사용해도 될까요?

1. id 값이getmapping으로 넘어오는 것도 관계가 궁급합니다. itemList.html에도 특정하게 id값을 넘겨달라 라고 보이는 문구도 없어보이는데 id값만 인자로 지정해서 넘어오는 것도 궁금합니다. 이어지는 부분이 없다고생각하는데 이런건 requestparam으로 받는게 맞지 않을까요? public String updateItemForm(@PathVariable("itemId") Long id, Model model){ Book one = (Book) itemService.findOne(id); 선생님 이부분에서 items/createItemForm 에서 정보를 입력받으면 submit버튼을 누르는 순간 postmapping 으로 값들이 담겨져서 밑의 코드처럼 bookform 형식의 값이담긴 form이 넘어와지게 된다고 하셨는데  booform의 클래스의 필드이름들이 html(createItemForm )태그에  타임리프 문법에 있는 name, id, isbn 등등 필드 이름과 매칭이 돼서 넘어오는줄 알았는데 bookform클래스의 필드 이름이 다르게 바껴도 값이 넘어오더라고요.... 어떻게 매칭이 되고 어떤 관계가 있어서 bookform에 잘 맞춰서 넘어오게되는지 궁금합니다. @PostMapping("/items/new")public String create(BookForm form){ Book book = new Book(); book.setName(form.getName()); book.setPrice(form.getPrice()); book.setStockQuantity(form.getStockQuantity()); book.setAuthor(form.getAuthor()); book.setIsbn(form.getIsbn()); itemService.saveItem(book); return "redirect:/";}

안녕하세요. 기본적으로 게시판을 만들 경우 LOB를 사용하게 됩니다.  그럼 Lazy를 사용하게 되는데  경험상 어떤 구조가 좋은지 알고 싶습니다.  지금까지는 @ElementCollection을 만들어서 Unique를 주어서 one to one 처럼사용을 하였습니다. 자구 눈에 거슬려서 리팩토링을 하고 싶은데 하나의 테이블에서 @Basic를 사용하는 것이 좋은지 아니면 서브 테이블을 만들고 @OneToOne 관계를 사용하는것이 좋은지 노하우를 공유하고 싶습니다. @OneToOne에서는 단방향을 사용하고 싶고 서브 테이블의 PK 컬럼은 PK이면서 FK로 설정하고 싶습니다. (즉, 메인 테이블의 PK값을 사용) 그럼, 수고하세요.

안녕하세요. JPA 강의를 듣고 연관관계부분 실습해보다 질문드립니다. 다대다 관계는 실무에서 사용하지 않는게 좋다고 하셔서 직접 중간테이블을 만들고 카테고리테이블, 카테고리_아이템 테이블, 아이템 테이블을 만들어 아래와 같이 구현해보려 했습니다. 간단히 엔티티 코드를 요약해보았습니다. 카테고리를 눌렀을 때  해당 카테고리에 Item 리스트를 불러오고 각각의 Item들에서도 카테고리 정보를 노출하고싶은데 어떻게 해야 할지 감이 잡히질 않습니다. categoryItem의 Repository에서 쿼리문으로 조인하여 가져오는것은 매우 복잡할것같고 Item이나 Category의 엔티티 안에 메서드를 만들어서 가져와보려했는데 제 기본기가 부족해서 그런지 도저히 방법이 떠오르질 않네요. 어떤식으로 구현을 해야좋을지 대략적인 흐름을 간단히 조언해주시면 감사하겠습니다.

안녕하세요. 좋은 강의 덕분에 업무에 많은 도움이 되고 있습니다.  감사합니다. ^^ 다름이아니라, 강의 예제에 나온 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'"오류 메세지가 나옵니다.  항상 좋은 강의로 보답 해주셔서 감사합니다. 코로나 조심하시고 다음 강의 기대하겠습니다.

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

안녕하세요, 공부하다 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 두 개념에 혼동이 와서... 위 질문에 답변해주시면 감사하겠습니다!

console 창 가져온건데 서버-클라이언트 코드가 달라 변경도 해보았는데 안되서 어떻게 해야할지 모르겠습니다ㅠㅠ 도와주세요ㅜㅜ 서버쪽코드 const request = axios.get(`${USER_SERVER}/auth`) 클라이언트코드 router.get("/auth", auth, (req, res) => {

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