The main differnce for null and blank is
null=True/False related to database
blank=True/False related to form validation, used when
form.is_valid() is called.
null=True defines database should accept NULL values, on other hand
defines on form validation this field should accept blank values or not(If blank=True it accept form without a value in that field and
blank=False[default value] on form validation it will show This field is required error.
The are some use cases for all four possible configurations:
null=False, blank=False: This is the default configuration and means that the value is required in all circumstances.
null=True, blank=True: This means that the field is optional in all circumstances.
null=False, 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 of this configuration 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 NULL was 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 (null=False).
Another use of this configuration is when you want to indicate that a ManyToManyField is optional. Because this field is implemented as a separate table rather than a database column, null is meaningless. The value of blank will still affect forms, though, controlling whether or not validation will succeed when there are no relations.
null=True, 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 for this that I've seen is when you have a ForeignKey for 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_NULL to implement a simple kind of soft deletion.
The default values of null and blank are False.
Also there is a special case, when you need to accept NULL values for a BooleanField, use
We take the vision which comes from dreams and apply the magic of science and mathematics, adding the heritage of our profession and our knowledge to create a design.