[Django] #36286: if I specify `null=False, blank=False` in a `models.TextField`, django should not generate a blank string for me

11 views
Skip to first unread message

Django

unread,
Apr 2, 2025, 9:44:12 AM4/2/25
to django-...@googlegroups.com
#36286: if I specify `null=False, blank=False` in a `models.TextField`, django
should not generate a blank string for me
---------------------+-----------------------------------------
Reporter: bwo | Type: Uncategorized
Status: new | Component: Uncategorized
Version: 5.1 | Severity: Normal
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
---------------------+-----------------------------------------
Suppose I have an existing model `M` with integer-valued fields `a` and
`b` and somewhere in my test code I do this: `M.objects.create(a=1, b=2)`.

Now I create add a new non-nullable string-valued field by altering M's
definition like so:

{{{

class Choices(models.TextChoices):
one = ("one", "one")
two = ("two", "two")

class M(models.Model):
# existing fields omitted
c = models.TextField(null=False, choices=Choices.choices)
}}}

I add some code that switches on the value of `c`, knowing that it will
certainly be either "one" or "two" (even though django actually does no
validation here…). I run tests, confident in the knowledge that either
Django or the database will complain at every site that doesn't set a
value for `c`.

In fact, this doesn't happen. The value of `c`, if not provided, generated
and set to `''`. This behavior by itself strikes me as a bug: if I wanted
it to be ok to not provide a value for `c`, I wouldn't have made it non-
nullable. But fine, let's add a `blank=False` (eve though this parameter
is apparently related to forms) to the definition and try again.

It's still `''`!
--
Ticket URL: <https://code.djangoproject.com/ticket/36286>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.

Django

unread,
Apr 2, 2025, 9:56:23 AM4/2/25
to django-...@googlegroups.com
#36286: if I specify `null=False, blank=False` in a `models.TextField`, django
should not generate a blank string for me
-------------------------------+--------------------------------------
Reporter: bwo | Owner: (none)
Type: Uncategorized | Status: closed
Component: Uncategorized | Version: 5.1
Severity: Normal | Resolution: wontfix
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------+--------------------------------------
Changes (by Clifford Gama):

* resolution: => wontfix
* status: new => closed

Comment:

See #35671 and https://forum.djangoproject.com/t/get-or-create-and-create-
with-unspecified-non-nullable-fields/33755.

Empty strings do not violate `null=False` and they are the default empty
value for string-based fields. If you don't want them as defaults,
consider setting `default=None`. `blank=False will only disallow them in
forms, not in Python code.
--
Ticket URL: <https://code.djangoproject.com/ticket/36286#comment:1>

Django

unread,
Apr 2, 2025, 1:31:07 PM4/2/25
to django-...@googlegroups.com
#36286: if I specify `null=False, blank=False` in a `models.TextField`, django
should not generate a blank string for me
-------------------------------------+-------------------------------------
Reporter: bwo | Owner: (none)
Type: Bug | Status: closed
Component: Database layer | Version: dev
(models, ORM) |
Severity: Normal | Resolution: invalid
Keywords: | Triage Stage:
| Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Changes (by Natalia Bidart):

* component: Uncategorized => Database layer (models, ORM)
* resolution: wontfix => invalid
* type: Uncategorized => Bug
* version: 5.1 => dev

Comment:

Thank you Clifford for the triage! I will just adjust the resolution,
since for tickets that are a user support request we usually close them as
`invalid`. We usually use `wontfix` for New Feature requests.
--
Ticket URL: <https://code.djangoproject.com/ticket/36286#comment:2>
Reply all
Reply to author
Forward
0 new messages