What is the difference between null=True and blank=True in Django?
NOT NULL) on the column in your DB. Blank values for Django field types such as
ForeignKey will be stored as
NULL in the DB.
blank determines whether the field will be required in forms. This includes the admin and your custom forms. If
blank=True then the field will not be required, whereas if it's
False the field cannot be blank.
The combo of the two is so frequent because typically if you're going to allow a field to be blank in your form, you're going to also need your database to allow
NULL values for that field. The exception is
TextFields, which in Django are never saved as
NULL. Blank values are stored in the DB as an empty string (
A few examples:
models.DateTimeField(blank=True) # raises IntegrityError if blankmodels.DateTimeField(null=True) # NULL allowed, but must be filled out in a form
Obviously, Those two options don't make logical sense to use (though there might be a use case for
null=True, blank=False if you want a field to always be required in forms, optional when dealing with an object through something like the shell.)
models.CharField(blank=True) # No problem, blank is stored as ''models.CharField(null=True) # NULL allowed, but will never be set as NULL
TEXT types are never saved as
NULL by Django, so
null=True is unnecessary. However, you can manually set one of these fields to
None to force set it as
NULL. If you have a scenario where that might be necessary, you should still include
This is how the ORM maps
null fields for Django 1.8
class Test(models.Model): charNull = models.CharField(max_length=10, null=True) charBlank = models.CharField(max_length=10, blank=True) charNullBlank = models.CharField(max_length=10, null=True, blank=True) intNull = models.IntegerField(null=True) intBlank = models.IntegerField(blank=True) intNullBlank = models.IntegerField(null=True, blank=True) dateNull = models.DateTimeField(null=True) dateBlank = models.DateTimeField(blank=True) dateNullBlank = models.DateTimeField(null=True, blank=True)
The database fields created for PostgreSQL 9.4 are :
CREATE TABLE Test ( id serial NOT NULL, "charNull" character varying(10), "charBlank" character varying(10) NOT NULL, "charNullBlank" character varying(10), "intNull" integer, "intBlank" integer NOT NULL, "intNullBlank" integer, "dateNull" timestamp with time zone, "dateBlank" timestamp with time zone NOT NULL, "dateNullBlank" timestamp with time zone, CONSTRAINT Test_pkey PRIMARY KEY (id))
The database fields created for MySQL 5.6 are :
CREATE TABLE Test ( `id` INT(11) NOT NULL AUTO_INCREMENT, `charNull` VARCHAR(10) NULL DEFAULT NULL, `charBlank` VARCHAR(10) NOT NULL, `charNullBlank` VARCHAR(10) NULL DEFAULT NULL, `intNull` INT(11) NULL DEFAULT NULL, `intBlank` INT(11) NOT NULL, `intNullBlank` INT(11) NULL DEFAULT NULL, `dateNull` DATETIME NULL DEFAULT NULL, `dateBlank` DATETIME NOT NULL, `dateNullBlank` DATETIME NULL DEFAULT NULL)
It's crucial to understand that the options in a Django model field definition serve (at least) two purposes: defining the database tables, and defining the default format and validation of model forms. (I say "default" because the values can always be overridden by providing a custom form.) Some options affect the database, some options affect forms, and some affect both.
When it comes to
blank, other answers have already made clear that the former affects the database table definition and the latter affects model validation. I think the distinction can be made even clearer by looking at use cases for all four possible configurations:
blank=False: This is the default configuration and means that the value is required in all circumstances.
blank=True: This means that the field is optional in all circumstances. (As noted below, though, this is not the recommended way to make string-based fields optional.)
blank=True: This means that the form doesn't require a value but the database does. There are a number of use cases for this:
The most common use is for optional string-based fields. As noted in the documentation, the Django idiom is to use the empty string to indicate a missing value. If
NULLwas also allowed you would end up with two different ways to indicate a missing value.
Another common situation is that you want to calculate one field automatically based on the value of another (in your
save()method, say). You don't want the user to provide the value in a form (hence
blank=True), but you do want the database to enforce that a value is always provided (
Another use is when you want to indicate that a
ManyToManyFieldis optional. Because this field is implemented as a separate table rather than a database column,
nullis meaningless. The value of
blankwill still affect forms, though, controlling whether or not validation will succeed when there are no relations.
blank=False: This means that the form requires a value but the database doesn't. This may be the most infrequently used configuration, but there are some use cases for it:
It's perfectly reasonable to require your users to always include a value even if it's not actually required by your business logic. After all, forms are only one way of adding and editing data. You may have code that is generating data which doesn't need the same stringent validation that you want to require of a human editor.
Another use case that I've seen is when you have a
ForeignKeyfor which you don't wish to allow cascade deletion. That is, in normal use the relation should always be there (
blank=False), but if the thing it points to happens to be deleted, you don't want this object to be deleted too. In that case you can use
on_delete=models.SET_NULLto implement a simple kind of soft deletion.