Фильтрация остальных фреймворков Django

Обновлено: 21.11.2024

Фильтры Django Rest Framework

django-rest-framework-filters – это расширение для Django REST framework и Django filter, которое упрощает фильтрацию взаимосвязей. Исторически сложилось так, что это расширение также предоставляло ряд дополнительных функций и исправлений, однако количество функций сократилось, поскольку они были объединены обратно в django-filter .

Используя django-rest-framework-filters, мы можем легко делать такие вещи, как:

<р>! Эти документы относятся к предстоящему выпуску 1.0. Текущие документы можно найти здесь.

<р>! Предварительная версия 1.0 совместима с django-filter 2.x и может быть установлена ​​с помощью pip install --pre .

Оглавление

  • Простая фильтрация отношений.
  • Поддержка фильтрации методов между отношениями.
  • Автоматическое отрицание фильтра с помощью простого синтаксиса param!=value.
  • Базовая часть для сложных операций с несколькими отфильтрованными наборами запросов. например, q1 | д2 .
  • Python: 3.5, 3.6, 3.7, 3.8
  • Джанго: 1.11, 2.0, 2.1, 2.2, 3.0, 3.1
  • DRF: 3.11
  • django-фильтр: 2.1, 2.2 (Django 2.0+)

Установите с помощью pip или предпочитаемого менеджера пакетов:

Добавьте в настройки INSTALLED_APPS:

Обновить django-filter до django-rest-framework-filters очень просто:

  • Импорт из rest_framework_filters вместо django_filters
  • Используйте серверную часть rest_framework_filters вместо предоставляемой django_filter.

Чтобы использовать серверную часть django-rest-framework-filters, добавьте в настройки следующее:

После настройки вы можете продолжать использовать все фильтры, найденные в django-filter .

Фильтрация отношений

Вы можете легко просмотреть несколько отношений при фильтрации с помощью RelatedFilter:

Пример вызовов фильтра:

Поскольку RelatedFilter является подклассом ModelChoiceFilter , аргумент набора запросов поддерживает вызываемое поведение. В следующем примере набор отделов ограничен подразделениями компании пользователя.

Рекурсивные и циклические отношения

Также поддерживаются рекурсивные отношения. Укажите путь к модулю в виде строки вместо класса набора фильтров.

Эта функция также полезна для циклических отношений, когда связанный набор фильтров может быть еще не создан. Обратите внимание, что связанный набор фильтров можно передать по имени, если он находится в том же модуле, что и родительский набор фильтров.

django_filters.MethodFilter объявлен устаревшим и повторно реализован в качестве аргумента метода для всех классов фильтров. Он включает в себя некоторые детали реализации старого rest_framework_filters.MethodFilter , но требует меньше шаблонного кода и его проще написать.

  • Больше нет необходимости выполнять проверку пустых/нулевых значений.
  • Вы можете использовать любой класс фильтра ( CharFilter , BooleanFilter и т. д. ), который будет проверять входные значения для вас.
  • Подпись аргумента изменилась с (name, qs, value) на (qs, name, value) .

Приведенное выше позволит включить следующие вызовы фильтра:

В первом вызове API метод фильтра получает набор запросов сообщений. Во втором он получает набор запросов пользователей. Метод фильтра в этом примере изменяет имя поиска, чтобы оно работало во всей связи, позволяя вам находить опубликованные сообщения или авторов, опубликовавших сообщения.

Автоматическое отрицание/исключение фильтра

Наборы фильтров поддерживают автоматическое исключение с помощью простого синтаксиса param!=value. Этот синтаксис внутренне устанавливает свойство exclude в фильтре.

Этот синтаксис поддерживает обычную фильтрацию в сочетании с фильтрацией исключения. Например, следующий запрос будет искать все статьи, содержащие «Привет» в заголовке, исключая те, которые содержат «Мир».

