REST framework now has more explicit and clear control over validating empty values for fields.
REST framework now has more explicit and clear control over validating empty values for fields.
Previously the meaning of the `required=False` keyword argument was underspecified. In practice its use meant that a field could either be not included in the input, or it could be included, but be `None`.
Previously the meaning of the `required=False` keyword argument was underspecified. In practice its use meant that a field could either be not included in the input, or it could be included, but be `None` or the empty string.
We now have a better separation, with separate `required` and `allow_none` arguments.
We now have a better separation, with separate `required`, `allow_none` and `allow_blank` arguments.
The following set of arguments are used to control validation of empty values:
The following set of arguments are used to control validation of empty values:
...
@@ -519,7 +519,7 @@ The following set of arguments are used to control validation of empty values:
...
@@ -519,7 +519,7 @@ The following set of arguments are used to control validation of empty values:
Typically you'll want to use `required=False` if the corresponding model field has a default value, and additionally set either `allow_none=True` or `allow_blank=True` if required.
Typically you'll want to use `required=False` if the corresponding model field has a default value, and additionally set either `allow_none=True` or `allow_blank=True` if required.
The `default` argument is there if you need it, but you'll more typically want defaults to be set on model fields, rather than serializer fields.
The `default` argument is also available and always implies that the field is not required to be in the input. It is unnecessary to use the `required` argument when a default is specified, and doing so will result in an error.
