The obvious use case there is something that can't be initialized with a reasonable default value. Null is valid because you just plain need it, but blank is false because you never want it to be null ever again except if the back end explicitly demands it.
On Thu, Aug 4, 2016 at 1:35 AM, James Schneider <jrschneide...@gmail.com> wrote: > On Aug 3, 2016 5:18 PM, "Kevin Brown" <ke...@kevin-brown.com> wrote: > > > > Within Django REST framework a discussion sparked about how the > combination of null=True and blank=False should be handled with validation. > What side is right in the discussion isn't the question here. > > > > Are there cases where it makes sense to set both `null=True`, which > should allow for `None` to be set on a field, and to set `blank=False`, > which does not allow blank values to be set on the field? > > > > And what is considered to be a "blank value" for a field? > > > > blank= is a helper attribute for forms, not directly on the model or > database itself. If you have null=True and blank=False, then an entry by > way of a form will not allow an empty/null value, but you would still be > able to set that same model field to null/False via the ORM directly, > either through the shell, a management command, or a 3rd party process that > may be using that table directly. > > Serializers in DRF are akin to Forms in Django. If you are performing > validation at the serializer level in DRF, my expectation would be that > blank=False would be taken into account, and that a value would be required > to pass validation. > > At the ORM level (Model.objects.create(), etc.) I would NOT want that to > apply. > > If you need to bypass that restriction for a particular form/serializer, a > custom class definition would be used. > > An example would be a user object. An email address may be required for > every account, but an admin may want to create accounts via the ORM without > an email address because they may not know the correct one, or it is an > internal system account, etc. Your code should account for that situation > if that's the case. > > -James > > -- > You received this message because you are subscribed to the Google Groups > "Django users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to django-users+unsubscr...@googlegroups.com. > To post to this group, send email to django-users@googlegroups.com. > Visit this group at https://groups.google.com/group/django-users. > To view this discussion on the web visit https://groups.google.com/d/ > msgid/django-users/CA%2Be%2BciUb-K4%3DuioVa7F%3DHn0-8_ > LQwr_o3S9Zp1dehbQX693EQw%40mail.gmail.com > <https://groups.google.com/d/msgid/django-users/CA%2Be%2BciUb-K4%3DuioVa7F%3DHn0-8_LQwr_o3S9Zp1dehbQX693EQw%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at https://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CA%2Bv0ZYUhvK6Y2zJ2HtnX04ZxcoCj491cZ%2BSB7aX5JE4tUK1SNA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
