TIL 230704 : @Getter의 중요성 (허무한 단순 오류 해결)

문제발생

퍼온 이미지이지만, 오류메시지가 비슷함

Reply 엔티티 작업하다 또 다시 이전처럼 Reponse가 오질 않았습니다.

디버깅을 돌려봅니다.

 

 

우선 claims까지는 잘가져옵니다.

 

갑자기 hibernate_interceptor가 나오고 원래의 멤버들은 null로 나옵니다.

User객체를 다르게 받아오고 있다.

 

 

시도 1. UserRepository를 제대로 주입 못 받고 있다?

여기에는 Bean이 주입이 안되어서 그런건가 Repository를 잘 못 가져오는 건지 생각했습니다.

다른 곳은 이렇게 옆에 Bean 주입받는게 보이는데 말이죠.

 

근데 이는 @RequiredArgsConstructor 어노테이션의 영향이고 크게 중요한건 아니었습니다.

 

 

시도 1-2. 다른 객체가 생성되서 그런가

제대로 작동할 때

오류나는 부분의 UserRepository

그래서 저 뒤에 참조값이 다른 것은 아닌가 추측해봤습니다.

-> 아무리 싱글톤으로 Bean이 관리된다지만 저 참조값은 애플리케이션이 실행될 때 또 다시 객체를 생성하기에 달라질 수 있다라고 추측.

 

 

제대로 작동하던 곳의 userRepository의 참조값도 재실행시 변경

 

 

시도 2. DB 테이블 Drop후 다시 시도

 

테이블을 비운 뒤 다시 회원가입 했습니다.

변함없었습니다.

 

 

시도 3. hibernate_interceptor 통제

 

왼쪽처럼 바로 user객체를 가져왔으면 했는데, 계속해서 오른쪽처럼 hibernate_interceptor가 생성된다.

왜 이렇게 불어와졌는지 이해가 안됐지만, 관련해서 찾아보니 영속성 관련된 옵션인 듯 했고, 이는 단순 조회해서 가져오는 것에서 오류를 일으킬만한게 아닌듯 했다.

 

혹시나 하는 마음에 @Transactional을 추가했지만 역시 객체의 수정을 감지하는 더티체킹은 이용될 일이 없었고, 1차캐시의 역할을 하는 것인가 정도의 추측만 남겼다.

 

 

다시 자세히 hibernate_interceptor속성을 찾다보니 'target' 에 user 정보가 들어있었다.

Proxy의 맥락으로 가짜 객체역할을 한다라는 내용을 봤던 건데 해당 내용과 관련된 듯 했다.

결국엔, user를 가져왔나 싶어서 댓글 테이블을 확인해봤다.

 

 

 

 

DB는 진작에 잘 되고 있었다.

앞단에 null을 보자마자 User를 못 찾아 온다고 생각해서 매몰됐는데, 그게 아니었다.

 

 

해결방법 : @Getter의 부재

 

"댓글 Reply 객체가 제대로 생성된 것을 확인하고, 생성에 초첨이 아닌 Response에 초점을 두고 확인해봤다."

Entity는 따로 별다른 게 없었다.

 

 

ReplyResponseDto를 확인했고, 아찔했다.

@Getter가 없었다.

 

 

@Getter 엔딩

---

협업하며 이런 단순한 실수가 오히려 더 나올 수도 있겠다는 생각이 들었다.
파트를 맡은 사람이 잘 해줘야하는 부분이라고 생각할 수도 있고,
먼저 작업해 주신 분이 다 세팅해줬을거라고 믿어서 일 수도 있고.

중요한 건, 소통과 기본기인 듯 하다.

@Getter 가 없으면 동작하지 않는다고 설명했던 강의 내용을 당연하게 흐르듯 받아들였던 게 어렴풋이 생각난다.