안녕하세요 현영님. 에러는 해결을 한 상태인데 궁금한 점이 생겨 질문드립니다. const fs = require ( ' fs ' ); 백쪽에 fs모듈을 쓰면서 부터 시작됐는데, 강의 마지막 부분에 와서 프론트 서버를 새로고침하니 저런 에러가 발생했습니다. 스택오버플로우를 찾아보니, https://github.com/vercel/next.js/issues/7755 프론트쪽에 next.config.js라는 폴더를 생성한 후 module . exports = { webpack : ( config , { isServer } ) => { // Fixes npm packages that depend on `fs` module if ( ! isServer ) { config . node = { fs : 'empty' } } return config } } 이런식으로 넣어주라는데, 프론트 서버에서는 fs모듈에 관련된 작업을 한 게 없어 여러가지 테스트를 하다가, 프론트 폴더의 .eslintrc파일에 extends를 airbnb가 아닌 주석처리된 부분으로 바꾸니 또 해결이 되었습니다. (다른 프론트나 백쪽의 코드는 수정이 없었습니다) 1. 혹시 extends랑 상관이 있는건지? 아니면 그냥 일시적인 에러라고 생각을 하면 될까요? 2. 관련이 없다고 하면 혹시나 알 수 없는 에러가 나올 경우 현영님의 경우 어떻게 대처를 하시나요? (에러가 생길 때마다 기록을 해두는 편인데 생각보다 찾기가 힘든? 에러들이 종종 나오더라고요.. 짬의 차인지..?) ++ 어제 업데이트 하신 정보들 확인했습니다. 바로바로 업데이트 해주셔서 불편함이 없네요 감사합니다
안녕하세요 강의 잘 듣고 있습니다. 중간에 조회 API 개발의 내용 중 QMemberTeamDto를 조회하는 메소드로 컨트롤러를 통해 응답을 주는 컨트롤러를 작성하는 내용이 있는데요 같은 내용의 Test는 통과하였으나 포스트맨에서 요청을 할 때는 NoClassDefFound 에러가 발생합니다 build가 되지 않았나? 해서 gradle로 clean compileJava compileQuerydsl 모두 실행하고 해봐도 같은 결과입니다 빌드된 결과 에러 내용
안녕하세요 선생님 JPA Repository에서 save메서드 호출 이후 바로 user id를 가지고 올 수 있는 이유가 너무 궁금하여 질문글을 올렸습니다. User entity를 생성한 후 아래와 같이 테스트를 진행해 보았습니다. 아래는 저의 테스트코드입니다. user 객체를 생성, user 객체에서 id 확인 db에 들어가기 전이기 때문에 id가 당연히 없을 것으로 예상 user 객체를 저장 user 객체에서 id 확인, db에서 다시 조회를 하지 않았기 때문에 id가 없을 것으로 예상하였지만 id가 존재 아래와 같은 결과를 얻을 수 있었습니다. JPARepository의 save method는 아래와 같았습니다. 1. save를 했을 때 바로 insert query 발생하는 이유 -> save 메서드를 살펴보면 @Transactional annotation이 존재하고, save 메서드 종료시 em.flush 발생으로 인해 바로 query가 발생하는 것으로 생각함. 2. user.getId를 받아올 수 있는 이유는 뭘까 user.getId를 받아올 수 있는 경우는 db에 저장을 완료하고, db에 있는 user 정보를 다시 조회했을 때 받아올 것이라고 생각한 것과 달리, save 메서드를 실행하자마자 db 저장 내용이 바로 반영이 된 것을 확인할 수 있었습니다. 따로 select query문이 발생하지 않은 것으로 보아, db 조회는 없었다는 것을 알 수 있습니다. persistcontext와 dirty check에 의해서 이러한 현상이 발생한 것이라고 추측은 하고 있습니다만 이게 어떻게 가능한 일인지 궁금합니다. 제 User entity는 아래와 같습니다. id의 생성시점은 user entity를 db에 저장하는 시점에 생성되는 것이라고 생각하는데, (쓰기 지연 SQL 저장소에서 flush 이후에 id값이 생성될 것이라고 생각함) 생성 이후에는 db에서 user를 다시 가져오고 있지 않습니다. 변경감지로 user id가 생성된 것인지, JPA repositoy에서 save 메서드 이후에 entity를 return 해 주기 때문인지 궁금합니다. 3. EntityManager의 생명주기는 Transactional의 생명주기와 동일하며, PersistContext의 생명주기는 EntityManagerFactory의 생명주기와 동일하게 Application loading 시점과 WAS가 종료되는 시점에 생성과 사멸을 한다고 볼 수 있는 것일까요? 4. 위와 동일한 맥락으로 저의 테스트 코드에서의 영속성 컨텍스트와 JPA Repository의 save 메서드 내의 영속성 컨텍스트는 동일한 영속성 컨텍스트라고 보면 될까요?
안녕하세요 영한님. 올려주신 spring 강의부터 jpa까지 거의 다 듣고 배운것을 활용해서 토이 프로젝트 만들고 있습니다. web api 설계시에 궁금한것이 있어 문의드립니다. 만약 parents 있고 children이 존재합니다. parent와 children은 1대N 관계입니다. 제가 처음 백엔드 api 설계했을때 아래처럼 설계했습니다. POST /parents : parents 리소스가 생성됩니다. POST /parents/{id}/children : parent와 연관된 children 이 생성됩니다. 설계를 마치고 프론트엔드에서 해당 api를 이용해서 등록하려했습니다. 여기서 궁금한것이 생겼습니다. 아래 두 방식중 어떤것이 좋은것인지 잘모르겠습니다. 1. 프론트에서 한번의 Post 요청으로 parents와 childrens list를 모두 생성합니다. request body 예시: { parent: "..." children:[ "...", "..." ] } 백엔드에서 parent정보로 parent 리소스를 만들고 만들어진 parent의 id와 body에 있는 children 리스트로 children 리소스를 생성합니다. 2. 프론트에서 POST /parent와 POST /parent/{id}/children을 각각 요청합니다. 먼저 POST /parents 요청을 보내고 응답값에서 parents id를 받아 children 갯수만큼 POST /parents/{id}/childrens 요청을 합니다.(이럴경우 요청수는 1+N이 겠네요). 1번과 2번 방식중에 어떤 방법이 나은지 잘 모르겠습니다. 제가 생각한 각각의 장단점입니다. 1번의 장점 : 하나의 요청에 모든 정보가 들어있어 요청 처리중 에러 발생시 기존에 저장된 정보도 롤백이 가능하다는 장점이 있을것같습니다. 또한 request도 한번이면 됩니다. 1번의 단점 : api가 직관적이지 않은것같습니다. 클라이언트는 POST /parents를 사용하면 parents 리소스가 생길것으로 예상합니다. 하지만 해당 요청으로 children이 생길것이라는것은 문서를 봐야합니다. 또한 유연하지 않다고 생각합니다(클라이언트마다 구현방식이 다를것이므로) 2번의 장점 : api가 직관적입니다. 유연합니다. 클라이언트가 구현방식을 바꾸더라도 백엔드의 api를 바꾸지 않아도 될것같습니다. 2번의 단점 : 클라이언트쪽에서 여러번 api를 호출해야합니다. 요청 도중에 에러가 발생할 경우 parents는 등록되고 children은 등록이 안될수도 있습니다. 둘중에 어떤것 방식을 실무에서 사용하나요? 2번으로 마음이 좀 기울긴하는데, 위에 적히 단점들이 걸리네요.. 그리고 클라이언트쪽에서 N개의 children를 모두 등록하고 싶을때 body에 list를 담아서 post /children 전부를 한번에 보내서 처리할수있게 api를 만드는게 좋은것인가요? (하나의 요청으로 여러개의 리소스 생성, 백엔드에서 리스트를 순회하면서 저장) 아니면 클라이언트쪽에서 list를 순회하면서 N번 post 요청 하게 만드는것이 좋은가요?( 하나의 요청으로 하나의 리소스생성, 대신 여러번 호출) 긴글 읽어주셔서 감사합니다.
왜 에러가 나오는지 모르겠습니다. Controller에서 Mapping 할 때 그냥 hello로 하면 404가 나오고 /hello 로 하게 되면 500 에러가 나오게 됩니다. 022-05-04 12:15:15.062 ERROR 5008 --- [nio-8080-exec-9] o.a.c.c.C.[.[.[/].[dispatcherServlet] : Servlet.service() for servlet [dispatcherServlet] in context with path [] threw exception [Request processing failed; nested exception is org.thymeleaf.exceptions.TemplateInputException: Error resolving template [hello!], template might not exist or might not be accessible by any of the configured Template Resolvers] with root cause org.thymeleaf.exceptions.TemplateInputException: Error resolving template [hello!], template might not exist or might not be accessible by any of the configured Template Resolvers at org.thymeleaf.engine.TemplateManager.resolveTemplate(TemplateManager.java:869) ~[thymeleaf-3.0.15.RELEASE.jar:3.0.15.RELEASE] at org.thymeleaf.engine.TemplateManager.parseAndProcess(TemplateManager.java:607) ~[thymeleaf-3.0.15.RELEASE.jar:3.0.15.RELEASE] at org.thymeleaf.TemplateEngine.process(TemplateEngine.java:1098) ~[thymeleaf-3.0.15.RELEASE.jar:3.0.15.RELEASE] at org.thymeleaf.TemplateEngine.process(TemplateEngine.java:1072) ~[thymeleaf-3.0.15.RELEASE.jar:3.0.15.RELEASE] at org.thymeleaf.spring5.view.ThymeleafView.renderFragment(ThymeleafView.java:366) ~[thymeleaf-spring5-3.0.15.RELEASE.jar:3.0.15.RELEASE] at org.thymeleaf.spring5.view.ThymeleafView.render(ThymeleafView.java:190) ~[thymeleaf-spring5-3.0.15.RELEASE.jar:3.0.15.RELEASE] at org.springframework.web.servlet.DispatcherServlet.render(DispatcherServlet.java:1401) ~[spring-webmvc-5.3.19.jar:5.3.19] at org.springframework.web.servlet.DispatcherServlet.processDispatchResult(DispatcherServlet.java:1145) ~[spring-webmvc-5.3.19.jar:5.3.19] at org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:1084) ~[spring-webmvc-5.3.19.jar:5.3.19] at org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:963) ~[spring-webmvc-5.3.19.jar:5.3.19] at org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:1006) ~[spring-webmvc-5.3.19.jar:5.3.19] at org.springframework.web.servlet.FrameworkServlet.doGet(FrameworkServlet.java:898) ~[spring-webmvc-5.3.19.jar:5.3.19] at javax.servlet.http.HttpServlet.service(HttpServlet.java:655) ~[tomcat-embed-core-9.0.62.jar:4.0.FR] at org.springframework.web.servlet.FrameworkServlet.service(FrameworkServlet.java:883) ~[spring-webmvc-5.3.19.jar:5.3.19] at javax.servlet.http.HttpServlet.service(HttpServlet.java:764) ~[tomcat-embed-core-9.0.62.jar:4.0.FR] at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:227) ~[tomcat-embed-core-9.0.62.jar:9.0.62] at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:162) ~[tomcat-embed-core-9.0.62.jar:9.0.62] at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:53) ~[tomcat-embed-websocket-9.0.62.jar:9.0.62] at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:189) ~[tomcat-embed-core-9.0.62.jar:9.0.62] at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:162) ~[tomcat-embed-core-9.0.62.jar:9.0.62] at org.springframework.web.filter.RequestContextFilter.doFilterInternal(RequestContextFilter.java:100) ~[spring-web-5.3.19.jar:5.3.19] at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:117) ~[spring-web-5.3.19.jar:5.3.19] at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:189) ~[tomcat-embed-core-9.0.62.jar:9.0.62] at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:162) ~[tomcat-embed-core-9.0.62.jar:9.0.62] at org.springframework.web.filter.FormContentFilter.doFilterInternal(FormContentFilter.java:93) ~[spring-web-5.3.19.jar:5.3.19] at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:117) ~[spring-web-5.3.19.jar:5.3.19] at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:189) ~[tomcat-embed-core-9.0.62.jar:9.0.62] at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:162) ~[tomcat-embed-core-9.0.62.jar:9.0.62] at org.springframework.web.filter.CharacterEncodingFilter.doFilterInternal(CharacterEncodingFilter.java:201) ~[spring-web-5.3.19.jar:5.3.19] at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:117) ~[spring-web-5.3.19.jar:5.3.19] at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:189) ~[tomcat-embed-core-9.0.62.jar:9.0.62] at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:162) ~[tomcat-embed-core-9.0.62.jar:9.0.62] at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:197) ~[tomcat-embed-core-9.0.62.jar:9.0.62] at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:97) ~[tomcat-embed-core-9.0.62.jar:9.0.62] at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:541) ~[tomcat-embed-core-9.0.62.jar:9.0.62] at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:135) ~[tomcat-embed-core-9.0.62.jar:9.0.62] at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:92) ~[tomcat-embed-core-9.0.62.jar:9.0.62] at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:78) ~[tomcat-embed-core-9.0.62.jar:9.0.62] at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:360) ~[tomcat-embed-core-9.0.62.jar:9.0.62] at org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:399) ~[tomcat-embed-core-9.0.62.jar:9.0.62] at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:65) ~[tomcat-embed-core-9.0.62.jar:9.0.62] at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:890) ~[tomcat-embed-core-9.0.62.jar:9.0.62] at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1743) ~[tomcat-embed-core-9.0.62.jar:9.0.62] at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49) ~[tomcat-embed-core-9.0.62.jar:9.0.62] at org.apache.tomcat.util.threads.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1191) ~[tomcat-embed-core-9.0.62.jar:9.0.62] at org.apache.tomcat.util.threads.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:659) ~[tomcat-embed-core-9.0.62.jar:9.0.62] at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61) ~[tomcat-embed-core-9.0.62.jar:9.0.62] at java.base/java.lang.Thread.run(Thread.java:829) ~[na:na]
실무에서 DB 를 사용한다고 하면 배치나 데이터 파이프라인 등이 아닌 OLTP 환경에서는 절대 오프셋 기반의 페이징을 쓰면 안되지 않 나요? 우선 페이징 도중에 다른 클라이언트에 의해 실시간으로 데이터가 삽입/삭제가 일어나 중복된 데이터가 보여지거나 중간 데이터 누락이 발생할 수도 있기 때문에 문제가 될 것이고, 성능의 관점에서도 SQL 쿼리에서 OFFSET 문의 경 우 index seek 과정에서 바로 페이지의 첫 데이터를 찾아가는것이 아니라 불필요하게 맨 처음 인덱스부터 offset 사이즈만큼 스캔한 뒤에 limit 만큼 가져오는 것이기 때문에 scalable 않지만, 커서 기반의 페이징의 경우 데이터의 양이 많아지더라도 where 절을 통해 index seek 과정에서 바로 커서에 해당하는 인덱스를 찾아가서 page size 만큼의 데이터만 스캔하면 되기 때문에 실무에서 굳이 오프셋 기반의 페이징을 쓸 이유가 없다. 라고 이해하면 맞을까요? 물론 페이징 대상이 되는 데이터의 수 자체가 매우 적거나 유저가 많은 페이지를 탐색하지 않는다면 큰 문제가 되지 않을 수도 있지만, 커서 기반의 페이징을 구현하는것이 특별이 어려운 것도 아니고 굳이 오프셋 기반의 페이징을 사용할 필요가 있나 궁금했습니다!
안녕하세요 강의 잘 듣고 있습니다. 다름이 아니라, 본 강의에선 DefaultTourBuilder 구현체로 빌더 패턴 사용 예시를 보여주셨습니다. 1. 첫 번째 질문으로, 칸쿤 여행의 경우 TourPlan의 모든 멤버 변수에 어떤 값을 할당해야 한다고 가정했을 때, 강의에선 getPlan에서 모든 변수가 제대로 초기화됐는지 체크하는 과정이 생략된 것 같은데 맞을까요? 2. DefaultTourBuilder가 칸쿤 여행과 같이 모든 멤버 변수를 초기화했을 때만 인스턴스를 만들 수 있도록 getPlan에 제약을 걸어놨다면, 본 강의에서 예시로 들었던 당일치기 롱비치 여행은 DefaultTourBuilder로 만들 수 없다고 생각합니다. 여러 방법이 존재하겠지만 강의에서 말씀하신 내용을 되짚어보면 당일치기 여행 인스턴스를 제공하는 ShortTourBuilder를 만드는 게 합리적이란 생각이 듭니다. 강사님의 의견은 어떠신가요? 감사합니다.
리덕스로 로그인을 구현한 후 로그인 되지않는 문제가 생겼었습니다. dispatch 함수가 실행되지만 rootReducer에서 LOG_IN 부분이 실행이 안됐습니다(console.log로 확인) 그래서 useDispatch를 불러온 부분이 문제라고 생각해, react-redux버전을 강의에 맞게 7로 바꾸니 문제가 해결됐습니다. 왜 이런 문제가 발생한건가요..? 추가로 이 강의를 다 들은 후, react-redux를 8버전으로 올리고 싶으면 어디서 변경내역을 확인해야 하나요..?
안녕하세요. 현재 프론트는 mysiteurl.site 라는 도메인으로 firebase 호스팅을 하고 있고 백엔드는 mysiteurl.shop 으로 다른 도메인으로 정할 예정인데요. 강의에선 프론트와 백엔드가 동일하게 nodebird.com 이 들어가 있고 route53에서 서로 다른 ip를 가르키게 했는데 제가 하려고 하는 방식에도 쿠키가 전달이 가능할까요? (nginx proxy_set_header 세팅은 동일하다는 가정)
안녕하세요 . 강의 너무나 잘 듣고 있어 언제나 감사드립니다 . (_ _) DTO 관련해서 궁금점이 있어 질문드립니다. 제가 많이 본 , 그리고 제가 지금도 쓰고있는 폴더 트리 ( 패키지 구조 ) 가 아래와 같이 사용하고 있습니다 . - Model - | Repository - | Service - | Controller ▼ Service단의 경우에는 다른 서비스단에서 연계해서 사용될 수도 있다고 들은적이 있어서, 최대한 Model 클래스를 반환되도록 사용하고 있구요. 위와 연계해서 Controller단에서 Model 클래스를 DTO로 변환해서 반환을 했습니다. 그래서 DTO의 위치가 Controller 패키지에 위치시키고 있었습니다. 그런데 join 쿼리로 인해서 DTO 를 Repository 에서 반환하게 된다면 , 해당 DTO 의 위치가 맨 끝인 Controller 패키지에 있어도 되는 걸까요 ?
안녕하세요! Form 컴포넌트 내부를 작성해보다 실수로 아래와 같이 작성하였는데요 function handleFormSubmit(event) { event.preventDefault(); console.log('submit'); setCounter(100); console.log(counter); } 이런식으로 작성을 했더니 처음 submit 시에는 console 에 1이 찍히고 그 다음에 100이 찍혔습니다. 이 동작이 잘 이해가 되지 않는데 이유를 알 수 있을까요?!
학습하는 분들께 도움이 되고, 더 좋은 답변을 드릴 수 있도록 질문전에 다음을 꼭 확인해주세요. 1. 강의 내용과 관련된 질문을 남겨주세요. 2. 인프런의 질문 게시판과 자주 하는 질문(링크)을 먼저 확인해주세요. (자주 하는 질문 링크: https://bit.ly/3fX6ygx) 3. 질문 잘하기 메뉴얼(링크)을 먼저 읽어주세요. (질문 잘하기 메뉴얼 링크: https://bit.ly/2UfeqCG) 질문 시에는 위 내용은 삭제하고 다음 내용을 남겨주세요. ========================================= [질문 템플릿] 1. 강의 내용과 관련된 질문인가요? (예/아니오) 2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? (예/아니오) 3. 질문 잘하기 메뉴얼을 읽어보셨나요? (예/아니오) [질문 내용] 여기에 질문 내용을 남겨주세요. 페치조인의 한계로, 일대다 관계에서 컬렉션을 함께 조회하는 페치조인의 경우 데이터 뻥튀기 문제가 일어나기 떄문에, 둘 이상의 컬렉션을 페치조인으로 함께 가져오려고 하면 더더욱 안된다고 설명해주셨습니다. 그렇다면 Order - (1:N) - Order_Item - (N:1) - Item 의 경우 Order_Item을 조회할 때 Order와 Item을 모두 함께 가져오는 페치조인은 해도 되는것인지 궁금합니다. (즉 둘 이상의 컬렉션을 가져오는게 아닌, 둘 이상의 Entity를 가져오는 페치조인의 경우는 써도 되는지) ( select o from OrderItem o join fetch o.orders join fetch o.item 과 같은 JPQL을 사용하여 )
항상 개념이 헷갈리면 강사님이 하는 코드를 보러 옵니다 ㅋㅋ 근데 개인적으로 그래프 큐엘을 연습하다 궁금한것이 생겨 질문올립니다.저는 저기 날짜 년도 별, 월별로 관리를 하고 싶다고 했을때 어떻게 로직을 처리하는게 좋을까요 백엔드에서처리를 해야하나요 아니면 저렇게 날짜 데이터를 받아서 프론트에서 처리를 해야하는것이 효율적인가요..? 아직까지 실력이 부족해서 1월부터 12월까지 배열을 짜서 해야하나 막막합니다.. {content:"string", date:"2022-03-05"}예를 들어 이런 데이터가 엄청 많을때2022년 3월은 3월콘텐츠 4월은 4월컨텐츠를 리스트로 따로 처리하는 방법은 뭐가 있는지 고수의 팁좀 알려주십시오 ㅠㅠ 로직이 떠오르지가 않습니다 .. 수업과는 조금 떨어지는 질문 죄송합니다 ..
안녕하세요! 실무에서 jpa를 쓰게 되서 강사님의 책과 강의를 번갈아 보면서 열심히 개발하던 중에 궁금한 점이 있어 문의드립니다. 쓰다보니 query dsl이 참 편하더라구요! 그런데 연관관계 없는 두 개 entity를 조인해서 데이터를 조회해오고 싶은데, 아래와 같이 쿼리를 작성하니 실행 중에 QuerySyntaxException이 발생합니다. List < HistoryDto > historyList = queryFactory .select ( Projections. fields ( HistoryDto. class, pmntHistoryEntity. approvalNo , pmntHistoryEntity. approvalDate , pmntHistoryEntity. cancelType , pmntHistoryEntity. trxId , pmntHistoryEntity. trxReqDate , creditCardEntity.cardName , creditCardEntity.cardNumber )) .from ( pmntHistoryEntity) .leftJoin ( creditCardEntity) .on ( pmntHistoryEntity. cardToken .eq ( creditCardEntity.cardToken )) .where ( eqUserId ( dto.getUserId ()) , eqOrderId ( dto.getOrderId ()) ) .fetch () ; exception = QuerySyntaxException: begin 0, end -1, length 19 queryDsl에서 연관 관계 없어도 on 절을 통해 join이 가능한 것으로 알고 있는데 projection과 호환이 안되는 걸까요? 하루종일 구글링을 해도 나오질 않네요.. 혹시 알고 계시다면 답변 부탁드립니다 ㅠ_ㅠ
@GetMapping("/api/v2/orders") public List<OrderDto> ordersV2() { List<Order> orders = orderRepository.findAllByString(new OrderSearch()); List<OrderDto> result = orders.stream() .map( o -> new OrderDto(o) ) .collect(Collectors.toList()); return result; } @Data static class OrderDto { private Long orderId; private String name; private LocalDateTime orderDate; private OrderStatus orderStatus; private Address address; private List<OrderItem> orderItems; public OrderDto(Order order) { orderId = order.getId(); name = order.getMember().getName(); orderDate = order.getOrderDate(); orderStatus = order.getStatus(); address = order.getDelivery().getAddress(); order.getOrderItems().stream().forEach(o -> o.getItem().getId()); orderItems = order.getOrderItems(); } } 위 코드에서 OrderDto 생성자 함수 내에 getOrderItem 요소들을 순회시, 각 아이템을 get후에 getId를 호출 할 때 각 item 프록시들이 초기화 돼야 하는 것 아닌가요..? 강의에서는 getName을 통해 초기화 하길래, 위 코드처럼 getId로 하면 될까 궁금증이 생겨 실행해보니 orderItems 내에 item 이 null 값으로 나옵니다. getName 으로 초기화 할 때는 전부 다 들어있구요. 코드 구글 드라이브 링크: https://drive.google.com/drive/folders/17gdIodVzIPG8_XzTeYUVDbLdaScP6c2s
