각 application.java에서 빈 스캔할때 차이

닉네임무얼하지님, 안녕하세요! 말씀 주신 사항만으로는 저도 정확한 원인 파악은 어렵지만, 짐작가는 부분 남겨봅니다! 강의에서는 애플리케이션에서 다른 패키지 모듈의 빈을 스캔하기 위해서 AutoConfiguration을 사용 중 인데요,outbox-message-relay > resources 디렉토리 > META-INF 디렉토리 > spring 디렉토리에서,org.springframework.boot.autoconfigure.AutoConfiguration.imports 파일을 정의하고,kuke.board.common.outboxmessagerelay.MessageRelayConfig자동으로 스캔하기 위한 Configuration 클래스를 선언하고 있습니다. 많이들 실수하시는 부분이,META-INF 디렉토리 하위의 spring 디렉토리인데, META-INF.spring 디렉토리로 선언하기org.springframework.boot.autoconfigure.AutoConfiguration.imports 파일명에서 오타kuke.board.common.outboxmessagerelay.MessageRelayConfig 에서 오타MessageRelayConfig에서 @ComponentScan("kuke.board.common.outboxmessagerelay") 스캔 범위 잘못 지정하거나 오타등이 있더라고요. 혹시 위 내용들 점검해보시겠어요?

섹션4 (좋아요)의 댓글 수 구현 강의에서 질문 있습니다.

태우님, 안녕하세요! 강의에서 제시한 요구사항에서는 논리적 삭제한 댓글도 "삭제 댓글"이란 상태로 사용자에게 나타나기 때문입니다.사용자가 내용은 볼 수 없지만, 아무튼 그 공간을 차지하고 있기 때문에 카운트에 포함되는게 적절하다고 판단 했네요!정책은 그냥 정하기 나름일 것 같습니다!

ArticleDeletedEventHandler

성장하자님, 안녕하세요! ArticleQueryModel 모델에 좋아요 수, 댓글 수도 모두 포함되어 있습니다.ArticleQueryModel을 삭제하면, 해당 데이터도 당연히 함께 삭제됩니다! 조회 수는 캐시 TTL에 의해 자동으로 제거됩니다. 굳이 실시간으로 지울 필요는 없습니다.특히 참조 데이터 지우는 작업들이 많고 무거울수록 실시간으로 한번에 처리하는 일은 드물고, 그럴 필요도 없습니다.어차피 진입점을 막으면 데이터 접근도 불가하고, 사용성에 문제가 생기지도 않습니다.트래픽이 적은 시점 또는 필요한 보관 기간이 끝난 시점 등 안전한 상황에 별도 배치나 스케줄링으로 데이터를 정리할 수도 있습니다.

TransactionalEventListener 관련 문의드리고자 글 남깁니다.

자기개발하고싶어요님, 안녕하세요! payload(강의에서는 OutboxEvent) 를 통해 분기처리하는 방법만 보이다보니제가 보기엔 이게 가장 깔끔하고 편할 것 같은데, 굳이 다른 방법을 찾으시는 이유가 있을까요?파라미터 타입이 다르면 호출이 되지 않는데, 어떠한 부분에서 불필요한 리소스 사용이라고 느끼셨을까요? 다른 구현 방법으로는,@TransactionalEventListener의 condition 필드를 사용해서 분기 조건을 만들 수도 있고,단일 리스너에서 직접 분기 코드를 작성할 수도 있습니다.직접 원하는 부분에만 커스텀 애노테이션을 만들어서 AOP를 적용시킬 수도 있고요. 다만, 그냥 파라미터 타입만 달리해서 구현을 하는게 가장 간단하고 편할 것 같네요!

오타 문의

감스트의웃음노예님, 안녕하세요! 앗, 말씀 주신 부분이 맞네요. 테이블을 쪼갠 것이므로 비정규화가 아니라 정규화가 맞습니다.이 부분 추후에 수정할 수 있도록 하겠습니다!제보 감사합니다!

406 Not Acceptable에러 발생

Gwangseok Lee님, 안녕하세요! 말씀 주신 내용으로는 파악하기가 어렵네요. Accept와는 무관할 것 같습니다.컨트롤러 코드도 보여주시겠어요?@RestController로 선언되어 있는지, @PostMapping으로 잘 선언된게 맞는지 확인해보시면 좋을 것 같네요!

안녕하세요 선생님 게시글 목록 API-페이지 번호 구현 강의에서 질문 있습니다.

