पृष्ठांकन परिणामांचा एक मोठा संच वेगळे पृष्ठांमध्ये विभाजित करते, जेणेकरून तुम्ही एकाच वेळी हजारो रेकॉर्ड लोड करत नाही. हे कार्यक्षमता आणि उपयोगिता साठी आवश्यक आहे. Django पारंपरिक views/templates साठी Paginator क्लास प्रदान करते, आणि 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, इ.) आहे — लक्ष्य घ्या की हे query मध्ये 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 एकदा कॉन्फिगर झाल्यानंतर आपोआप list endpoints पृष्ठांकित करते, परिणामांच्या सोबत पृष्ठ metadata (count, next/previous links) परत करते — क्लायंट प्रदान केलेल्या 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.
पृष्ठांकन हे वास्तविक डेटा व्हॉल्यूम हाताळणारी कार्यक्षम, वापरण्यायोग्य अनुप्रयोगे बांधण्यासाठी आवश्यक आहे — याशिवाय, listing endpoints आणि pages जे संपूर्ण tables लोड करते (संभवतः हजारो किंवा लाखो rows) हळू, मेमरी-गहन आणि वापरण्यायोग्य असतात, डेटाबेसवर दबाव टाकते आणि वापरकर्ते आणि क्लायंटला भारी करते.
पृष्ठांकन समजून घेणे दैनंदिन व्यावहारिक ज्ञान आहे: Django चा Paginator पारंपरिक views/templates हाताळते (querysets ला पृष्ठांमध्ये विभाजित करते नेव्हिगेशन सहायकांसह, LIMIT/OFFSET द्वारे फक्त एक पृष्ठ कार्यक्षमतेने मिळवते), आणि DRF चा अंतर्निर्मित पृष्ठांकन APIs हाताळते (एकदा कॉन्फिगर झाल्यानंतर metadata आणि नेव्हिगेशन links सह list endpoints आपोआप पृष्ठांकित करते) — तुम्ही server-rendered pages किंवा APIs बांधत आहात की नाही यावर अवलंबून दोन्ही आवश्यक आहे.
दोन्ही संदर्भांमध्ये पृष्ठांकन कसे लागू करायचे हे जाणून घेणे जवळजवळ कोणत्याही डेटा-listing फीचरसाठी आवश्यक आहे.
कार्यक्षमता सूक्ष्मता विशेषतः मूल्यवान senior-level ज्ञान आहे: मानक OFFSET-आधारित पृष्ठांकन अगदी मोठ्या tables च्या खोल पृष्ठांवर कमी होते (डेटाबेसने सर्व पूर्ववर्ती rows वगळले पाहिजे), म्हणून cursor (keyset) पृष्ठांकन विशाल किंवा वेगाने बदलणार्या datasets साठी कार्यक्षम निवड आहे, आणि नेहमी स्थिर फील्डने क्रमवारी करणे आवश्यक आहे पृष्ठांवर असंगत किंवा डुप्लिकेट परिणाम टाळण्यासाठी.
मूलभूत यांत्रिकी (Paginator, DRF पृष्ठांकन classes) आणि या कार्यक्षमता विचारांची (OFFSET vs cursor पृष्ठांकन, सुसंगत क्रमवारी) समजून घेणे अनुप्रयोगे बांधण्यासाठी महत्वाचे आहे जे डेटा वाढत असताना वेगवान आणि योग्य राहते — पृष्ठांकन सर्वव्यापी आवश्यकता आहे, आणि हे योग्यरित्या करणे, विशेषतः scale वर, हे व्यावहारिक कौशल्य आहे जे थेट अनुप्रयोग कार्यक्षमता आणि वापरकर्ता अनुभव प्रभावित करते.