TIL - 21.01.28

1 minute read

페이징 완성도

Pageable 구현체

  • 기본 생성자가 있다면 오버로딩을 잘 활용하자

  • 생성자에서 반드시 Validation 처리해줄 것.
    • 음수값, 최솟값등 체크해주자
  • final 로 만들어서 수정 불가한 Immutable 로 만들기

image-20210129122215811

실수하는 것 - Validation 체크

input값이 이상적으로 들어오는 케이스만 고려하고 있다.

offset과 limit이 숫자가 아닌 문자가 들어왔다면?

문자를 숫자를 만드려다가 NumberFormatException이 발생한다. request가 페이징 API 쿼리로 들어오지도 않는다. ⇒ 이런식의 처리는 좋지않다. 기본값을 셋팅해놨으니깐 적절한 값이 들어오지 않은 경우 에러가 아닌 Default Value로 처리해주도록 하자.

fallbackPageable

image-20210129122431709

supportsParameter() 구현이 중요

  • 해당 타입이 맞는지 확인할 때,
  • equals로 하는 경우 생길 수 있는 문제

    인터페이스가 아니라 구체 타입이 나온다면 제대로 처리가 되지 않는다.

  • isAssignableFrom() 으로 처리해주자

    상속관계에 있는 것도 확인할 수 있도록 처리해줘야 한다.

항상 생각할 것

  • 외부의 입력값을 절대로 믿지말고 Validation을 하자
  • 모든 가능한 예외사항을 고려해서 코드를 만들자. 의도하지 않은 에러를 만들지 말자
  • 구체타입을 쓰는 것보다 인터페이스를 써서 많이 처리한다.

좋아요 API

적어도 JOIN은 잘 작성할 수 있어야한다.

image-20210129122937160

스칼라 서브 쿼리 문제점

추출되는 데이터가 적을(수십개??) 경우에는 select 절안에 select 쿼리를 또 적어도 되겠지만, 스칼라쿼리로 조회되는 데이터양이 많다면 성능에 문제가 있을 수 있다.

주의할 점 - 놓칠 수 있는 Validation

POST는 나와 친구의 POST만 읽을 수 있다.

(로그인한 유저가 1일 때,), /user/2/post/33 POST를 읽을 수 있을까? ⇒ 실패

33번 게시물이 2번 유저의 글이 아니므로, 이것을 체크하는 where 조건을 작성해줘야한다.

voter에서는 /user/2 까지만 체크하므로 쿼리에서 2번 유저가 33번 게시물을 작성한 것이 맞는지를 체크해줘야하는 것이다.

image-20210129123025242