Особо надо отметить использование blank=True совместно с полями даты/времени и численными. Погрузимся в теорию.

SQL обладает собственным способом представления пустых значений — специальное значение NULL. NULL может обозначать «неизвестное» или «неверное», или какое-то другое конкретное значение.

В SQL значение NULL отличается от пустой строки, так же как и в Python специальный объект None отличается от пустой строки («»). Это значит, что некоторые типы полей (например, VARCHAR) могут содержать как NULL, так и пустые строки.

Это может вызвать нежелательную путаницу и неопределённость: «Почему эта запись содержит NULL, а следующая пустую строку? В чём разница? Или данные просто были ошибочно введены?» И: «Как мне получить все записи с пустым полем — следует ли искать записи с пустой строкой и с NULL, или учитывать только пустую строку?»

Что бы избежать подобной путаницы, Django автоматически создает операторы CREATE TABLE (которые рассматривались в главе «Модели»), добавляя явно NOT NULL к каждому полю. Например, сгенерированый запрос создания таблицы для модели Author:

CREATE TABLE "books_author" (
    "id" serial NOT NULL PRIMARY KEY,
    "first_name" varchar(30) NOT NULL,
    "last_name" varchar(40) NOT NULL,
    "email" varchar(75) NOT NULL
);

В большинстве случаев, такое стандартное поведение является оптимальным для вашего приложения и избавит вас от проблем, вызванных несоответствием данных. И оно отлично работает с остальными компонентами Django: такими как административный интерфейс, который вставляет пустую строку (а не значение NULL), если вы оставляете символьное поле пустым.

Исключением являются поля базы данных, для которых пустая строка является недопустимым значением — например, поля даты, времени, числовые. Если вы попытаетесь добавить пустую строку в поле даты или целочисленное поле, скорее всего вы получите ошибку, в зависимости от типа базы данных, которую вы используете. (PostgreSQL, являясь строгим, вернет исключение; MySQL может принять или нет, в зависимости от используемой версии, времени дня и фазы луны.) В таких случаях, NULL является единственным вариантом определения пустого значения. В моделях Django, вы можете указать, что поле допускает значения NULL, добавив параметр null=True в определение поля.

Так вот к чему мы ведём: если вы хотите разрешить пустые значения для полей даты(таких как, DateField, TimeField, DateTimeField) или числовых полей( IntegerField, DecimalField, FloatField), вы должны использовать и blank=True, и null=True.

Для примера, изменим модель Book, разрешив пустое значение для поля publication_date. Вот так вот будет выглядеть наша модель:

class Book(models.Model):
    title = models.CharField(max_length=100)
    authors = models.ManyToManyField(Author)
    publisher = models.ForeignKey(Publisher)
    publication_date = models.DateField(blank=True, null=True)

Добавление null=True является более сложным, чем добавление blank=True, потому что null=True изменяет структуру базы данных — то есть, изменяет оператор CREATE TABLE, убирая NOT NULL у поля publication_date. Чтобы завершить изменение, вы должны обновить структуру таблицы в базе данных.

По ряду причин Django не пытается автоматизировать изменение структуры базы данных, так что ответственность за выполнение соответствующих запросов ALTER TABLE ложится на вас всякий раз, когда вы вносите подобные изменения в модель. Напомним, что вы можете использовать команду manage.py dbshell, чтобы войти в оболочку сервера базы данных. Вот запрос для внесения изменений, которые мы совершили:

ALTER TABLE books_book ALTER COLUMN publication_date DROP NOT NULL;

(Обратите внимание, что такой синтаксис специфичен для PostgreSQL.)

Изменения структуры базы данных более детально мы рассмотрим в главе «Расширения для шаблонной системы».

Завершив изменения, вернёмся к интерфейсу администратора. Теперь форма редактирования книги позволяет оставлять пустой дату публикации.