Обратите внимание, что большинство фильтров принимают только один параметр запроса. В приведенном выше примере title__contains и title__contains! интерпретируются как два отдельных параметра запроса. Следующее, вероятно, будет недопустимым, хотя это зависит от специфики отдельного класса фильтра:

Разрешение любого типа поиска в поле

Если вам нужно включить несколько поисков для поля, django-filter предоставляет синтаксис dict для Meta.fields .

django-rest-framework-filters также позволяет вам включить все возможные поиски для любого поля. Этого можно добиться с помощью AllLookupsFilter или значения '__all__' в синтаксисе в стиле словаря Meta.fields. Сгенерированные фильтры ( Meta.fields , AllLookupsFilter ) никогда не переопределяют объявленные вами фильтры.

Обратите внимание, что использование всех поисковых запросов сопровождается теми же предупреждениями, что и включение полей '__all__' в формах django (документы). Предоставление всех поисковых запросов может позволить пользователям создавать запросы, которые непреднамеренно приводят к утечке данных. Используйте эту функцию ответственно.

Вы не можете комбинировать AllLookupsFilter с RelatedFilter, так как имена фильтров будут конфликтовать.

Чтобы обойти это, у вас есть следующие варианты:

Можно ли смешивать и сочетать django-filter и django-rest-framework-filters?

Да, можете. django-rest-framework-filters — это просто расширение django-filter. Обратите внимание, что RelatedFilter и другие функции django-rest-framework-filters предназначены для работы с rest_framework_filters.FilterSet и не будут работать с django_filters.FilterSet . Однако целевой RelatedFilter.filterset может указывать на FilterSet из любого пакета, и обе реализации FilterSet совместимы с другой базой DRF.

MultiWidget несовместим

djangorestframework-filters несовместим с виджетами форм, которые анализируют имена запросов, которые отличаются от имени атрибута фильтра. Хотя это практически применимо только к MultiWidget , это общее ограничение, которое влияет на пользовательские виджеты, которые также имеют такое поведение. Затронутые фильтры включают RangeFilter , DateTimeFromToRangeFilter , DateFromToRangeFilter , TimeRangeFilter и NumericRangeFilter .

Чтобы продемонстрировать несовместимость, используйте следующий набор фильтров:

Приведенный выше фильтр позволяет пользователям выполнять запрос диапазона на дату публикации. Класс фильтра внутренне использует MultiWidget для раздельного анализа значений верхней и нижней границ. Несовместимость заключается в том, что MultiWidget добавляет индекс к своим внутренним именам виджетов. Вместо парсинга publish_date он ожидает publish_date_0 и publish_date_1. Это можно исправить, включив имя атрибута в строку запроса, хотя это не рекомендуется.

MultiWidget также не рекомендуется, поскольку:

  • интроспекция поля core-api завершается ошибкой по тем же причинам
  • _0 и _1 менее удобны для API, чем _min и _max

Рекомендуются следующие решения:

  • Создайте отдельные фильтры для каждого вложенного виджета (например, publish_date_min и publish_date_max ).
  • Используйте фильтр на основе CSV, например фильтры, производные от BaseCSVFilter / BaseInFilter / BaseRangeFilter . например,

ComplexFilterBackend определяет настраиваемый синтаксис строки запроса и процесс кодирования, который позволяет выражать сложные запросы. Этот синтаксис расширяет стандартные строки запросов, позволяя определять несколько наборов параметров и операторов для объединения запросов.

<р>! Обратите внимание, что эта функция является экспериментальной. Могут возникать ошибки, а серверная часть может быть изменена.

Чтобы лучше понять серверную часть, рассмотрите запрос, чтобы найти все статьи, названия которых начинаются с "Кто" или "Что". Базовый запрос может быть представлен следующим образом:

Теперь рассмотрим запрос, но измененный с верхней и нижней границами даты:

