Returns the field instance that should be used to represent a related field when `depth` is specified as being non-zero.
Returns the field instance that should be used to represent a related field when `depth` is specified as being non-zero.
Note that the `model_field` argument will be `None` for reverse relationships. The `related_model` argument will be the model class for the target of the field. The `to_many` argument will be a boolean indicating if this is a to-one or to-many relationship.
Returns the field instance that should be used to represent a related field when `depth` is not specified, or when nested representations are being used and the depth reaches zero.
Returns the field instance that should be used to represent a related field when `depth` is not specified, or when nested representations are being used and the depth reaches zero.
Note that the `model_field` argument will be `None` for reverse relationships. The `related_model` argument will be the model class for the target of the field. The `to_many` argument will be a boolean indicating if this is a to-one or to-many relationship.
@@ -4,7 +4,6 @@ REST framework 2.3 is geared towards making it easier and quicker to build your
...
@@ -4,7 +4,6 @@ REST framework 2.3 is geared towards making it easier and quicker to build your
## ViewSets & Routers
## ViewSets & Routers
**TODO**
## Easier Serializers
## Easier Serializers
...
@@ -132,13 +131,21 @@ If you've been customizing this behavior, for example perhaps to use `rst` marku
...
@@ -132,13 +131,21 @@ If you've been customizing this behavior, for example perhaps to use `rst` marku
Note that the relevant methods have always been private APIs, and the docstrings called them out as intended to be deprecated.
Note that the relevant methods have always been private APIs, and the docstrings called them out as intended to be deprecated.
## ModelSerializers and reverse relationships
The support for adding reverse relationships to the `fields` option on a `ModelSerializer` class means that the `get_related_field` and `get_nested_field` method signatures have now changed.
In the unlikely event that you're providing a custom serializer class, and implementing these methods you should note the new call signature for both methods is now `(self, model_field, related_model, to_many)`. For revese relationships `model_field` will be `None`.
The old-style signature will continue to function but will raise a `PendingDeprecationWarning`.
---
---
# Other notes
# Other notes
## Explict view attributes
## More explicit style
The usage of `model` attribute in generic Views is still supported, but it's usage is being discouraged in favour of the more explict `queryset` attribute.
The usage of `model` attribute in generic Views is still supported, but it's usage is being discouraged in favour of the setting the mode explict `queryset` and `serializer_class` attributes.
For example, the following is now the recommended style for using generic views:
For example, the following is now the recommended style for using generic views:
...
@@ -146,9 +153,9 @@ For example, the following is now the recommended style for using generic views:
...
@@ -146,9 +153,9 @@ For example, the following is now the recommended style for using generic views:
queryset = MyModel.objects.all()
queryset = MyModel.objects.all()
serializer_class = MyModelSerializer
serializer_class = MyModelSerializer
Using an explict `queryset` attribute makes the functioning of the view more clear than using the shortcut `model` attribute.
Using an explict `queryset` and `serializer_class` attributes makes the functioning of the view more clear than using the shortcut `model` attribute.
It also makes the usage of an overridden `get_queryset()` method more obvious.
It also makes the usage of the `get_queryset()` or `get_serializer_class()` methods more obvious.
class AccountListView(generics.RetrieveAPIView):
class AccountListView(generics.RetrieveAPIView):
serializer_class = MyModelSerializer
serializer_class = MyModelSerializer
...
@@ -167,6 +174,10 @@ It also makes the usage of an overridden `get_queryset()` method more obvious.
...
@@ -167,6 +174,10 @@ It also makes the usage of an overridden `get_queryset()` method more obvious.
The 2.3 release series will be the last series to provide compatiblity with Django 1.3.
The 2.3 release series will be the last series to provide compatiblity with Django 1.3.
## Version 2.2 API changes
All API changes in 2.2 that previously raised `PendingDeprecationWarning` will now raise a `DeprecationWarning`, which is loud by default.
## What comes next?
## What comes next?
The plan for the next few months is to concentrate on addressing outstanding tickets. 2.4 is likely to deal with relatively small refinements to the existing API.
The plan for the next few months is to concentrate on addressing outstanding tickets. 2.4 is likely to deal with relatively small refinements to the existing API.