Though you can not achieve what you want by just overriding *validate, *and not overriding *run_validation*.
This would be a major change in DRF though, as with the current behavior, when you write your *validate *method, you can assume other validations passed, so I imagine changing this behavior as default now would break a lot of existing code. I think this would fit better as an optional addition, maybe with a configuration option on existing serializer classes, or with a different set of serializer classes. On Wednesday, July 1, 2020 at 1:59:33 AM UTC+3, Brent O'Connor wrote: > > I guess my point is that I don't feel like I should have to override > anything and this should be DRF's default behavior. 🙂 Thank you for > pointing out that `validation` should be the method that should be used. > > On Tue, Jun 30, 2020, 5:42 PM Carl Nobile <[email protected] > <javascript:>> wrote: > >> Brent, overriding the 'to_internal_value' method is normal and >> encouraged, however, the 'run_validation' shouldn't generally be >> overridden, what you can override is the 'validate' method which is called >> by 'run_validation'. >> ~Carl >> >> On Tue, Jun 30, 2020 at 5:51 PM Brent O'Connor <[email protected] >> <javascript:>> wrote: >> >>> For anyone that might come across this thread, I went ahead and created an >>> issue <https://github.com/encode/django-rest-framework/issues/7394> for >>> this on Github. >>> >>> On Friday, June 26, 2020 at 5:08:03 PM UTC-5, Brent O'Connor wrote: >>>> >>>> I created an example project >>>> <https://github.com/epicserve/drf-validation-issue> to illustrate this >>>> issue, but basically if you have custom validation logic on a serializer >>>> and the data has a field that isn't valid, then the errors raised are only >>>> the field level errors and not the custom validation logic errors. This >>>> ends up being a bad user experience because the user can fix the field >>>> error and then when post another request they can end up getting errors >>>> thrown in the custom validation. I'm thinking this might need to be an >>>> issue added the DRF project on Github, but thought I would check here >>>> first. Please see the project example for more details. >>>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Django REST framework" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected] >>> <javascript:>. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/django-rest-framework/ea8a9b5d-a671-42b4-9cee-043f28f8efa3o%40googlegroups.com >>> >>> <https://groups.google.com/d/msgid/django-rest-framework/ea8a9b5d-a671-42b4-9cee-043f28f8efa3o%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> >> >> >> -- >> >> ------------------------------------------------------------------------------- >> Carl J. Nobile (Software Engineer) >> [email protected] <javascript:> >> >> ------------------------------------------------------------------------------- >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Django REST framework" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected] <javascript:> >> . >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/django-rest-framework/CAGQqDQL2UvWyjr6UgK%2BpCDexAc%2BC%2BeBUGxAwZYyaxC3dJYwGsQ%40mail.gmail.com >> >> <https://groups.google.com/d/msgid/django-rest-framework/CAGQqDQL2UvWyjr6UgK%2BpCDexAc%2BC%2BeBUGxAwZYyaxC3dJYwGsQ%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> > -- You received this message because you are subscribed to the Google Groups "Django REST framework" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/django-rest-framework/bfc354ad-f398-4380-a481-a1d1764f21f4o%40googlegroups.com.
