Re: null=True and blank=False within model fields

[Alex Heyden]

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 
wrote:

> On Aug 3, 2016 5:18 PM, "Kevin Brown"  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
> 
> .
>
> 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.

Re: null=True and blank=False within model fields

[James Schneider]

On Aug 3, 2016 5:18 PM, "Kevin Brown"  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.
For more options, visit https://groups.google.com/d/optout.

null=True and blank=False within model fields

[Kevin Brown]

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?

-- 
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/048e1e36-cf1f-4087-b989-d527994eb79b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.