url_filter.backends.base module¶
-
class
url_filter.backends.base.
BaseFilterBackend
(queryset, context=None)[source]¶ Bases:
object
Base filter backend from which all other backends must subclass.
Parameters: - queryset – Iterable which this filter backend will eventually filter.
The type of the iterable depends on the filter backend.
For example for
DjangoFilterBackend
, Django’sQuerySet
needs to be passed. - context (dict) – Context dictionary. It could contain any information which potentially could be useful to filter given queryset. That can include, request, view, view kwargs, etc. The idea is similar to DRF serializers. By passing the context, it allows custom filters to reference all the information they need to be able to effectively filter data.
-
bind
(specs)[source]¶ Bind the given specs to the filter backend.
This allows the filter backend to be instantiated first before filter specs are constructed and later, specs can be binded to the backend.
Parameters: specs (list) – List of FilterSpec
to be binded for the filter backend for filtering
-
callable_specs
¶ Property for getting custom filter specifications which have a filter callable for filtering querysets. These specifications cannot be directly used by filter backend and have to be called manually to filter data.
See also
-
enforce_same_models
= True¶ Whether same models should be enforced when trying to use this filter backend.
More can be found in
BaseFilterBackend.model()
-
filter_by_callables
(queryset)[source]¶ Method for filtering queryset by using custom filter callables as given in the
Filter
definition.This is really meant to accommodate filtering with simple filter keys having complex filtering logic behind them. More about custom callables can be found at
CallableFilter
-
filter_by_specs
(queryset)[source]¶ Method for filtering queryset by using standard filter specs.
Note
MUST be implemented by subclasses
-
get_model
()[source]¶ Get the queryset model.
Note
MUST be implemented by subclasses.
model()
property uses this method to get the model.See also
-
model
¶ Property for getting model on which this filter backend operates.
This is meant to be used by the integrations directly shipped with django-url-filter which need to be able to validate that the filterset will be able to filter given queryset. They can do that by comparing the model they are trying to filter matches the model the filterbackend got. This primarily will have misconfigurations such as using SQLAlchemy filterset to filter Django’s
QuerySet
.
-
name
= None¶ Name of the filter backend.
This is used by custom callable filters to define callables for each supported backend. More at
CallableFilter
-
regular_specs
¶ Property for getting standard filter specifications which can be used directly by the filter backend to filter queryset.
See also
-
supported_lookups
= set([])¶ Set of supported lookups this filter backend supports.
This is used by leaf
Filter
to determine whether it should constructFilterSpec
for a particular key-value pair from querystring since it if constructs specification but then filter backend will not be able to filter it, things will blow up. By explicitly checking if filter backend supports particular lookup it can short-circuit the logic and avoid errors down the road. This is pretty much the only coupling between filters and filter backends.
- queryset – Iterable which this filter backend will eventually filter.
The type of the iterable depends on the filter backend.
For example for