* Add graphwrap to third-party-packages documentation
* Fix typo in third party packages docs
* Remove additional newline
Co-authored-by: Paul Gilmartin <paulgilmartin@Pauls-MacBook-Pro.local>
Co-authored-by: Tom Christie <tom@tomchristie.com>
When I apply a theme to the bootstrap used in the project, boolean inputs are out of line with the rest of the form. With this small payment, this no longer occurs.
* Handle None in to_representation()
* Return None as '' in to_representation() when coerce_to_string=True
* Handle '' as None in to_internal_value(), for symmetry with
to_representation(), and because the empty concept doesn't make sense
for Decimal.
Added a sentence describing the use of a dictionary as the `detail` argument of a ValidationError, and how it can be used to add field-level errors during object-level validation.
There were recent updates to the `@action` decorator calling a little more attention to the kwargs it accepts.
I thought it would be useful to also provide an example in the throttling section of how those kwargs can be used to define/override throttle_classes through the action decorator as well.
In the `to_internal_value` method of the primary key and slug related fields, `TypeError`s and `ValueError`s are caught from `self.get_queryset().get(...)` and presented to the user. This works fine for most cases, but can cause problems if the exception is coming from `self.get_queryset()` rather than from the `.get(...)`.
It means errors in the `get_queryset` method can be hidden and presented back to the user as though, for example, the input provided to the `to_internal_value` was the wrong type, whereas in reality there's a bug in the `get_queryset` method and therefore it should bubble up and be exposed as a server error.
I've decided to fix this because twice now I've had to debug why I'm seeing `invalid_type` errors from my serializer (errors like `wrong pk type - int` when the `pk` type on my model is `int`) when the real problem was a bug in my custom `get_queryset` method.
Erroring on deprecation or pending deprecation warnings means they are caught early. This will avoid the cycle of releasing with 'support for Django X', then chasing all the deprecation warnings one-by-one. Instead, when a new Django version is added to the test matrix, it will fail until all the relevant warnings are fixed. This avoids passing these warnings on to users, some of whom don't upgrade until they are all fixed.
