학습하는 분들께 도움이 되고, 더 좋은 답변을 드릴 수 있도록 질문전에 다음을 꼭 확인해주세요. 1. 강의 내용과 관련된 질문을 남겨주세요. 2. 인프런의 질문 게시판과 자주 하는 질문(링크)을 먼저 확인해주세요. (자주 하는 질문 링크: https://bit.ly/3fX6ygx) 3. 질문 잘하기 메뉴얼(링크)을 먼저 읽어주세요. (질문 잘하기 메뉴얼 링크: https://bit.ly/2UfeqCG) 질문 시에는 위 내용은 삭제하고 다음 내용을 남겨주세요. ========================================= [질문 템플릿] 1. 강의 내용과 관련된 질문인가요? (예/아니오) 2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? (예/아니오) 3. 질문 잘하기 메뉴얼을 읽어보셨나요? (예/아니오) [질문 내용] 여기에 질문 내용을 남겨주세요. 프로젝트 지웠다가 처음부터 다시 해보기도 하고 질문글 따라 보면서 해봐도 에러가 떠서 어떻게 해야할지 모르겠어요.. .
21:09 지금 까지 이해한 포인터의 방법은 주소 사용할때는 & 또는 생략, 값을 사용할때는 *로 이해하고 있습니다. 해당 printf("%s\n", arr[0][0]); 라는 구문에 질문이 있습니다. 포인터 변수로 해당 문자열의 주소를 각 맵핑하였고 배열에 맞게 출력하는걸로 해석이 되는데 이때 왜 값을 안 가져오고 주소를 가져오는지 궁금합니다. 또한 %s로 출력하고 해서 주소대신에 값으로 가져오는지 궁금합니다.
유형 9번에서 처음에 Child obj = new Child(); 의 뜻이 Child 타입의 새로운 생성자를 생성하는 것이고, 이 생성자의 자식 class로 갔는데, 생성자가 없고, 부모에도 생성자가 없어서 출력되는 값은 없는 것이고, 그 뒤의 obj.display()코드를 실행해 display의 메서드에서 부모로부터 상속받아 Parent display, Child display가 답이 되는것이 맞을까요?
안녕하세요. 궁금한게 있어서 질문 드립니다. domain 패키지에 entity를 위치 한다고 했을때 주석이라고 말씀하신 어노테이션 JPA @Entity를 만들어서 Member로 정의 그리고 mongo DB도 필요해서 @Document를 정의해서 domain 패키지에 위치 시켜 Member로 정의 이처럼 같은 도메인이 서로 다른 DB로 사용 될때 어떻게 도메인으로 정의해야할지 궁금합니다. 그리고 이름이 중복되는 현상도 발생하기도 합니다. 그렇다고 OracleMember, MongoMember로 지을수도 없는것같습니다. 제 생각은 Member라는 도메인이 Domain 패지키에 별도로 나와서 adapter 안에 JPA Persistent의@Entity로 정의된 클래스와 Mongo Persistent의 @Document로 정의된 클래스가 위치 되어야한다고 생각하는데 어떤 의견이신지 궁금합니다.
안녕하신가 미스터 KILL-9 항상 빠르고 친절한 답변 고맙다 이번에 회사 로직 작성중에 조금 막막한 부분이 있어 질문 하러 왔다 reader 엑셀 파일 읽어오고 processor 에서 해당 엑셀 데이터 값을 가지고 dao 호출해서 검증하고, 깍고 (가공) 마지막으로 쓰기 처형하는데 작업을 하는데 문제는 가공 단계에서 dao 를 직접 호출하면 ExecutorType 이 simple 로 호출되고 쓰기 단계에서 batch 로 ExecutorType 실행되어 에러가 발생한다 Cannot change the ExecutorType… 이렇게 말이다.. 그래서 일단 아래 코드 처럼 해결은 했어 우선 기존 코드는 PoiItemReader -> ItemProcessor<> (여기서 mybatis dao 호출 해서 검증작업도 함) -> MyBatisBatchItemWriter -> 에러 Cannot change the ExecutorType… 해결한 코드 PoiItemReader -> ItemProcessor<> (여기서 mybatis dao 호출 해서 검증작업도 함) -> JdbcBatchItemWriter-> (해결) 그런데 이렇게 작성해도 되려나 싶네.. 그리고 String 문으로 쿼리 짜는것도 맘에 안들고..ㅠㅠ
- 명백한 한계점 (단점): - 네트워크 대역폭 소모: 실제 데이터를 전송하므로 네트워크 부하가 극심하다. 데이터 건수가 많거나 크기가 크면 통신 자체가 병목이 될 수 있다. ( "핵탄두 데이터 전송에 따른 통신망 과부하 주의!" ) - Manager 읽기 병목: Manager 혼자 모든 데이터를 읽어야 하므로, 읽기 자체가 느리다면 원격 청킹은 효과가 없다. ( "중앙 정찰 위성의 스캔 속도 한계!" ) - 복잡성(감시와 디버깅의 지옥문): 역시 미들웨어(Kafka 등)와 프링 인티그레이션 설정이 필수적이다. 프링 인티그레이션 ->스프링 인티그레이션
안녕하세요. redis 강의를 통해 간단한 프로젝트로 적용을 하려고 합니다. @Cacheable( value = "reviewList", key = "'review:store:' + #storeId + ':page:' + #pageable.pageNumber", cacheManager = "reviewCacheManager", condition = "#pageable.pageNumber == 0") @Transactional(readOnly = true) public Page<ResViewReviewDto> getReviews(UUID storeId, ReviewRepositorySearchConditionDto condition, Pageable pageable) { Page<ResViewReviewDto> reviews = reviewRepository.findReviews(storeId, condition, pageable); return new PageImpl<>(reviews.getContent(), pageable, reviews.getTotalElements()); } 원래는 return reviews를 했더니 계속 조회를 누르면 ClassCastException: LinkedHashMap cannot be cast to Page 이 오류가 나오게 됩니다. 강의에서는 그냥 getContent를 List로 반환값을 보냈는데 혹시 위 코드처럼 new PageImpl 형식으로 return 해도 괜찮을까요?
학습 관련 질문을 최대한 상세히 남겨주세요! 고민 과정도 같이 나열해주셔도 좋습니다. 먼저 유사한 질문이 있었는지 검색해보세요. 인프런 서비스 운영 관련 문의는 1:1 문의하기를 이용해주세요. 안녕하세요, 선생님! 강의 알차게 잘 수강하고 있습니다. 현재 90% 수강 완료하였는데, 어렵고 힘들게 여기까지 온 만큼 저의 역량도 비교할 수 없을 정도로 많이 성장한 것 같습니다. 먼저 감사의 말씀을 드립니다. 일단 현재 게시글 목록 최적화 전략 구현(64강) 강의를 수강 중인데, 이전의 강의 내용(게시글 조회 최적화 전략)과 비교하였을때 최적화 전략을 수립하는 과정과 관련하여 몇가지 의문점이 들어 질문드리게 되었습니다. 의문점) - 게시글/카테고리에 대한 게시글 목록 모두 전략을 나누어야 하는가? 의문점이 들었던 과정) - 일단 크게 보았을때, 게시글 내용에 대한 캐싱(articleId)과 게시글 목록(*특정 카테고리, board로 지칭)에 대한 캐싱(boardId)으로 내용을 나눌 수 있을 것 같습니다. - 여기서 드는 제 개인적인 생각은, (일단 전략의 당위성이나 세부적인 내용 상관없이) 캐싱전략을 너무 세세하게, 오히려 성능적 이점보다는 관리적 비용이 더 크게 소모되지 않을까 하는 염려가 들 정도로 배꼽이 더 큰 전략/관리방안을 각각 구분해놓는 것이 아닌가하는 생각이 들었습니다. - 예를 들어, 게시글 목록 최적화 전략의 경우 말씀하신대로 최초 목록 조회 진입 시 보여지는 내용이기도 하고 이는 모든 사용자에게 공통적으로 적용할 수 있는 정책이므로 관리의 당위성이나 책임이 명확하다고 생각하였습니다. - 하지만 게시글 조회 최적화 전략의 경우, 목록 최적화 전략을 수강한 이후에는 "게시글 조회"역시 어떻게 보면 그 게시글을 보고싶은 사용자 일부에 대해서만 보여지는 글이므로..지금처럼 모든 생성 글/댓글/좋아요에 대해 ArticleQueryModel 데이터를 생성하는 것이 비용효율이나 관리효율면에서 과연 올바른 방향인지 다소 의문이 들게 되었습니다. 또한, 이러한 전략수립의 당위성을 떠나서 각 조회기능별로 전략을 구상하는게(단건/목록 등) 수립은 가능하더라도 관리가 힘들 것 같은데, 실무적으로 관리가 가능할지 의문이 들기도 하였습니다. 최종 질문) - 제가 올바르게 강의내용을 이해하지 못하여 질문드리는 것 일 수 있기에, 일단 제가 들었던 의문이 선생님께서 생각하셨을때, 타당한 의문일지 궁금합니다. - 타당하다면 아래와 같은 "게시글 단건" 조회 전략을 생각할 수 있을 것 같은데, 혹시 바람직한 전략이 될 수 있을지 고견을 요청드려보고자 합니다. - 또한 실무적으로 이러한 다양한 관리전략을 수립하게된 계기가 "성능문제" "사용자 패턴에 따른 문제점 예상" 등, 여러 문제 중 어떠한 부분이 가장 중요하게 작용하는지 궁금하여 질문드립니다. [단건 조회전략 구상 방안] 게시글 조회 전략을 만약 구상한다면(세부적인 전략구현은 생략) - 지금처럼 단건 데이터 생성마다 articleQueryModel을 구성하는 것이 아니라, 각 카테고리별 보여지는 1000개의 데이터에 대해 articleQueryModel 데이터를 구성한다. (*게시글을 보는 것도 결국 최신 1000개의 데이터에 대해서만 볼 것이기 때문이다.) - 인기글 데이터 생성 후 해당 인기글에 대한 articleQueryModel 데이터를 구성한다. (*인기글 데이터에 대해서만 단건 조회 트래픽이 몰릴 것으로 예상할 수 있기 때문이다.) 읽어주셔서 감사드립니다.
