• 친구 스키마 작성

    • OneToOne 로 user정보를 가지고 있도록 구성
      • 유저정보 중복. 제거하기로 한다.
    • OneToMany로 user에 다른 User list가 포함된 형태로 구성
    • ManyToMany 구성이 맞다.

    Untitled

    • id는 자동생성말고 User id 와 동일하게 가도록 한다.
    • https://ict-nroo.tistory.com/126
    • https://ict-nroo.tistory.com/125

  • 친구 레포지토리, 서비스, dto 작성

    • 이전에 작업했던 messsage, user 참고해서 수행
    • 매번 User 생성할 때 Friends 정보도 같이 생성

  • API controller 작성

    • 메인 api 작성할 때 하나로 하는게 나은가, 여러개로 나눠서 하는게 나은가.
    • https://softwareengineering.stackexchange.com/questions/341872/rest-api-design-multiple-calls-vs-single-call-to-the-api
    • 일반적으로 분리해서 하는게 적절. 개발 관련해서도(테스트) 성능 관련해서도 더 좋다는게 정설
    • 분리해서 작성 후 테스트 까지 추가
    • 테스트에서 에러 발생
    org.hibernate.LazyInitializationException: failed to lazily initialize a collection of role: com.ys.chatserver.domain.friends.Friends.friendSet, could not initialize proxy - no Session
    • https://velog.io/@ohjinseo/테스트-코드에서-getOne-또는-getById쓸-시-LazyInitializationException-could-not-initialize-proxy-no-Session
      • OneToMany 를 사용하는 경우 Fetch type default 가 lazy loading인데 (성능상의 이유인 것으로 보임)
      • 객체를 가져올 때 proxy 객체를 가져오고 실제 객체에 접근하는 순간 DB에서 가져오는 방식
      • 따라서 지연 로딩을 하려면 해당 객체는 무조건 영속성 컨텍스트에서 관리해야 한다. 라고 한다
      • @Transaction 어노테이션을 붙이면 해결되긴 함.
      • 이 부분은 따로 공부가 필요...

  • 스키마 변경

    • 생각해보니 요청은 유저 아이디로 요청을 하게 되고 (userseq를 아니면 프론트에서 가지고 있어야 하는데, 이건 좀 고민이 필요..)
    • userSeq 로 가져오도록 우선 생각하고 이 후에 수정은 고민하기로 한다.
    • User Friend 관계를 OneToMany → ManyToMany로 변경
    • 음 ManyToMany는 실무에서는 사용하지 않는 것을 권장한다. 굳이 나도 쓸 필요는 없을 듯 하다.
      • 실제로 동작 방식은 해당 어노테이션을 사용하는 경우 숨겨진 테이블을 하나 더 생성해서 동작하는 방식이 됨
      • 해당 조인테이블에 과도한 데이터가 추가될 가능성이 있고,
      • 매핑 정보 외에 추가 정보는 넣을 수 없다.
      • 예상하지 못한 쿼리가 수행될 수 있다.
    • rdbms 에서 row 수는 성능적으로 크게 문제가 되지 않는다고 한다.
      • user - friendUser 라는 테이블을 생성한다 가정하면 (일반적인 서비스라면) 100억 이상은 될 것 같음 → 너무 깊게 고민 x
      • 그냥 USERID - friendUserID 저장하는 것으로 정의

  • User - Friend 스키마 재정의

    • 두 컬럼 모두 @ManyToOne