django models необязательное поле
Django Book: изменение полей на необязательные
После того как вы немного поработаете с панелью управления вы, возможно, заметите некоторые ограничения, например — форма редактирования записи требует, что бы все поля были заполнены, хотя в некоторых случаях вы хотели бы оставить их пустыми. Например, вы хотите что бы поле email модели Authors было не обязательным для заполнения (опциональным).
После того как вы добавили blank=True — перезагрузите страницу «Add author» и вы увидите, что поле Email больше не выделено жирным шрифтом. Теперь вы можете добавить нового автора без указания адреса почты — сообщений «This field is required» больше не будет.
Изменение даты и числовых полей
Описанный пример с blank=True подойдёт и для полей даты и чисел, но тут требуется дополнительное пояснение и действие.
В SQL значение NULL отличается от пустой строки, так как же специальный объект None в Python отличается от пустой строки («»). Это значит, что некоторые символьные поля (такие как VARCHAR ) могут содержать значения и NULL и пустые строки.
Это может вызвать нежелательную двусмысленность и путаницу: «Почему эта запись имеет значение NULL, а другая — пустую строку?» и «Как мне получить все записи с пустыми значениями — должен ли я искать и NULL и пустые строки, или только пустые строки?»
Что бы избежать такой путаницы — сгенерированный Django запрос CREATE TABLE (который мы рассматривали в предыдущей главе) добавляет явное указание NOT NULL для описания каждой колонки. Например, вот запрос для нашей модели Author :
Как правило это оптимальное решение для ваших приложений, которое избавит вас от головной боли с несогласованностью данных в базе данных, и оно работает со всеми частями Django, такими как панель управления, которая вставляет пустые строки (а не значение NULL ), когда вы оставляете пустое поле при добавлении или редактировании записи.
Однако, имеются исключения, которые касаются полей типа даты, времени и чисел в вашей базе данных — они не принимают пустые строки в качестве корректных значений. Если вы попробуете добавить пустую строку в колонку с датой или цифрами — вы скорее всего получите ошибку базы данных, в зависимости от типа сервера баз данных (PostgreSQL вернёт ошибку, MySQL — может вернуть — а может и нет, в зависимости от используемой версии, времени для и фазы луны). В таком случае — NULL единственный вариант что бы задать пустое значение. В моделях Django вы можете указать, что использование NULL разрешено, добавив строку null=True к нужному полю.
Или для PostgreSQL:
Мы рассмотрим изменения схемы баз данных подробнее далее в нашей книге.
Возвращаясь к панели управления Django — теперь в форме редактирования «Add book» поле даты публикации можно оставлять пустым.
Django models необязательное поле
После того, как вы познакомились с интерфейсом администратора, вы наверное заметили ограничение — форма редактирования требует, что бы каждое поле было заполнено, тогда как вы хотели, чтобы некоторые поля были необязательными. Например, мы желаем, чтобы поле email модели Author было необязательным, то есть оно могло принимать пустую строку. В реальности, возможно, вам не потребуется хранить адреса электронной почты всех авторов.
Это указывает Django, что поле адреса электронной почты может быть пустым. По умолчанию, все поля имеют blank=False — это означает, что поля не могут быть пустыми.
Необязательные числовые поля и поля с датой
Особо надо отметить использование blank=True совместно с полями даты/времени и численными. Погрузимся в теорию.
Что бы избежать подобной путаницы, Django автоматически создает операторы CREATE TABLE (которые рассматривались в главе « Модели » ), добавляя явно NOT NULL к каждому полю. Например, сгенерированый запрос создания таблицы для модели Author :
В большинстве случаев, такое стандартное поведение является оптимальным для вашего приложения и избавит вас от проблем, вызванных несоответствием данных. И оно отлично работает с остальными компонентами Django: такими как административный интерфейс, который вставляет пустую строку (а не значение NULL ), если вы оставляете символьное поле пустым.
(Обратите внимание, что такой синтаксис специфичен для PostgreSQL.)
Завершив изменения, вернёмся к интерфейсу администратора. Теперь форма редактирования книги позволяет оставлять пустой дату публикации.
1 комментарий | Оставьте комментарий
В MySQL код для изменения значения свойства поля с NOT NULL на NULL выглядит так:
ALTER TABLE books_book MODIFY books_book.publication_date date NULL;
Содержимое
Добавь себя на карту!
Нашли опечатку?
Документация Django 1.8
Модели отображают информацию о данных, с которыми вы работаете. Они содержат поля и поведение ваших данных. Обычно одна модель представляет одну таблицу в базе данных.
Атрибут модели представляет поле в базе данных.
Django предоставляет автоматически созданное API для доступа к данным; смотрите Выполнение запросов.
Примеры¶
Вот пример модели, которая определяет гипотетического человека( Person ), с именем( first_name ) и фамилией( last_name ):
first_name и last_name поля модели. Каждое поле определено как атрибут класса, и каждый атрибут соответствует полю таблицы в базе данных.
Модель Person создаст в базе данных таблицу:
Поле id добавлено автоматически, но его также можно переопределить. Подробнее Первичный ключ по умолчанию.
CREATE TABLE SQL в этом примере соответствует синтаксису PostgreSQL, но стоит учесть что Django использует синтаксис SQL соответственно настройкам базы данных в файле настроек.
Использование моделей¶
Типы полей¶
Минимальные правила проверки данных, используемые в интерфейсе администратора и для автоматического создания формы.
В Django есть большое количество полей; полный список можно посмотреть на странице списка полей. Вы можете легко добавить собственное поле; смотрите Создание собственных полей для модели.
Настройка полей¶
Также есть список стандартных аргументов для всех полей. Все они не обязательны. Все они описаны в разделе про аргументы полей модели, вот список самых используемых:
Итератор (например, список или кортеж) 2-х элементных кортежей, определяющих варианты значений для поля. При определении, виджет формы использует select вместо стандартного текстового поля и ограничит значение поля указанными значениями.
Список значений выглядит:
Подсказка, отображаемая в поле формы. Это полезно для описания поля, даже если поле не используется в формах.
При True поле будет первичным ключом.
Поле первичного ключа доступно только для чтения. Если вы поменяете значение первичного ключа для существующего объекта, а зачем сохраните его, будет создан новый объект рядом с существующим. Например:
При True поле будет уникальным.
Это краткое описание самых используемых аргументов. Полный список можно найти на странице описания аргументов поля модели.
Первичный ключ по умолчанию¶
По умолчанию Django для каждой модели добавляет такое поле:
Это автоинкрементный первичный ключ.
Читабельное имя поля¶
Связи¶
Связь многое-к-одному¶
Пример работы с обратно-связанными объектами смотрите в в соответствующем разделе.
Связь много-ко-многому¶
Например, если пицца( Pizza ) содержит много добавок( Topping ) – то есть добавки( Topping ) могут быть в различных сортах пиццы( Pizza ) – вот как вы можете представить это:
Примеры использования связи многие-ко-многим можно найти в соответствующем разделе
Дополнительные поля для связи многие-ко-многим¶
В промежуточной модели необходимо добавить внешние ключи на модели, связанные отношением многие-ко-многим. Эти ключи указывают как связаны модели.
Есть несколько ограничений для промежуточной модели:
В Django 1.6 и ниже был запрещено использовать промежуточную модель, которая имела несколько связей со связываемой моделью.
Добавив несколько связей, создав промежуточную модель, вы захотите выполнить несколько запросов для получения данных. Так же, как и для обычной связи, вы можете получить связанные объекты, используя атрибуты связанных моделей:
Вы можете использовать поле промежуточной модели в запросах:
Вы можете получить данные непосредственно из модели Membership :
Связь один-к-одному¶
Чаще всего связь одни-к-одному используется для первичного ключа для модели, которая “расширяет” другую модель.
Связь моделей из разных модулей¶
Нормальная практика использовать связи для моделей из разных приложений. Для этого, импортируйте связанную модель перед определением главной модели и используйте как аргумент для поля. Например:
Ограничения при выборе названия поля¶
В Django существует только два ограничения:
Название поля не может быть слово зарезервированное Python, т.к. это приведет к синтаксической ошибке. Например:
Название поля не может содержать несколько нижних подчеркиваний(_) подряд, т.к. такой подход Django использует для формирования запросов. Например:
Собственные типы полей¶
Мета-настройки¶
Полный список опций для Meta можно найти в разделе о настройках модели.
Атрибуты модели¶
Методы модели¶
Это хороший подход для хранения бизнес логики работы с данными в одном месте – модели.
Например, эта модель содержит два дополнительных метода:
Раздел о моделях содержит полный список методов, автоматически добавляемых в модель. Вы можете переопределить большинство из них – смотрите Переопределение методов модели, – но есть методы, которые вы чаще всего определите для каждой модели:
“Волшебный метод” Python, который возвращает unicode “представление” объекта. Это то, что Python и Django используют для отображения объекта как строки, обычно в консоли, интерфейсе администратора или шаблоне.
Желательно определить этот метод, т.к. значение по умолчанию не слишком привлекательно.
Этот метод указывает Django, какой URL использовать для объекта. Django использует его в интерфейсе администратора и каждый раз, когда необходимо получить URL для объекта.
Каждый объект, который имеет уникальный URL должен иметь этот метод.
Переопределение методов модели¶
Вы можете переопределить эти методы и любые другие методы модели.
Распространенная задача, это выполнить какое-либо действие после сохранения объекта. Например (принимаемые параметры смотрите save() ):
Вы также можете отменить сохранение:
Не забывайте вызывать родительский метод – super(Blog, self).save(*args, **kwargs) – чтобы объект корректно сохранился в базе данных. Если этого не сделать, данные не будут сохранены в базе данных.
Переопределенные методы модели не вызываются при множественных операциях(bulk)
Выполнение SQL запросов¶
Запросы на чистом SQL лучше выполнять в методе модели. Подробнее о SQL-запросах можно прочитать в разделе о запросах на чистом SQL.
Наследование моделей¶
Единственное, что вам нужно определить, это должна ли родительская модель быть независимой моделью (с собственной таблицей в базе данных), или же родительская модель просто контейнер для хранения информации, доступной только через дочерние модели.
Существует три вида наследования моделей в Django.
Чаще всего вы будете использовать родительскую модель для хранения общих полей, чтобы не добавлять их в каждую дочернюю модель. Если вы не собираетесь использовать его как независимую модель – Абстрактные модели то, что вам нужно.
Если родительская модель независимая(возможно, из другого приложения) и должна храниться в отдельной таблице, Multi-table наследование то, что вам нужно.
Если же вы хотите переопределить поведение модели на уровне Python, не меняя структуры базы данных, вы можете использовать Proxy-модели.
Абстрактные модели¶
В большинстве случаев вы будете использовать этот тип наследования моделей. Он позволяет на уровне Python разделить общие данные, используя в то же время одну таблицу в базе данных.
Наследование класса Meta ¶
После создания абстрактной модели, Django добавляет класс Meta как атрибут класса. Если дочерний класс не определяет собственный класс Meta, он унаследует родительский класс Meta. Если дочерняя модель хочет расширить родительский Meta класс, она может унаследовать его. Например:
Некоторые атрибуты не имеет смысла добавлять в класс Meta абстрактной модели. Например, добавление db_table означает, что каждая дочерняя модель(каждая, которая не определяет свой собственный класс Meta) будет использовать туже таблицу в базе данных, что точно не то, что вам нужно.
Осторожно с related_name ¶
‘%(class)s’ будет заменен на название дочерней модели, в которой поле используется, в нижнем регистре.
‘%(app_label)s’ будет заменено на название приложения, в котором находится модель, в нижнем регистре. Название приложения должно быть уникальным, так же, как и название модели в приложении, в результате получится уникальное значение атрибута.
Например, есть приложение с common/models.py :
И еще другое rare/models.py :
Multi-table наследование¶
Meta и multi-table наследование¶
При multi-table наследовании, не имеет смысла дочерней модели наследовать Meta от родительской. Все атрибуты класса Meta уже используются в родительской модели и использование их снова может привести к противоречивому поведению (это отличие от абстрактной модели, которая сама по себе не существует как независимая модель).
Если родительская модель определяет сортировку, но вы не хотите ее наследовать в дочерней модели, вы можете указать это таким способом:
Наследование и обратные связи¶
Например, используя Place определенную выше, создадим еще одну дочернюю модель с ManyToManyField :
Это приведет к ошибке:
Добавление related_name для поля customers – models.ManyToManyField(Place, related_name=’provider’) – решит эту проблему.
Определение связи к родительской модели¶
Proxy-модели¶
При использовании multi-table наследования, будет создана новая таблица в базе данных. Это обязательное требование, т.к. дочерней модели необходимо хранить дополнительные поля. Иногда вам необходимо изменить поведение модели на уровне Python – переопределить менеджер по умолчанию или добавить новые методы.
Вот для чего используют proxy-модель: создать proxy для оригинальной модели. Вы можете создать, изменить или обновить объект proxy модели и все изменения будут сохранены так же, как и при изменении оригинальной(non-proxied) модели. Разница в том, что вы можете изменить сортировку по-умолчанию или менеджер по умолчанию в proxy-модели, без изменения оригинальной модели.
Вы также можете использовать proxy модель для определения различной сортировки по умолчанию. Модель Person не имеет сортировки по умолчанию (намеренно; сортировка трудоемкая операция, и мы не хотим ее использовать при каждом доступе к данным о пользователях). Возможно вы хотите сортировать по полю last_name при использовании proxy-модели. Это просто:
QuerySets возвращает объекты запрашиваемого типа¶
Ограничения базового класса¶
Proxy-модель должна наследоваться от одной не абстрактной модели. Вы не можете унаследоваться от нескольких не абстрактных моделей т.к. proxy-модель не может хранить информации о полях в нескольких таблицах базы данных. Proxy-модель может наследоваться от нескольких абстрактных моделей при условии, что они не определяют поля модели.
Proxy-модель наследует атрибуты класса Meta родительской не абстрактной модели, которые она не переопределяет.
Менеджер proxy-модели¶
Если вы не определите ни один менеджер для proxy-модели, он будет унаследован от родительской модели. Если вы определите менеджер, он будет использован как менеджер по умолчанию, в то же время доступны менеджеры, определенные в родительской модели.
Если вы хотите добавить новый менеджер, без замены существующего менеджера, вы можете использовать методы, описанные в разделе о собственных менеджерах: создайте базовый класс с новым менеджером и добавьте его в наследование после базового класса:
Скорее всего вам это не понадобится, но если все таки понадобится, знайте, что это возможно.
Разница между proxy наследованием и неуправляемой(unmanaged) моделью¶
Когда эти две функции были реализованы, была попытка объединить их в одно решение. Оказалось, что работа с наследованием в общем и менеджеры в частности делает API очень сложным и потенциально тяжелым для понимания. Так возникло решение использовать два механизма.
Множественное наследование¶
Так же, как и наследование в Python, можно использовать множественное наследование моделей Django. Имейте в виду, что используются правила именования Python. Например, есть несколько родительских объектов с классом Meta, в таком случае будет использован атрибут первой родительской модели, остальные будут проигнорированы.
В большинстве случаев вам не нужно будет использовать множественное наследование. В основном множественное наследование используют для “mix-in” классов: добавление дополнительных полей и методов для каждой модели унаследованной от mix-in класса. Старайтесь содержать иерархию наследования настолько простой и понятной, насколько это возможно, чтобы не возникало проблем с определением, откуда взялась та или другая информация.
Следующий код показывает, как создание дочернего объекта может перезаписать данные в родительском:
Документация Django 1.8
Этот раздел содержит все существующие подробности о всех параметрах поля и типах полей в Django.
Если существующие поля не предоставляют необходимого функционала, вы можете поискать в django-localflavor, который содержит дополнительный функционал полезный для различных стран. Также вы можете легко создать собственное поле для модели.
Параметры поля¶
Приведенные аргументы доступны для всех полей. Все они не обязательны.
При использовании Oracle, NULL будет использоваться для пустой строки независимо от значения этого параметра.
blank ¶
choices ¶
Первый элемент каждого кортежа – это значение, которое будет сохранено в базе данных. Второй элемент – название, которое будет отображаться для пользователей. Например:
Значения лучше указать в константах внутри модели:
Можно указать список значений и не в модели, но так все данные будут связаны с моделью, и к значениям можно легко обратиться (например, Student.SOPHOMORE можно использовать импортировав модель Student ).
Вы можете сгруппировать значения в именованные группы:
Первый элемент каждого кортежа – это название группы. Второй элемент – итератор с двух-элементными кортежами содержащими значение и отображаемое название. Сгруппированные опции могут комбинироваться с не сгруппированными (как unknown в примере выше).
db_column ¶
Имя колонки в базе данных для хранения данных этого поля. Если этот параметр не указан, Django будет использовать название поля.
Если имя колонки это зарезервированное SQL слово, или содержит символы запрещенные в названиях переменной в Python – в частности, дефис – все нормально. Django автоматически экранирует название колонок и таблиц.
db_index ¶
db_tablespace ¶
default ¶
Значение по умолчанию для поля. Это может быть значение или вызываемый(callable) объект. Если это вызываемый объект, он будет вызван при создании нового объекта.
Значение по умолчанию не может быть изменяемым значением (экземпляр модели, список, множество и т.д.), т.к. все объекты модели будут ссылаться на этот объект и использовать его как значение по умолчанию. Вместо этого укажите функцию, которая возвращает нужное значение. Например, если у вас есть собственное поле JSONField и вы хотите указать словарь как значение по умолчанию, используйте следующую функцию:
Обратите внимание, lambda нельзя использовать в качестве значения для default т.к. она не может быть сериализована для миграций. Подробности смотрите в соответствующем разделе.
editable ¶
error_messages ¶
error_messages позволяет переопределить сообщения ошибок возвращаемых полем. Используйте словарь с ключами соответствующими необходимым ошибкам.
help_text ¶
Подсказка, отображаемая под полем в интерфейсе администратора. Это полезно для описания поля, даже если модель не используется в форме.
primary_key ¶
При True это поле будет первичным ключом.
Первичный ключ доступен только для чтения. Если вы поменяете значение для существующего объекта и сохраните его, будет создан новый объект.
unique ¶
При True значение поля должно быть уникальным.
unique_for_date ¶
unique_for_month ¶
unique_for_year ¶
verbose_name ¶
Отображаемое имя поля. Если параметр не указан, Django самостоятельно создаст его используя имя атрибута поля, заменяя подчеркивание на пробелы. Смотрите раздел про отображаемые имена полей.
validators ¶
Список проверок(“валидаторов”) выполняемых для этого поля. Смотрите раздел о “валидаторах” для подробной информации.
Регистрация и загрузка операторов для фильтрации¶
Field предоставляет API для регистрации своих операторов фильтрации. Этот API позволяет добавить свои варианты фильтрации по полю.
Типы полей¶
AutoField ¶
BigIntegerField ¶
BinaryField ¶
BooleanField ¶
Поле хранящее значение true/false.
CharField ¶
Строковое поле для хранения коротких или длинных строк.
Максимальная длинна(в символах) этого поля. max_length используется для проверки данных на уровне базы данных и форм Django.
Если вы создаете независимое приложение, которое должно работать на различных базах данных, помните что существуют некоторые ограничения использования max_length для некоторых типов баз данных. Смотрите раздел про использование различных типов баз данных.
Если вы используете это поле с MySQLdb 1.2.2 и utf8_bin “collation” (которое не является значением по умолчанию), могут быть некоторые проблемы. Смотрите советы при работе с MySQL для подробностей.
CommaSeparatedIntegerField ¶
DateField ¶
Дата, представленная в виде объекта datetime.date Python. Принимает несколько дополнительных параметров:
Значение поля будет автоматически установлено в текущую дату при каждом сохранении объекта. Полезно для хранения времени последнего изменения. Заметим, что текущее время будет использовано всегда; это не просто значение по умолчанию, которое вы можете переопределить.
Значение поля будет автоматически установлено в текущую дату при создании(первом сохранении) объекта. Полезно для хранения времени создания. Заметим, что текущее время будет использовано всегда; это не просто значение по-умолчанию, которое вы можете переопределить.
В форме поле будет представлено как :class:`
DateTimeField ¶
DecimalField ¶
Количество знаков после запятой.
Например, для хранения числа до 999 с двумя знаками после запятой, используйте:
Для хранения числа до миллиарда и 10 знаков после запятой:
DurationField ¶
Арифметика над DurationField работает в большинстве случаев. Однако, для всех баз данных, кроме PostgreSQL, арифметическое сравнение DurationField и DateTimeField работает не как ожидается.
EmailField ¶
Значение max_length по умолчанию было увеличено с 75 до 254 для совместимости с RFC3696/5321.
FileField ¶
Поле для загрузки файла.
primary_key и unique не принимаются, и вызовут исключение TypeError при использовании.
Также принимается два дополнительных параметра:
upload_to был обязателен в предыдущих версиях Django.
Также принимается вызываемый объект, такой как функция, который будет вызван для получения пути к загруженному файлу, включая имя файла. Вызываемый объект должен принимать два обязательных аргумента, и возвращать путь в стиле Unix (с прямыми слэшами), который будет передан в систему хранения файлов(storage). Два аргумента это:
Оригинальное имя файла. Вы можете его учитывать, или проигнорировать при определении окончательного пути к файлу.
Объект “storage”, который отвечает за хранение и получение файлов. Смотрите Управление файлами для подробной информации.
Процесс сохранения файла – часть процесса сохранения объекта, таким образом имя файла, сохраненного на диске, не будет доступно, пока объект не будет сохранен.
Заметим, что при загрузке файлов, вы должны обращать внимание, куда вы загружаете файлы и какие типы файлов загружаются, чтобы предотвратить возможные уязвимости в защите системы. Проверяйте все загружаемые файлы. Например, если вы разрешите загрузить файл без проверки в каталог, который обрабатывается сервером, кто-нибудь сможет загрузить CGI или PHP скрипт и выполнить его, посетив его URL на вашем сайте. Не допускайте это.
Также заметим что это относится и к HTML файлам, так как они могу быть выполнены в браузере(хоть и не на сервере), и нести угрозу XSS или CSRF атаки.
FileField и FieldFile¶
Работает так же как и метод file.close() в Python и закрывает файл связанный с объектом.
Или же создать из строки с содержимым файла:
Обратите внимание, когда объект модели удаляется, связанные файлы не удаляются. Если вам необходимо удалять их, делайте это самостоятельно (например, используя команду, запущенную через cron).
FilePathField ¶
Конечно же можно использовать все аргумента вместе.
FloatField ¶
FloatField или DecimalField
ImageField ¶
Имя поля, которому автоматически будет присвоено значение высоты изображения при каждом сохранении объекта.
Имя поля, которому автоматически будет присвоено значение ширины изображения при каждом сохранении объекта.
IntegerField ¶
IPAddressField ¶
GenericIPAddressField ¶
NullBooleanField ¶
PositiveIntegerField ¶
PositiveSmallIntegerField ¶
SlugField ¶
Slug – газетный термин. “Slug” – это короткое название-метка, которое содержит только буквы, числа, подчеркивание или дефис. В основном используются в URL.
SmallIntegerField ¶
TextField ¶
Если вы используете это поле с MySQLdb 1.2.1p2 и utf8_bin “collation” (которое не является значением по умолчанию), могут быть некоторые проблемы. Смотрите советы при работе с MySQL для подробностей.
TimeField ¶
URLField ¶
UUIDField ¶
Поля отношений¶
Django предоставляет набор полей для определения связей между моделями.
ForeignKey ¶
Связь многое-к-одному. Принимает позиционный аргумент: класс связанной модели.
Если вам необходимо добавить связь на модель, которая еще не определена, вы можете использовать имя модели вместо класса:
Такой способ позволяет создать циклическую зависимость между моделями из разных приложений.
Не рекомендуется использовать ForeignKey из приложения без миграций к приложению с миграциями. Смотрите раздел о зависимостях миграций.
Представление в базе данных¶
Параметры¶
Указание функции может быть полезно, если используется объект Python datetime для фильтрации. Например:
Название, используемое для обратной связи от связанной модели. Также значение по умолчанию для related_query_name (название обратной связи используемое при фильтрации результата запроса). Ищите подробности и примеры в разделе о связанных объектах. Заметим, что вы должны определить этот параметр для поля в абстрактной модели; при этом можно использовать некоторые дополнительные возможности.
Поле связанной модели, которое используется для создания связи между таблицами. По-умолчанию, Django использует первичный ключ.
Указывает создавать ли “constraint” для внешнего ключа в базе данных. По умолчанию True и в большинстве случает это то, что вам нужно. Указав False вы рискуете целостностью данных. Некоторые ситуации, когда вам может быть это необходимо:
Вам досталась в наследство нецелостная база данных
Вы используете шардинг базы данных.
Каскадное удаление, значение по умолчанию.
Препятствует удалению связанного объекта вызывая исключение django.db.models.ProtectedError`(подкласс :exc:`django.db.IntegrityError ).
Этот параметр добавлен для обратной совместимости т.к. в предыдущих версиях Django можно было назначать не сохраненные объекты.
Django не позволяет назначать полю ForeignKey не сохраненные объекты, чтобы избежать потерю данных (такие объекты просто игнорируются при сохранении объекта модели).
ManyToManyField ¶
Не рекомендуется использовать ManyToManyField из приложения без миграций к приложению с миграциями. Смотрите раздел о зависимостях в миграциях.
Представление в базе данных¶
Параметры¶
Используется только при рекурсивной связи. Например, есть модель:
Если вы не указали through модель, вы все равно может обратиться к неявно промежуточной модели, которая была автоматически создана. Она содержит три поля, связывающие модели.
Если связанные модели разные, создаются следующие поля:
id : первичный ключ для связи.
Если ManyToManyField ссылается на одну и ту же модель, будут созданы поля:
id : первичный ключ для связи.
from_ _id : id объекта основной модели (исходный объект).
to_ _id : id объекта, на который указывает связь (целевой объект).
Этот класс может использоваться для получения связей.
Используется, если явно указана промежуточная модель для связи многое-ко-многим. Обычно Django самостоятельно определяется какие поля использовать для создания связи. Однако, возьмем такой пример:
Имя промежуточной таблицы для хранения связей многое-ко-многим. Если не указан, Django самостоятельно создаст название по умолчанию используя название таблицы определяющей связь и название поля.
Указывает создавать ли “constraint” для внешних ключей в промежуточной таблице в базе данных. По умолчанию True и в большинстве случает это то, что вам нужно. Указав False вы рискуете целостностью данных. Некоторые ситуации, когда вам может быть это необходимо:
Вам досталась в наследство нецелостная база данных
Вы используете шардинг базы данных.
Нельзя указать db_constraint и through одновременно.
OneToOneField ¶
В основном применяется как первичный ключ модели, которая “расширяет” другую модель. Например, Multi-table наследование работает через неявное добавление связи один-к-одному от дочерней модели к родительской.
модель User будет содержать следующие атрибуты:
При True и связанной модели, которая наследуется от другой модели, определяет, что должна сохраняться связь на родительскую модель, а не поле OneToOneField дочерней модели, которое используется для организации наследования моделей.
Смотрите примеров использования OneToOneField в Связь один к одному.
Справочник по полям модели¶
Field – абстрактный класс, отображающий колонку в таблице в базе данных. Django используется поля для создания таблицы в базе данных ( db_type() ), для преобразования типов Python в типа в базе данных ( get_prep_value() ) и наоборот ( from_db_value() ), и для применения Lookup API reference ( get_prep_lookup() ).
Может использовать форматирование:
Аргументы будут подставляется из значений __dict__ поля.
Для преобразования типа Field в тип базы данных Django используется два метода:
Возвращает текстовое название типа поля для использования в бэкендах баз данных. По умолчанию возвращает название класса.
Смотрите Эмуляция встроенных полей, как использовать в собственных полях модели.
Смотрите Типы полей базы данных, как использовать в собственных полях модели.
Существует три основных ситуации, когда Django используется преобразование типа поля:
При запросе используются методы get_db_prep_value() и get_prep_value() :
value – значение атрибута поля модели. Метод должен вернуть значение, которое можно использовать как параметр в запросе.
get_db_prep_value(value, connection, prepared=False)¶
При загрузке данных используется from_db_value() :
Для большинства встроенных полей этот метод не используется т.к. бэкенд базы данных возвращает уже правильный объект Python, или же бэкенд сам выполняет необходимые преобразования.
При сохранении используются методы pre_save() и get_db_prep_save() :
model_instance – объект модели, к которому принадлежит поле, add – указывает сохраняется ли объект первый раз в базу данных.
При использовании фильтрации по полю, может быть необходимо “приготовить” значение. Django используется для этого два метода:
get_db_prep_lookup(lookup_type, value, connection, prepared=False)¶
Поля часто принимает значения разных типов из сериализатора, или формы
Кроме сохранения в базу данных, поле также должно знать как сериализовать свое значение:
Преобразует obj в строку. Используется при сериализации значения поля.
formfield(form_class=None, choices_form_class=None, **kwargs)¶
Возвращает 4-х элементный кортеж с информацией, как воссоздать поле:
Название поля в модели.
Путь для импорта класса поля (например, «django.db.models.IntegerField» ). Должен возвращаться максимально переносимый между платформами и версиями вариант.
Список позиционных аргументов.
Словарь именованных аргументов.
Этот метод должен быть добавлен полям, созданным до 1.7, для использования Миграции.
Атрибуты поля¶
Атрибуты поля¶
Флаг, который указывает было ли поле создано автоматически, например OneToOneField при наследовании моделей.
Флаг, который указывает представлено ли поле колонкой в таблице в базе данных.
Флаг, который указывает, что поле скрыто и используется для работы другого не скрытого поля (например, поля content_type и object_id используются для работы GenericForeignKey ). Флаг hidden используется, чтобы выделить публичные поля модели из всех полей.
Содержит модель, в которой это поле определено. Если поле определено в родительском классе, model будет ссылаться на этот класс, а не класс экземпляра модели.
Атрибуты связывающих полей¶
Атрибуты, определяющие связь поля. Эти атрибуты присутствуют во всех полях, однако, только для связывающих полей( Field.is_relation=True ) они содержат полезные значения.