Related name django для чего
Для чего используется `related_name` в Django?
4 ответа
related_name Атрибут задает имя обратной связи от User модель обратно к вашей модели.
Документация Django содержит более подробную информацию.
Добавление к существующему названию, связанному с ответом, является обязательным, если в модели 2 FK, указывающих на одну и ту же таблицу. Например, в случае спецификации
Поэтому, когда вам нужно будет получить доступ к этим данным, вы можете использовать только связанное имя
Это не работает иначе (по крайней мере, я не смог пропустить использование связанного имени в случае 2 FK для одной таблицы.)
related_name Аргумент также полезен, если у вас есть более сложные связанные имена классов. Например, если у вас есть отношение внешнего ключа:
Суть вашего вопроса заключается в следующем.
Поскольку у вас есть Map а также User модели и вы определили ManyToManyField в модели карты, если вы хотите получить доступ к членам карты, у вас есть возможность map_instance.members.all() так как вы определили поле members. Тем не менее, если вы хотите получить доступ ко всем картам, пользователь является частью того, какой вариант у вас есть.
По умолчанию Django предоставил вам user_instance.modelname_set.all() и это переведет на user.map_set.all() в этом случае.
карты намного лучше, чемmap_set.
related_name дает вам возможность сообщить Django, как вы собираетесь получить доступ к карте из модели пользователя или в целом, как вы можете получить доступ к обратным моделям, что составляет весь смысл создания полей ManyToMany и использования ORM в этом смысле.
What does related_name do?
In the Django documentation about related_name it says the following:
The name to use for the relation from the related object back to this one. It’s also the default value for related_query_name (the name to use for the reverse filter name from the target model). See the related objects documentation for a full explanation and example. Note that you must set this value when defining relations on abstract models; and when you do so some special syntax is available.
If you’d prefer Django not to create a backwards relation, set related_name to ‘+’ or end it with ‘+’.
I didn’t understand it clearly. If somebody would please explain it a bit more, it would help me a lot.
2 Answers 2
When you create a foreign key, you are linking two models together. The model with the ForeignKey() field uses the field name to look up the other model. It also implicitly adds a member to the linked model referring back to this one.
There are three possible scenarios here:
1. Don’t specify related_name
If you don’t specify a name, django will create one by default for you.
2. Specify a custom value
3. Prevent the reverse reference from being created
Sometimes you don’t want to add the reference to the foreign model, so use related_name=»+» to not create it.
related_query_name is basically the same idea, but when using filter() on a queryset:
But to be honest I’ve never used this since the related_name value is used by default.
If in a model you have a ForeignKey field (this means you point through this field to other model):
if you specify related_name on this field
you give a name to the attribute that you can use for the relation (named reverse realationship) from the related object back to this one (from Author to Article ). After defining this you can retrieve the articles of an user like so:
If you don’t define a related_name attribute, Django will use the lowercase name of the model followed by _set (that is, in our case, article_set ) to name the relationship from the related object back to this one, so you would have to retrieve all articles of an user like so:
If you don’t want to be possible a reverse relationship (from the model to which points your ForeignKey filed to this model (the model in which the ForeignKey field is defined) you can set
Best Practices в работе с моделями Django
1. Правильный нейминг моделей
2. Название поля Relationship
Связям (relationships), таким как «один ко многим» ( ForeignKey ), «один к одному» ( OneToOneKey ), «многие ко многим» ( ManyToMany ), порой лучше давать более специфические имена.
3. Подходящее имя related_name
4. Не используйте ForeignKey с unique=True
5. Порядок атрибутов и методов в модели
Предпочтительный порядок указания атрибутов и методов в модели:
Этот список был составлен на основе рекомендуемого в документации и слегка расширен.
6. Добавление модели с помощью миграции
Допустим, вам нужно добавить модель. Имея готовый класс модели, выполните серию команд manage.py: makemigrations и migrate (для Django 1.6 и ниже используйте South ).
7. Денормализация
Не следует допускать бездумную денормализацию в реляционных базах данных. Всегда старайтесь избегать этого, за исключением случаев, когда вам по каким-то причинам (например, для повышения производительности) приходится постоянно денормализовывать данные.
Если на этапе проектирования базы данных вы понимаете, что многие данные придется денормализовывать, хорошим вариантом будет использование NoSQL. Однако, если большинство данных не требуют непременной денормализации, подумайте о реляционной базе с JsonField для хранения некоторых данных.
8. BooleanField
9. Бизнес-логика в моделях
Бизнес-лоигку проекта лучше всего размещать в моделях, а именно — в методах и менеджере модели. Допустимо делать так, чтобы методы модели только запускали какие-то методы/функции. Если разместить логику в моделях неудобно или невозможно, следует перенести ее в формы.
10. Дублирование полей в ModelForm
11. Не используйте ObjectDoesNotExist
Использование ModelName.DoesNotExist вместо ObjectDoesNotExist сделает ваш перехват исключений более точным. Это хорошая практика.
12. Использование choices
При использовании choices рекомендуется следующее:
14. Много флагов в модели?
Если это оправдано, замените несколько BooleanField одним полем, например:
Допустим, логика нашего приложения предполагает, что в «исходном положении» статья не опубликована и не проверена. Затем она проверяется (при этом is_verified помечается как True ), а затем публикуется. То есть, статья не может быть опубликована, пока она не проверена.
Этот пример, быть может, не слишком показательный, но представьте, что у вас в модели таких BooleanField три или даже больше. Контролировать проверку комбинаций значений этих полей может быть довольно утомительным делом.
15. Имя модели в имени поля это излишество
16. В базе не должно быть грязных данных
17. Получение самого первого/последнего объекта
18. Никогда не используйте len(queryset)
19. if queryset это плохая идея
20. Используйте help_text в качестве документации
Использование модели help_text в полях в качестве части документации существенно облегчит понимание структуры данных. Это принесет пользу и вам, и вашим коллегам, и пользователям-админам.
21. Хранение денежной информации
22. Не используйте null=true без необходимости
null=True — позволяет столбцу хранить значение null.
blank=True — должно использоваться только для валидации в формах и там, где это не будет связано с работой с базой данных.
Таким образом вы будете получать только одно возможное значение для столбцов без данных.
23. Избавляйтесь от _id
24. Определяйте __unicode__ или __str__
Во всех неабстрактных моделях добавляйте методы __unicode__ (python 2) или __str__ (python 3). Эти методы должны всегда возвращать строки.
25. Прозрачный список полей
26. Не сваливайте все файлы, загруженные пользователем, в одну папку
27. Используйте абстрактные модели
Если вы хотите, чтобы какая-то логика у моделей была общей, можно использовать абстрактные модели.
28. Применяйте пользовательские Manager и QuerySet
Допустим, вы хотите вести подсчет комментариев к постам из приведенного выше примера.
Вы можете использовать следующий подход:
Если вы хотите использовать этот метод в связке с другими методами queryset, стоит применить пользовательский QuerySet :
Документация Django 1.7
Этот раздел содержит все существующие подробности о всех параметрах поля и типах полей в 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 знаков после запятой:
EmailField ¶
Несоответствие с RFC
Значение max_length в 75 символов не достаточно для хранения всех возможных значений в соответствии RFC3696/5321. Для хранения всех возможных вариантов необходимо значение max_length в 254. Значение в 75 символов сложилось исторически и не изменяется для обратной совместимости.
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 ¶
Поля отношений¶
Django предоставляет набор полей для определения связей между моделями.
ForeignKey ¶
Связь многое-к-одному. Принимает позиционный аргумент: класс связанной модели.
Если вам необходимо добавить связь на модель, которая еще не определена, вы можете использовать имя модели вместо класса:
Такой способ позволяет создать циклическую зависимость между моделями из разных приложений.
Не рекомендуется использовать ForeignKey из приложения без миграций к приложению с миграциями. Смотрите раздел о зависимостях миграций.
Представление в базе данных¶
Параметры¶
Указание функции может быть полезно, если используется объект Python datetime для фильтрации. Например:
Поле связанной модели, которое используется для создания связи между таблицами. По-умолчанию, Django использует первичный ключ.
Указывает создавать ли “constraint” для внешнего ключа в базе данных. По умолчанию True и в большинстве случает это то, что вам нужно. Указав False вы рискуете целостностью данных. Некоторые ситуации, когда вам может быть это необходимо:
Вам досталась в наследство нецелостная база данных
Вы используете шардинг базы данных.
Каскадное удаление, значение по умолчанию.
Препятствует удалению связанного объекта вызывая исключение django.db.models.ProtectedError`(подкласс :exc:`django.db.IntegrityError ).
ManyToManyField ¶
Не рекомендуется использовать ManyToManyField из приложения без миграций к приложению с миграциями. Смотрите раздел о зависимостях в миграциях.
Представление в базе данных¶
Параметры¶
Используется только при рекурсивной связи. Например, есть модель:
Если вы не указали through модель, вы все равно может обратиться к неявно промежуточной модели, которая была автоматически создана. Она содержит три поля:
id : первичный ключ для связи.
Этот класс может использоваться для получения связей.
Используется, если явно указана промежуточная модель для связи многое-ко-многим. Обычно Django самостоятельно определяется какие поля использовать для создания связи. Однако, возьмем такой пример:
Имя промежуточной таблицы для хранения связей многое-ко-многим. Если не указан, Django самостоятельно создаст название по умолчанию используя название таблицы определяющей связь и название поля.
Указывает создавать ли “constraint” для внешних ключей в промежуточной таблице в базе данных. По умолчанию True и в большинстве случает это то, что вам нужно. Указав False вы рискуете целостностью данных. Некоторые ситуации, когда вам может быть это необходимо:
Вам досталась в наследство нецелостная база данных
Вы используете шардинг базы данных.
Нельзя указать db_constraint и through одновременно.
OneToOneField ¶
В основном применяется как первичный ключ модели, которая “расширяет” другую модель. Например, Multi-table наследование работает через неявное добавление связи один-к-одному от дочерней модели к родительской.
модель User будет содержать следующие атрибуты:
При True и связанной модели, которая наследуется от другой модели, определяет, что должна сохраняться связь на родительскую модель, а не поле OneToOneField дочерней модели, которое используется для организации наследования моделей.
Смотрите примеров использования OneToOneField в Связь один к одному.
Справочник по полям модели¶
Field – абстрактный класс, отображающий поле в таблице в базе данных. Django используется поля для создания таблицы в базе данных ( db_type() ), для преобразования типов Python в типа в базе данных ( get_prep_value() ) и наоборот ( to_python() ), и для применения 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)¶
При загрузке данных используется to_python() :
При сохранении используются методы pre_save() и get_db_prep_save() :
model_instance – объект модели, к которому принадлежит поле, add – указывает сохраняется ли объект первый раз в базу данных.
Кроме сохранения в базу данных, поле также должно знать как сериализовать свое значение (процесс обратный to_python() ):
Преобразует obj в строку. Используется при сериализации значения поля.
При использовании фильтрации по полю, может быть необходимо “приготовить” значение. Django используется для этого два метода:
get_db_prep_lookup(lookup_type, value, connection, prepared=False)¶
formfield(form_class=None, choices_form_class=None, **kwargs)¶
Возвращает 4-х элементный кортеж с информацией, как воссоздать поле:
Название поля в модели.
Путь для импорта класса поля (например, «django.db.models.IntegerField» ). Должен возвращаться максимально переносимый между платформами и версиями вариант.
Список позиционных аргументов.
Словарь именованных аргументов.
Этот метод должен быть добавлен полям, созданным до 1.7, для использования Миграции.
Перевод Django Documentation: Models. Part 3
Доброго времени суток!
Еще одна часть серии моих переводов раздела о моделях из документации Django.
___Мета-параметры
___Методы моделей
_____Переопределение предопределенных методов
_____Использование SQL
___Наследование моделей
_____Абстрактные базовые классы
_______Мета-наследование
_______Будьте аккуратны с related_names
Добавить вашей модели мета-данные вы можете с помощью внутреннего класса Meta:
Copy Source | Copy HTML
class Ox (models.Model):
horn_length = models.IntegerField()
class Meta :
ordering = [ «horn_length» ]
verbose_name_plural = «oxen»
Мета-данные в модели это «что-либо не являющееся полем», например: параметры сортировки (ordering), имя таблицы базы данных (db_table), читабельные имена объектов в единственном (verbose_name) или множественном (verbose_name_plural) числе и тд. Мета-данные не являются обязательными, добавление класса Meta в вашу модель полностью опционально.
Полный список мета-параметров вы можете найти в справке по параметрам модели.
Вы можете определить в модели методы, чтобы добавить собственной функциональности вашим объектам. В то время как методы Manager предназначены для работы с данными всей таблицы, методы модели созданы для действий в отдельном экземпляре модели.
Эта техника полезна для хранения бизнес-логики приложения в одном месте — в модели.
Например, эта модель имеет несколько собственных методов:
Copy Source | Copy HTML
from django.contrib.localflavor.us.models import USStateField
class Person (models.Model):
first_name = models.CharField(max_length= 50 )
last_name = models.CharField(max_length= 50 )
birth_date = models.DateField()
address = models.CharField(max_length= 100 )
city = models.CharField(max_length= 50 )
state = USStateField() # Yes, this is America-centric.
def _get_full_name (self):
«Returns the person’s full name.»
return ‘%s %s’ % (self.first_name, self.last_name)
full_name = property( _get_full_name )
Последний метод этом примере — управляемый атрибут (property). Более подробно здесь.
В справке по экземплярам моделей содержится полный список автоматически добавляемых каждой модели методов. Вы можете переопределить большую их часть (об этом ниже). Также есть пара методов, которые переопределяют в большинстве случаев:
«Магический метод» языка Python, который возвращает «представление» любого объекта в кодировке unicode. Его используют, когда требуется отобразить экземпляр модели в виде простой, понятной строки. Например, при работе в интерактивной консоли или в интерфейсе администратора.
Переопределение этого метода требуется довольно часто, потому что стандартный не очень полезен.
Этот метод сообщает Django алгоритм вычисления URL для объекта. Он используется в интерфейсе администратора, а также каждый раз, когда нужно выяснить URL некоторого объекта.
Каждый объект, который имеет однозначно определяемый URL, должен содержать данный метод.
Переопределение предопределенных методов
Существует еще несколько методов моделей, с помощью которых вы можете изменять поведение базы данных. В частности, нередко требуется изменение алгоритма работы методов save() и delete().
Вы можете переопределять эти методы (так же как и все остальные в модели), и тем самым менять их поведение.
Например, переопределение встроенных методов используется, если вы хотите, чтобы при сохрании объекта совершались некоторые действия (более подробно о принимаемых методом save() параметрах вы можете прочитать в документации):
Copy Source | Copy HTML
class Blog (models.Model):
name = models.CharField(max_length= 100 )
tagline = models.TextField()
Copy Source | Copy HTML
class Blog (models.Model):
name = models.CharField(max_length= 100 )
tagline = models.TextField()
Важно не забыть вызвать метод наследуемого класса (в нашем примере super(Blog, self).save()), чтобы гарантировать сохранение данных в базу данных Если же вы забудете вызвать этот метод, то база данных останется нетронутой.
Использование SQL
Еще один частоиспользуемый прием заключается в написании собственных конструкций SQL в методах модели или в методах модуля. Более подробно об использовании «сырого» SQL вы можете прочитать в документации.
добавлено в версии Django 1.0: пожалуйста, прочтите примечания к релизу.
Принцип наследования моделей в Django почти полностью идентичен наследованию классов в языке Python. Единственное решение, которое вам придется принимать это, будут ли наследуемые модели представлять собой таблицу базы данных, или же они будут являться лишь хранителями данных, и доступ к ним будет возможен только через производные модели.
Абстрактные базовые классы
Абстрактные базовые классы полезны, когда вы хотите создать несколько моделей с общей информацией. Создайте базовый класс, поместите параметр abstract=True в класс Meta, и эта модель не будет использоваться при создании таблиц базы данных. Вместо этого, когда он будет использоваться как базовый для некоторой модели, его поля будут добавлены к производному классу. Если же имя поля в базовом и производном классе совпадут, Django возбудит исключение.
Copy Source | Copy HTML
class CommonInfo (models.Model):
name = models.CharField(max_length= 100 )
age = models.PositiveIntegerField()
class Meta :
abstract = True
class Student ( CommonInfo ):
home_group = models.CharField(max_length= 5 )
Модель Student будет содержать три поля: name, age и home_group. Так как модель CommonInfo — абстрактный базовый класс, она не будет использоваться как обычная модель Django: она не будет генерировать таблицу базы данных, иметь manager, нельзя будет сохранить или создать ее экземпляр напрямую.
Во многих случаях этот тип наследования будет удовлетворять вашим требованиям. Данный метод позволяет «вынести за скобки» общую информацию на Python-уровне, в то время как на уровне базы данных будут создаваться отдельные таблицы для каждого производного класса.
Когда создается абстрактный базовый класс, Django делает внутренний класс Meta, который вы определили в базовом классе, доступным как атрибут. Если в производном классе не будет определен собственный класс Meta, он будет унаследован от родителя. Однако при желании вы можете расширить базовый класс Meta, использовав наследование в классах Meta. Например:
Copy Source | Copy HTML
class CommonInfo (models.Model):
.
class Meta :
abstract = True
ordering = [ ‘name’ ]
Django делает лишь одну корректировку в классе Meta абстрактного базового класса: перед установлением атрибута Meta, параметр abstract принмает значение False. Это делается для того, чтобы производные классы не становились автоматически абстрактными. Разумеется, вы можете создать абстрактный базовый класс, который наследуется от другого абстрактного базового класса. Для этого вам просто следует явно устанавливать abstract=True.
Не имеет смысла добавлять некоторые атрибуты в класс Meta абстрактного базового класса. Например, добавление параметра db_name, будет означать, что все производные классы, которые не имеют собственного класса Meta, будут использовать одну и ту же таблицу базы данных. Почти наверняка, это совсем не то чего вы хотели.
Будьте аккуратны с related_name
Если вы используете атрибут related_name в поле ForeignKey или ManyToManyField, вы должны определить уникальное обратное имя для каждого поля. Это обычно приводит проблеме в абстрактных базовых классах, так как все поля и их значения добавляются в каждый производный класс.
Чтобы обойти эту проблему, при использовании атрибута related_name в абстрактных базовых классах (и только в них), частью имени должна быть строка ‘%(class)s’. Она будет заменена на имя производного класса в нижем регистре, в котором используется это поле. Так как классы имеют различные имена, каждый атрибут будет иметь уникальное значение. Например:
Copy Source | Copy HTML
class Base (models.Model):
m2m = models.ManyToManyField(OtherModel, related_name= «%(class)s_related» )
class Meta :
abstract = True
class ChildA ( Base ):
pass
Обратное имя ChildA.m2m будет childa_related, а для ChildB.m2m — childb_related. Ваше дело как использовать конструкцию ‘%(class)s’, однако если вы забудете про нее, Django возбудит исключение при валидации ваших моделей (или при выполнении syncdb).
Если же вы не определили атрибут related_name для поля в абстрактном базовом классе, обратное имя по умолчанию будет именем производного класса в нижнем регистре с добавлением строки ‘_set’, так будто вы явно определили это поле непосредственно в производном классе. Например, для приведеного выше текста, если бы атрибут related_name был опущен, обратными именами для полей m2m были бы childa_set для класса ChildA и childb_set в случае с классом ChildB.
На сегодня все 🙂 Следущая часть будет последней в данном разделе. Думаю, после ее перевода создать опрос — нужны ли хабру эти самые переводы или нет. Буду ли я продолжать напрямую зависит от его результатов. А пока нужно завершить переводить то, что начал )
to be continued
Любые комментарии приветствуются 🙂