પેજિનેશન મોટા પરિણામોના સમૂહને અલગ-અલગ પેજમાં વિભાજિત કરે છે, જેથી તમે એક સાથે હજારો રેકોર્ડ લોડ ન કરો. તે પারફોર્મન્સ અને ઉપયોગિતા માટે આવશ્યક છે. Django Paginator ક્લાસ ટેમ્પ્લેટ/views માટે પ્રદાન કરે છે, અને DRF APIs માટે બિલ્ટ-ઇન પેજિનેશન આપે છે.
# ❌ loading everything — slow, memory-heavy, bad UX with thousands of rows
articles = Article.objects.()
from django.core.paginator import Paginator
def article_list(request):
articles = Article.objects.all().order_by("-created_at") # ORDER matters for consistent pages
paginator = Paginator(articles, 20) # 20 items per page
page_number = request.GET.get("page") # ?page=2
page_obj = paginator.get_page(page_number) # the requested page
return render(request, "list.html", {"page_obj": page_obj})
<!-- in the template -->
{% for article in page_obj %}
<h2>{{ article.title }}</h2>
{% endfor %}
{% if page_obj.has_previous %}<a href="?page={{ page_obj.previous_page_number }}">Prev</a>{% endif %}
Page {{ page_obj.number }} of {{ page_obj.paginator.num_pages }}
{% if page_obj.has_next %}<a href="?page={{ page_obj.next_page_number }}">Next</a>{% endif %}
Paginator queryset ને પેજમાં સ્લાઇસ કરે છે અને get_page() નેવિગેશન હેલ્પર્સ (has_next, next_page_number, વગેરે) સાથે પેજ ઑબ્જેક્ટ પરત કરે છે — નોટ કરો કે તે ક્વેરીમાં LIMIT/OFFSET ઉમેરે છે, તેથી ડેટાબેસમાંથી માત્ર એક જ પેજ ફેચ થાય છે.
# global default in settings.py
REST_FRAMEWORK = {
"DEFAULT_PAGINATION_CLASS": "rest_framework.pagination.PageNumberPagination",
"PAGE_SIZE": 20,
}
# now list endpoints are automatically paginated, returning:
# { "count": 1000, "next": "...?page=3", "previous": "...?page=1", "results": [...] }
DRF એક વાર કન્ફિગર કર્યા પછી લિસ્ટ એન્ડપોઇન્ટને સ્વચાલિતપણે પેજિનેટ કરે છે, પરિણામોની સાથે પેજ મેટાડેટા (count, next/previous લિંક્સ) પરત કરે છે — ક્લાયન્ટ્સ પ્રદાન કરવામાં આવેલ URLs દ્વારા નેવિગેટ કરે છે.
PageNumberPagination → ?page=2 (simple page numbers)
LimitOffsetPagination → ?limit=20&offset=40 (flexible offsets)
CursorPagination → opaque cursor; consistent & performant for large/changing data
(avoids OFFSET performance issues on huge datasets)
⚠️ OFFSET-based pagination (page/offset) gets SLOWER on deep pages of huge tables
(the DB must skip OFFSET rows). For very large datasets, CURSOR pagination
(keyset, using a WHERE on an indexed column) is far more efficient.
⚠️ Always ORDER BY a stable field, or pages can be inconsistent/repeat items.
પેજિનેશન પરફોર્મન્ટ, ઉપયોગી એપ્લિકેશન્સ બનાવવા માટે આવશ્યક છે જે વાસ્તવિક ડેટા વોલ્યુમ સંભાળે છે — તેના વિના, લિસ્ટિંગ એન્ડપોઇન્ટ્સ અને પેજ્સ જે સંપૂર્ણ ટેબલ્સ (સંભવતઃ હજારો અથવા લાખો પંક્તિઓ) લોડ કરે છે તે ધીમું, મેમોરી-ઇન્ટેન્સિવ અને ઉપયોગમાં આવતું નથી, જે ડેટાબેસને તણાવમાં મૂકે છે અને ઉપયોગકર્તાઓ અને ક્લાયન્ટ્સને અભિભૂત કરે છે.
પેજિનેશن સમજવું રોજીંદી વ્યવહારિક જ્ઞાન છે: Django નો Paginator પરંપરાગત views/templates સંભાળે છે (querysets ને નેવિગેશન હેલ્પર્સ સાથે પેજમાં સ્લાઈસ કરે છે, LIMIT/OFFSET દ્વારા કુશળતાપૂર્વક માત્ર એક જ પેજ ફેચ કરે છે), અને DRF નો બિલ્ટ-ઇન પેજિનેશન APIs સંભાળે છે (એક વાર કન્ફિગર કર્યા પછી લિસ્ટ એન્ડપોઇન્ટ્સને સ્વચાલિતપણે મેટાડેટા અને નેવિગેશન લિંક્સ સાથે પેજિનેટ કરે છે) — બંને તમે સર્વર-રેન્ડર્ડ પેજ્સ અથવા APIs બનાવો તેના પર આધાર રાખે છે.
બંને કન્ટેક્સ્ટમાં પેજિનેશન લાગુ કરવાનું જ્ઞાન લગભગ કોઇપણ ડેટા-લિસ્ટિંગ ફીચર માટે જરૂરી છે.
પારફોર્મન્સ ન્યુન્સ ખાસ કરીને મૂલ્યવાન સીનિયર-લેવલ જ્ઞાન છે: માનક OFFSET-આધારિત પેજિનેશન ખૂબ જ મોટી ટેબલ્સના ઊંડા પેજ્સ પર હ્રાસ પામે છે (ડેટાબેસને તમામ અગાઉની પંક્તિઓ છોડી દેવી પડે છે), તેથી કર્સર (keyset) પેજિનેશન વિશાળ અથવા ઝડપથી બદલાતા ડેટાસેટ્સ માટે કુશળ પસંદગી છે, અને હંમેશા સ્થિર ફીલ્ડ દ્વારા ક્રમાંક કરવું પેજ્સમાં અસંગત અથવા ડુપ્લીકેટ પરિણામોને અટકાવવા માટે જરૂરી છે.
મૂળભૂત મિકેનિક્સ (Paginator, DRF પેજિનેશન ક્લાસ્સીસ) અને આ પારફોર્મન્સ ધ્યાનમાં રાખવાનું (OFFSET વર્સ કર્સર પેજિનેશન, સંગત ક્રમાંક) સમજવું એપ્લિકેશન્સ બનાવવા માટે મહત્ત્વપૂર્ણ છે જે ડેટા વૃદ્ધી પર ઝડપી અને સાચું રહે — પેજિનેશન એક સર્વવ્યાપી આવશ્યકતા છે, અને તેને સારી રીતે કરવું, ખાસ કરીને સ્કેલ પર, એક વ્યવહારિક કૌશલ્ય છે જે સીધું એપ્લિકેશન પારફોર્મન્સ અને ઉપયોગકર્તા અનુભવને પ્રભાવિત કરે છે.