[11] Spring - 친구요청 관련 쿼리문 트러블 슈팅

2024. 10. 27. 14:59Spring/뉴스피드 프로젝트

728x90

프로젝트 링크

https://github.com/ii-news-feed/ii-news-feed-backend

 

GitHub - ii-news-feed/ii-news-feed-backend

Contribute to ii-news-feed/ii-news-feed-backend development by creating an account on GitHub.

github.com

 

 

📚 담당역할

친구요청생성)

ㄴ 요청받을사람의 기본키id와 status(상태값)을 대기(PENDING) 로 보내 저장

 

친구요청생성 - 예외처리)

ㄴ 요청을 이미 보낸경우
ㄴ 요청받을사람이 이미 나에게 요청을 한 경우
ㄴ 자기자신에게 요청하는 경우

ㄴ 요청받는 사람과 요청보내는 사람의 승인(ACCEPT)값이 대기(PENDING) 또는 승인인 경우

 

친구요청생성 - 예외처리 모두 통과후  등록 되는 조건) 

ㄴ 테이블의 데이터가 아예 0개일 경우

ㄴ 요청 받는사람이 친구요청을 거절(REJECT)했을 경우

 

※  요청 보낼때 - 로그인 고유번호(id) == fromUserId  요청생성 / 요청조회,요청응답 (나눠진 조건에따라 기준 id가 변경)

 

친구요청조회)

ㄴ 상태값이 대기(PENDING)이면서 요청받는 사람과 요청보내는사람의 고유번호(id)를 확인하여 조회


※  요청 조회시 - 로그인 고유번호(id) == toUserId

 

친구요청응답)

ㄴ 본인이 받은 요청이면서 상태값이 대기(PENDING)인 데이터만 응답할 수 있도록

 

친구요청응답 - 예외처리)

ㄴ 입력값이 ACCEPT(승인), REJECT(거절)이 아닐 경우에는 유효하지 않은 상태값으로 예외처리
ㄴ 위의 2가지 조건을 충족한 후 선택한 값이 대기(PENDING)일 경우에만 응답할 수 있도록 2차처리

(조회 조건에 들어가있지만 2차체크)


※  요청 응답시 - 로그인 고유번호(id) == toUserId

 

 

🛠️ 트러블슈팅

1. 개요

- 뉴스피드 프로젝트 개발 중 담당작업 친구요청 부분에서 예외처리 부분을 개발하는 과정에서 발생한 고민과 이슈등에 대해서 트러블 슈팅을 작성해보겠습니다.

 

2. 배경

- 먼저 요청을 보낼때 이미 대기,승인값의 데이터가 있는 경우(이미 내가 보낸 경우)에 대한 예외를 생각하고 쿼리문을 작성했습니다.

 

3. 발단

- 쿼리문을 완벽하게 구현했다고 생각하고 테스트를 했는데 테이블의 데이터가 아예 없는 경우에도 예외처리 되어버리는 오류가 발생했습니다.

 

4. 전개

- 해당 조건(테이블의 데이터가 1개도 없는 경우는 등록되도록)을 추가로 잡기 위해서 새로운 쿼리문을 작성했습니다.

 

5. 위기

- 내가 요청을 보낼사람이 나에게 이미 요청한 경우를 조건으로 잡는 쿼리문을 작성하면서 고민하는 시간이 길어졌습니다.

추가적으로 체크해야할 조건과 테스트하면서 자기자신에게 친구요청이 보내져서 이 부분도 조건을 만들어야하는 것을 뒤늦게 깨달았습니다.

 

6. 절정

-  친구요청생성 / 친구요청목록조회, 친구요청응답 1,2개의 대해서 요청받는사람과 요청보내는사람의 고유번호(id) 기준이 다르다는것을 깨달았다.

 - 요청을 보내는 사람(from_user_id)이 로그인한 상태로 요청하고 요청을 받는 사람(to_user_id)은 받는 입장이기 때문에 이렇게 저장이 된다.

- 하지만 반대로 요청을 조회할땐 로그인한 사람이 (to_user_id)와 매핑되어야하고, 요청 보낸 사람은 (from_user_id)와 매핑이 되어야한다.

- 위와 같은 형태이기 때문에 사실상 쿼리문에서 요청에 대한 경우를 체크할땐 from_user_id, to_user_id 2개를 동시에 체크해야한다. 아래와 같이 2개 컬럼 다 쿼리에서 조건절로 같이 들어가줘야한다.

 

 

7. 결말

1) 해당되는 조건에따라 쿼리문을 별도로 생성하면서 해결해나갔다.

2) @Query 어노테이션을 사용해서 해결했고, 대부분 count()집계함수를 활용했는데 추후에 다이렉트 쿼리 형태를 변경하고 count()함수도 jpa제공하는 형태로 변경할 예정이다.

3) 자기자신에게도 요청을 보내지 못하도록 로그인정보와 보내는사람의 고유번호(id)를 비교하여 예외처리해야한다.

4) 내가 이미 요청을 보낸 경우를 체크할때도 상태값에 대한 체크가 추가로 들어가야한다.

 

고민의 흔적

- 쿼리를 고민하면서 조회하고, 또 조회하고 조건에 대해서 계속 고민했다.

 

728x90