태우님, 안녕하세요! 서버에서 값을 정하고 항상 똑같은 pageSize를 써야하는 것 아닌가요 ??그렇게 할 수도 있겠지만, 보통은 그렇게 하지 않습니다.클라이언트 기기의 화면 크기에 따라서 필요한 pageSize가 다를 수 있고,또는 사용자에게 페이지 개수 제어하는 기능을 제공하는 경우도 있기 때문입니다.만약 pageSize가 고정값이라면, 클라이언트 요구사항에 따라서 항상 새로운 API를 만들어주거나 수정이 필요할 수 있습니다.그럴거라면 차라리 pageSize를 인자로 받는 경우가 훨씬 편합니다.pageSize를 제어할 수 있도록 API만 제공해주면,클라이언트는 구현 세부 사항을 API에 알리지 않고도 필요한 개수만 불러와서 유연하게 개발할 수 있습니다.실서비스에서는 pageSize에 대한 최댓값 제약은 당연히 필요하고,특정한 값(20개/30개 등)만 인자를 받도록 제약을 만들 수도 있습니다.물론, 이게 정답이라는 것은 아니고 pageSize의 변동이 없어도 된다면, 말씀하신대로 처리해도 무방합니다.어떠한 방식이든 구현하기 나름이고, 요구사항에 맞춰주면 되는 부분이네요!

안녕하세요 ! 강의 잘 듣고 있습니다.

태우님, 안녕하세요!강의 잘 수강해주셔서 감사합니다! 서비스가 커질수록 API가 아주 많아질 수 있는데요,그럴 때 API path가 하나로 합쳐져있으면 어떠한 외부 도구의 도움 없이도 해당 API 코드 찾기가 아주 편합니다.이 정도는 딱히 문제될 만한 중복이라고 볼 수 없기도 하고, 이러한 이점으로 인해 full path를 다 적게 되더라고요!

페이지네이션 시 조회 과정 질문

yso829612님, 안녕하세요! secondary index에서 offset 위치까지 순차탐색 -> secondary index -> 클러스터링 인덱스에서 primary key 조회 -> 실제 데이터 조회커버링 인덱스 활용한 최적화 쿼리에 대해서 말씀하시는 것이겠죠?살짝 정정해보면, 클러스터링 인덱스는 데이터를 포함하고 있습니다."클러스터링 인덱스에서 primary key 조회 -> 실제 데이터 조회" 이거를 하나로 통합해서 생각하시면 될 것 같네요.세컨더리 인덱스가 클러스터링 인덱스에 접근하기 위한 primary key를 가지고 있는 것이고,클러스터링 인덱스는 데이터를 가지고 있습니다.즉, secondary index에서 offset 만큼 순차적으로 scan 하는 것은 맞고(where 조건은 인덱스 트리에서 로그 시간에 탐색하고, 그 지점부터 순차 탐색이란 의미입니다.),해당 지점에서부터 limit 만큼 primary key(클러스터링 인덱스에 접근하기 위한 포인터)를 찾아서,클러스터링 인덱스에서 데이터를 조회하는 것입니다.클러스터링 인덱스를 탐색하는 것이 실제 데이터를 조회하는 과정입니다. 2 . 위 과정이 맞다면 이 과정에서 db에서 데이터 조회를 limit만큼 반복하는 것인지, 아니면 실제 db에서 데이터 조회는 한 번에 이루어지는 것인지 궁금합니다.limit 만큼 반복한다는 것을 이해를 못하였는데 어떤 의미일까요?offset만큼 scan이 끝났으면, limit 만큼 한 번에 데이터를 조회하면 됩니다.("한 번에"라는 말의 정확한 의미 파악은 못하였지만, limit이 크면 물리적으로 디스크 I/O가 반복적으로 수행될 수는 있을 것 같네요. 이 이상의 영역은 블랙박스로 생각해도 좋을 것 같습니다.) 페이지 조회 말고 그냥 범위 조회일 시에는 한 번에 조회되서 값이 많아도 시간 차이가 많이 안나는지 궁금합니다. offset 없이 조회해보니 바로 조회되는 거 같긴합니다.범위 조회라는게 어떤 의미일까요? 인덱스는 트리 구조로 이루어져있다는 점을 기반으로 인지하면, 충분히 동작을 유추해보실 수 있을 것 같습니다.where 조건이 인덱스를 태울 수 있으면, 기준점은 로그 시간에 찾을 수 있으므로 당연히 빠르게 조회가 됩니다.offset은 기준점부터 순차적으로 scan하는 과정이 필요하기 때문에 커질수록 느려지게 됩니다!

값이 안변해요

kimoon Hong님, 안녕하세요!스프링부트 애플리케이션에서 API가 정상 호출되고 있는지 디버깅해보시면 좋을 것 같습니다!짐작가는 사항으로는, 혹시 스프링부트 버전이 강의와 다를까요?최신 버전에서는, restClient.put() .uri("/v1/articles/{articleId}", articleId) .body(new ArticleUpdateRequest("hi 2", "my content 22")) .retrieve();retreive까지만 코드 수행하면 정상적으로 API 호출이 안되더라고요! restClient.put() .uri("/v1/articles/{articleId}", articleId) .body(new ArticleUpdateRequest("hi 2", "my content 22")) .retrieve() .toBodilessEntity()서버 애플리케이션에 요청 자체가 들어가지 않는 상황이라면,위처럼 toBodilessEntity까지 호출해보시면 해결될지도 싶습니다!