# 어제 무엇을 했나요?
- 1. 리뷰 전체조회api 장르 필터걸기
- 2. 리뷰요약 api에서 1차 욕설필터를 라이브러리 이용으로 전환
# 오늘은 무엇을 할 것인가요?
- 1. 리뷰 전체조회api PR리뷰 반영
# 진행하는데 어려운 부분(도움이 필요한 부분)이 있나요?
오늘 학습 내용 ✅
PR
- N+1
- 검색 필터 대소문 처리
대소문
__iexact또는__icontains를 사용하여 대소문자 방지를 진행하려 하였으나- DB데이터를 불러와서 선택창으로 만들것이기 때문에 굳이 필요없어짐
필터 방식 변경
현재
- 사용자가 장르명을 직접 타이핑하여 검색함
- 이거때문에 대소문 처리를 해야함
- 정확한 장르명을 모르면 조회조차 불가능
- 사용자가 장르명을 직접 타이핑하여 검색함
변경 방안
- 저번주에 만든 DB데이터에 저장된 장르 데이터를 조회하는 api를 이용
- DB데이터를 기준으로 선택창 방식 사용 예정
.distinct()
- 데이터베이스 쿼리 결과에서 중복된 행(row)을 제거하는 역할
중간 리뷰 반영
exception 한 위치에서 관리
- core에서 handler로 전역에서 발생하는 공통예외를 관리함
- 각 개별앱에서 앱의 비즈니스 로직에서만 발생하는 예외를 정의
쿼리는 최대한 아끼자
- get_summary
- 게임 존재 여부 없애기
- game.summary.exist
- get조회는 풀스캔
- exist가 효율적임
- get_summary
새롭게 알게된 내용 ✅
OneToOneField 역참조의 특성
- OneToOne 관계에서 역참조 속성인 summary에 접근할 때,
- Django는 해당 데이터가 메모리에 있는지 먼저 확인합니다.
- 데이터가 없다면 DB에 쿼리를 날려 데이터를 가져오려 시도합니다.
- 보통 "역참조(Reverse Relation)는 prefetch_related를 써야 한다"고 인지함
- 1:1 관계(OneToOneField)는 예외적으로 select_related를 지원하며 성능상 더 유리
select_related 가능 이유
- ForeignKey의 역참조(game.reviews 등)는
- 결과가 여러 개(List)라서 DB의 JOIN으로 처리하기 까다롭지만(데이터 뻥튀기 문제),
- OneToOneField의 역참조는 결과가 무조건 1개(또는 0개)입니다.
- 따라서 데이터베이스 차원에서 JOIN을 해도 결과 행(Row) 수가 늘어나지 않으므로,
- Django는 역참조임에도 불구하고 select_related를 통한 SQL JOIN을 지원합니다.
- ForeignKey의 역참조(game.reviews 등)는
무한스크롤 작동 원리
- User: 스크롤을 내림.
- Front: "어? 바닥이네? 2페이지 주세요." (GET /reviews?page=2)
- Back: 2페이지 데이터(10개)만 줌.
- Front: 기존 목록 아래에 이어 붙임.
오늘 발생한 문제(발생 했다면) ✅
안녕하세요.