Def str self django что это
Документация Django 1.8
Этот раздел описывает Model API. Изложенный материал опирается на материал, изложенный в разделах о моделях и выполнении запросов, возможно вам следует прочитать их перед прочтением этого раздела.
В примерах будут использованы :ref:` примеры моделей web-блога ` представленные в разделе о выполнении запросов.
Создание объектов¶
Чтобы создать объект модели, просто создайте ее экземпляр как любого другого класса Python:
Добавить метод класса в модель:
Добавить метод в менеджер модели(лучший вариант):
Настройка загрузки модели¶
Метод from_db() позволяет настроить создания экземпляра модели при загрузке данных из базы данных.
Кроме создания экземпляра модели метод from_db() должен установить флаги adding и db атрибута _state нового объекта модели.
В этом примере вы можете увидеть как сохранить начальные загруженные значений полей и проверять их при сохранении:
Обновление объектов из базы данных¶
Все загруженные поля модели будут обновлены значениями из базы данных.
Обратите внимание, загружаются только поля модели. Аннотации и прочие специфические значения не будут загружены.
Перезагрузка выполняется из базы данных, из которой объект был изначально загружен, или из базы данных по умолчанию, если база данных не была явно указана. Аргумент using позволяет явно указать базу данных.
Обратите внимание, при доступе к отложенным(deferred) полям они загружаются этим методом. Таким образом вы можете переопределить способ загрузки отложенных полей. В этом примере мы перегружаем все поля, если загружаются отложенные поля:
Возвращает список текущих отложенных полей для экземпляра модели.
Проверка объектов¶
Проверка объектов модели проходив в три этапа:
Model. full_clean(exclude=None, validate_unique=True)¶
Первым делом full_clean() выполняет проверку каждого поля.
Этот метод должен быть переопределен, если вам нужна дополнительная проверка модели или изменить значения атрибутов. Для объектов, вы можете определить его для автоматического определения полей, или для проверки, которая требует значения нескольких полей:
Также full_clean() выполняет все проверки на уникальность модели.
Сохранение объектов¶
Чтобы сохранить объект в базе данных, используйте save() :
Model. save( [ force_insert=False, force_update=False, using=DEFAULT_DB_ALIAS, update_fields=None ] )¶
Процесс сохранения модели имеет ряд особенностей описанных ниже.
Автоинкрементные первичные ключи¶
Свойство pk ¶
Явное определение значения первичного ключа¶
Если вы определяете значение первичного автоинкрементного ключа, убедитесь что это значение не существует уже в базе данных! Если вы укажите существующее в базе значение, Django предположит что вы хотите изменить запись в базе данных, а не сохранить новую.
Учитывая пример с блогом ‘Cheddar Talk’ выше, этот код перезапишет предыдущий объект в базе данных:
О том, как это определяется, смотрите How Django knows to UPDATE vs. INSERT (FIXME) ниже.
Явное определение первичного ключа в основном полезно при сохранении множества объектов, когда вы уверенны что все значения уникальны.
Что происходит при сохранении?¶
При сохранении объекта Django выполняет следующие шаги:
Предварительная обработка данных. Каждое поле объекта выполняет изменения значения поля при необходимости.
Подготовка данных для базы данных. Каждое поле преобразует текущее значение к типу данных, которой может быть сохранен в базу данных.
Большинство полей не требует подготовки данных. Простые типы данных, такие как числа и строки, уже ‘готовы к сохранению’ как объекты Python. Однако, большинство сложных типов данных требуют некоторой модификации.
Сохранение данных в базе данных. Предварительно обработанные, подготовленные данные формируются в SQL запрос, который выполняется в базе данных.
Как Django определят использовать UPDATE или INSERT¶
Если атрибут первичного ключа объекта содержи значение равное True (например, не None или не пустая строка), Django выполняет UPDATE запрос.
Будьте осторожны, явно указывая значение первичного ключа при сохранении нового объекта, если вы не уверенны, что этот первичный ключ не используется. Более подробно об этом читайте Explicitly specifying auto-primary-key values (FIXME) и Принудительное выполнение INSERT или UPDATE.
Принудительное выполнение INSERT или UPDATE¶
Вряд ли вам понадобится использовать эти параметры. Django почти всегда сделает то, что вам нужно, и переопределение такого поведения может привести к ошибкам, которые трудно отследить. Эта функция предназначена для опытных пользователей.
Обновление значений полей¶
Иногда вам может понадобиться выполнить простые арифметические операции над полями, такие как увеличить или уменьшить текущее значение. Очевидный способ сделать это:
Указываем какие поля сохранять¶
Если в save() передать именованный аргумент update_fields со списком полей модели, только эти поля будут обновлены. Это может пригодиться, если вы хотите обновить одно или несколько полей. Таким образом можно получить небольшой прирост в производительности. Например:
update_fields может принимать любой итератор строк. Пустой update_fields пропустит сохранение. None сохранит все поля.
Указав update_fields вы инициируете редактирование записи.
Удаление объектов¶
Выполняет SQL DELETE запрос для объекта. Удаляет объекты только из базы данных; объекты Python будут существовать и содержать данные.
Подробности, включая как удалить множество объектов, смотрите в Удаление объектов.
Сериализация объектов¶
Вы не можете использовать объекты, упакованные на разных версиях Django
Упакованные модели работают только для той версии Django, на которой они были созданы. Если вы упаковали модель на Django версии N, нет гарантии, что вы сомжете распаковать её на Django версии N+1. Упаковка моделей не должна использоваться для долговременного архивирования объектов.
Ошибки несовместимости версий при распаковке объектом тяжело диагностировать, например сломанный объект, поэтому вызывается RuntimeWarning при попытке распаковать модель на версии Django отличной от той, которая использовалась при упаковке.
Остальные методы модели¶
Несколько методов имеют специальное назначение.
__unicode__ ¶
Метод __unicode__() вызывается когда вы применяете функцию unicode() к объекту. Django использует unicode(obj) (или похожую функцию str(obj) ) вы нескольких местах. В частности, для отображения объектов в интерфейсе администратора Django и в качестве значения, вставляемого в шаблон, при отображении объекта. Поэтому, вы должны всегда возвращать в методе __unicode__() красивое и удобное для восприятия представление объекта.
__str__ ¶
Метод __str__() вызывается когда вы применяете функцию str() к объекту. В Python 3 Django использует str(obj) в нескольких местах. В частности, для отображения объектов в интерфейсе администратора Django и в качестве значения, вставляемого в шаблон, при отображении объекта. Поэтому, вы должны всегда возвращать в методе __str__() красивое и удобное для восприятия представление объекта.
__eq__ ¶
В предыдущих версиях только экземпляры одно класса с одинаковым первичным ключом считались равными.
__hash__ ¶
В предыдущих версиях объекты без первичного ключа можно было хешировать.
get_absolute_url ¶
При создания URL не используйте непроверенные данные от пользователя, чтобы избежать подделки ссылок или перенаправлений:
Хорошая практика использовать get_absolute_url() в шаблонах, вместо того, чтобы “хардкодить” URL-ы. Например, это плохой подход:
Этот шаблон значительно лучше:
Дополнительные методы модели¶
Оба метода используют менеджер по умолчанию модели. Если вам необходимо использовать свой менеджер, которые должен выполнить какую-то фильтрацию, или просто добавить дополнительную фильтрацию, в методы можно передать дополнительные аргументы, которые должны соответствовать формату операторов фильтрации.
Заметим, что в случае одинаковых значений даты, эти методы будут использовать значение первичного ключа, для определения порядка объектов. Это гарантирует, что записи не будут пропущены или дублированы. Это также означает, что вы не можете использовать эти методы для не сохраненных объектов.
Справочник по методам модели¶
Создание объектов¶
Чтобы создать новый экземпляр модели, создайте его экземпляр, как и любой другой класс Python:
Добавьте метод в класс модели:
Добавить метод в пользовательский менеджер (обычно предпочтительнее):
Настройка загрузки модели¶
Метод from_db() можно использовать для настройки создания экземпляра модели при загрузке из базы данных.
Помимо создания новой модели, метод from_db() должен установить флаги adding и db в атрибуте _state нового экземпляра.
Ниже приведен пример, показывающий, как записать начальные значения полей, загружаемых из базы данных:
Обновление объектов из базы данных¶
Если вы удаляете поле из экземпляра модели, при повторном доступе к нему значение из базы данных снова загружается:
Только поля модели загружаются из базы данных. Другие зависящие от базы данных значения, такие как аннотации, не перезагружаются. Любые атрибуты @cached_property также не очищаются.
Перезагрузка происходит из базы данных, из которой был загружен экземпляр, или из базы данных по умолчанию, если экземпляр не был загружен из базы данных. Аргумент using может использоваться для принудительной перезагрузки базы данных.
Например, чтобы проверить, что вызов update() привел к ожидаемому обновлению, вы можете написать тест, подобный следующему:
Обратите внимание, что при доступе к отложенным полям загрузка значения отложенного поля происходит с помощью этого метода. Таким образом, можно настроить способ отложенной загрузки. В приведенном ниже примере показано, как можно перезагрузить все поля экземпляра при перезагрузке отложенного поля:
Вспомогательный метод, который возвращает набор, содержащий имена атрибутов всех тех полей, которые в данный момент откладываются для этой модели.
Проверка объектов¶
Существует три этапа проверки модели:
Необязательный аргумент exclude может использоваться для предоставления списка имен полей, которые можно исключить из проверки и очистки. ModelForm использует этот аргумент, чтобы исключить проверку полей, которые отсутствуют в вашей форме, поскольку любые возникшие ошибки не могут быть исправлены пользователем.
Model. clean_fields ( exclude = None ) [исходный код] ¶
Этот метод должен использоваться для обеспечения пользовательской проверки модели и для изменения атрибутов вашей модели, если это необходимо. Например, вы можете использовать его для автоматического предоставления значения для поля или для проверки, которая требует доступа к более чем одному полю:
Чтобы назначить исключения конкретному полю, создайте экземпляр ValidationError со словарем, где ключами являются имена полей. Мы могли бы обновить предыдущий пример, чтобы присвоить ошибку полю pub_date :
Наконец, full_clean() проверит любые уникальные ограничения на вашей модели.
Как вызвать специфичные для поля ошибки проверки, если эти поля не отображаются в ModelForm
Сохранение объектов¶
Чтобы сохранить объект обратно в базу данных, вызовите save() :
Процесс сохранения модели также имеет некоторые тонкости; см. разделы ниже.
Автоинкрементные первичные ключи¶
Для удобства каждая модель имеет AutoField с именем id по умолчанию, если вы явно не укажете primary_key=True для поля в вашей модели. Смотрите документацию для AutoField для получения более подробной информации.
Свойство pk ¶
Явное указание значений авто-первичного ключа¶
Если вы назначаете значения авто-первичного ключа вручную, убедитесь, что вы не используете уже существующее значение первичного ключа! Если вы создаете новый объект с явным значением первичного ключа, который уже существует в базе данных, Django будет предполагать, что вы изменяете существующую запись, а не создаете новую.
Посмотрите, «Как Django определяет UPDATE или INSERT» ниже, по той причине, по которой это происходит.
Явное указание значений авто-первичного ключа в основном полезно для массового сохранения объектов, когда вы уверены, что у вас не будет коллизии первичного ключа.
Что происходит, когда вы сохраняете?¶
Когда вы сохраняете объект, Django выполняет следующие шаги:
Подготовка данных для базы данных. Метод каждого поля get_db_prep_save() должен предоставить свое текущее значение в виде данных, которые можно записать в базу данных.
Большинство полей не требуют подготовки данных. Простые типы данных, такие как целые числа и строки, «готовы к записи» в виде объекта Python. Однако более сложные типы данных часто требуют некоторой модификации.
Вставка данных в базу данных. Предварительно обработанные, подготовленные данные составляются в оператор SQL для вставки в базу данных.
Как Django узнает, когда использовать UPDATE или INSERT¶
Единственное, что здесь нужно сделать, это то, что вы должны быть осторожны, чтобы не указывать значение первичного ключа явно при сохранении новых объектов, если вы не можете гарантировать, что значение первичного ключа не используется. Подробнее об этом нюансе смотрите в разделе Explicitly specifying auto-primary-key values и Форсирование INSERT или UPDATE ниже.
INSERT или UPDATE¶
Это должно быть очень редко, что вам нужно будет использовать эти параметры. Django почти всегда делает правильные вещи, и попытка переопределить это приведет к ошибкам, которые трудно отследить. Эта функция предназначена только для расширенного использования.
Обновление атрибутов на основе существующих полей¶
Иногда вам нужно выполнить простую арифметическую задачу в поле, например, увеличить или уменьшить текущее значение. Одним из способов достижения этого является выполнение арифметики в Python, например:
Указание полей для сохранения¶
Аргумент update_fields может быть любым итеративным, содержащим строки. Пустая итерация update_fields пропустит сохранение. Значение None обновит все поля.
Указание update_fields приведет к обновлению.
Удаление объектов¶
Выдает SQL DELETE для объекта. Это только удаляет объект в базе данных; Экземпляр Python все еще будет существовать и все еще будет содержать данные в своих полях. Этот метод возвращает количество удаленных объектов и словарь с количеством удалений на тип объекта.
Иногда с помощью наследование от нескольких таблиц вы можете удалить только данные дочерней модели. Указание keep_parents=True сохранит данные родительской модели.
Упаковывание объектов¶
Когда вы pickle модель, ее текущее состояние сохраняется. Когда вы откроете его, он будет содержать экземпляр модели в тот момент, когда он был выбран, а не данные, которые в данный момент находятся в базе данных.
Вы не можете использовать pickle между версиями
Упакованные модели действительны только для той версии Django, которая использовалась для их генерации. Если вы генерируете pickle с использованием Django версии N, нет никакой гарантии, что pickle будет читаться с Django версии N+1. pickle не должны использоваться как часть долгосрочной архивной стратегии.
Так как ошибки совместимости с pickle могут быть трудно диагностируемыми, например, незаметно поврежденные объекты, возникает «RuntimeWarning», когда вы пытаетесь распаковать модель в версии Django, отличной от той, в которой она была упакована.
Другие методы экземпляра модели¶
Несколько методов объекта имеют специальные цели.
__str__() ¶
__eq__() ¶
Метод равенства определен так, что экземпляры с одинаковым значением первичного ключа и одним и тем же конкретным классом считаются равными, за исключением того, что экземпляры со значением первичного ключа None не равны ничему, кроме самих себя. Для прокси-моделей конкретный класс определяется как первый непрокси-родитель модели; для всех остальных моделей это просто класс модели.
__hash__() ¶
get_absolute_url() ¶
Хотя этот код является правильным и простым, он может быть не самым переносимым способом написания такого рода метода. Функция reverse() обычно является наилучшим подходом.
Вы должны избегать создания URL из неподтвержденного пользовательского ввода, чтобы уменьшить возможности ссылки или перенаправления:
Хорошей практикой является использование get_absolute_url() в шаблонах вместо жесткого кодирования URL-адресов ваших объектов. Например, этот код шаблона плох:
Этот шаблон кода намного лучше:
Логика здесь заключается в том, что если вы изменяете структуру URL-адресов ваших объектов, даже для чего-то простого, например, для исправления орфографической ошибки, вам не нужно отслеживать каждое место, где может быть создан URL-адрес. Укажите его один раз в get_absolute_url() и пусть весь ваш другой код вызывает только его.
Строка, которую вы возвращаете из get_absolute_url() должна содержать только символы ASCII (требуется спецификацией URI RFC 2396#section-2) и быть при необходимости закодированной в URL.
Дополнительные методы экземпляра¶
Обратите внимание, что в случае идентичных значений даты эти методы будут использовать первичный ключ в качестве прерывателя связей. Это гарантирует, что никакие записи не будут пропущены или дублированы. Это также означает, что вы не можете использовать эти методы на несохраненных объектах.
Переопределение дополнительных методов экземпляра
Другие атрибуты¶
_state ¶
Работа с запросами¶
В этом руководстве (и в справочнике) мы будем ссылаться на следующие модели, которые составляют приложение Weblog:
Создание объектов¶
Для представления данных таблицы базы данных в объектах Python Django использует интуитивно понятную систему: класс модели представляет таблицу базы данных, а экземпляр этого класса представляет конкретную запись в таблице базы данных.
Предполагая, что модели находятся в файле mysite/blog/models.py :
Метод save() не имеет возвращаемого значения.
save() использует несколько дополнительных параметров, которые здесь не описаны. Смотрите документацию save() для получения полной информации.
Сохранение изменений в объектах¶
Сохранение полей ForeignKey и ManyToManyField ¶
Джанго сообщит, если вы попытаетесь назначить или добавить объект неправильного типа.
Получение объектов¶
Чтобы получить объекты из вашей базы данных, создайте QuerySet через Manager в своем классе модели.
Managers доступны только через классы модели, а не из экземпляров модели, чтобы обеспечить разделение между операциями на уровне таблицы и операциями на уровне записи.
Получение всех объектов¶
Метод all() возвращает QuerySet всех объектов в базе данных.
Получение определенных объектов с помощью фильтров¶
Например, чтобы получить QuerySet записей блога за 2006 год, используйте filter() примерно так:
С классом менеджера по умолчанию, он такой же, как:
Цепочки фильтров¶
Отфильтрованные QuerySet являются уникальными¶
Получение одного объекта с помощью get() ¶
Если вы знаете, что только один объект соответствует вашему запросу, вы можете использовать метод get() из Manager который возвращает объект напрямую:
Другие методы QuerySet ¶
Ограничение QuerySet ¶
Например, этот код возвращает первые 5 объектов ( LIMIT 5 ):
Это возвращает объекты с шестого по десятый ( OFFSET 5 LIMIT 5 ):
Отрицательное индексирование (т.е. Entry.objects.all()[-1] ) не поддерживается.
Дальнейшая фильтрация или упорядочение нарезанного набора запросов запрещены из-за неоднозначного характера того, как это может работать.
Чтобы извлечь один объект, а не список (например, SELECT foo FROM bar LIMIT 1 ), используйте простой индекс вместо среза. Например, этот код возвращает первый Entry в базе данных, после упорядочивания записей в алфавитном порядке по заголовку:
Это примерно эквивалентно:
Поиск по полям¶
переводит (примерно) в следующий SQL:
Python имеет возможность определять функции, которые принимают произвольные аргументы имя-значение, имена и значения которых оцениваются во время выполнения. Для получения дополнительной информации см. Keyword Arguments в официальном руководстве по Python.
«Точное» совпадение. Например:
Будет генерировать SQL по этим строкам:
Например, следующие два оператора эквивалентны:
Это сделано для удобства, потому что точный поиск является распространенным случаем.
Соответствие без учета регистра. Итак, запрос:
Проверка содержимого в зависимости от регистра. Например:
Примерно переводится в такой SQL:
Поиск, который использует отношения¶
Django предлагает мощный и интуитивно понятный способ «отслеживать» отношения в поисках, автоматически заботясь о SQL JOIN для вас, за кулисами. Чтобы охватить отношение, просто используйте имя поля связанных полей в моделях, разделенных двойным подчеркиванием, пока не дойдете до нужного поля.
Этот охват может быть настолько глубоким, насколько вы захотите.
Если вы фильтруете по нескольким отношениям и одна из промежуточных моделей не имеет значения, которое удовлетворяет условию фильтра, Django будет обрабатывать его как пустой (все значения NULL ), но допустимый объект там. Все это означает, что никакой ошибки не возникнет. Например, в этом фильтре:
Охватывающие многозначные отношения¶
Это может показаться немного запутанным, поэтому, надеемся, пример прояснит. Чтобы выбрать все блоги, которые содержат записи с «Lennon» в заголовке и которые были опубликованы в 2008 году (та же запись, удовлетворяющая обоим условиям), мы должны написать:
Чтобы выбрать все блоги, которые содержат запись с «Lennon» в заголовке, а также запись, которая была опубликована в 2008 году, мы должны написать:
Предположим, что существует только один блог, в котором есть записи, содержащие «Lennon» и записи 2008 года, но ни одна из записей 2008 года не содержит «Lennon». Первый запрос не вернет ни одного блога, но второй запрос вернет этот блог.
Например, следующий запрос исключит блоги, содержащие обе записи с «Lennon» в заголовке и записи, опубликованные в 2008 году:
Фильтры могут ссылаться на поля модели¶
В приведенных выше примерах мы создали фильтры, которые сравнивают значение модельного поля с константой. Но что, если вы хотите сравнить значение поля модели с другим полем той же модели?
Например, чтобы найти список всех записей блога, у которых было больше комментариев, чем у пингбэков, мы создаем объект F() для ссылки на счетчик пингбэков и используем этот объект F() в запросе:
Чтобы найти все записи, в которых рейтинг записи меньше суммы пингбэков и комментариев, мы должны выполнить запрос:
Oracle не поддерживает побитовую операцию XOR.
Использование сокращения pk ¶
Поиск pk также работает через объединения. Например, эти три утверждения эквивалентны:
Экранирующие знаки процента и подчеркивания в выражениях LIKE ¶
Это означает, что все должно работать интуитивно, чтобы абстракция не просачивалась. Например, чтобы получить все записи, содержащие знак процента, просто используйте знак процента, как и любой другой символ:
Джанго заботится об экранировании для вас; результирующий SQL будет выглядеть примерно так:
То же самое касается подчеркивания. Оба знака процента и подчеркивания обрабатываются для вас прозрачно.
Кэширование и QuerySet ¶
Каждый класс QuerySet содержит кэш для минимизации доступа к базе данных. Понимание того, как это работает, позволит вам написать наиболее эффективный код.
Это означает, что один и тот же запрос к базе данных будет выполнен дважды, что фактически удваивает нагрузку на вашу базу данных. Кроме того, существует вероятность того, что два списка могут не включать в себя одни и те же записи базы данных, потому что «запись» может быть добавлена или удалена за доли секунды между двумя запросами.
Чтобы избежать этой проблемы, просто сохраните QuerySet и повторно используйте его:
Когда QuerySet не кэшируется¶
Queryset`ы не всегда кэшируют свои результаты. При оценке только части набора запросов проверяется кэш, но если он не заполняется, элементы, возвращаемые последующим запросом, не кэшируются. В частности, это означает, что ограничение набора запросов с использованием среза массива или индекса не заполнит кэш.
Например, многократное получение определенного индекса в объекте набора запросов будет каждый раз запрашивать базу данных:
Однако, если весь набор запросов уже был оценен, вместо этого будет проверяться кеш:
Вот несколько примеров других действий, которые приведут к оценке всего набора запросов и, следовательно, заполнению кеша:
Простой вывод набора запросов не заполнит кэш. Это связано с тем, что вызов __repr__() возвращает только часть всего набора запросов.
Запросы к JSONField ¶
Хранение и запрос для « None«¶
Преобразование ключа, индекса и пути¶
Для запроса на основе заданного ключа словаря используйте этот ключ в качестве имени поиска:
Несколько ключей могут быть объединены в цепочку для формирования пути поиска:
Если ключ является целым числом, он будет интерпретирован как преобразование индекса в массиве:
Чтобы запросить отсутствующие ключи, используйте поиск isnull :
Поскольку любая строка может быть ключом в объекте JSON, любой поиск, кроме перечисленных ниже, будет интерпретироваться как поиск ключа. Ошибок не возникает. Будьте особенно осторожны с опечатками и всегда проверяйте, работают ли ваши запросы так, как вы хотите.
Пользователи MariaDB и Oracle
Использование order_by() для преобразований ключа, индекса или пути отсортирует объекты с использованием строкового представления значений. Это связано с тем, что MariaDB и Oracle Database не предоставляют функцию, которая преобразует значения JSON в их эквивалентные значения SQL.
Сдерживание и ключевые поиски¶
contains ¶
contains не поддерживается в Oracle и SQLite.
contained_by ¶
contains_by не поддерживается в Oracle и SQLite.
has_key ¶
Возвращает объекты, в которых данный ключ находится на верхнем уровне данных. Например:
has_keys ¶
Возвращает объекты, в которых все данные ключи находятся на верхнем уровне данных. Например:
has_any_keys ¶
Возвращает объекты, где любой из указанных ключей находится на верхнем уровне данных. Например:
Сложные поиски с объектами Q ¶
Например, этот объект Q инкапсулирует один запрос LIKE :
Это эквивалентно следующему оператору SQL WHERE :
Вы можете составлять операторы произвольной сложности, комбинируя объекты Q с операторами & и | и используя группировку в скобках. Кроме того, объекты Q могут быть отменены с помощью оператора
, что позволяет комбинировать поиск, который объединяет как обычный запрос, так и отрицательный ( NOT ) запрос:
… примерно переводится в SQL как:
… будет правильным запросом, эквивалентным предыдущему примеру, но:
Сравнение объектов¶
Удаление объектов¶
Например, это удаляет все объекты Entry с pub_date 2005 года:
Копирование экземпляров модели¶
Все становится сложнее, если вы используете наследование. Рассмотрим подкласс Blog :
Из-за того, как работает наследование, вы должны установить для pk и id значение None :
Для OneToOneField вы должны продублировать связанный объект и назначить его полю нового объекта, чтобы избежать нарушения однозначного уникального ограничения. Например, предполагая, что entry уже продублировано, как указано выше:
Обновление нескольких объектов одновременно¶
Метод update() применяется мгновенно и возвращает количество строк, соответствующих запросу (которое может быть не равно количеству обновленных строк, если некоторые строки уже имеют новое значение). Единственное ограничение на обновляемый QuerySet состоит в том, что он может получить доступ только к одной таблице базы данных: главной таблице модели. Вы можете фильтровать на основе связанных полей, но вы можете обновить только столбцы в основной таблице модели. Пример:
Вызовы обновлений также могут использовать выражения F для обновления одного поля на основе значения другого поля в модели. Это особенно полезно для увеличения счетчиков на основе их текущего значения. Например, чтобы увеличить количество пингбэков для каждой записи в блоге:
Связанные объекты¶
(За кулисами эта функциональность реализована с помощью дескрипторов Python. Это не должно иметь большого значения для вас, но мы отметим это здесь для любопытных.)
Отношения один ко многим¶
Прямые¶
Если поле ForeignKey установлено null=True (т.е. оно допускает значения NULL ), вы можете назначить None для удаления отношения. Пример:
Прямой доступ к отношениям «один ко многим» кэшируется при первом обращении к связанному объекту. Последующие обращения к внешнему ключу в том же экземпляре объекта кэшируются. Пример:
Обратные отношения¶
Использование собственного реверсивного менеджера¶
Указание собственного обратного менеджера также позволяет вам вызывать его пользовательские методы:
Дополнительные методы для обработки связанных объектов¶
Чтобы назначить членов связанного набора, используйте метод set() с повторяющимися экземплярами объекта. Например, если e1 и e2 являются экземпляром Entry :
Каждая «обратная» операция, описанная в этом разделе, оказывает непосредственное влияние на базу данных. Каждое добавление, создание и удаление немедленно и автоматически сохраняется в базе данных.
Отношения многие ко многим¶
Обе стороны отношения «многие ко многим» получают автоматический доступ API другой стороны. API работает аналогично «обратному» отношению «один ко многим» выше.
Пример облегчает понимание:
Отношения один-к-одному¶
Отношения один-к-одному очень похожи на отношения многие-к-одному. Если вы определяете OneToOneField в вашей модели, экземпляры этой модели будут иметь доступ к связанному объекту через простой атрибут модели.
Экземпляры могут быть назначены на обратную связь так же, как вы бы назначили прямую связь:
Как возможны обратные отношения?¶
Другие объектно-реляционные связи требуют, чтобы вы определяли отношения с обеих сторон. Разработчики Django считают, что это является нарушением принципа DRY (не повторяй себя), поэтому Django требует, чтобы вы определяли отношения только с одной стороны.
Но как это возможно, учитывая, что класс модели не знает, какие другие классы модели связаны с ним, пока эти другие классы модели не будут загружены?
Запросы к связанным объектам¶
Запросы, связанные со связанными объектами, подчиняются тем же правилам, что и запросы, включающие поля с обычными значениями. При указании значения для сопоставляемого запроса вы можете использовать либо сам экземпляр объекта, либо значение первичного ключа для объекта.