Clarify 'to_internal_value()' validation behavior #5466
Conversation
|
I'm not totally sure this is the tack that the docs should take. Perhaps we should instead just be calling out more clearly (at L997) that |
| @@ -1011,7 +1011,7 @@ Takes the object instance that requires serialization, and should return a primi | |||
|
|
|||
| Takes the unvalidated incoming data as input and should return the validated data that will be made available as `serializer.validated_data`. The return value will also be passed to the `.create()` or `.update()` methods if `.save()` is called on the serializer class. | |||
|
|
|||
| If any of the validation fails, then the method should raise a `serializers.ValidationError(errors)`. Typically the `errors` argument here will be a dictionary mapping field names to error messages. | |||
| If any of the validation fails, then the method should raise a `serializers.ValidationError(errors)`. The `errors` argument should be a dictionary mapping field names (or `settings.NON_FIELD_ERRORS_KEY`) to a list of error messages. If you don't need to alter deserialization behavior and instead want to provide object-level validation, it's recommended that you intead override the [`.validate()`](#object-level-validation) method. | |||
There was a problem hiding this comment.
If we did accept this docs change, I think we ought to at least split this into two paragraphs.
|
Just to leave my 2 cents here. I am not sure how this is supposed to work, but in my project we use |
|
@MadWombat, it's difficult to give advice without having a practical/concrete example to work from. Open a discussion on the support group and I'll see if I can help. |
|
@tomchristie I take your point about steering people to validate_field, but does this change on its own not help that? i.e. removing the mention of validation from the opening paragraph. Perhaps an additional note saying “make sure you read all the stuff higher up before you take on this” might be enough... it is in the Advance Use section. (Slight aside, I think my first conversations on using DRF, moons ago, were around using validate_field functions to transform values.) |
This should resolve #3864 and #5438.