Используя только FilterSet , вполне возможно представить прежний запрос, написав собственный класс фильтра. Однако это менее осуществимо с последним запросом, где необходимо проверить несколько наборов различных типов данных и поисковых запросов. Напротив, ComplexFilterBackend может создать этот сложный запрос с помощью произвольной комбинации простого фильтра. Для поддержки вышеизложенного необходимо создать строку запроса с минимальными изменениями. Пример без кодировки:

По умолчанию серверная часть объединяет запросы как с & (И), так и с | (ИЛИ) и поддерживает унарное отрицание ~ . Например,

Бэкенд поддерживает как стандартные, так и сложные запросы. Для выполнения сложных запросов запрос должен быть закодирован и задан как значение complex_filter_param (по умолчанию фильтры). Для выполнения стандартных запросов используйте серверную часть так же, как RestFrameworkFilterBackend .

Подобно другим бэкэндам, ComplexFilterBackend необходимо добавить к атрибуту filter_backends представления. Либо добавьте его в параметр DEFAULT_FILTER_BACKENDS, либо установите его как серверную часть в классе представления.

Вы можете настроить способ объединения запросов, создав подкласс ComplexFilterBackend и переопределив атрибут operator. operator — это сопоставление символов операторов с функциями, которые объединяют два набора запросов. Например, карту можно переопределить, чтобы использовать QuerySet.intersection() и QuerySet.union() вместо & и | .

Унарное отрицание зависит от внутреннего устройства ORM и может давать ошибки при определенных обстоятельствах. Если с этой функцией возникают проблемы, ее можно отключить, установив для атрибута отрицания значение False в классе серверной части. Если вы столкнулись с ошибками, откройте проблему в системе отслеживания ошибок.

Сложное кодирование строки запроса

Ниже представлена ​​процедура кодирования сложного запроса:

  • Преобразуйте параметры запроса в отдельные строки запроса.
  • URL-кодирование отдельных строк запроса.
  • Заключите закодированные строки в круглые скобки и соедините их операторами.
  • URL-кодирование всей строки запроса.
  • Задайте в качестве значения сложный параметр фильтра (например, ?filters= ).

Обратите внимание, что фильтры — это имя параметра по умолчанию, и его можно переопределить во внутреннем классе.

Используя первый пример, эти шаги можно визуализировать следующим образом:

  • title__startswith=кто , title__startswith=что
  • title__startswith%3DWho , title__startswith%3DWhat
  • (title__startswith%3DWho) | (title__startswith%3DWhat)
  • %28title__startswith%253DWho%29%20%7C%20%28title__startswith%253DWhat%29
  • filters=%28title__startswith%253DWho%29%20%7C%20%28title__startswith%253DWhat%29

ComplexFilterBackend вызовет любые ошибки декодирования под именем параметра сложной фильтрации. Например,

При фильтрации наборов запросов ошибки проверки набора фильтров будут собираться и выдаваться под сложным именем параметра фильтрации, а затем под декодированной строкой запроса набора фильтров. Для сложного запроса типа (a=1&b=2) | (c=3&d=4) ошибки будут возникать следующим образом:

Переход на 1.0

Бэкэнд переименован, предоставляет новые шаблоны

Бэкэнд был переименован из DjangoFilterBackend в RestFrameworkFilterBackend и теперь использует собственные пути шаблонов, расположенные в rest_framework_filters вместо django_filters/rest_framework .

Чтобы загрузить включенные шаблоны, необходимо добавить rest_framework_filters в настройку INSTALLED_APPS.

Теперь требуется связанный фильтр.queryset

Модель связанного набора фильтров больше не используется для предоставления значения по умолчанию для RelatedFilter.queryset . Это изменение снижает вероятность непреднамеренного раскрытия данных в отображаемых формах фильтров. Теперь вы должны явно указать аргумент набора запросов или переопределить метод get_queryset() (см. вызываемые объекты набора запросов).

get_filters() переименован в get_request_filters()

