alsdud1513501876

시간이 좀 지난 질문이지만, 다른 분들도 궁금하실 것 같애서 추가 답변 남깁니다.<code>@ModelAttribute</code> 를 사용할 경우 <code>ModelAttributeMethodProcessor</code>(<code>ArgumentResolver</code>)가 사용됩니다.여기서 리플렉션을 통해 <code>@ModelAttribute</code> 객체의 생성자를 기본 생성자를 호출합니다.(모든 필드 변수의 값이 디폴트 값[int = 0, String = null, ...])이후 <code>DataBinder</code> 를 사용하여 요청 파라미터의 key를 가지고 리플렉션을 통해 <code>@ModelAttribute</code> 객체의 같은 key 에 대한 정보를 찾습니다.그리고 찾은 필드 변수의 타입을 가지고 요청 파라미터의 값을 설정합니다.이 때, int 필드에 문자열이 들어가면 형 변환에 실패하고, <code>BindingResult</code> 에 <code>FieldError</code> 를 넣는 과정이 있습니다.그래서 <code>@ModelAttribute</code> 경우 <code>TypeMismatch</code> 에러가 발생해도 <code>BindingResult</code> 를 파라미터러 받는다면 컨트롤러가 호출됩니다.&nbsp;<code>@RequestBody</code> 의 경우는 <code>RequestResponseBodyMethodProcessor</code>(<code>ArgumentResolver</code>)가 호출됩니다.이후 <code>AbstractJackson2HttpMessageConverter</code>(<code>HttpMessageConverter</code>)에서 <code>Jackson</code> 라이브러리를 통해 요청 HTTP 메시지 바디의 <code>json string</code> 를 <code>@RequestBody</code> 객체로 변환하는 작업을 합니다.이 때, int 필드에 문자열이 들어갔다면, <code>Jackson</code> 라이브러리에서 <code>InvalidFormatException</code> 을 발생시키고, <code>BindingResult</code> 가 있더라도 컨트롤러에 진입 조차 할 수 없고 400 예외 메시지가 발생하게 됩니다.이 차이 떄문에 <code>@ModelAttribute</code> 는 클라이언트가 잘못된 데이터 타입의 값을 입력해도 적절한 에러 메시지를 바인딩하여 컨트롤러에 진입할 수 있지만, <code>@RequestBody</code> 는 아예 컨트롤러 진입 전에 요청이 실패하는 차이가 있습니다.&nbsp;감사합니다.`&nbsp;&nbsp;

컨트롤러 호출 안되는 이유 질문

지나가는 학생입니다. 상황 1의 경우 스프링 배치에서 제공하는 ItemReader에는 없을 것 같군요.굳이 구현한다면 ItemReader 인터페이스를 직접 구현해서 사용할텐데, 해당 구현 내용에는 <code>select * from table limit 1 offset 0...2000</code> 이렇게 증가하면서 조회한다고 가정하겠습니다.&nbsp;상황 1과 상황 2의 성능을 비교한다면,차라리 상황 1이 더 더 빠르다고 생각되네요. 어차피 상황 1과 2 둘다 커넥션 풀에 있는 커넥션을 사용할거라 커넥션 생성 비용은 동일할텐고요.다만, 상황 2에서는 chunk size 단위로 커밋이 이뤄지기 때문에 커밋(네트워크 통신) 2000번이 발생하겠네요.상황 1에서는 write 커밋은 1번할테니 둘의 커밋 차이는 2000배가 되겠네요.&nbsp;도움이 되셨기를~

ItemReader에서 chunkSize의 두 사용 방법 비교

자답입니다. m1 칩을 사용할 때 kafka-streams 라이브러리의 rocksDB 버전이 6.29.4.1 이상이여야 정상 동작합니다. <a target="_blank" rel="noopener noreferrer nofollow" href="https://github.com/facebook/rocksdb/issues/7720">https://github.com/facebook/rocksdb/issues/7720</a><img src="https://cdn.inflearn.com/public/files/posts/4dd4f75f-a297-497b-bf68-2e01a805dc3d/image.png" alt="image" title="image">kafka-streams 2.5.0 + rocksDB 6.29.4.1을 사용할 경우 2개의 버전이 호환이 되지 않아 에러가 발생합니다. 정상적으로 사용하기 위해서 <code>implementation 'org.apache.kafka:kafka-streams:3.2.0'</code> 이상의 버전을 사용하시면 됩니다.

KStream, KTable 조인 스트림즈 애플리케이션에서 에러가 발생하고 있습니다.

http method는 단순히 스펙일 뿐이지 사실 delete에서 데이터를 생성하는 로직을 만들수 있습니다.당연히 post에서도 데이터를 삭제할 수 있고요.기본적으로는 uri와 httpmethod만 보고 이 api는 사용자를 생성 하구나~ 이렇게 식별할 수 있게 만드는 것이 좋은 api 설계입니다.질문자님이 얘기하신 delete를 사용한다고 알아서 삭제해주는 것이 아니라 delete를 호출했을 때 실행되는 메서드에서 삭제하는 로직을 직접 작성하셔야 합니다.post를 호출했을 때 동작하는 것은 post uri에 해당되는 메서드를 호출하는게 전부입니다. post를 호출했다고 알아서 해주는건 없습니다~

POST를 사용한 회원 삭제

지나가다 들린 학생입니다.
스프링은 기본 원칙은 더 "자세한 설정을 사용한다" 입니다.
properties에 설정된 설정보단 직접 @Bean을 사용한 설정이 더 우선 순위를 갖게 되어 사용되는게 맞습니다.

test DB 설정 질문

강의를 듣는 학생입니다.
커넥션을 1개로 계속 사용하면 커넥션 풀에 1개인 것과 비슷하다고 볼 수 있네요. 다만 커넥션을 일정 시간 사용하지 않으면 커넥션 타임 아웃이 발생하겠네요.
&nbsp;
개인적으로 커넥션을 1개로 돌리면 배치에서 작업하는 특성에 따라 다를 수 있을 것 같네요.&nbsp;
예를 들어 중복 체크하는 로직이 들어가 있어야 하는데 커넥션을 1개로 돌린다면 빠져도 될 수 있겠어요.
커넥션을 맺는 작업은 맺는 당시에만 비용이 발생하니 비용이 비싸서 1개를 사용하는 것 같진 않네요. 다른 숨은 의도가 있을 수도 있을 것 같네요.
&nbsp;
보통 배치가 오래걸리면 그 시간 만큼 서비스에서 배치 결과를 늦게 보여주는 거니 저라면 커넥션을 늘리고 멀티 쓰레드를 사용하여 배치를 돌려 작업 시간을 줄일 것 같네요. 동시 처리 작업이 5개라고 하니 최소 5개는 사용할 것 같고요.
&nbsp;
제 답변이 도움될진 모르갰지만 지나가다 적어봅니다.
선생님 답변도 기다려보겠습니다~
&nbsp;
&nbsp;

레거시 코드에서 DriverManager를 사용하는데요...

저도 동일한 증상이 나타납니다.
<img src="https://cdn.inflearn.com/public/comments/24f102cd-56ae-4a64-8148-b17c66f78e40/blob" alt="" />
<img src="https://cdn.inflearn.com/public/comments/20d8c038-3151-401e-9eb8-86a031f27d19/blob" alt="" />

alsdud1513501876

Posts