from django.db import models class Saas(models.Model): data = models.DateTimeField(blank=True, null=True) title = models.CharField(max_length=128, blank=True ) text = models.TextField(blank=True, null=True) def __unicode__(self): return self.title
Параметры типов полей моделей.
text == models.TextField(blank=True, null=True)
Для новичков переведу на человеческий язык, то, что написано.
Создать таблицу в базе (техе = models.....) данных, в виде текстового поля (TextField) не ограниченной длины (к примеру для текста статьи), разрешить при заполнении полю оставаться пустым (blank=true), (вы тоже, так будете читать, не волнуйтесь).
Если вы прочитаете, этот кусок текста..................разрешить при заполнении полю оставаться пустым (blank=true), (вы тоже, так будете читать, не волнуйтесь).
То наверное заметите, что (null=True), там просто нет.
Но даже опытные программисты, пишут код так. Хотя в справке ясно написано:
выдержка из справки Django:
Избегайте использования null для строковых полей таких, как CharField и TextField, т.к. пустое значение, всегда будет сохранено как пустая строка, а не NULL.
А теперь представьте себе, у вас сто приложений и каждому приложению при обращении к базе данных, Django сделает много лишних шагов.
Например.
Шаг 1 . Обратится к базе.
Шаг 2. Прочитает, что есть два параметра
.......(blank=True, null=True)
Вычислит, что blank= True - и определит для себя, это строка
Вычислит null=True, - это ничего.
Обратится в ядро, получит команду использовать blank= True,
Для себя, определит, что null=True, здесь вообще не уместно, но скрипя зубами передаст, на первое место указав явно использовать
blank= True.
А вот MySQL? здесь всё зависит от фазы луны и настроения и сервера конкретного.
Вариант 1. Проглотит и сайт будет работать (но при смене версии, вдруг программист, увидит ошибку на сайте ). И наверное не подумает, а пошёл бы учится в школу Бовсуновского, так не было бы этой ошибки. И начнутся мытарства по инету и поиски. Страшно, что, так пишут код более 50% программистов в рунете, потом уберут null=True, ошибка пропадёт, программист вздохнёт с облегчением. ....
Повезло.
Вариант 2. База данных не примет и програмист вынужден будет исправить сразу (что не происходит в MySQL практически никогда)
Вся проблема в том, что програмист считает, что :
(blank=True, null=True)- одним целым.
И читает для себя, разрешить полю быть не обязательным, при заполнении (иными словами мы можем отправить пустую статью).
Мы себе такого не можем позволить, терять время из-за собственной недоученности и разберём тонкое различие между blank и null и типы полей, где обязательно использование совместно blank и null.
А насчёт механизма поясню. Параметр blank - расширяет модель Джанго и относится к коду Django.
Параметр null - вооще ни как не связана с Django, а относится к особенности устройства базы данных (например MySql)
И именно это различие не понимают многие. В справке про это нет ничего, кроме рекомендации, для меня явной.
Вот в курсе 20 мы разобрались в этом вопросе досконально. Визуально на пальцах, потом практическим путём, набрав код в PyCarm, и посмотрев реузльтат в базе данных, а, так же выписали поля, к которым применим null.
Вообще в рунете вопросы параметров не рассматриваются, а просто говорят многие, запишите так.........
Обеспечив будущему программисту часы поиска ошибок, непонимая откуда они взялись. А посмотреть-то надо всего пару курсов на эту тему и часы будут высвобождены на получние удовольствия от программирования.
Если Вы не понимаете, что здесь написано, не беда. Ведь это 30-ый шаг, когда пройдёте предыдущие 29, уже будете легко понимать.
Начать с ноля по шагам на этом портале = много времени высвободите на семью и получение удовольствие от программирования и быстрее будет конечный проект, который принесёт деньги.