위는 강의 pdf 파일에서 캡쳐한 build.gradle 설정 내용입니다. 아래는 제가 프로젝트 생성후 캡쳐한 build.gradle의 의존성 사진입니다. pdf 설명대로 JUnit4를 추가했습니다. 그런데 pdf 파일에 testImplementation(‘org.springframework.boot:spring-boot-starter-test’) { exclude group: ‘org.junit.vintage’, module: ‘junit-vintage-engine’ } 가 있던데 이것도 추가해줘야하는 부분인가요? 없으면 추후 강의를 진행하는데 문제가 될까요? 현재 pdf 파일에 있는 build.gradle 내용과 제가 방금 프로젝트 생성 후의 build.gradle 내용과 조금 다른 것 같아 질문드립니다
안녕하세요. 수업을 듣다가 알려주신 거랑 다르게 동작하는 것 같아 질문드립니다. 5.2 풀라우트 캐시2 스크립트 기준 10:09 "자, 이런 Fetch 메서드는 자동으로 No Store 옵션을 갖는다고 말씀을 드렸죠?" -> 그래서 예상한 결과값은 dynamic page를 예상했는데 static page로 나오는 것 같습니다 npm run build를 했을 때 cache 옵션을 안 준 경우 const response = await fetch(`${process.env.NEXT_PUBLIC_API_SERVER_URL}/book`) Route (app) Size First Load JS ┌ ○ / 288 B 106 kB 이렇게 static page로 나오고 cache 옵션 no-store로 준 경우 Route (app) Size First Load JS ┌ ƒ / 288 B 106 kB 이렇게 dynamic page로 나와서 next 공식 문서를 찾아보니 https://nextjs.org/docs/15/app/api-reference/functions/fetch auto no cache (default): Next.js fetches the resource from the remote server on every request in development, but will fetch once during next build because the route will be statically prerendered. If Dynamic APIs are detected on the route, Next.js will fetch the resource on every request. 이렇게 build 때는 static 이라고 해서 질문이 생겼습니다. 어떤 블로그에서는 또 브라우저마다 다르게 동작한다고 해서 헷갈립니다..! 답변 주시면 감사드리겠습니다.
[질문 템플릿] 1. 강의 내용과 관련된 질문인가요? (예) 2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? (예) 3. 질문 잘하기 메뉴얼을 읽어보셨나요? (아니오) [질문 내용] 안녕하세요. 컬렉션 조회 최적화 부분에서 페이징 + 검색 조건 관련해서 궁금한 점이 있어서 질문드립니다. 질문) Order 리스트 페이징을 하고 싶은데@BatchSize는 안쓰고 5번처럼 QueryDto직접 쿼리 2번 + map O(0) 방식으로 처리하려고 합니다. 이 때 만약 검색 조건이 toMany 로 맺어진 테이블 (orderItem.quantity, orderItem.item.name 등) 에 있다면 toOne 방향 루트 join fetch 쿼리 할 때 이 조건을 함께 포함시켜면 되는걸까요 (join orderItem .. where .. 같이) 예를들어 item.name이 "tesla"인 item을 포함하고 있는 모든 order를 페이징 적용해서 보여주고 싶은 경우에 어떻게 하면 좋을지 궁금합니다.
like테이블을 생성하고자 작성을 한 후 Add foregin key relation 을 클릭하여 public schema를 선택한 이후에도 하위 테이블 목록이 보이지 않습니다..ㅠㅠ 딱히 다른 설정을 만진것이 없이 강의를 따라 쭉 해보고 있는데 무언가가 바뀐건가요? 강의 내에서는 post테이블이면 public.post로 나오지만 지금 현재는 post로만 보이는 상태인데 어떤 부분이 바뀌었나? 혹은 설정을 못한 부분이 있나 잘 모르겠습니다..
3.0.2 버전의 경우 readValue가 JacksonException을 throw하는 것으로 타입이 선언되어 있는데요. (unchecked Exception 타입) public <T> T readValue(String content, Class<T> valueType) throws JacksonException Unchecked Exception(상위 에러 타입이 RuntimeException)이지만 강의처럼 try catch 이용하여 JacksonException을 catch 하면 될까요? 아님 RuntimeException 이니 별도로 catch 없이 코드를 작성하는게 좋을까요?
클로드 pro price 사용중입니다. 이번 과제를 진행하면서 초기화없이 한 섹션?(이 단위를 부르는 명칭을 잘 모르겠네요)에서 진행을 했는데, 약 5~6번의 수정을 거치니 토큰 사용량(current session)이 한도에 도달해버리네요. 미션 템플릿에 따라 처음 plan 요청 후에는, accept edit 모드로 간단하다고 생각되는 수정 사항을 요청했습니다. 수정 내용으로는 1. 블랙+옐로우의 어두운 컬러감 말고 main, secondary 컬러 다시 정해서 밝은 테마, 다채로운 컬러 사용해서 수정해줘 2. 경력 섹션에 카드 형식말고 아코디언 형식의 타임라인 형태로 수정해줘 이런 식으로 두가지 정도씩해서 4~5번 수정사항을 요청했습니다. 매 수정 때마다 거의 10분을 잡아먹드라구요 중간에 clear가 없었던 탓일까요? 토큰 사용 속도가 너무 빠른데. 만약 그렇다면 clear를 중간 중간에 해주면 사용량이 줄어들까요?
강의 섹션4. 데이터베이스를 지배하라. 챕터에서 아래는 JPA 방식으로 일대다 관계를 가진 데이터를 페치 조인으로 가져오는 예제 코드야. returnnew JpaCursorItemReaderBuilder <Post>() .name( "postBlockReader" ) .entityManagerFactory(entityManagerFactory) .queryString( """ SELECT p FROM Post p JOIN FETCH p.reports r WHERE r.reportedAt >= :startDateTime AND r.reportedAt < :endDateTime """ ) .parameterValues(Map.of( "startDateTime" , startDateTime, "endDateTime" , endDateTime )) .build(); 근데 jdbc 커서 예제에서는 킬구형이 아래처럼 단일 테이블만 조회하는 예제를 사용했어. @Bean public JdbcCursorItemReader < Victim > terminatedVictimReader () { returnnew JdbcCursorItemReaderBuilder<Victim>() .name( "terminatedVictimReader" ) .dataSource(dataSource) .sql( "SELECT * FROM victims WHERE status = ? AND terminated_at <= ?" ) .queryArguments(List.of( "TERMINATED" , LocalDateTime.now ())) .beanRowMapper(Victim. class ) .build(); } 근데 내가 지금 하려고 하는 건 jdbc 커서 방식에서 일대다 관계 테이블 데이터를 조회해서 일일정산 데이터 만드는 기능으로 복습해보려고 하는데, 데이터가 뻥튀기 되서 강의 예제에서 해당 케이스를 찾아보려고 하는데, 못 찾아서 질문글 작성했어. jdbc 방식으로 일대다 관계 데이터를 Reader로 읽어와서 위에 jpa 구조로 매핑하려면 어떻게 해야하는지 알려줄 수 있어? @Bean @StepScope public JdbcCursorItemReader<OrderBatchJoinDto> jdbcCursorReader( @Value("#{jobParameters['orderDate']}") LocalDate orderDate) { LocalDateTime startOrderDate = orderDate.atStartOfDay(); LocalDateTime endOrderDate = orderDate.atTime(23, 59, 59); return new JdbcCursorItemReaderBuilder<OrderBatchJoinDto>() .name("jdbcCursorReader") .dataSource(dataSource) .sql(""" SELECT ob.ORDERS_BATCH_ID, ob.USER_ID, ob.STATUS, ob.ORDER_DATE_TIME, oib.ORDERS_ITEM_BATCH_ID, oib.ORDERS_BATCH_ID, oib.PRODUCT_BATCH_ID, oib.PRODUCT_NAME, oib.PRICE, oib.QUANTITY FROM orders_batch ob LEFT JOIN orders_item_batch oib ON ob.ORDERS_BATCH_ID = oib.ORDERS_BATCH_ID WHERE ob.ORDER_DATE_TIME BETWEEN ? AND ? ORDER BY ob.ORDERS_BATCH_ID, oib.ORDERS_ITEM_BATCH_ID """) .queryArguments(List.of(startOrderDate, endOrderDate)) .beanRowMapper(OrderBatchJoinDto.class) } public class OrderItemBatchDto { private Long id; private Long ordersBatchId; private Long productBatchId; private String productName; private int price; private int quantity; } public class OrderItemBatchDto { private Long id; private Long ordersBatchId; private Long productBatchId; private String productName; private int price; private int quantity; }
이정환 쌤 강의는 무조건 다 듣는 프론트 개발자 학생입니다. 근데, 궁금한점이 있어 질문드려요. 리액트 강의부터 하시고, 그다음 Next.js 강의 하시고, 다시 리액트로 이번에 강의를 하시는데, 저는 이정환 쌤 Next.js 강의를 듣고 난 후에는 리액트로는 개발을 안하고 Next.js로만 개발했거든요. 다시 리액트로 돌아간 이유에 대해 궁금해서 질문드립니다. Next.js 말고 리액트를 선택한 이유가 있을까요? Next.js에 어떤 이슈가 있는걸까요?
Q. SQL 로 미리 테이블 작성하거나 인덱스 설정을 SQL 로 직접하는데 이유가 궁금합니다 인덱스 같은경우 jpa 에서 쓸수있는 옵션이 제한적이라 따로 SQL 로 관리한다고 듣긴했는데 테이블도 실제로 SQL 에서 하는지 궁금하고, SQL 로만 테이블 생성 인덱스 관리를 할경우 현업에서는 어떤 db 마이그레이션 라이브러리를 주로 사용하는지도 궁금합니다. Q. 참조관계를 DB 에서 걸지않고 논리적으로만 걸었을때 참조테이블에대한 조인은 어떤식으로 하는지 궁금합니다. MSA 기준으론 데이터베이스가 아예 분리될텐데 어떤식으로 조인하나요? 추가적으로 논리적으로 참조설계가 된 상황에서 @ManyToOne 사용이 가능한지궁급합니다. 예를들면 Comment 엔티티에서 parentCommentId 같은 같은 데이터베이스에 있는 테이블에 @ManyToOne 적용이 가능한지궁급합니다.
안녕하세요! 강의를 모두 학습하고, 실습도 진행하면서 오케스트레이션 방식을 적용해보고 있는데 궁금한 점이 있어 질문드립니다. 현재 실습 환경에서는 service_1 이 단일 진입점 역할을 하면서 Account 관련 로직까지 함께 처리하고 있습니다. 그런데 실무에서는 이 두 역할을 분리하는 것이 맞는지 고민되고 있습니다. 제가 생각하기로는, 명확한 Orchestrator 서비스가 존재하지 않으면 각 서비스가 상황에 따라 오케스트레이션 역할을 맡게 되고, 시간이 지나면서 구조가 복잡해지고 유지보수에 많이 불리할 것 같습니다. 그래서 실제 운영 환경에서는 다음과 같은 구조가 더 적절한지 여쭙고 싶습니다. orchestration-service → account-service → ... 즉, 오케스트레이션만 담당하는 서비스를 별도로 두고, 각 도메인 서비스는 자신의 책임만 수행하도록 설계하는 것이 맞을까요? 좋은 강의 감사합니다! 많이 배우고 있습니다!
