기본 방식(lazy loading)으로 패치가 되지 않는 문제점

뷰 랜더링 전에 study의 manager 정보를 출력을 해보았습니다. @GetMapping("/study/{path}")public String viewStudy(@CurrentUser Account account, Model model, @PathVariable String path){ Study study = studyService.getStudy(path); model.addAttribute(account); model.addAttribute(study); log.info(study.getManagers().toString()); // study의 Manager 정보가 잘 패치 되는지 확인 return "study/view";} lazy loading에 의해서 study 테이블 쿼리 한번, study_manager 테이블 쿼리 한번으로, 쿼리는 정상적으로 출력이 되었습니다. 하지만 당연히 해당 코드에서 에러가 발생하였고, 에러 내용은 다음과 같았습니다. log.info(study.getManagers().toString()); (사진) 에러에서는 Large Objects 는 자동 커밋모드에서 사용할 수 없다고 말하고 있습니다! 해당 문제로 인해서 manager 정보가 제대로 패치가 되지 않는 것 같습니다. 다음은 웹페이지 상의 에러입니다! (사진) 마찬가지로 lob stream 에 접근할 수 없다고 합니다. (사진) 참고로 조인 테이블에는 해당 study에 대한 manager 정보가 잘 저장이 되어있습니다!

기본 방식(lazy loading)으로 패치가 되지 않는 문제점

안녕하세요. 기선님! (사진) 제가 질문할때 오타가 있었네요. account_manager 테이블이 아니라 study_manager 테이블이었습니다. 질문 게시글과 마찬가지로 study_manager 테이블에 해당 study에 대한 manager 객체가 존재하는데도 패치가 되지 않았었습니다! 동일한 study_manager 테이블에 대해서 @EntitiyGraph를 통해서 study 객체와 한번에 전부 패치 받을때는 잘 받아와지는데 Lazy loading으로는 패치가 안되었네요!

Adaptor 패턴의 사용 (UserAccount)

기선님 계속해서 진행해보다가 질문을 드립니다! 기존의 form 입력값으로 로그인을 하는 과정에서는 시큐리티 인증 처리 과정에 의해서 UserDetailsService의 loadUserByUsername 메서드의 리턴값인 UserDetails의 구현체로 인증을 하게되는데, 제가 사용한 방식은 자동 로그인의 경우 account를 principal로 사용하였습니다. 그렇기 때문에 자동 로그인에 의해서 인증이 된 사용자는 @AuthenticationPrincipal을 통해서 account를 바인딩 받을 수 있었지만, form 로그인으로 인증이 된 사용자는 직접적으로 account를 바인딩 받을 수 없었습니다. 그래서 이를 동일하게 맞춰주기 위해서 UserAccount 클래스를 사용한다고 보면 되는 것인가요? 기선님이 말씀해주신 account와 시큐리티의 UserDetails의 간극이라는 것이 이것이 맞는지 궁금합니다!!

테스트 시 DB 싱크 문제

안녕하세요 기선님! 계속 고민하고 이유를 찾다가 결국은 해결을 하게 됐습니다. 이해를 해서 해결한 것은 아니지만요..^^ 제가 기존 Account 클래스의 tags 초기화 값을 Set tags = new HashSet(); 으로 초기화 해주지 않아 기본적으로 null 을 참조하고 있었습니다. 하지만 그래도 이해가 되지 않는 부분이 이전에 애플리케이션에서 실행할 당시, tags의 초깃값을 지정해주지 않아도 트랜잭션 처리를 해주면 DB와 잘 싱크가 되었는데, 테스트에서는 그것이 잘 적용이 안 되었습니다! 이러한 차이점은 어찌해서 발생하는지 궁금합니다..ㅎㅎ! 기본적으로 null을 참조하게 하는 것이 좋지 않은건 알고 있지만, 트랜잭션 처리가 되지 않았던 부분은 의문이네요!

[자문자답] 대안소스로 해도 똑같이 not found에러 발생.

정말 감사합니다 ㅠㅠ 저도 csv 파일 이름을 한번 수정해보니 바로 작동하네요!! 왜그런 것일까요...

테스트 시 DB 싱크 문제

안녕하세요 기선님! 기선님 말씀대로 디버거로 break 포인트들을 찍어서 확인해본 결과, 실제 애플리케이션 실행에서는 addTag 메소드에서 트랜잭션 내부에 있는 Optional 객체인 byId를 생성하고, 이에는 당연히 DB와 싱크된 tags 정보가 있었습니다!! 하지만 테스트 코드에서 생성된 Optional 객체인 byId에서는 트랜잭션 내부임에도 불구하고 tags 정보를 받아오지 못하여 그 인스턴스가 null인 것을 확인 할 수 있었습니다..!! 트랜잭션 내부에 있다고 생각이 되는데 왜 싱크가 잘 안된것인지 모르겠어서 다시 말씀드리게됐네요..! (사진) 비록 해결은 못했지만, 덕분에 디버거를 통해서 상태를 확인하는 방법에 대해서 학습을 할 수 있었습니다!^^ 추가로 테스트 클래스에서 Transactional을 주지 않았을때에는 account에 tags 컬렉션에 예외를 발생시키지만 (사진) byId의 tags 필드는 또 DB와의 싱크가 되는 것인지, PersistentSet에 대한 정보가 있었습니다..!! (사진)