django-filter добавил метод класса get_filters() в свой API, поэтому этот метод был переименован.

Авторское право (c) Филип Нейстром, 2013–2015 гг., и Райан П. Килби, 2016–2019 гг. Подробнее см. в ЛИЦЕНЗИИ.

Корневой набор запросов, предоставленный менеджером, описывает все объекты в таблице базы данных. Однако обычно вам нужно выбрать только часть полного набора объектов.

— документация по Django

По умолчанию общие представления списка REST framework возвращают весь набор запросов для диспетчера моделей. Часто вам нужно, чтобы ваш API ограничивал элементы, возвращаемые набором запросов.

Самый простой способ отфильтровать набор запросов любого представления, являющегося подклассом GenericAPIView, — переопределить метод .get_queryset().

Переопределение этого метода позволяет настраивать набор запросов, возвращаемый представлением, различными способами.

Фильтрация текущего пользователя

Возможно, вы захотите отфильтровать набор запросов, чтобы гарантировать, что возвращаются только результаты, относящиеся к текущему аутентифицированному пользователю, делающему запрос.

Фильтрация по URL

Другой стиль фильтрации может заключаться в ограничении набора запросов на основе некоторой части URL-адреса.

Например, если ваша конфигурация URL содержит такую ​​запись:

Затем вы можете написать представление, которое возвращает набор запросов на покупку, отфильтрованный по имени пользователя в URL-адресе:

Фильтрация по параметрам запроса

Последним примером фильтрации исходного набора запросов может быть определение исходного набора запросов на основе параметров запроса в URL-адресе.

Помимо возможности переопределения набора запросов по умолчанию, платформа REST также включает поддержку общих механизмов фильтрации, которые позволяют легко создавать сложные поиски и фильтры.

Настройка внутренних фильтров

Фильтры по умолчанию могут быть установлены глобально с помощью параметра DEFAULT_FILTER_BACKENDS. Например.

Вы также можете установить внутренние фильтры для каждого представления или набора представлений, используя представления на основе класса GenericAPIView.

Фильтрация и поиск объектов

Обратите внимание, что если серверная часть фильтра настроена для представления, то она будет использоваться не только для фильтрации представлений списка, но и для фильтрации наборов запросов, используемых для возврата одного объекта.

Например, для предыдущего примера и продукта с идентификатором 4675 следующий URL либо вернет соответствующий объект, либо вернет ответ 404, в зависимости от того, были ли выполнены условия фильтрации данным экземпляром продукта:

Переопределение исходного набора запросов

Обратите внимание, что вы можете использовать как переопределенный .get_queryset(), так и общую фильтрацию вместе, и все будет работать как положено. Например, если продукт имеет связь многие ко многим с пользователем с именем покупка, вы можете написать такое представление:

DjangoFilterBackend

Класс DjangoFilterBackend поддерживает фильтрацию полей с широкими возможностями настройки с помощью пакета django-filter.

Чтобы использовать DjangoFilterBackend среды REST, сначала установите django-filter .

Указание полей фильтра

Если все, что вам нужно, это простая фильтрация на основе равенства, вы можете установить атрибут filter_fields в представлении или наборе представлений, перечислив набор полей, по которым вы хотите фильтровать.

Это автоматически создаст класс FilterSet для заданных полей и позволит вам делать такие запросы, как:

Указание набора фильтров

Для более сложных требований к фильтрации можно указать класс FilterSet, который должен использоваться представлением. Например:

Что позволит вам делать такие запросы, как:

Вы также можете установить отношения с помощью django-filter . Предположим, что каждый продукт имеет внешний ключ к модели производителя, поэтому мы создаем фильтр, который фильтрует, используя имя производителя. Например:

Это позволяет нам делать такие запросы, как:

Это хорошо, но это раскрывает соглашение о двойном подчеркивании Django как часть API. Если вместо этого вы хотите явно назвать аргумент фильтра, вы можете вместо этого явно включить его в класс FilterSet:

