differentiate null=True, blank=True in django
When we add a database field in django we generally write models.CharField(max_length=100, null=True, blank=True) . The same is done with ForeignKey , DecimalField etc. What is the basic difference in having
null=True only blank=True only null=True , blank=True in respect to different ( CharField , ForeignKey , ManyToManyField , DateTimeField ) fields. What are the advantages/disadvantages of using 1/2/3?
null=True sets NULL (versus NOT NULL ) on the column in your DB. Blank values for Django field types such as DateTimeField or ForeignKey will be stored as NULL in the DB.
blank=True determines whether the field will be required in forms. This includes the admin and your own 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 CharField s and TextField s, 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 blank
models.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, but 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
CHAR and 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 null=True .
This is how the ORM maps blank & 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
)
As said in Django Model Field reference: Link
Field options
The following arguments are available to all field types. All are optional.
null
Field.null If True , Django will store empty values as NULL in the database. Default is False .
Avoid using null on string-based fields such as CharField and TextField because empty string values will always be stored as empty strings, not as NULL . If a string-based field has null=True , that means it has two possible values for "no data": NULL , and the empty string. In most cases, it's redundant to have two possible values for "no data"; the Django convention is to use the empty string, not NULL .
For both string-based and non-string-based fields, you will also need to set blank=True if you wish to permit empty values in forms, as the null parameter only affects database storage (see blank ).
Note
When using the Oracle database backend, the value NULL will be stored to denote the empty string regardless of this attribute
blank
Field.blank If True , the field is allowed to be blank. Default is False .
Note that this is different than null . null is purely database-related, whereas blank is validation-related. If a field has blank=True , form validation will allow entry of an empty value. If a field has blank=False , the field will be required.