25%
66,000원
다른 수강생들이 자주 물어보는 질문이 궁금하신가요?
- 미해결실전! 스프링 부트와 JPA 활용2 - API 개발과 성능 최적화
OneToMany Many쪽의 페이지네이션 질문입니다
안녕하세요? 섹션 4 강의 컬렉션 조회 페이징을 보고 질문 드립니다. 주문 조회 V3.1에서 페이징을 위해 jpa.properties.hibernate.default_batch_fetch_size=100, @BatchSize를 사용하거나 또는 V5에서 Map, groupBy를 이용하여 DTO 직접 조회Order에 대하여 페이징이 가능하다는 것을 알았습니다. 그런데 만약 Order 페이징 + OrderItem 페이징(예를 들어 주문을 10건 중 비싼 아이템 2건만 조회하기)같은 경우에는 어떻게 적용이 가능한가요? public List<OrderQueryDto> findAllOpt(){ List<OrderQueryDto> result = findOrders(); // 기존의 ToOne 쿼리 List<Long> orderIds = result.stream() // in 쿼리를 위한 id 뽑기 .map(o -> o.getOrderId()) .collect(Collectors.toList()); List<OrderItemQueryDto> orderItems = findMap(orderIds); Map<Long, List<OrderItemQueryDto>> orderItemMap = orderItems.stream() .collect(Collectors.groupingBy(OrderItemQueryDto::getOrderId)); result.forEach(o -> o.setOrderItems(orderItemMap.get(o.getOrderId()))); return result; } public List<OrderItemQueryDto> findMap(List<Long> orderIds) { return em.createQuery( "select new queryDto(파라미터들)" + " from OrderItem oi" + " join oi.item i" + " where oi.order.id in :orderIds", OrderItemQueryDto.class) .setFirstResult(0) .setMaxResults(2) .setParameter("orderIds", orderIds) .getResultList(); ) } 이렇게 Limit를 걸었을 때 UserA 2건 뜨고 UserB는 null 이 뜨더군요. 다른 방법을 찾아본 결과 https://bottom-to-top.tistory.com/45 처럼 방향을 반대로 하여 ManyToOne으로 조회하는 방법도 있다는것을 알았습니다. 결국엔 Order 페이징 + OrderItem 페이징 까지 접목시키려면 ManyToOne으로 조회하는 방법밖에 없을까요?
- 미해결실전! 스프링 부트와 JPA 활용2 - API 개발과 성능 최적화
엔티티가 아닌 DTO로 변환을 할 때 컬렉션 조회를 할 경우 @JsonIgnore가 필요로 하는상태가 생겼습니다.
API 개발 고급 - 컬렉션 조회 최적화에서 주문 조회 V2: 엔티티를 DTO를 변환 수업에서 4:30 에 No properties문제가 발생하여 저도 getter를 넣었으나 다음과 같은 에러가 발생했습니다. 구글링 한 결과 해당 컬렉션이 지연 로딩으로 인해 프록시 객체를 serialize하기 때문에 나는 에러라고 합니다. 그래서 제가 조치한 것은 해당 에러가 발생하는 @OneToMany필드를 @JsonIgnore를 했습니다. 다행히 정상 작동은 했으나 김영한님의 강의에서도 그렇고 제가 개인적으로 하는 프로젝트에서도 단 한번도 Entity에 @JsonIgnore를 사용하지 않았습니다. 단순히 DTO에 getter를 사용했는데 작동이 잘 되었습니다. 어떻게 하면 Entity에 @JsonIgnore를 사용하지 않고 문제를 해결할 수 있을까요?
- 미해결실전! 스프링 부트와 JPA 활용2 - API 개발과 성능 최적화
하이버네이트 모듈과 @JsonIgnore를 굳이 함께 사용할 필요는 없는 걸까요?
하이버네이트 모듈을 사용해서 프록시상태인 객체에 대한 조회를 무시할 수 있다면.. member의 orders에 굳이 @JsonIgnore를 걸어주지 않아도 될 것이라고 생각됩니다.(굳이 order.member. orders에 접근해서 orders에까지 지연로딩을 활성화시킬 일은 없을테니) 그럼 굳이 @JsonIgnore 처리를 해주지 않고 orders : null로 전달되도록 해도 상관이 없나요? 아님 orders:null조차 안 뜨도록 @JsonIgnore도 함께 사용해주는게 좋을까요? 실무에선 어떤식으로 진행하는지 궁금합니다!
- 해결됨실전! 스프링 부트와 JPA 활용2 - API 개발과 성능 최적화
클라이언트단과 서버단의 DTO 공유방식
안녕하세요 영한님! 만약에 실무에서 리액트와 스프링을 이용해서 클라이언트단과 서버단으로 나눠서 운영한다고 가정한다면, 클라이언트단과 서버단은 물리적으로 분리되어 있고 API로 데이터 요청과 응답을 주고받을 것이라 생각합니다. 근데 여기서 API를 주고 받기 위해서 클라이언트와 서버의 API 스펙을 매핑 해야하는데 클라이언트단 따로, 서버단 따로 클래스를 만들어서 관리하는 방식은 유지보수 측면에서 좋지 않다고 생각이 듭니다. 실제 실무에서는 어떤 방식으로 처리하는지 궁금합니다.
- 미해결실전! 스프링 부트와 JPA 활용2 - API 개발과 성능 최적화
강의중 궁금한게 생겼습니다
API스펙에선 엔티티가 아니라 DTO로 바꿔서 보내라 이제 머리에 새겨졌습니다 하지만, API가 아닌, 일단 웹사이트를 만들때도 DTO로 바꿔야하나요? 만약 바꾼다고치면 바꿀때, packge를 이용해서 DTO packge를 만들고 그 안에서 다 해결해수있을까요? 강의 설명을 들어보면 뭔가 바꾸는게 더 좋을 코드 같긴한데 감이안오네요 아직 토이프로젝트도 못해본 학생이라 너무 궁금합니다! ++ 이번에 MVC강의가 나왔던데(이미구매는해놨습니다) 강의 순서를 쿼리dsl까지 다듣고 MVC강의를 듣는게 좋을지 아니면 활용2까지 마져끝내고 MVC강의를 들을지 고민됩니다! 현재( 스프링입문 -> 핵심원리기본편 -> http웹지식 -> 활용1 -> ORM기본편 -> 활용1순서로 들었고 현재는 활용2 듣는중입니다!)
- 미해결실전! 스프링 부트와 JPA 활용2 - API 개발과 성능 최적화
JPA/Spring 동기화 문제와 관련하여 문의드립니다.
안녕하세요. 최근 JPA강의와 Spring boot강의를 연달아 들었는데요, 너무 좋은 강의 감사드립니다. 지금까지 영한님께 배운 내용을 토대로 Spring boot + jpa를 이용하여 사이드 프로젝트를 진행중인데, 동기화 문제와 관련해 문의드리고자 글남깁니다. 제가 문제를 겪은 시나리오는 아래 코드와 같습니다. 이 경우 여러 사용자가 동시에 요청하지 않는 경우에는 문제없이 잘 동작하지만, 동시에 많은 사용자가 접근하게 되는 경우에는 동기화 문제가 발생될 것으로 생각됩니다. ( 어떤 thread가 jpa context에 업데만 해놓고 commit하기전에 다른 스레드에서 쿼리를 통해 데이터를 가지고 온 경우.) 그렇다고 Controller layer에서 단순히 sync 키워드를 사용하게 되면 많은 사용자가 동시에 접근할때, 너무 느려지지 않을까 우려되기도 하는데, 어떤 방식으로 접근하는게 좋을지 조언 여쭙고자 질문드립니다. @Transactional boolean addInformation(Data data) { // 어떤 정보가 현재 DB에 쓰여져 있지 않은 경우에 한해 업데이트. List<Infomation> info infoRepository.findAllWith(data); if (info.size() > 1) return false; /// DB에 없으므로 db update ..... }
- 미해결실전! 스프링 부트와 JPA 활용2 - API 개발과 성능 최적화
DTO의 필요성이 와닿지 않습니다.
안녕하세요 강사님, 질문 드리겠습니다. DTO의 필요성에 대한 부분으로 "엔티티가 변경됐을 때 변경된 사항이 API 스펙에 적용되지 않아 API가 제대로 동작하지 않을 수 있다."라고 말씀해주셨는데요. 이러한 문제가 발생하는 V1에서는 받을 때는 Member, 돌려줄때는 CreateMemberResponse를 사용하고 있습니다. 그런데, 여기서 요청을 때, 응답을 줄 때 모두 Member를 사용해버린다면.. Member가 변경된다 하더라도 Response에서도 변경사항이 적용되기 때문에 문제가 없는 것 아닌가?? 하는 생각이 듭니다. 이 부분에 대한 추가설명을 부탁드리고 싶습니다. 감사합니다! ㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡ 이어지는 강의들을 듣다보니 자연스럽게 이해되었습니다. 이해한 바를 바탕으로 질문에 대한 자답을 해보자면.. ************************************************** DTO를 반드시 사용해야 하는 이유는 다음과 같다. 1. DTO를 사용하지 않을 경우 엔티티의 변경에 의해 API 스펙이 변경될 수 있다. -> 엔티티와 API가 일대일 대응의 관계를 가진다면 엔티티에 수정이 일어날 때마다 API 스펙을 일일히 변경해줘야한다. 이는 매우 번거로운 작업이며 컴파일 에러로 이를 감지할 수 없기 때문에 에러 원인을 찾기가 어렵다. (DTO를 사용하면 DTO -> 엔티티 과정에서 컴파일 에러가 발생되므로 엔티티의 변경사항을 반드시 파악할 수 있다) 2. 하나의 엔티티에 대해서 API는 여러 개가 존재할 수 있다. -> 각각의 API가 요구하는 엔티티에 대한 데이터는 모두 다를 확률이 높다. 이때, 그냥 엔티티의 모든 정보를 넘겨줘버린다면 필요없는 데이터까지 받긴 하지만 필요한 건 전부 받은 셈이니 기능 동작에는 문제가 없을 것이다. 하지만 PW처럼 보안상 감추어야 할 정보까지 모두 JSON으로 함께 넘어가기 때문에 보안 문제가 발생할 수 있다. 엔티티 측에서 컬럼에 @JsonIgnore를 사용해 JSON 전달을 막을 수는 있지만 이는 엔티티가 API 스펙에 의존성을 갖게 되므로 좋지 않다. 유지보수가 복잡해질 뿐 아니라 다른 API에 대해서는 그때그때 또 변경을 해줘야 하는 쓸 데 없는 번거로움이 발생한다. 3. 엔티티를 그대로 넘겨줄 경우, 엔티티가 가진 정보 외의 것들은 넘겨주지 못한다. -> DTO를 사용하면 엔티티의 정보 외에 추가적으로 필요한 정보도 함께 넘겨줄 수 있다. ************************************************** 이 정도가 될 것 같습니다만.. 제가 놓친 내용이 있을까요??
- 해결됨실전! 스프링 부트와 JPA 활용2 - API 개발과 성능 최적화
HTTP PUT, PATCH
안녕하세요! 좋은 강의 정말 잘 듣고있습니다 감사합니다! 다름이 아니라, 며칠 전 영한님이 찍으신 HTTP 강의를 들었습니다 해당 강의에서 PUT 과 PATCH 사용의 차이점에 대해서도 설명해 주셨는데 결론적으로 Member 리소스의 이름만 변경하는 현재 로직상 PUT 요청보다 PATCH 요청이 HTTP 스팩을 잘 맞춘(?) 설계라고 생각되는데 맞을까요? 또 저는 이렇게 스팩을 정확하게 맞춘 경우에는 (엔티티 데이터 수정시 변경감지를 사용하는 것이 권장되지만) 수정을 할 때 PUT 요청으로 수정이 오는경우, detached 된 엔티티 데이터를 수정하고 merge를 사용하여 업데이트를 하는 방법도 고려할 수 있겠다고 생각했습니다. 그리고 동시에 또 스팩에 너무 발이 묶이는 것도 결국은 비효율적이라는 생각도 들면서 머리가 복잡해지네요 결론적으로, 실무에서는 PUT 과 PATCH 를 HTTP 스팩에 정확히 맞추어 사용하기 보다, PUT으로 통일하여 사용함으로써 개발의 효율을 높이는 경우가 많을까요? 구글링을 하다보니 그런 글들을 본 기억이 있는것 같은데 영한님의 생각도 궁금하네요! 다시 한번 좋은 강의 감사합니다! :)
- 해결됨실전! 스프링 부트와 JPA 활용2 - API 개발과 성능 최적화
batch size 와 Limit 질문입니다
안녕하세요 영한님! 강의 재밌고 유익하게 잘 보고 있습니다. 토이 프로젝트를 진행하면서 Batch SIze 와 Limit 에 대한 궁금증이 생겨서 질문 드리게 되었습니다. # 명세 도메인을 대략적으로 설명 드리면 한 명의 사용자는 여러 게시글을 작성할 수 있고 각 게시글에는 여러 개의 댓글이 달릴 수 있습니다. 사용자 (Member) 1 -> 게시글 (Post) N -> 댓글 (Comment) M 제가 뽑고자 하는 데이터는 여러 사용자가 작성한 게시글과 댓글인데, 여기서 페이징을 적용하기 위해 limit 을 사용하려고 합니다. 여러 Member 가 작성한 Post 를 5 개만 뽑고 각 Post 에 달린 Comment 는 3 개만 뽑는 로직을 짜려고 합니다. default_batch_fetch_size 는 1000 으로 설정했습니다. # 질문 1. 먼저 Post 를 5 개 뽑아야 하는데 이런 경우 쿼리 자체에 Limit 을 거는 게 좋을까요? // (1) 직접 순회 List<Member> members = memberRepository.findAll(); // 편의를 위해 findAll 로 했습니다. 실제로는 조건이 있음!! List<Post> posts = members.stream() .map(Member::getPosts) .flatMap(Collection::stream) .limit(5L) .collect(Collectors.toList()); // (2) Repository 메서드의 IN + Limit 쿼리 사용 List<Member> members = memberRepository.findAll(); // 편의를 위해 findAll 로 했습니다. 실제로는 조건이 있음!! List<Post> posts = postRepository.findTop5ByMemberIn(members); (1) 번으로 할 때 배치 사이즈 설정이 적용되어 1 + N 문제는 발생하진 않지만 모든 Post 데이터를 다 끌어오게 됩니다. Fetch Join 도 Limit 쿼리가 제대로 적용되지 않아서 OutOfMemory 발생 위험이 있기 때문에 안쓰는 걸로 알고 있는데 (2) 번으로 하는 게 맞을까요? (2) 번으로 했을 시 우려되는 점은 만약 members 의 사이즈가 1000 이 넘어가면 IN 쿼리의 성능이 굉장히 떨어지지 않을까 걱정됩니다. Limit 를 걸어두었으니 괜찮을지 아니면 개발자가 직접 사이즈를 쪼개서 나누어서 IN 쿼리를 호출해야 할지.. 어느 방법이 맞을까요 2. 1번과 비슷한 질문인데 5 개의 Post 를 순회하면서 3 개의 Comment 씩 뽑으려고 할 때도 @OneToMany 컬렉션을 호출하는 것보다 쿼리를 직접 호출하는게 좋을까요? 1 번 질문의 답에 따라서 조금 다를 것 같은데 만약 쿼리를 직접 호출해야 한다면 Post -> Dto 구하는 과정에 넣지 말고 Service 에서 쿼리를 호출한 후 직접 넣어줘야 할까요? public class PostDto { // ... 자잘한 field 생략 public static PostDto of(Post post) { return PostDto.builder() .comment(post.getComments().stream().limit(3L)...) .build(); } } 현재는 위와 같이 Post Entity 만을 넘겨줘서 Dto 로 변환시켜 주고 있는데 만약 쿼리를 직접 호출하는게 좋다면 Service 로 옮겨서 작성하는지 아니면 BatchSize 와 Limit 을 동시에 사용하는 꿀팁이 있는지 궁금합니다 ! 3. 마지막으로 위의 Post, Comment 와 같이 데이터가 무한히 많아질 가능성이 있는 테이블을 다룰 때는 Batch Size 가 아닌 다른 방법을 사용하기도 할까요?
- 미해결실전! 스프링 부트와 JPA 활용2 - API 개발과 성능 최적화
OrderItem 지연로딩 쿼리
안녕하세요 선생님. 강의에서 궁금한 점이 생겨서 질문드립니다. List<OrderDto> orders = orderRepository.findALlWithMemberDelivery(offset, limit) .stream().map(o -> new OrderDto(o)).collect(toList()); 멤버와 딜리버리가 페치조인된 첫번째 쿼리가 나가고 지연로딩으로 OrderItem을 조회하는 쿼리에서 select orderitems0_.order_id as order_id5_5_0_, orderitems0_.order_item_id as order_it1_5_0_, orderitems0_.order_item_id as order_it1_5_1_, orderitems0_.count as count2_5_1_, orderitems0_.item_id as item_id4_5_1_, orderitems0_.order_id as order_id5_5_1_, orderitems0_.order_price as order_pr3_5_1_ from order_item orderitems0_ where orderitems0_.order_id=? order_id와 order_item_id가 select문에 두번씩 조회되는데 왜 그런지 생각해봐도 이유를 모르겠네요ㅜㅜ 감사합니다!!
- 미해결실전! 스프링 부트와 JPA 활용2 - API 개발과 성능 최적화
중복컬럼 질문
안녕하세요 강사님, 주문조회 V2 : 엔티티를 DTO로 변환 강의 동영상에서 14분17초에 orderitems에 대한 셀렉트문이 나가고 있는데, 잘 보면 order_item_id 라는 똑같은 id 컬럼에 대해서 앨리어스만 다르게해서 조회하고 있는게 보이는데 왜 같은 컬럼을 두개나 적어서 조회가 되는지 궁금합니다.
- 미해결실전! 스프링 부트와 JPA 활용2 - API 개발과 성능 최적화
스프링MVC 강의를 먼저 듣고 오는 게 맞을까요?
안녕하세요 강사님, 학습 방향에 대해 질문을 드리고 싶습니다. 우선 저는 지금까지 강사님의 스프링 입문, 기본, HTTP, JPA 이론, 실전1편의 수강을 마친 상황입니다. 강의를 듣기 전에는 스프링MVC를 사용한 CRUD를 경험해본 적이 있었고 지금까지의 강의들을 수강하며 크게 이해하지 못하겠는 부분은 없었습니다. 그런데 이번 활용2편에 들어오고나니 이전과는 확실히 달라짐을 느꼈습니다. 강의에서 당연하다는 듯이 말씀하시는 API 통신이 무엇인지 모르겠고 활용1편에서처럼 form태그로 요청을 받아 처리하는 방식과 어떤 차이가 있는지? 왜 그렇게 하는지? CreateMemberResponse라는 inner클래스는 왜 만들었고 왜 저걸 반환해주는건지? 를 전혀 모르겠습니다. 또한 당연하게 사용하시는 postman이란 툴의 사용 목적과 방법 또한 전혀 모르겠습니다. 아마 제가 기본적인 부분이 많이 부족한 것 같습니다. 이런 상태로 활용2편 수강을 이어나가도 괜찮을까요? 아직 1강도 다 듣지 않았지만 이대로 계속 들으면서 따라치기만 한다면 시간 낭비만 하는 꼴이 되지 않을까 걱정됩니다. 저의 원래 계획은 JPA활용2편 -> 스프링데이터JPA -> 쿼리DSL -> 스프링MVC1편 이었습니다. 그런데 상황이 이렇다보니 JPA 로드맵은 잠시 멈춰두고 스프링MVC를 먼저 학습하는 것이 옳은 선택이 아닐지 심히 고민이 됩니다.(스프링MVC 강의의 커리큘럼을 보니 스프링MVC도 스프링MVC지만 기본적인 백엔드 개발에 관한 지식도 많이 포함된 것 같아서요.) 이에 대해 강사님의 조언을 구하고자 합니다. 혹시 그대로 JPA로드맵을 강행해도 괜찮다고 생각하신다면 위와 같은 저의 상황에서 활용2편을 수강하기 전에 간단하게나마 따로 학습해야할 것들에 대한 키워드를 부탁드리고 싶습니다. 주절주절 적다보니 질문이 너무 길어져서 죄송합니다. 감사합니다.
- 해결됨실전! 스프링 부트와 JPA 활용2 - API 개발과 성능 최적화
일대N 컬렉션 페치 조인시의 페이징이 '불가능'?
안녕하세요. 영한님은 강의에서 컬렉션 페치 조인으로는 페이징이 불가능하다고 말씀하셨는데요, 빌드와 실행까지는 어쨌든 되니 불가능하다는 표현은 좀 안맞지 않을까요? 다만, 매우 위험하고 의도한 결과를 못낼 수 있기 때문에 사실상 쓰지 않는 것이 좋다 정도로 이해하는 게 적절한 것 같아서 소견을 말씀드리고 여쭙습니다. _ _;; 읽어 주셔서 감사합니다.
- 해결됨실전! 스프링 부트와 JPA 활용2 - API 개발과 성능 최적화
내부 클래스 질문
안녕하세요 선생님! 바쁘신데 이곳저곳 여러번 질문드려 죄송합니다. 강의를 복습하다가 정말 궁금한게 생겨서요.. Request Dto는 인자로 받아야돼서 테스트같은 곳에서 직접 생성해야하 되기 때문에 static으로 선언했고, Response Dto 같은 경우에는 그럴 필요가 없기 때문에 non-static으로 선언했다고 이해했습니다. 그런데 이런 경고가 뜨길래 찾아봤더니 이펙티브 자바에서 메모리 문제나 gc 문제 떄문에 바깥 인스턴스에 접근할 일이 없다면 무조건 static을 붙여서 정적멤버 클래스로 만들라고 되어있습니다. 실제 프로젝트나 실무에서는 reponse dto처럼 외부에서 직접 생성할 일이 없어도 static inner class로 선언해야 될까요? 정말 감사합니다.
- 미해결실전! 스프링 부트와 JPA 활용2 - API 개발과 성능 최적화
디자인 패턴
선생님 강의 잘 듣고 있습니다. 제가 이 강의를 들으며 API 서버를 만들었는데 만들고 보니 이게 어떤 디자인 패턴을 사용한 건지 의문이 듭니다. MVC패턴을 사용한 것 같긴 한데 API서버이다 보니 V 부분은 클라이언트가 안드로이드로 만들어 저는 작성한 바가 없습니다. 그래서 이게 MVC 디자인 패턴을 사용한게 맞는지 의문이 드는데 MVC패턴이 맞나요?
- 미해결실전! 스프링 부트와 JPA 활용2 - API 개발과 성능 최적화
안녕하세요!! dto class에 관한 질문입니다
안녕하세요 jpa 관련 강의들을 모두 듣고 프로젝트에 적용을 해보고 있습니다!! 프로젝트에 적용하던 도중 dto 클래스가 엄청 많아지는 것을 보고 질문하게 되었습니다. api를 개발할 때 하나의 엔티티에 생성,수정 등의 여러가지 requestdto를 만들고 이에 대한 여러가지 responsedto를 만들었습니다. 프로젝트를 계속 진행하면 하나의 엔티티에 수많은 dto class 들이 생겨나는 데 이렇게 하는 것이 맞는 것인지 궁금합니다!!
- 미해결실전! 스프링 부트와 JPA 활용2 - API 개발과 성능 최적화
v3하면서 오류가나서 질문 올립니다 ㅠㅠ
강의들으면서 똑같이 코딩하였는데 요청을 보내면 에러가 뜨면서 저렇게 반환됩니다 어떤게 문제인지 잘 모르겠습니다 ㅠㅠ
- 미해결실전! 스프링 부트와 JPA 활용2 - API 개발과 성능 최적화
상속관계에서 Item 대신 자식엔티티를 사용하는 경우 질문입니다.
안녕하세요 강사님 먼저 정말 좋은 강의 정말 정말 감사합니다. 덕분에 회사에서 일할맛이 납니다ㅠㅠ 강의를 다듣고 혼자서 복습해보다가 문득 생각나서 질문드립니다. 혹시 먼저 질문한 사람이 있을까해서 찾아봤는데 없어서 질문드립니다. Single Table 상속관계에서 강의에서는 부모 엔티티인 Item를 바로 가져오셨는데, 만약 자식인 Book, Album 등을 Dto로 조회할 때는 자식 타입으로 다운 캐스팅해야 되는 것인가요? Item 객체에서는 Album의 artist, etc를 가져올 방법이 없는 것 같아서요 class AlbumDto { private String artist; private String etc; setArtist(Item item) { this.artist = (Album) item.getArtist(); } } 아니면 DType을 조건으로 해서 직접 Album, Book을 직접 가져오는지 궁금합니다. 둘다 아니라면 각 자식 엔티티 별로 Repository를 생성하여 데이터를 반환하는지 궁금합니다. 마지막으로 데이터베이스의 Item들을 모두 가져오고 싶으면 각 행의 결과에 따라 모두 자식 엔티티로 형 변환을 해줘야 되는지 궁금합니다.
- 미해결실전! 스프링 부트와 JPA 활용2 - API 개발과 성능 최적화
혼자 개발하면서 인텔리제이가 소스가 자꾸 생략되어요..ㅠ어떻게하면 좋을까요?
안녕하세요! 영한님! jpa 수업을 들으며 혼자 조금씩 공부를 하고 있는데요. 소스 코드가 매번 프로젝트를 열때마다 생략되어서 마우스를 올리면 위에처럼 코드 미리보기가 가능하구요. 클릭해야지만 소스코드가 풀리는 현상이 좀 있는데,, 이걸 어떻게 하면 풀 수 있을까요?
- 미해결실전! 스프링 부트와 JPA 활용2 - API 개발과 성능 최적화
OSIV끈 상태에서 질문 있습니다!!
OSIV 끈 상태라면 controller -> OrderQueryService -> OrderService 이런 식으로 진행이 되는 건가요?