Теперь вы можете выполнить:

Дополнительные сведения об использовании наборов фильтров см. в документации по django-filter.

Советы и подсказки

  • По умолчанию фильтрация не включена. Если вы хотите использовать DjangoFilterBackend, не забудьте убедиться, что он установлен с помощью параметра «DEFAULT_FILTER_BACKENDS».
  • При использовании логических полей следует использовать значения True и False в параметрах запроса URL, а не 0 , 1 , true или false . (Разрешенные логические значения в настоящее время жестко запрограммированы в реализации NullBooleanSelect в Django.)
  • django-filter поддерживает фильтрацию отношений, используя синтаксис двойного подчеркивания Django.
  • Для поддержки Django 1.3 обязательно установите django-filter версии 0.5.4, так как более поздние версии не поддерживают 1.3.

Фильтр поиска

Класс SearchFilter поддерживает простой поиск на основе одного параметра запроса и основан на функциях поиска администратора Django.

Класс SearchFilter будет применяться только в том случае, если для представления установлен атрибут search_fields. Атрибут search_fields должен быть списком имен полей текстового типа в модели, например CharField или TextField .

Это позволит клиенту фильтровать элементы в списке, выполняя такие запросы, как:

Вы также можете выполнить связанный поиск для ForeignKey или ManyToManyField с двойным подчеркиванием API поиска:

По умолчанию при поиске будут использоваться частичные совпадения без учета регистра. Параметр поиска может содержать несколько условий поиска, которые должны быть разделены пробелами и/или запятыми. Если используется несколько условий поиска, объекты будут возвращены в список только в том случае, если все предоставленные условия совпадают.

Поведение при поиске может быть ограничено добавлением различных символов перед search_fields .

  • '^' Начинается с поиска.
  • '=' Точные совпадения.
  • '@' Полнотекстовый поиск. (В настоящее время поддерживается только серверная часть Django MySQL.)

По умолчанию параметр поиска называется "поиск", но его можно переопределить с помощью параметра SEARCH_PARAM.

Подробнее см. в документации Django.

Фильтр заказа

Класс OrderingFilter поддерживает простое упорядочение результатов, контролируемое параметром запроса. По умолчанию параметр запроса называется ordering , но его можно переопределить настройкой ORDERING_PARAM.

Например, чтобы упорядочить пользователей по имени пользователя:

Клиент также может указывать обратный порядок, добавляя к имени поля префикс "-", например:

Также можно указать несколько заказов:

Указание того, какие поля можно упорядочить

Рекомендуется явно указать, какие поля API должен разрешить в фильтре упорядочивания. Вы можете сделать это, установив атрибут ordering_fields в представлении, например так:

Это помогает предотвратить непредвиденную утечку данных, например разрешить пользователям размещать заказы на основе хэш-поля пароля или других конфиденциальных данных.

Если вы не укажете атрибут ordering_fields в представлении, класс фильтра по умолчанию позволит пользователю фильтровать любые читаемые поля в сериализаторе, заданном атрибутом serializer_class.

Если вы уверены, что набор запросов, используемый представлением, не содержит конфиденциальных данных, вы также можете явно указать, что представление должно разрешать упорядочение по любому полю модели или агрегату набора запросов, путем используя специальное значение '__all__' .

Указание порядка по умолчанию

Если для представления установлен атрибут порядка, он будет использоваться как порядок по умолчанию.

Обычно это можно контролировать, задав order_by в начальном наборе запросов, но использование параметра ordering в представлении позволяет указать порядок таким образом, чтобы его можно было затем автоматически передать в качестве контекста отображаемому шаблону. Это позволяет автоматически отображать заголовки столбцов по-разному, если они используются для упорядочивания результатов.

Атрибут порядка может быть либо строкой, либо списком/кортежем строк.

Фильтр разрешений DjangoObject

