PatientPal

5/24 ~ 5/26

후후후하하하 2024. 5. 24. 17:03

1. git amend 이슈 - 왜 반영 안되는거 같지?

 

2. BaseTime, BaseEntity, @CreatedBy 문제

 

3. Member와 Patient 1 : 1관계에서 연관관계의 주인을 누구로?

- 

 

4. member쪽에 patient or caregiver 엔티티 연관관계 갖게할지?

 - 주인은 patient에 두는데, member 엔티티에도 patient를 둬야하나?

 

5. Patient 엔티티에 환자 특이사항 / 간병 요구사항 같은 컬럼들은 입력값이 매우 길어질 수 있다. 

 - @Column(Text) vs @Lob 둘의 차이 학습 후 무엇을 적용? 장단점이 뭔지. -> 만약 TEXT를 쓴다면 성능 개선을 어떻게 할지

 - https://velog.io/@yullivan/VARCHAR-vs-TEXT

 

 

6. 빌더패턴으로 객체 생성시 값 안넣어도 객체가 생성이됨(null로 들어감). 그러면 null 체크 어떻게함?

-https://growth-coder.tistory.com/172

 

 

7. Match 테이블은 DB 예약어라 사용이 안돼서 테이블명을 matches로 변경함.

 

 

 

8. aws rds로 데베를 공유하다보니, ddl = create 시에 다른 팀원이 작업한 테이블 drop이 외래키 제약조건때문에 제대로 되지 않는 상황이 발생. => h2로 데베 변경 후 진행 => 스키마 확정 후 sql로 합치기

 

 

 

 

5/25 문제 정리

1. 변수 네이밍 규칙 - camel case? yaml에 physical규칙 적용

 

2. 설정관리 yml 단일 파일에서 ? 아니면 application-local, -prod.yml로 나눠서?

 - 우선 단일파일 내부에서 profile 그룹을 나눠서 관리, 이후 설정 정보 많아지면 분리 고려.

 

 

5/26 문제 정리

  1. JpaRepository에 @Repository 생략 가능한 이유
    1. Spring Data JPA에서 @Repository 어노테이션을 생략할 수 있는 이유는 Spring의 컴포넌트 스캐닝과 Spring Data JPA의 자동 구성 기능 덕분입니다. 이를 통해 리포지토리 인터페이스가 자동으로 Spring의 빈으로 등록되고 예외 처리가 향상됩니다.Spring Data JPA는 리포지토리 인터페이스를 자동으로 감지하고, 이를 구현하는 프록시 빈을 생성합니다. 이 과정에서 @Repository 어노테이션이 없어도 자동으로 빈으로 등록됩니다. 이는 Spring Data JPA의 리포지토리 인터페이스가 Spring의 컴포넌트 스캐닝 메커니즘에 포함되기 때문입니다.
    2. 컴포넌트 스캐닝과 @EnableJpaRepositories
    3. Spring Boot 애플리케이션에서는 @SpringBootApplication 어노테이션이 있는 클래스가 있는 패키지와 그 하위 패키지를 자동으로 스캔합니다. 이 과정에서 Spring Data JPA 리포지토리 인터페이스도 자동으로 감지됩니다. @EnableJpaRepositories 어노테이션을 사용하면 리포지토리가 정의된 패키지를 명시적으로 지정할 수 있습니다. 그러나 Spring Boot는 자동 구성을 제공하므로 일반적으로 생략 가능합니다.
    4. 스프링은 extends JpaRepository, 즉 상속을 받는지를 확인하여 자동으로 감지해서 리포지토리를 등록한다.
  2. Matching 과정에서, 중복 신청 가능하게 할지, 요청 거절을 추가할지, 거절을 없애고 열람/미열람으로 나뉘어서 돌려 거절하기 식으로 풀지, ReadStatus를 ENUM으로 넣어야 하는지, Patient의 필드에 boolean으로 넣어야 할지.(따로 이력서를 만들어서 보내는 것이 아닌, 프로필을 기반으로 상대에게 전송되기 때문에, 프로필(환자 Entity) 자체에서 isRead 변수를 가지고 있으면 한번 true로 바뀌면 계속 true로 됨. ->  무슨 문제라 명칭하지? 동시성?) 이력서를 기반으로 보내는 거면 이력서에 boolean isRead 을 넣으면 될듯한데, 우리 서비스는 이력서기반이 아닌, 프로필 기반이다. 
  3. 상대에게 요청을 전송하고, 상대가 수락을 했는데, 그 이후 내가 프로필을 수정하면 상대가 수락한 프로필도 자동으로 바뀐다. (왜냐하면 같은 Patient 엔티티이기 때문에).
    1. 이걸 허용할거냐, 아니면 요청 시 프로필을 저장시킬거냐 가 있는데, 안전성을 위해 요청 시 프로필을 저장시키는 쪽으로 생각해봤다.
    2. 매칭 시, 스냅샷을 저장하는 쪽으로 - gpt가 알려줌