앱개발자인데 백엔드 공부중이다
근데 공부중에 궁금한게 생겼는데
예를들어 페이지네이션도 되는데 삭제도 되는 기능이 있어
pageSize는 10개라고 가정해볼게
사용자가 3페이지까지 페이징을 했어 그러면 30개를 내려줬겠지?(29번째 index까지)
근데 사용자가 12번째 아이템을 하나 삭제했어
그럼 db에서 하나씩 다 앞으로 당겨지면서 30번째 인덱스 아이템은 3페이지에 포함이 될거아니야
근데 사용자가 4페이지 로드를 했어
그러면 db에는 30번째 인덱스 아이템은 3페이지에 들어가있으니까 사용자는 31번째 아이템부터 받게 될텐데
이 30번째 아이템은 어떻게 처리해야하는거임?
기존의 31번 나올듯? 하나당겨져서. 실제로 실시간으로 글많이올라오는 갤가서 2페이지로 넘어가면 1페이지에잇던글 위에 나오잖아. 링크주소도 바껴서 이미눌럿던링크표시?(보라색되는거)도 사라져잇음
미리캐시...? 해두고 꺼내쓰면 몰루(이런걸 하나?)
이게 맞나 모르겠는데 no offset 페이징이랑 커서기반 페이징 한번 검색ㄱㄱ
페이지 api 요청에 따라 달라짐. 마지막에 조회 결과로 나온 아이디를 기준으로 요청을 보내면 사용자는 30번째 아이템을 볼 수 있음 근데 단순 페이지로 조회한다고하면 30번째 아이템은 못보고 지나가는거임 이건 백엔드가 어떻게 처리하느냐, 도메인이 어떻게 되냐에 따라 달라짐. 단순 커뮤니티글이면 그거 하나 안본다고해서 사용자에게 타격이 크지 않음
아 근데 이거 좀 대단하네 이렇게 처리 하면 될듯? 그냥 내려준 데이터의 마지막 인덱스 아이디를 클라이언트가 가지고 있다가 다음 페이지 요청할때 그냥 페이지 사이즈랑 아이템 아이디만 보내면 되는거잖아 그치?
사용자가 삭제가 가능하다 = 중요한 정보가 아니니 못봐도 된다라고 생각하시면 될 듯 거기다가 3페이지 > 4페이지 누르는 0.1초 안에 데이터가 삭제되어서 30번째 아이템을 못보는 사람이 많은 것도 아니니 현실적으로 고려하시면서 처리하시면 댐
ㅇㅇ 저게 윗댓글에서 언급한 no offset, 커서 기반 페이지네이션인데 성능최적화 할 때 쓰이는 기법임
게시판 같은 거면 사용자가 글 하나 못본다고 큰일 나는 건 아니니까 상관 없긴 함. 근데 Spring Batch에선 PagingReader 쓸 때 데이터 삭제하는 로직 있으면 데이터를 못보고 지나치는 문제가 있어서 위에 말대로 no offset paginatination 쓰면 좋음.