DjangoObjectPermissionsFilter предназначен для использования вместе с пакетом django-guardian с добавленными пользовательскими разрешениями на просмотр. Фильтр гарантирует, что наборы запросов будут возвращать только те объекты, для которых у пользователя есть соответствующее разрешение на просмотр.

Этот класс фильтра должен использоваться с представлениями, которые предоставляют либо набор запросов, либо атрибут модели.

Если вы используете DjangoObjectPermissionsFilter , вы, вероятно, также захотите добавить соответствующий класс разрешений для объектов, чтобы пользователи могли работать с экземплярами только в том случае, если у них есть соответствующие разрешения на объекты. Самый простой способ сделать это — создать подкласс DjangoObjectPermissions и добавить разрешения «просмотр» в атрибут perms_map.

Полный пример использования DjangoObjectPermissionsFilter и DjangoObjectPermissions может выглядеть примерно так.

разрешения.py:

views.py:

Дополнительную информацию о добавлении разрешений «просмотр» для моделей см. в соответствующем разделе документации django-guardian и в этом сообщении блога.

Вы также можете предоставить свой собственный общий механизм фильтрации или написать устанавливаемое приложение для использования другими разработчиками.

Для этого переопределите BaseFilterBackend и переопределите метод .filter_queryset(self, request, queryset, view). Метод должен возвращать новый отфильтрованный набор запросов.

Помимо того, что клиенты могут выполнять поиск и фильтрацию, общие серверные части фильтров могут быть полезны для ограничения того, какие объекты должны быть видны для любого заданного запроса или пользователя.

Пример

Например, вам может потребоваться разрешить пользователям видеть только созданные ими объекты.

Того же поведения можно добиться, переопределив get_queryset() для представлений, но использование бэкенда фильтра позволяет упростить добавление этого ограничения к нескольким представлениям или применить его ко всему API.

Следующие сторонние пакеты предоставляют дополнительные реализации фильтров.

Цепочка инфраструктуры Django REST

Пакет django-rest-framework-chain работает вместе с классом DjangoFilterBackend и позволяет легко создавать фильтры для отношений или создавать несколько типов поиска фильтров для заданного поля.

Интеграция с Django Rest Framework осуществляется через набор фильтров для DRF и серверную часть фильтра. Их можно найти в подпакете rest_framework.

Быстрый старт¶

Для использования нового набора фильтров достаточно просто изменить путь импорта. Вместо импорта из django_filters импортируйте из подпакета rest_framework.

Ваш класс представления также должен добавить DjangoFilterBackend в filter_backends .

Если вы хотите использовать бэкэнд django-filter по умолчанию, добавьте его в параметр DEFAULT_FILTER_BACKENDS.

Добавление FilterSet с filterset_class ¶

Чтобы включить фильтрацию с помощью FilterSet , добавьте его в параметр filterset_class класса представления.

Использование ярлыка filterset_fields¶

Вы можете обойти создание FilterSet, добавив вместо этого filterset_fields в свой класс представления. Это эквивалентно созданию FilterSet только с Meta.fields .

Обратите внимание, что совместное использование полей filterset_fields и filterset_class не поддерживается.

Переопределение создания набора фильтров¶

Создание FilterSet можно настроить, переопределив следующие методы внутреннего класса:

  • .get_filterset(я, запрос, набор запросов, представление)
  • .get_filterset_class(self, view, queryset=None)
  • .get_filterset_kwargs(я, запрос, набор запросов, представление)

Вы можете переопределять эти методы в каждом отдельном случае для каждого представления, создавая уникальные серверные части, или эти методы можно использовать для написания собственных перехватчиков для класса представления.

Создание схемы с помощью Core API и Open API¶

