Re: Sharing validation with the admin under DRF 3
I think all you need to do is add the following to your model.
class Foo(models.Model):
from = models.IntegerField()
to = models.IntegerField()
def clean(self): if self.from > self.to:
raise ValidationError("`From` must be before or equal to `to`")
def save(self, **kwargs):
self.full_clean()
super().save(**kwargs)
On Thursday, July 2, 2020 at 5:00:59 PM UTC-5, Ben Warren wrote:
>
> I have a question about writing reusable validation logic shared between
> the admin and DRF. If I have this setup:
>
> class Foo(models.Model):
> from = models.IntegerField()
> to = models.IntegerField()
> def clean(self): if self.from > self.to:
> raise ValidationError("`From` must be before or equal to `to`")
>
> class FooSerializer(serializers.ModelSerializer):
> class Meta:
> model = Foo
>
> Then starting with DRF3 the clean() validation will not be called by the
> serializer. The docs mention that I could use this mixin:
>
> def validate(self, attrs):
> model = self.Meta.model
> instance = Model(attrs)
> instance.clean()
>
>
> but that it is dispreferred, and suggests "you really should look at
> properly separating the validation logic out of the model method if
> possible". How would I factor logic like the above so that it could be used
> in the admin and in DRF? What if the logic gets more complex, like "field B
> can be populated only if field A is > 7"?
>
> Would I do something like this? The reach into __dict__ feels weird.
>
> def ordervalidator(dct):
>if self.from > self.to:
> raise ValidationError # Using Django ValidationError, because the
> model admin needs it?
>
> class Foo(models.Model):
> from = models.IntegerField()
> to = models.IntegerField()
> validators = [ordervalidator]
> def clean(self):
>for validator in self.validators:
> validator(self.__dict__)
>
> class FooSerializer(serializers.ModelSerializer):
> class Meta:
> model = Foo
> validators = [ordervalidator]
>
--
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 django-rest-framework+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-rest-framework/d4d5e79b-6aa5-4afe-8b45-4ada71ef5060o%40googlegroups.com.
Re: Skip an object in ListView
What exception is it throwing? On Wednesday, July 1, 2020 at 2:49:46 PM UTC-5, Gagan Deep wrote: > > I have a SerializerMethodField in serializer. I am catching an exception > in the function like below. I want to skip this object in the ListView > entirely if that exception is caught. How can I do this? > > I am using ListApiView from rest_framework.generics > > > classFooSerializer(serializers.ModelSerializer): > foo = serializers.SerializerMethodField() > > get_foo(self, object): > try: > # Do something here > except: > # If an exception is captured than skip this object > > > -- 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 django-rest-framework+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/django-rest-framework/c15a63b8-b052-4ade-ae0f-c53e57d4a848o%40googlegroups.com.
Re: Django Rest Framework Validation Order Issue
Hi Özgür, I'm not sure if you saw it or not but I did come up with a solution in another branch (https://github.com/epicserve/drf-validation-issue/blob/fix-validation/pizzas/serializers.py) and I did end up overriding *run_validation* and *to_internal_value*. If I can find time, I think I'll look into putting my solution into a fork of DRF and just see what might break when I run tests. It doesn't seem like anything would break, but I'm not confident that is the case. On Wednesday, July 1, 2020 at 6:02:53 AM UTC-5, Özgür Akçalı wrote: > > I think you also need to override *run_validators *method in your example > project for it to work as you expect, just like you did for > *to_internal_value. > *If a validation error is raised fom run_validators method, *validate *method > is not called, so you can not aggregate any possible errors raised from > validation checks in that method. > > Also, with this flow, you should take care not to raise validation errors > in your custom *validate *methods one by one, but aggregate them and > raise them or return them together there as well. > > On Wednesday, July 1, 2020 at 1:45:00 PM UTC+3, Özgür Akçalı wrote: >> >> 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 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 >>>> 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 django-rest-framework+unsubscr...@googlegroups.com. >>>>> 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_source=footer> >>>>> . >>>>> >>>> >&g
Re: Django Rest Framework Validation Order Issue
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 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 > 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 django-rest-framework+unsubscr...@googlegroups.com. >> 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_source=footer> >> . >> > > > -- > > --- > Carl J. Nobile (Software Engineer) > carl.nob...@gmail.com > > --- > > -- > 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 django-rest-framework+unsubscr...@googlegroups.com. > 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_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 django-rest-framework+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/django-rest-framework/CA%2Bx7ZMp9HOprA-aUjP93s02BVLmMyz8%3DwKrGZjgA2gPAh2ExJg%40mail.gmail.com.
Re: Django Rest Framework Validation Order Issue
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 django-rest-framework+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/django-rest-framework/ea8a9b5d-a671-42b4-9cee-043f28f8efa3o%40googlegroups.com.
Re: Django Rest Framework Validation Order Issue
I understand that you can go about solving it this way, but it seems like a
lot of extra work when it just works the way you would expect on a Django
ModelForm. I'm guessing this isn't possible for it to "just work", so I
might end up making an issue in the DRF project.
On Saturday, June 27, 2020 at 3:34:05 PM UTC-5, Carl Nobile wrote:
>
> Then write your custom validation as a field validator and put them all in
> the list in the order you want them to fire off in or you could include the
> field validator checks into your custom validation method.
> The problem is that DRF can only implement what the common cases are, not
> all the edge cases people may need, but the hooks are there in the code to
> customize it the way you want.
>
>
> On Sat, Jun 27, 2020 at 4:05 PM Brent O'Connor > wrote:
>
>> Unfortunately, that doesn't really solve the issue because you want
>> field-level validation to run because you want to make sure that valid
>> numbers, etc. are being sent to the API.
>>
>> On Sat, Jun 27, 2020 at 12:25 PM Carl Nobile > > wrote:
>>
>>> It is possible to turn off the built infield errors. The empty list
>>> essentially turns off al field validation. If there are multiple and you
>>> don't want all turned off you would need to specify them yourself.
>>>
>>> Class SomeSeializer(...):
>>>
>>> class Meta:
>>> extra_kwargs = {
>>>'field_name': {'validators': []},
>>>}
>>>
>>> On Fri, Jun 26, 2020 at 6:08 PM 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 django-rest-framework+unsubscr...@googlegroups.com
>>>> .
>>>> To view this discussion on the web visit
>>>> https://groups.google.com/d/msgid/django-rest-framework/121a7ebe-4b34-4197-be60-1178730361f7o%40googlegroups.com
>>>>
>>>> <https://groups.google.com/d/msgid/django-rest-framework/121a7ebe-4b34-4197-be60-1178730361f7o%40googlegroups.com?utm_medium=email_source=footer>
>>>> .
>>>>
>>>
>>>
>>> --
>>>
>>> ---
>>> Carl J. Nobile (Software Engineer)
>>> carl@gmail.com
>>>
>>> ---
>>>
>>> --
>>> 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 django-rest-framework+unsubscr...@googlegroups.com
>>> .
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/django-rest-framework/CAGQqDQ%2BOzPQ-Xuad4OboE-%2BgXF_-uAkuxF%2B9XT5jLPiAnFJfog%40mail.gmail.com
>>>
>>> <https://groups.google.com/d/msgid/django-rest-framework/CAGQqDQ%2BOzPQ-Xuad4OboE-%2BgXF_-uAkuxF%2B9XT5jLPiAnFJfog%40mail.gmail.com?utm_medium=email_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 django-rest-framework+unsubscr...@googlegroups.com
>> .
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-rest-framework/CA%2Bx7ZMq7iMmi4PaQ9aBjGaEybKWH0piWumZTOOfR5-wJOBwwZw%40mail.gmail.com
>>
&g
Re: Call a fucntion after POST
You can override the save method on your serializer or on the model.
On Sunday, June 28, 2020 at 1:14:37 AM UTC-5, Muhammad Bashir Al-Noimi
wrote:
>
> Hi,
>
> How can I call a function after a successful POST?
>
> Below a simple contact example I want to run a function called
> contact_added() after a succefull contcat adding/updating.
> Sorry for the silly question, I'm still a newbie in Django universe :)
>
> #models.py
> from django.db import models
>
> class Contact(models.Model):
> id = models.BigIntegerField(primary_key=True, unique=True)
> mobile = models.BigIntegerField(default=0)
> username = models.CharField(max_length=60, blank=True, null=True)
> first_name = models.CharField(max_length=60, blank=True, null=True)
> last_name = models.CharField(max_length=60, blank=True, null=True)
>
> def __str__(self):
> return str(self.mobile)
>
>
> #views.py
> from django.shortcuts import render
>
> from rest_framework import viewsets
>
> from .serializers import ContactSerializer
> from .models import Contact
>
>
> class ContactViewSet(viewsets.ModelViewSet):
> queryset = Contact.objects.all().order_by('mobile')
> serializer_class = ContactSerializer
>
>
> #serializers.py
> from rest_framework import serializers
>
> from .models import Contact
>
> class ContactSerializer(serializers.HyperlinkedModelSerializer):
> class Meta:
> model = Contact
> fields = ('id', 'mobile', 'username', 'first_name', 'last_name')
>
>
>
--
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 django-rest-framework+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-rest-framework/601119ba-f454-43aa-a2c7-3f7044e50fc1o%40googlegroups.com.
Re: Django Rest Framework Validation Order Issue
Unfortunately, that doesn't really solve the issue because you want
field-level validation to run because you want to make sure that valid
numbers, etc. are being sent to the API.
On Sat, Jun 27, 2020 at 12:25 PM Carl Nobile wrote:
> It is possible to turn off the built infield errors. The empty list
> essentially turns off al field validation. If there are multiple and you
> don't want all turned off you would need to specify them yourself.
>
> Class SomeSeializer(...):
>
> class Meta:
> extra_kwargs = {
>'field_name': {'validators': []},
>}
>
> On Fri, Jun 26, 2020 at 6:08 PM 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 django-rest-framework+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-rest-framework/121a7ebe-4b34-4197-be60-1178730361f7o%40googlegroups.com
>> <https://groups.google.com/d/msgid/django-rest-framework/121a7ebe-4b34-4197-be60-1178730361f7o%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>
>
> --
>
> ---
> Carl J. Nobile (Software Engineer)
> carl.nob...@gmail.com
>
> ---
>
> --
> 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 django-rest-framework+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-rest-framework/CAGQqDQ%2BOzPQ-Xuad4OboE-%2BgXF_-uAkuxF%2B9XT5jLPiAnFJfog%40mail.gmail.com
> <https://groups.google.com/d/msgid/django-rest-framework/CAGQqDQ%2BOzPQ-Xuad4OboE-%2BgXF_-uAkuxF%2B9XT5jLPiAnFJfog%40mail.gmail.com?utm_medium=email_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 django-rest-framework+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-rest-framework/CA%2Bx7ZMq7iMmi4PaQ9aBjGaEybKWH0piWumZTOOfR5-wJOBwwZw%40mail.gmail.com.
