@@ -140,6 +140,14 @@ For more details on using filter sets see the [django-filter documentation][djan
---
### Filtering and object lookups
Note that if a filter backend is configured for a view, then as well as being used to filter list views, it will also be used to filter the querysets used for returning a single object.
For instance, given the previous example, and a product with an id of `4675`, the following URL would either return the corresponding object, or return a 404 response, depending on if the filtering conditions were met by the given product instance:
Note that you can use both an overridden `.get_queryset()` and generic filtering together, and everything will work as expected. For example, if `Product` had a many-to-many relationship with `User`, named `purchase`, you might want to write a view like this:
@@ -93,6 +93,8 @@ To serialize a queryset instead of an object instance, you should pass the `many
When deserializing data, you always need to call `is_valid()` before attempting to access the deserialized object. If any validation errors occur, the `.errors` and `.non_field_errors` properties will contain the resulting error messages.
When deserialising a list of items, errors will be returned as a list of tuples. The first item in an error tuple will be the index of the item with the error in the original data; The second item in the tuple will be a dict with the individual errors for that item.
### Field-level validation
You can specify custom field-level validation by adding `.validate_<fieldname>` methods to your `Serializer` subclass. These are analagous to `.clean_<fieldname>` methods on Django forms, but accept slightly different arguments.
@@ -40,6 +40,18 @@ You can determine your currently installed version using `pip freeze`:
## 2.2.x series
### Master
*Filtering backends are now applied to the querysets for object lookups as well as lists. (Eg you can use a filtering backend to control which objects should 404)
*Deal with error data nicely when deserializing lists of objects.
*Bugfix:Workaround for Django bug causing case where `Authtoken` could be registered for cascade delete from `User` even if not installed.
### 2.2.3
**Date**:7th March 2013
*Bugfix:Fix None values for for `DateField`, `DateTimeField` and `TimeField`.