Бэкэнд-класс интегрируется с генерацией схемы DRF путем реализации get_schema_fields() и get_schema_operation_parameters() . get_schema_fields() включается автоматически при установке Core API. get_schema_operation_parameters() всегда включен для Open API (новое с DRF 3.9). Генерация схемы обычно работает без проблем, однако реализация ожидает вызова метода get_queryset() представления. Существует предостережение в том, что представления создаются искусственно во время генерации схемы, поэтому атрибуты args и kwargs будут пустыми. Если вы зависите от аргументов, проанализированных из URL-адреса, вам нужно будет обработать их отсутствие в get_queryset() .

Класс DjangoFilterBackend используется для фильтрации набора запросов на основе указанного набора полей. Этот серверный класс автоматически создает класс FilterSet (django_filters.rest_framework.FilterSet) для заданных полей. Мы также можем создать собственный класс FilterSet с индивидуальными настройками.

Чтобы настроить базовые классы фильтров в нашей веб-службе Django, нам нужно установить пакет django-filter в нашу виртуальную среду.Убедитесь, что вы вышли из сервера разработки Django (Ctrl + C) и активировали виртуальную среду. Давайте запустим приведенную ниже команду.

После установки нам нужно определить приложение django_filters как INSTALLED_APPS в файле settings.py.

Питон3

В качестве следующего шага нам нужно установить класс DjangoFilterBackend из django_filters в качестве класса фильтра по умолчанию. Укажем это в словаре REST_FRAMEWORK в файле settings.py.

Питон3

Теперь наша веб-служба RESTful настроена на использование функции фильтрации, предоставляемой классом django_filters.rest_framework.DjangoFilterBackend. Давайте отфильтруем класс роботов, который получает список роботов. Класс RobotList выглядит следующим образом:

Питон3

Здесь вы можете заметить атрибут с именем filter_fileds, где мы указываем имя поля для фильтрации. Теперь мы можем получать роботов по их категории (robot_category) и/или производителю.

Вывод:

Вывод:

Теперь давайте проверим функциональность Browsable API. Вы можете просмотреть приведенный ниже URL

Вы можете нажать кнопку "Фильтры" в правом верхнем углу, чтобы использовать функцию фильтра. Он будет отображаться, как показано ниже

Нажав кнопку отправки, вы получите результат на основе заполненных полей фильтра, как показано ниже.

Фильтр поиска

Класс SearchFilter поддерживает функцию поиска на основе одного параметра запроса и основан на функции поиска администратора Django.

  • «^» Начинается с поиска.
  • ‘=’ Точные совпадения.
  • ‘@’ Полнотекстовый поиск. (для серверной части Django PostgreSQL)
  • Поиск регулярного выражения ‘$’

По умолчанию параметр поиска называется search, и его можно переопределить с помощью параметра SEARCH_PARAM. Давайте воспользуемся классом SearchFilter, добавив класс rest_framework.filters.SearchFilter в словарь REST_FRAMEWORK.

Питон3

Наш класс RobotList выглядит следующим образом:

Питон3

Атрибут search_fields указывает кортеж строк, который указывает имена полей, которые мы хотим включить в функцию поиска.

Вывод:

Фильтр заказа

Класс OrderingFilter позволяет упорядочить результат на основе указанных полей. По умолчанию параметр запроса называется ordering, и его можно переопределить с помощью параметра ORDERING_PARAM. Атрибут ordering_field определяет кортеж строк, который указывает имена полей для сортировки результатов.

Если вы не укажете атрибут ordering_fields в представлении, класс фильтра позволит пользователю фильтровать любые доступные для чтения поля, указанные в атрибуте serializer_class. Это позволяет пользователю заказывать конфиденциальную информацию, такую ​​как поля хэшей паролей и т. д., что может привести к непредвиденной утечке данных. Вы также можете указать порядок по умолчанию, установив атрибут порядка в представлении. Это может быть либо строка, либо список/кортеж строк.

Чтобы использовать класс OrderingFilter, нам нужно установить класс в качестве класса фильтра упорядочения по умолчанию для словаря REST_FRAMEWORK.

Читайте также: