Built-in Field Validations in Django models are the default validations that come predefined to all Django fields. Every field comes in with built-in validations from Django validators. One can also add more built-in field validations for applying or removing certain constraints on a particular field. null=True
will make the field accept NULL values. Blank values for Django field types such as DateTimeField or ForeignKey will be stored as NULL in the database.
Syntax
field_name = models.Field(null = True)
Django Built-in Field Validation null=True
Explanation
Illustration of null=True using an Example. Consider a project named neveropen
having an app named Lazyroar
.
Refer to the following articles to check how to create a project and an app in Django.
Enter the following code into models.py
file of Lazyroar app. We will be using CharField for experimenting for all field options.
from django.db import models from django.db.models import Model # Create your models here. class GeeksModel(Model): Lazyroar_field = models.CharField(max_length = 200 , null = True ) |
After running makemigrations and migrate on Django and rendering the above model, let us try to create an instance using None from Django shell. To start Django shell, enter the command,
Python manage.py shell
Now let us try to create instance of GeeksModel using None.
# importing required model from Lazyroar.models import GeeksModel # creating instance of GeeksModel s = GeeksModel.objects.create(Lazyroar_field = None ) # saving current model instance s.save() |
Let us check in admin interface if the instance of model is created.
Therefore, null=True modifies the field to accept NULL values or in python’s terms None Values.
Advanced Concepts with null=True
Avoid using null on string-based fields such as CharField and TextField. 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. One exception is when a CharField has both unique=True and blank=True set. In this situation, null=True
is required to avoid unique constraint violations when saving multiple objects with blank values.
For both string-based and non-string-based fields, one 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).
More Built-in Field Validations
Field Options | Description |
---|---|
Null | If True, Django will store empty values as NULL in the database. Default is False. |
Blank | If True, the field is allowed to be blank. Default is False. |
db_column | The name of the database column to use for this field. If this isn’t given, Django will use the field’s name. |
Default | The default value for the field. This can be a value or a callable object. If callable it will be called every time a new object is created. |
help_text | Extra “help” text to be displayed with the form widget. It’s useful for documentation even if your field isn’t used on a form. |
primary_key | If True, this field is the primary key for the model. |
editable | If False, the field will not be displayed in the admin or any other ModelForm. They are also skipped during model validation. Default is True. |
error_messages | The error_messages argument lets you override the default messages that the field will raise. Pass in a dictionary with keys matching the error messages you want to override. |
help_text | Extra “help” text to be displayed with the form widget. It’s useful for documentation even if your field isn’t used on a form. |
verbose_name | A human-readable name for the field. If the verbose name isn’t given, Django will automatically create it using the field’s attribute name, converting underscores to spaces. |
validators | A list of validators to run for this field. See the validators documentation for more information. |
Unique | If True, this field must be unique throughout the table. |
<!–
–>
Please Login to comment…