diff --git a/api-guide/caching/index.html b/api-guide/caching/index.html index d8ef1ce85..df1522e60 100644 --- a/api-guide/caching/index.html +++ b/api-guide/caching/index.html @@ -436,7 +436,7 @@ provided in Django.

Using cache with apiview and viewsets

Django provides a method_decorator to use decorators with class based views. This can be used with -with other cache decorators such as cache_page and +other cache decorators such as cache_page and vary_on_cookie.

from rest_framework.response import Response
 from rest_framework.views import APIView
diff --git a/api-guide/fields/index.html b/api-guide/fields/index.html
index c7f75e117..e4857b6d8 100644
--- a/api-guide/fields/index.html
+++ b/api-guide/fields/index.html
@@ -707,7 +707,14 @@ color_channel = serializers.ChoiceField(
 
BooleanField

 
A boolean representation.

 
When using HTML encoded form input be aware that omitting a value will always be treated as setting a field to False, even if it has a default=True option specified. This is because HTML checkbox inputs represent the unchecked state by omitting the value, so REST framework treats omission as if it is an empty checkbox input.

-
Note that default BooleanField instances will be generated with a required=False option (since Django models.BooleanField is always blank=True). If you want to change this behaviour explicitly declare the BooleanField on the serializer class.

+
Note that Django 2.1 removed the blank kwarg from models.BooleanField.
+Prior to Django 2.1 models.BooleanField fields were always blank=True. Thus
+since Django 2.1 default serializers.BooleanField instances will be generated
+without the required kwarg (i.e. equivalent to required=True) whereas with
+previous versions of Django, default BooleanField instances will be generated
+with a required=False option.  If you want to control this behaviour manually,
+explicitly declare the BooleanField on the serializer class, or use the
+extra_kwargs option to set the required flag.

 
Corresponds to django.db.models.fields.BooleanField.

 
Signature: BooleanField()

 
NullBooleanField

diff --git a/api-guide/filtering/index.html b/api-guide/filtering/index.html
index 410ef2665..971dcb6a7 100644
--- a/api-guide/filtering/index.html
+++ b/api-guide/filtering/index.html
@@ -616,7 +616,7 @@ class UserListView(generics.ListAPIView):
     """
     model = Product
     serializer_class = ProductSerializer
-    filter_class = ProductFilter
+    filterset_class = ProductFilter
 
     def get_queryset(self):
         user = self.request.user
@@ -642,12 +642,12 @@ class UserListView(generics.ListAPIView):
     ...
     filter_backends = (DjangoFilterBackend,)
-

If all you need is simple equality-based filtering, you can set a filter_fields attribute on the view, or viewset, listing the set of fields you wish to filter against.

+

If all you need is simple equality-based filtering, you can set a filterset_fields attribute on the view, or viewset, listing the set of fields you wish to filter against.

class ProductList(generics.ListAPIView):
     queryset = Product.objects.all()
     serializer_class = ProductSerializer
     filter_backends = (DjangoFilterBackend,)
-    filter_fields = ('category', 'in_stock')
+    filterset_fields = ('category', 'in_stock')

This will automatically create a FilterSet class for the given fields, and will allow you to make requests such as:

http://example.com/api/products?category=clothing&in_stock=True
@@ -686,6 +686,12 @@ class UserListView(generics.ListAPIView):
 
search_fields = ('=username', '=email')
 

 
By default, the search parameter is named 'search', but this may be overridden with the SEARCH_PARAM setting.

+
To dynamically change search fields based on request content, it's possible to subclass the SearchFilter and override the get_search_fields() function. For example, the following subclass will only search on title if the query parameter title_only is in the request:

+
class CustomSearchFilter(self, view, request):
+    if request.query_params.get('title_only'):
+        return ('title',)
+    return super(CustomSearchFilter, self).get_search_fields(view, request)
+

 
For more details, see the Django documentation.

 

 
OrderingFilter

diff --git a/api-guide/pagination/index.html b/api-guide/pagination/index.html
index 710f97059..c7aabe589 100644
--- a/api-guide/pagination/index.html
+++ b/api-guide/pagination/index.html
@@ -726,7 +726,7 @@ that REST framework provides, by implementing a get_schema_fields()
 
drf-proxy-pagination

 
The drf-proxy-pagination package includes a ProxyPagination class which allows to choose pagination class with a query parameter.

 
-
The django-rest-framework-link-header-pagination package includes a LinkHeaderPagination class which provides pagination via an HTTP Link header as desribed in Github's developer documentation.

+
The django-rest-framework-link-header-pagination package includes a LinkHeaderPagination class which provides pagination via an HTTP Link header as described in Github's developer documentation.

             
 
            
diff --git a/api-guide/permissions/index.html b/api-guide/permissions/index.html
index 79c3dbae0..99913c616 100644
--- a/api-guide/permissions/index.html
+++ b/api-guide/permissions/index.html
@@ -484,7 +484,7 @@
                     
                   
                     
  • 
-                      Django Rest Framework API Key
+                      Django REST Framework API Key
                     
    • 
                   
                     
  • 
@@ -519,8 +519,8 @@
 
 
    Together with authentication and throttling, permissions determine whether a request should be granted or denied access.
    
 
    Permission checks are always run at the very start of the view, before any other code is allowed to proceed.  Permission checks will typically use the authentication information in the request.user and request.auth properties to determine if the incoming request should be permitted.
    
-
    Permissions are used to grant or deny access different classes of users to different parts of the API.
    
-
    The simplest style of permission would be to allow access to any authenticated user, and deny access to any unauthenticated user. This corresponds the IsAuthenticated class in REST framework.
    
+
    Permissions are used to grant or deny access for different classes of users to different parts of the API.
    
+
    The simplest style of permission would be to allow access to any authenticated user, and deny access to any unauthenticated user. This corresponds to the IsAuthenticated class in REST framework.
    
 
    A slightly less strict style of permission would be to allow full access to authenticated users, but allow read-only access to unauthenticated users. This corresponds to the IsAuthenticatedOrReadOnly class in REST framework.
    
 
    How permissions are determined
    
 
    Permissions in REST framework are always defined as a list of permission classes.
    
@@ -545,6 +545,15 @@ or if you override the get_object method on a generic view, then yo
     self.check_object_permissions(self.request, obj)
     return obj
    • +
    +

    Note: With the exception of DjangoObjectPermissions, the provided +permission classes in rest_framework.permssions do not implement the +methods necessary to check object permissions.

    +

    If you wish to use the provided permission classes in order to check object +permissions, you must subclass them and implement the +has_object_permission() method described in the Custom +permissions section (below).

    +

    Limitations of object level permissions

    For performance reasons the generic views will not automatically apply object level permissions to each instance in a queryset when returning a list of objects.

    Often when you're using object level permissions you'll also want to filter the queryset appropriately, to ensure that users only have visibility onto instances that they are permitted to view.

    @@ -608,7 +617,7 @@ class ExampleView(APIView): } return Response(content) -

    Note: it only supports & -and- and | -or-.

    +

    Note: it supports & (and), | (or) and ~ (not).

    API Reference

    AllowAny

    @@ -719,8 +728,8 @@ class BlacklistPermission(permissions.BasePermission):

    The DRY Rest Permissions package provides the ability to define different permissions for individual default and custom actions. This package is made for apps with permissions that are derived from relationships defined in the app's data model. It also supports permission checks being returned to a client app through the API's serializer. Additionally it supports adding permissions to the default and custom list actions to restrict the data they retrieve per user.

    Django Rest Framework Roles

    The Django Rest Framework Roles package makes it easier to parameterize your API over multiple types of users.

    -

    Django Rest Framework API Key

    -

    The Django Rest Framework API Key package allows you to ensure that every request made to the server requires an API key header. You can generate one from the django admin interface.

    +

    Django REST Framework API Key

    +

    The Django REST Framework API Key package provides the ability to authorize clients based on customizable API key headers. This package is targeted at situations in which regular user-based authentication (e.g. TokenAuthentication) is not suitable, e.g. allowing non-human clients to safely use your API. API keys are generated and validated through cryptographic methods and can be created and revoked from the Django admin interface at anytime.

    Django Rest Framework Role Filters

    The Django Rest Framework Role Filters package provides simple filtering over multiple types of roles.

    diff --git a/api-guide/relations/index.html b/api-guide/relations/index.html index a4d6ce2d0..df3314346 100644 --- a/api-guide/relations/index.html +++ b/api-guide/relations/index.html @@ -570,11 +570,11 @@ class Track(models.Model): unique_together = ('album', 'order') ordering = ['order'] - def __unicode__(self): + def __str__(self): return '%d: %s' % (self.order, self.title)

    StringRelatedField

    -

    StringRelatedField may be used to represent the target of the relationship using its __unicode__ method.

    +

    StringRelatedField may be used to represent the target of the relationship using its __str__ method.

    For example, the following serializer.

    class AlbumSerializer(serializers.ModelSerializer):
     tracks = serializers.StringRelatedField(many=True)
@@ -945,7 +945,7 @@ class CustomerHyperlink(serializers.HyperlinkedRelatedField):
     object_id = models.PositiveIntegerField()
     tagged_object = GenericForeignKey('content_type', 'object_id')
 
-    def __unicode__(self):
+    def __str__(self):
         return self.tag_name

    And the following two models, which may have associated tags:

    diff --git a/api-guide/requests/index.html b/api-guide/requests/index.html index 22012376c..e128c6d41 100644 --- a/api-guide/requests/index.html +++ b/api-guide/requests/index.html @@ -530,7 +530,7 @@

    Content negotiation

    The request exposes some properties that allow you to determine the result of the content negotiation stage. This allows you to implement behaviour such as selecting a different serialisation schemes for different media types.

    .accepted_renderer

    -

    The renderer instance what was selected by the content negotiation stage.

    +

    The renderer instance that was selected by the content negotiation stage.

    .accepted_media_type

    A string representing the media type that was accepted by the content negotiation stage.

    diff --git a/api-guide/serializers/index.html b/api-guide/serializers/index.html index 9c6448ef8..6c2df2e80 100644 --- a/api-guide/serializers/index.html +++ b/api-guide/serializers/index.html @@ -760,7 +760,7 @@ serializer = CommentSerializer(comment, data=data) serializer.is_valid() # False serializer.errors -# {'email': [u'Enter a valid e-mail address.'], 'created': [u'This field is required.']} +# {'email': ['Enter a valid e-mail address.'], 'created': ['This field is required.']}

    Each key in the dictionary will be the field name, and the values will be lists of strings of any error messages corresponding to that field. The non_field_errors key may also be present, and will list any general validation errors. The name of the non_field_errors key may be customized using the NON_FIELD_ERRORS_KEY REST framework setting.

    When deserializing a list of items, errors will be returned as a list of dictionaries representing each of the deserialized items.

    @@ -838,7 +838,7 @@ class GameRecord(serializers.Serializer):

    Partial updates

    By default, serializers must be passed values for all required fields or they will raise validation errors. You can use the partial argument in order to allow partial updates.

    # Update `comment` with partial data
-serializer = CommentSerializer(comment, data={'content': u'foo bar'}, partial=True)
+serializer = CommentSerializer(comment, data={'content': 'foo bar'}, partial=True)

    Dealing with nested objects

    The previous examples are fine for dealing with objects that only have simple datatypes, but sometimes we also need to be able to represent more complex objects, where some of the attributes of an object might not be simple datatypes such as strings, dates or integers.

    @@ -871,7 +871,7 @@ class CommentSerializer(serializers.Serializer): serializer.is_valid() # False serializer.errors -# {'user': {'email': [u'Enter a valid e-mail address.']}, 'created': [u'This field is required.']} +# {'user': {'email': ['Enter a valid e-mail address.']}, 'created': ['This field is required.']}

    Similarly, the .validated_data property will include nested data structures.

    Writing .create() methods for nested representations

    @@ -971,7 +971,7 @@ serializer.data

    You can provide arbitrary additional context by passing a context argument when instantiating the serializer. For example:

    serializer = AccountSerializer(account, context={'request': request})
 serializer.data
-# {'id': 6, 'owner': u'denvercoder9', 'created': datetime.datetime(2013, 2, 12, 09, 44, 56, 678870), 'details': 'http://example.com/accounts/6/details'}
+# {'id': 6, 'owner': 'denvercoder9', 'created': datetime.datetime(2013, 2, 12, 09, 44, 56, 678870), 'details': 'http://example.com/accounts/6/details'}

    The context dictionary can be used within any serializer field logic, such as a custom .to_representation() method, by accessing the self.context attribute.

    @@ -1485,10 +1485,10 @@ class MySerializer(MyBaseSerializer): >>> model = User >>> fields = ('id', 'username', 'email') >>> ->>> print UserSerializer(user) +>>> print(UserSerializer(user)) {'id': 2, 'username': 'jonwatts', 'email': 'jon@example.com'} >>> ->>> print UserSerializer(user, fields=('id', 'email')) +>>> print(UserSerializer(user, fields=('id', 'email'))) {'id': 2, 'email': 'jon@example.com'}

    Customizing the default fields

    diff --git a/api-guide/throttling/index.html b/api-guide/throttling/index.html index ed1a236d4..ddda40781 100644 --- a/api-guide/throttling/index.html +++ b/api-guide/throttling/index.html @@ -530,8 +530,10 @@ def example_view(request, format=None):

    Setting up the cache

    The throttle classes provided by REST framework use Django's cache backend. You should make sure that you've set appropriate cache settings. The default value of LocMemCache backend should be okay for simple setups. See Django's cache documentation for more details.

    If you need to use a cache other than 'default', you can do so by creating a custom throttle class and setting the cache attribute. For example:

    -
    class CustomAnonRateThrottle(AnonRateThrottle):
-    cache = get_cache('alternate')
+
    from django.core.cache import caches
+
+class CustomAnonRateThrottle(AnonRateThrottle):
+    cache = caches['alternate']
 
    
 
    You'll need to remember to also set your custom throttle class in the 'DEFAULT_THROTTLE_CLASSES' settings key, or using the throttle_classes view attribute.
    
 
    
diff --git a/community/3.0-announcement/index.html b/community/3.0-announcement/index.html
index 4c55848ea..91e17b1e2 100644
--- a/community/3.0-announcement/index.html
+++ b/community/3.0-announcement/index.html
@@ -763,7 +763,7 @@ LocationRatingSerializer():

    These fields will be mapped to serializers.ReadOnlyField() instances.

    >>> serializer = InvitationSerializer()
->>> print repr(serializer)
+>>> print(repr(serializer))
 InvitationSerializer():
     to_email = EmailField(max_length=75)
     message = CharField(max_length=1000)
diff --git a/community/release-notes/index.html b/community/release-notes/index.html
index e38de04fd..e3ddd77c2 100644
--- a/community/release-notes/index.html
+++ b/community/release-notes/index.html
@@ -486,10 +486,10 @@
 
    The timeline for deprecation of a feature present in version 1.0 would work as follows:

    3.9.x series

    +

    3.9.2

    +

    Date: 3rd March 2019

    +

    3.9.1

    -

    Date: 16th Janurary 2019

    +

    Date: 16th Janurary 2019