QuerySet - объекты, представляющие собой запрос к базе данных. Именно запрос, а не его результаты. QuerySet являются ленивыми (lazy) объектами. Это значит, что запрос осуществляется не в момент создания QuerySet, а в момент итерации по нему, либо вызова метода, возвращающего результат.
filter,exclude - фильтрация, в SQL это WHEREorder_by - сортировкаannotate - выборка агрегатов, в SQL это JOIN и GROUP BYvalues - выборка отдельных колонок, а не объектовdistinct - выборка уникальных значенийselect_related,prefetch_related - выборка из нескольких таблицcreate - создание нового объектаupdate - обновление всех подходящих объектовdelete - удаление всех подходящих объектовget_or_create - выборка объекта или его созданиеcount - выборка количества COUNT(*)get_or_create - выборка объекта или его созданиеВ методах filter и exclude:
field = value - точное совпадениеfield__contains = value - суффикс оператора LIKEfield__isnull, field__gt, field__lterelation__field = value - условие по связанной таблицеcategory__title__contains = "Perl"__!
В модели содержатся методы для работы с одним объектом (одной строкой). В ModelManager содержатся объекты для работы со множеством объектов. ModelManager «по-умолчанию» содержит все те же методы что QuerySet и используется для создания QuerySet объектов связанных с данной моделью.
RelatedManager связан с конкретным объектом Post и во все выборки будет добавлять условие post=p1
create(**kwargs) - создание нового тэга, связанного с постомadd(t2) - привязка существующего тэга t2 к текущему постуremove(t2) - отвязка существующего тэга t2 от текущего постаclear() - очистка списка тэгов у текущего постаМиграция - это процедура изменения схемы базы данных для приведения ее в соответствие с моделями.
Начиная с версии 1.7 Django поддерживает миграции на уровне фреймворка.
./manage.py makemigrations - анализ изменений в моделях и создание миграций../manage.py migrate - применение новых миграций к базе данных.project/migration/2015-08-08-more-post-fields.py
Типичная проблема начинающих разработчиков - размещение логики в контроллерах.
Это плохое решение, у которого есть имя - антипаттерн Fat Controller.
Размещение логики в контроллере лишает вас возможности использовать ее повторно.
Всю бизнес-логику приложения следует размещать в моделях.