aboutsummaryrefslogtreecommitdiffstats
path: root/docs/api-guide
diff options
context:
space:
mode:
Diffstat (limited to 'docs/api-guide')
-rw-r--r--docs/api-guide/filtering.md46
-rw-r--r--docs/api-guide/relations.md6
-rw-r--r--docs/api-guide/viewsets.md4
3 files changed, 46 insertions, 10 deletions
diff --git a/docs/api-guide/filtering.md b/docs/api-guide/filtering.md
index b5dfc68e..a710ad7d 100644
--- a/docs/api-guide/filtering.md
+++ b/docs/api-guide/filtering.md
@@ -182,7 +182,7 @@ For more details on using filter sets see the [django-filter documentation][djan
The `SearchFilterBackend` class supports simple single query parameter based searching, and is based on the [Django admin's search functionality][search-django-admin].
-The `SearchFilterBackend` class will only be applied if the view has a `search_fields` attribute set. The `search_fields` attribute should be a list of names of text fields on the model.
+The `SearchFilterBackend` class will only be applied if the view has a `search_fields` attribute set. The `search_fields` attribute should be a list of names of text type fields on the model, such as `CharField` or `TextField`.
class UserListView(generics.ListAPIView):
queryset = User.objects.all()
@@ -190,7 +190,7 @@ The `SearchFilterBackend` class will only be applied if the view has a `search_f
filter_backends = (filters.SearchFilter,)
search_fields = ('username', 'email')
-This will allow the client to filter the itemss in the list by making queries such as:
+This will allow the client to filter the items in the list by making queries such as:
http://example.com/api/users?search=russell
@@ -198,12 +198,50 @@ You can also perform a related lookup on a ForeignKey or ManyToManyField with th
search_fields = ('username', 'email', 'profile__profession')
-By default, searches will use case-insensitive partial matches. If the search parameter contains multiple whitespace seperated words, then objects will be returned in the list only if all the provided words are matched.
+By default, searches will use case-insensitive partial matches. The search parameter may contain multiple search terms, which should be whitespace and/or comma separated. If multiple search terms are used then objects will be returned in the list only if all the provided terms are matched.
+
+The search behavior may be restricted by prepending various characters to the `search_fields`.
+
+* '^' Starts-with search.
+* '=' Exact matches.
+* '@' Full-text search. (Currently only supported Django's MySQL backend.)
+
+For example:
+
+ search_fields = ('=username', '=email')
For more details, see the [Django documentation][search-django-admin].
---
+## OrderingFilter
+
+The `OrderingFilter` class supports simple query parameter controlled ordering of results. To specify the result order, set a query parameter named `'order'` to the required field name. For example:
+
+ http://example.com/api/users?ordering=username
+
+The client may also specify reverse orderings by prefixing the field name with '-', like so:
+
+ http://example.com/api/users?ordering=-username
+
+Multiple orderings may also be specified:
+
+ http://example.com/api/users?ordering=account,username
+
+If an `ordering` attribute is set on the view, this will be used as the default ordering.
+
+Typicaly you'd instead control this by setting `order_by` on the initial queryset, but using the `ordering` parameter on the view allows you to specify the ordering in a way that it can then be passed automatically as context to a rendered template. This makes it possible to automatically render column headers differently if they are being used to order the results.
+
+ class UserListView(generics.ListAPIView):
+ queryset = User.objects.all()
+ serializer = UserSerializer
+ filter_backends = (filters.OrderingFilter,)
+ ordering = ('username',)
+
+The `ordering` attribute may be either a string or a list/tuple of strings.
+
+---
+
# Custom generic filtering
You can also provide your own generic filtering backend, or write an installable app for other developers to use.
@@ -223,7 +261,7 @@ For example, you might need to restrict users to only being able to see objects
def filter_queryset(self, request, queryset, view):
return queryset.filter(owner=request.user)
-We could do the same thing by overriding `get_queryset` on the views, but using a filter backend allows you to more easily add this restriction to multiple views, or to apply it across the entire API.
+We could achieve the same behavior by overriding `get_queryset()` on the views, but using a filter backend allows you to more easily add this restriction to multiple views, or to apply it across the entire API.
[cite]: https://docs.djangoproject.com/en/dev/topics/db/queries/#retrieving-specific-objects-with-filters
[django-filter]: https://github.com/alex/django-filter
diff --git a/docs/api-guide/relations.md b/docs/api-guide/relations.md
index 756e1562..155c89de 100644
--- a/docs/api-guide/relations.md
+++ b/docs/api-guide/relations.md
@@ -196,15 +196,13 @@ Would serialize to a representation like this:
'artist': 'Thom Yorke'
'track_listing': 'http://www.example.com/api/track_list/12/',
}
-
+
This field is always read-only.
**Arguments**:
* `view_name` - The view name that should be used as the target of the relationship. **required**.
-* `slug_field` - The field on the target that should be used for the lookup. Default is `'slug'`.
-* `pk_url_kwarg` - The named url parameter for the pk field lookup. Default is `pk`.
-* `slug_url_kwarg` - The named url parameter for the slug field lookup. Default is to use the same value as given for `slug_field`.
+* `lookup_field` - The field on the target that should be used for the lookup. Should correspond to a URL keyword argument on the referenced view. Default is `'pk'`.
* `format` - If using format suffixes, hyperlinked fields will use the same format suffix for the target unless overridden by using the `format` argument.
---
diff --git a/docs/api-guide/viewsets.md b/docs/api-guide/viewsets.md
index e354a43a..cd92dc58 100644
--- a/docs/api-guide/viewsets.md
+++ b/docs/api-guide/viewsets.md
@@ -13,11 +13,11 @@ A `ViewSet` class is simply **a type of class-based View, that does not provide
The method handlers for a `ViewSet` are only bound to the corresponding actions at the point of finalizing the view, using the `.as_view()` method.
-Typically, rather than exlicitly registering the views in a viewset in the urlconf, you'll register the viewset with a router class, that automatically determines the urlconf for you.
+Typically, rather than explicitly registering the views in a viewset in the urlconf, you'll register the viewset with a router class, that automatically determines the urlconf for you.
## Example
-Let's define a simple viewset that can be used to listing or retrieving all the users in the system.
+Let's define a simple viewset that can be used to list or retrieve all the users in the system.
class UserViewSet(viewsets.ViewSet):
"""