이번 필수 구현에서 맡은 필수 구현이다!
생각보다 쉬워보이지만 "최근 3번안에 사용한 비밀번호는 사용할 수 없도록 제한합니다" 기능은 까다로워보이지만 할만 하겠다고 생각하고 구현했다가 크게 당해버렸다...
문제를 여러개 맞이했는데 말해볼 예정이다.
- Hibernate에서 Queue를 지원 안 한다.
어자피 Queue는 Collection 인터페이스를 상속받는거니... 굳이 라는 생각이 들긴 했다. 대신 큐의 구현체인 LinkList를 사용하면 된다. 튜터님 말씀에는 Queue가 지원하도록 Hibernate GitHub에 Pull Request를 해봐라 그러는데... 굳이라는 생각이 들면서 왜 지원을 안 하는지 알게 되는 부분이기도 했다.
- LAZY 대신에 EAGER를 써야한다
나는 EAGER는 쓰면 안 되고 무조건 LAZY만 써야한다고 배웠고 실무에서도 LAZY만 쓴다고 했었다. 대표적인 이유는 N + 1 쿼리 문제가 있다. 하지만 LAZY를 쓰면 에러가 써서 EAGER만 써야했다... jpql를 쓰면 된다고 하는데 복잡했다...
User Entity
HistoryPassword
일단 EAGER로 설정된 경우 User 엔티티를 조회할 떄 연관된 HistoryPassword 엔티티도 즉시 함꼐 조회된다. 즉, 사용자 정보를 가져올 떄 해당 사용자의 모든 비밀번호도 함꼐 가져온다.
HistroyPassword의 역할은 무엇인가? 최근 3개의 비밀번호만 저장이 되어있다. 그래서 EAGER를 써서 해당 사용자의 변경된적 있는 모든 비밀번호(최대 3개)를 함꼐 가져온다고 생각 하면 된다.
왜 LAZY를 사용을 권장하는가?
-> 데이터 양 관리: EAGER를 사용하면 사용자 정보를 조회할 떄 관련된 모든 비밀번호들도 함꼐 조회되기 떄문에, 이로 인해 불필요한 데이터를 가져오는 상황이 발생할 수 있다. 이는 응용 프로그램의 DB 부하를 증가시킬수 있다.
하지만 내 코드의 로직은 최대 3개의 변경 되었던 비밀번호만 저장이 되고 새로운 비밀번호로 변경이 되면 가장 마지막에 변경되어 저장이 된 비밀번호를 지워주기 떄문에 "데이터 양 관리"라는 단점에 아무런 피해가 없다!
아마 내가 설계한 코드가 옳은 설계인지는 모르겠다! 지금 궁금한게 많고 튜터님한테 물어볼게 많다... 해결이 되면 여기에도 적지 않을까...
글 잘 봤습니다, 감사합니다.