Django REST framework(DRF) APIView Implement Pagination
Django provides a few classes that help you manage paginated data — that is, data that’s split across several pages, with “Previous/Next” links. As apiview is a Django own customize API, pagination can be done by different method.Step to be implemented for APIVIew Pagination are as follows.
Setp 1. Import REST framework Pagination
Django REST Framework provide three way of importing a pagination they are:
PageNumberPagination
LimitOffsetPagination
CursorPagination
In this case, we use LimitOffsetPagination now create a pagination.py file and set up a pagination class:
Setp 2. Setup pagination_class
The LimitOffsetPagination class includes a number of attributes that may be overridden to modify the pagination style.To set these attributes you should override the LimitOffsetPagination class, and then enable your custom pagination class.Here in LimitOffsetPagination class
default_limt : A numeric value indicating the limit to use if one is not provided by the client in a query parameter.
max_limit : It is a numeric value indicating the maximum allowable limit that may be requested by the client.
Setp 3. Setup APIView
before setup a apiview import a BasicPagination and PaginationHandlerMixin from pagination
Now APIView Pagination is ready to use.
Thank for watching.
If you still have any issues with this implementation let me know in the comments.
Pagination made easy with Django Rest Framework
In most cases a user would want quick access to the most recent entries in the result-set, while the older entries are only fetched when the user scrolls up/down or selects the next page of the table.
Pagination is therefore core to any application but there are several ways to implement it using Django. You could go with the Paginator class that comes out of the box if all you need is the bare minimum, but if you are looking for a more feature rich solution, Django Rest Framework is the way to go.
How pagination should work
Any type of pagination can be implemented by following a simple API response pattern. An API must return these 4 details.
- A count of the number of entries in the complete result-set.
- A list of entries which represents one page of the result-set.
- A URL that can be used to fetch the next page, if the next page exists.
- A URL that can be used to fetch the previous page if the previous page exists.
Previously I demonstrated how CRUD applications can be built using DRF with an apple notes like application as a reference and I believe the same example can be used to demonstrate pagination.
Let's say that there are 10 notes in the database, but I only want to look at the latest 2 notes at a time, the API response for the note listing API should look like this
This can be achieved using DRF with 2 lines of code.
Paginating an API response
The quickest way is to set up pagination globally and apply it on all the APIs where a query set is returned as a response.
First make sure you have Django Rest Framework installed in your application, then add these lines of code to settings.py
<p> CODE: https://gist.github.com/sankalpjonn/764a728457b8c3fec4d6b5b1115765f0.js</p>
That's it, we're done! You will now notice that all the APIs that return a query set as a response have automatically become paginated. If this solves your problem then great, but if you want to dig deeper into the rich solutions offered by DRF, please keep reading.
Overriding pagination for each API view
If you would like to override individual views with their own pagination settings, this can be done by writing a custom paginator which inherits from any of the existing paginators that DRF provides.
You can then include a pagination_class in your API view as shown below.
<p> CODE: https://gist.github.com/sankalpjonn/c398b821e2e46419733e21f919e902a5.js</p>
To create a custom pagination class, first create a paginations.py file in your app folder and create a class that inherits from an existing DRF paginator.
<p> CODE: https://gist.github.com/sankalpjonn/4a7ace453e708a1d332a555e997f0177.js</p>
The parameters given in this custom paginator class will enable you to provide a page_size query parameter to determine the size of each page. If this parameter exists, it will override the default page size of 2. The page number itself would be indicated using the query parameter p.
Therefore, calling the URL http://localhost:8000/note/all?p=2&page_size=3 will now result in this response:
This is because of setting a page size of 3 and fetching the second page in the result-set.
Types of paginations offered by DRF
DRF offers 3 types of paginations that you can choose from based on your use case. You can also set any of these types as the default pagination class in settings.py
- Page number pagination
- Limit and offset pagination
- Cursor pagination
Page number pagination
This type of pagination is to used to fetch any arbitrary page from the result-set. How it should be used has already been demonstrated in the above example.
Limit and offset pagination
Simulates a database query where you retrieve part of a result-set from a table by providing a limit and an offset. Limit will constrain the maximum rows returned in the query while offset represents the starting position of the rows with reference to the complete size of the result-set.
<p> CODE: https://gist.github.com/sankalpjonn/89e39507bb1a0f1a5e39c168e75a8c14.js</p>
The limit_query_param and offset_query_param will indicate the names of the query params to be used for limit and offset. You can set a default_limit if no query parameter is provided and a max_limit to restrict the max number of rows returned in a page.
If this paginator class is used, the response returned by the URL http://localhost:8000/note/all?l=3&o=3 would be something like this.
This is because we have specified the limit as 3 which indicates that the page size is 3 and an offset of 3 means that the starting point of this page should be after the first 3 rows in the result-set.
Cursor pagination
Gives you a database cursor of the exact page you are looking at and therefore it becomes very efficient when querying a large dataset, but the limitation is that the ordering cannot be changed and must be unique.
To order the results, one must use a field that is set once during creation and is relatively unique. When this type of pagination is used, we cannot fetch an arbitrary page and can only move forward or backwards in a result-set.
Also, this pagination will not return a count of the entries because there is no query being run on the entire result-set.
<p> CODE: https://gist.github.com/sankalpjonn/74588fe42c44b4b4543dcf748e9e5bd2.js </p>
custom_query_param indicates what query parameter to use to represent a cursor and ordering indicates the field based on which pagination will be applied. Since this field has to have a fixed order and the values must be unique, I have chosen the primary key in descending as the ordering.
This is what the response returned by this type of pagination looks like:
Clicking on the next URL returns
Custom pagination
If you prefer to have the count, previous link and next link in the HTTP headers while the data only contains the list of results, you can make these customisations by overriding the get_paginated_response method in the pagination class that you inherit from any of the above 3 mentioned types of paginations.
<p> CODE: https://gist.github.com/sankalpjonn/e49f95c67fe935952d28cd820c518815.js</p>
You will now see the links in headers and only the actual data in the response
Closing notes
It takes a very low amount of code to paginate any list API using Django Rest Framework and therefore I would highly recommend using it over the default paginator class that Django provides out of the box.
DRF itself inherits from the default paginator class so you can save yourself some time.
�� �� Enjoyed reading?
I write about navigating my life around being a technical co-founder of a startup, leveraging Django to build SaaS products and leading a wholesome life.
Subscribe to my weekly newsletter to get notified on new content published every Sunday. I promise to deliver value and not BS ��
Pagination
Django предоставляет несколько классов,которые помогут вам управлять постраничными данными-то есть данными,разделенными на несколько страниц,со ссылками «Предыдущая/Следующая».
— Документация Джанго
REST-фреймворк включает в себя поддержку настраиваемых стилей пагинации.Это позволяет изменять то,как большие наборы результатов разбиваются на отдельные страницы данных.
API пагинации может поддерживать и то,и другое:
- Ссылки на страницу,которые предоставляются как часть содержания ответа.
- Ссылки на страницы, которые включены в заголовки ответа, такие как Content-Range или Link .
Во всех встроенных стилях в настоящее время используются ссылки,включенные в содержание ответа.Этот стиль более доступен при использовании браузерного API.
Разбивка на страницы выполняется автоматически, только если вы используете общие виды или наборы видов. Если вы используете обычный APIView , вам нужно самостоятельно вызвать API-интерфейс разбиения на страницы, чтобы убедиться, что вы возвращаете постраничный ответ. Посмотрите исходный код для классов mixins.ListModelMixin и generics.GenericAPIView для примера.
Разбивка может быть отключена путем установки класса постраничного в None .
Установка стиля пагинации
Стиль нумерации страниц можно задать глобально, используя PAGE_SIZE настройки DEFAULT_PAGINATION_CLASS и PAGE_SIZE . Например, чтобы использовать встроенную нумерацию пределов / смещений, вы должны сделать что-то вроде этого:
Обратите внимание, что вам нужно установить как класс пагинации, так и размер страницы, который следует использовать. Оба DEFAULT_PAGINATION_CLASS и PAGE_SIZE не None по умолчанию.
Вы также можете установить класс пагинации в отдельном представлении с помощью атрибута pagination_class . Как правило, вы захотите использовать один и тот же стиль нумерации страниц в своем API, хотя вам может потребоваться варьировать отдельные аспекты нумерации страниц, такие как размер страницы по умолчанию или максимальный размер, для каждого просмотра.
Изменение стиля нумерации страниц
Если вы хотите изменить отдельные аспекты стиля пагинации,вы должны переопределить один из классов пагинации и установить атрибуты,которые вы хотите изменить.
Затем вы можете применить свой новый стиль к представлению, используя атрибут pagination_class :
Или примените стиль глобально, используя ключ настроек DEFAULT_PAGINATION_CLASS . Например:
API Reference
PageNumberPagination
Этот стиль пагинации принимает один номер страницы в параметрах запроса.
Request:
Response:
Setup
Чтобы включить PageNumberPagination стиль PageNumberPagination , используйте следующую конфигурацию и установите PAGE_SIZE по своему усмотрению:
На GenericAPIView подклассов вы можете также установить pagination_class атрибут для выбора PageNumberPagination на основе каждого вида.
Configuration
Класс PageNumberPagination включает в себя ряд атрибутов, которые могут быть переопределены для изменения стиля нумерации страниц.
Чтобы установить эти атрибуты, вы должны переопределить класс PageNumberPagination , а затем включить свой пользовательский класс разбиения на страницы, как указано выше.
- django_paginator_class — класс Django Paginator для использования. По умолчанию используется django.core.paginator.Paginator , который подходит для большинства случаев использования.
- page_size — числовое значение, обозначающее размер страницы. Если установлено, это переопределяет настройку PAGE_SIZE . По умолчанию используется то же значение, что и PAGE_SIZE настроек PAGE_SIZE .
- page_query_param — строковое значение, указывающее имя параметра запроса, который будет использоваться для управления разбиением на страницы.
- page_size_query_param — если установлено, это строковое значение, указывающее имя параметра запроса, который позволяет клиенту устанавливать размер страницы для каждого запроса. По умолчанию None , что означает, что клиент может не контролировать запрошенный размер страницы.
- max_page_size — если установлено, это числовое значение, указывающее максимально допустимый запрашиваемый размер страницы. Этот атрибут действителен, только если также задан page_size_query_param .
- last_page_strings — Список или кортеж строковых значений, указывающих значения, которые могут использоваться с page_query_param для запроса последней страницы в наборе. По умолчанию (‘last’,)
- template — имя шаблона, используемого при рендеринге элементов управления пагинацией в API с возможностью просмотра. Может быть переопределено, чтобы изменить стиль рендеринга, или установить значение « None чтобы полностью отключить элементы управления разбиением на страницы HTML. По умолчанию это «rest_framework/pagination/numbers.html» .
LimitOffsetPagination
Этот стиль нумерации страниц отражает синтаксис, используемый при поиске нескольких записей базы данных. Клиент включает в себя как параметр запроса limit, так и offset. Предел указывает максимальное количество возвращаемых элементов и эквивалентен page_size в других стилях. Смещение указывает начальную позицию запроса по отношению к полному набору не разбитых на элементы.
Request:
Response:
Setup
Чтобы включить LimitOffsetPagination стиль LimitOffsetPagination , используйте следующую конфигурацию:
При желании вы также можете установить ключ PAGE_SIZE . Если параметр PAGE_SIZE также используется, то параметр запроса limit будет необязательным и может быть опущен клиентом.
На GenericAPIView подклассов вы можете также установить pagination_class атрибут для выбора LimitOffsetPagination на основе каждого вида.
Configuration
Класс LimitOffsetPagination включает в себя ряд атрибутов, которые могут быть переопределены для изменения стиля нумерации страниц.
Чтобы установить эти атрибуты, вы должны переопределить класс LimitOffsetPagination , а затем включить свой пользовательский класс разбиения на страницы, как указано выше.
- default_limit — Числовое значение, указывающее ограничение для использования, если оно не указано клиентом в параметре запроса. По умолчанию используется то же значение, что и PAGE_SIZE настроек PAGE_SIZE .
- limit_query_param — Строковое значение, указывающее имя параметра запроса «limit». По умолчанию ‘limit’ .
- offset_query_param — строковое значение, указывающее имя параметра запроса «смещение». По умолчанию ‘offset’ .
- max_limit — если установлено, это числовое значение, указывающее максимально допустимый предел, который может запрашивать клиент. По умолчанию None .
- template — имя шаблона, используемого при рендеринге элементов управления пагинацией в API с возможностью просмотра. Может быть переопределено, чтобы изменить стиль рендеринга, или установить значение « None чтобы полностью отключить элементы управления разбиением на страницы HTML. По умолчанию это «rest_framework/pagination/numbers.html» .
CursorPagination
Пагинация по курсору представляет собой непрозрачный индикатор «курсор»,который клиент может использовать для пролистывания страницы через результирующий набор.Этот стиль пагинации представляет только прямые и обратные элементы управления и не позволяет клиенту перемещаться по произвольным позициям.
Пагинация на основе курсора требует уникального,неизменного порядка расположения элементов в результирующем наборе.Этот порядок может обычно быть меткой времени создания записей,так как он представляет собой последовательный порядок нумерации страниц.
Пагинация на основе курсора более сложна,чем другие схемы.Она также требует,чтобы результирующий набор представлял собой фиксированный порядок,и не позволяет клиенту произвольно индексировать его в результирующий набор.Однако это дает следующие преимущества:
- Обеспечивает последовательный просмотр страниц. При правильном использовании CursorPagination гарантирует, что клиент никогда не увидит один и тот же элемент дважды при перелистывании записей, даже если новые элементы вставляются другими клиентами во время процесса разбиения на страницы.
- Поддерживает использование с очень большими наборами данных.При работе с очень большими наборами данных использование стилей пагинации со смещением может стать неэффективным или непригодным.Вместо этого схемы пагинации на основе курсора имеют свойства фиксированного времени и не замедляются по мере увеличения размера набора данных.
Детали и ограничения
Правильное использование пагинации на основе курсора требует небольшого внимания к деталям. Вам нужно подумать о том, к какому порядку вы хотите применить схему. По умолчанию это порядок «-created» . Это предполагает, что в экземплярах модели должно быть «созданное» поле отметки времени , и будет представлено представление в виде «временной шкалы» с разбивкой по страницам, с самыми последними добавленными элементами.
Вы можете изменить порядок, переопределив атрибут ‘ordering’ в классе пагинации, или используя класс фильтра OrderingFilter вместе с CursorPagination . При использовании с OrderingFilter вы должны строго ограничить поля, по которым пользователь может упорядочивать.
Правильное использование пагинации курсора должно иметь поле заказа,которое удовлетворяет следующим требованиям:
- Должно быть неизменным значением,например,временная метка,слизняк или другое поле,которое устанавливается только один раз,при создании.
- Должны быть уникальными или почти уникальными.Хорошим примером являются метки времени с точностью до миллисекунды.В этой реализации пагинации курсора используется умный стиль «позиция плюс смещение»,который позволяет ему правильно поддерживать не-строгие-единообразные значения как порядок следования.
- Должно быть непреодолимое значение,которое может быть принуждено к строке.
- Не должно быть поплавка. Точные ошибки легко приводят к неверным результатам. Подсказка: используйте вместо этого десятичные дроби. (Если у вас уже есть поле с плавающей точкой и вы должны разбить его на страницы, пример подкласса CursorPagination , который использует десятичные дроби для ограничения точности, доступен здесь .)
- Поле должно иметь индекс базы данных.
Использование поля заказа,которое не удовлетворяет этим ограничениям,как правило,все равно будет работать,но вы потеряете некоторые преимущества пагинации курсора.
Для получения более подробной технической информации о реализации, которую мы используем для разбивки на страницы курсора, в блоге «Построение курсоров для API Disqus» представлен хороший обзор базового подхода.
Setup
Чтобы включить стиль CursorPagination в глобальном масштабе, используйте следующую конфигурацию, изменив PAGE_SIZE по желанию:
На GenericAPIView подклассов вы можете также установить pagination_class атрибут для выбора CursorPagination на основе каждого вида.
Configuration
Класс CursorPagination включает в себя ряд атрибутов, которые могут быть переопределены для изменения стиля нумерации страниц.
Чтобы установить эти атрибуты, вы должны переопределить класс CursorPagination , а затем включить свой пользовательский класс разбиения на страницы, как указано выше.
- page_size = числовое значение, обозначающее размер страницы. Если установлено, это переопределяет настройку PAGE_SIZE . По умолчанию используется то же значение, что и PAGE_SIZE настроек PAGE_SIZE .
- cursor_query_param = Строковое значение, указывающее имя параметра запроса «курсора». По умолчанию ‘cursor’ .
- ordering = Это должна быть строка или список строк, указывающий поле, к которому будет применена пагинация на основе курсора. Например: ordering = ‘slug’ . По умолчанию -created . Это значение также может быть переопределено с помощью OrderingFilter в представлении.
- template = имя шаблона для использования при рендеринге элементов управления разбиением на страницы в просматриваемом API. Может быть переопределено, чтобы изменить стиль рендеринга, или установить значение « None чтобы полностью отключить элементы управления разбиением на страницы HTML. По умолчанию это «rest_framework/pagination/previous_and_next.html» .
Пользовательские стили нумерации страниц
Чтобы создать собственный класс сериализатора разбивки на страницы, вы должны наследовать подкласс pagination.BasePagination , переопределить методы paginate_queryset(self paginate_queryset(self, queryset, request, view=None) и get_paginated_response(self, data) :
- Метод paginate_queryset передается начальному набору запросов и должен возвращать итерируемый объект. Этот объект содержит только данные запрошенной страницы.
- Метод get_paginated_response передается сериализованным данным страницы и должен возвращать экземпляр Response .
Обратите внимание, что метод paginate_queryset может установить состояние для экземпляра нумерации страниц, которое впоследствии может использоваться методом get_paginated_response .
Example
Допустим,мы хотим заменить стиль вывода страниц по умолчанию на измененный формат,который включает в себя следующую и предыдущую ссылки во вложенном ключе ‘links’.Мы можем указать пользовательский класс разбивки по страницам:
Затем нам нужно будет настроить пользовательский класс в нашей конфигурации:
Обратите внимание, что если вы заботитесь о том, как упорядочение ключей отображается в ответах в просматриваемом API, вы можете использовать OrderedDict при создании тела разбитых на страницы ответов, но это необязательно.
Используя свой собственный класс разбивки по страницам
Чтобы ваш пользовательский класс нумерации использовался по умолчанию, используйте параметр DEFAULT_PAGINATION_CLASS :
Ответы API для конечных точек списка теперь будут включать заголовок Link вместо ссылок на нумерацию страниц в качестве части тела ответа, например:
Пользовательский стиль нумерации страниц с использованием заголовка «Ссылка»
Нумерация страниц и схемы
Вы также можете сделать элементы управления разбиением на страницы доступными для автогенерации схемы, предоставляемой платформой REST, путем реализации get_schema_fields() . Этот метод должен иметь следующую подпись:
Метод должен возвращать список экземпляров coreapi.Field .
управления пагинацией HTML
По умолчанию использование классов разбиения на страницы приведет к отображению элементов управления разбиением на страницы HTML в обозреваемом API. Есть два встроенных стиля отображения. В PageNumberPagination и LimitOffsetPagination классы отображения списка номеров страниц с предыдущей и следующей контрольной группы . Класс CursorPagination отображает более простой стиль, который отображает только предыдущий и следующий элемент управления.
Настройка элементов управления
Вы можете переопределить шаблоны,которые отображают элементы управления пагинацией HTML.Два встроенных стиля:
- rest_framework/pagination/numbers.html
- rest_framework/pagination/previous_and_next.html
Предоставление шаблона с любым из этих путей в глобальном каталоге шаблонов переопределит рендеринг по умолчанию для соответствующих классов пагинации.
В качестве альтернативы вы можете полностью отключить элементы управления разбиением на страницы HTML, создав подклассы существующих классов, установив template = None в качестве атрибута класса. Затем вам нужно будет настроить ключ настроек DEFAULT_PAGINATION_CLASS , чтобы использовать пользовательский класс в качестве стиля нумерации страниц по умолчанию.
Low-level API
Низкоуровневый API для определения, должен ли класс пагинации отображать элементы управления или нет, отображается как атрибут display_page_controls в экземпляре пагинации. Для пользовательских классов разбиения на страницы следует установить значение True в методе paginate_queryset , если они требуют отображения элементов управления разбиением на страницы HTML.
.to_html() и .get_html_context() методы могут быть переопределены в пользовательском классе постраничной для того , чтобы настроить дополнительные параметры , как элементы управления оказаны.
сторонние пакеты
Также доступны следующие пакеты услуг сторонних организаций.
DRF-extensions
DRF-extensions пакета включает в себя PaginateByMaxMixin класс подмешать , который позволяет вашим клиентам API указать ?page_size=max , чтобы получить максимально допустимый размер страницы.
drf-proxy-pagination
В пакет ProxyPagination drf-proxy-pagination pagination входит класс ProxyPagination, который позволяет выбрать класс пагинации с параметром запроса.
link-header-pagination
django-rest-framework-link-header-pagination пакет включает в себя LinkHeaderPagination класса , который обеспечивает разбиение на страницы с помощью HTTP Link заголовка , как описан в документации для разработчиков GitHub в .
django-rest-framework
пагинация
Пагинация — это разделение больших наборов данных на отдельные и автономные страницы.
В среде django rest, разбиение на страницы позволяет пользователю изменять количество данных на каждой странице и стиль, с помощью которого применяется разделение.
[Вводный] Настройка Стиль разбивки на страницы во всем мире
Чтобы установить стиль разбивки на страницы для всего проекта, вам нужно установить DEFAULT_PAGINATION_CLASS и PAGE_SIZE в настройках проекта.
Для этого перейдите в settings.py и в переменную REST_FRAMEWORK , добавьте следующее:
Вместо DESIRED_PAGINATION_STYLE должно быть установлено одно из следующих:
PageNumberPagination : принимает номер одной page в параметрах запроса запроса.
LimitOffsetPagination : принимает limit параметр, который указывает максимальное количество элементов, которые будут возвращены, и параметр offset который указывает начальную позицию запроса относительно набора данных. Для этого стиля не нужно устанавливать PAGE_SIZE .
CursorPagination : разбиение на страницы курсора более сложное, чем приведенные выше стили. Это требует, чтобы набор данных фиксировал порядок и не позволял клиенту перемещаться в произвольные позиции набора данных.
Вместо указанных выше можно выбрать пользовательские стили для разбивки на страницы.
[Промежуточное] Переопределение стиля и настройки разбиения на страницы Разбиение на класс
Переопределить стиль разбивки на страницы:
Каждый доступный стиль разбиения на страницы можно переопределить, создав новый класс, который наследует один из доступных стилей, а затем изменяет его параметры:
- page_size : числовое значение, указывающее размер страницы. Если установлено, это переопределяет параметр PAGE_SIZE . Значение по умолчанию совпадает с значением параметра PAGE_SIZE .
- page_query_param : Строковое значение, указывающее имя параметра запроса, используемого для элемента управления разбиением на страницы.
- page_size_query_param : если установлено, это строковое значение, указывающее имя параметра запроса, которое позволяет клиенту устанавливать размер страницы для каждого запроса. По умолчанию « None , что указывает на то, что клиент не может управлять запрошенным размером страницы.
- max_page_size : если установлено, это числовое значение, указывающее максимально допустимый размер запрашиваемой страницы. Этот атрибут действителен только в том случае, если также задан параметр page_size_query_param .
- last_page_strings : список или кортеж строковых значений, указывающий значения, которые могут использоваться с page_query_param для запроса последней страницы в наборе. По умолчанию ('last',)
- template : имя шаблона, используемого при рендеринге элементов управления разбиением на страницы в API-интерфейсе. Может быть переопределено для изменения стиля рендеринга или для параметра « None чтобы полностью отключить элементы управления разбиением на страницы. По умолчанию "rest_framework/pagination/numbers.html" .
- default_limit : числовое значение, указывающее ограничение на использование, если клиент не задает параметр запроса. Значение по умолчанию совпадает с значением параметра PAGE_SIZE .
- limit_query_param : Строковое значение, указывающее имя параметра запроса «limit». По умолчанию 'limit' .
- offset_query_param : Строковое значение, указывающее имя параметра запроса «смещение». По умолчанию 'offset' .
- max_limit : если установлено, это числовое значение, указывающее максимально допустимый предел, который может быть запрошен клиентом. По умолчанию — None .
- template : То же, что и PageNumberPagination .
- page_size : То же, что и PageNumberPagination .
- cursor_query_param : Строковое значение, указывающее имя параметра запроса «курсор». По умолчанию используется 'cursor' .
- ordering : Это должна быть строка или список строк, указывающая поле, с которым будет применяться разбивка на основе курсора. Например: ordering = 'slug' . По умолчанию -created . Это значение также можно переопределить, используя OrderingFilter в представлении.
- template : То же, что и PageNumberPagination .
Настройка разбиения на страницы по классу:
В дополнение к возможности настройки стиля Pagination во всем мире доступна настройка для каждого класса:
Теперь только MyViewSet имеет LimitOffsetPagination страницы LimitOffsetPagination .
Пользовательский стиль разбивки на страницы можно использовать таким же образом:
[Промежуточный] Пример использования комплекса
Предположим, что у нас есть сложный api, с множеством общих представлений и некоторыми общими представлениями. Мы хотим включить параметр « PageNumberPagination для каждого представления, за исключением одного (либо общего представления, либо представления, не имеет значения), для которого мы хотим создать индивидуальный случай LimitOffsetPagination .
Для этого нам необходимо:
На settings.py мы разместим нашу разбивку по умолчанию, чтобы включить ее для каждого общего представления / вида, и мы установим PAGE_SIZE на 50 элементов:
Теперь в нашем views.py (или в другом .py ex: paginations.py ), нам нужно переопределить LimitOffsetPagination :
Пользовательский LimitOffsetPagination с PAGE_ZISE из 20 элементов и максимальный limit 1000 элементов.
В нашем views.py , мы должны определить pagination_class нашего специального обзора:
Теперь каждый общий вид / viewet в приложении имеет PageNumberPagination , за исключением класса IAmSpecial , который действительно является особым и имеет собственную настраиваемую LimitOffsetPagination .
[Продвинутый] Разбиение страниц на не общие представления / Viewsets
Это продвинутый вопрос, не пытайтесь без первого понимания других примеров этой страницы .
Как указано в официальной структуре Django Rest по разбивке на страницы :
Pagination выполняется только автоматически, если вы используете общие представления или виды. Если вы используете обычный APIView, вам нужно позвонить в API разбиения на страницы, чтобы убедиться, что вы возвращаете постраничный ответ. См. Исходный код классов mixins.ListModelMixin и generics.GenericAPIView для примера.
Но что, если мы хотим использовать разбиение на страницы на не общий вид / viewet?
Ну, давай спустимся по кроличьей норе:
Первой остановкой является официальный репозиторий Django Rest Framework и, в частности, django-rest-framework / rest_framework / generics.py . Конкретная строка, на которую ссылается эта ссылка, показывает нам, как разработчики рамочной программы занимаются разбиением на страницы в своих дженериках.
Именно это мы и будем использовать в нашем представлении!
Предположим, что у нас есть глобальная настройка разбиения на страницы, как показано на вводном примере этой страницы, и давайте предположим, что у нас есть APIView которому мы хотим применить разбиение на страницы.
Затем на views.py :
Теперь у нас есть APIView который обрабатывает разбиение на страницы!
[Промежуточное] Разбиение страницы на основе функции
Мы видели в этих примерах ( ex_1 , ex_2 ), как использовать и переопределять классы разбиения на страницы в любом представлении базового класса.
Что происходит, когда мы хотим использовать разбиение на страницы в представлении, основанном на функции?
Предположим также, что мы хотим создать представление функции для MyModel с помощью PageNumberPagination , отвечая только на запрос GET . Затем:
Мы также можем сделать это для пользовательской разбивки на страницы, изменив эту строку: