related name django для чего

What is related_name used for?

6 Answers 6

The related_name attribute specifies the name of the reverse relation from the User model back to your model.

So when you will have to access this data you only can use related name

It is not working otherwise (at least I was not able to skip the usage of related name in case of 2 FK’s to the same table.)

The related_name argument is also useful if you have more complex related class names. For example, if you have a foreign key relationship:

The essentials of your question are as follows.

Since you have Map and User models and you have defined ManyToManyField in Map model, if you want to get access to members of the Map then you have the option of map_instance.members.all() since you have defined members field. However, say you want to access all maps a user is a part of then what option do you have.

By default, Django provided you with user_instance.modelname_set.all() and this will translate to the user.map_set.all() in this case.

maps is much better than map_set.

related_name provides you an ability to let Django know how you are going to access Map from User model or in general how you can access reverse models which is the whole point in creating ManyToMany fields and using ORM in that sense.

Источник

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 :

Источник

Для чего используется ‘ related_name` в Django?

6 ответов

У меня есть следующая модель в Django: class Feedback(models.Model): solution=models.ForeignKey(Solution, related_name=’solution1′) idea=models.ForeignKey(Idea,null=True, blank=True,related_name=’idea1′) idea2=models.ForeignKey(Idea, related_name=’idea2′) Учитывая ID решения, как я могу написать.

Атрибут related_name указывает имя обратной связи между моделью User и вашей моделью.

В документации Django содержится более подробная информация.

Добавление к существующему имени, связанному с ответом, необходимо в том случае, если в модели есть 2 FKs, которые указывают на одну и ту же таблицу. Например, в случае спецификации

В противном случае он не работает (по крайней мере, я не смог пропустить использование связанного имени в случае 2 FK в той же таблице.)

Аргумент related_name также полезен, если у вас есть более сложные связанные имена классов. Например, если у вас есть отношение внешнего ключа:

Суть вашего вопроса заключается в следующем.

related_name предоставляет вам возможность сообщить Django, как вы собираетесь получить доступ к карте из пользовательской модели или вообще как вы можете получить доступ к обратным моделям, что является целым смыслом создания полей ManyToMany и использования ORM в этом смысле.

У меня есть ряд таблиц, определенных в моем файле Django models, и он сказал мне добавить ключевое слово related_name в небольшую группу моих полей, так как несколько полей указывают на одну и ту же таблицу. Я сделал это, и теперь, когда я пытаюсь синхронизировать свою базу данных, я получаю.

Похожие вопросы:

Есть ли предложения по правильной конфигурации related_name в models.py для создания структуры категорий и подкатегорий? Ошибка при запуске syncdb : myapp.category: Accessor for field ‘parent’.

Я слышал, как много людей говорили о Django на различных форумах. Но у меня есть очень простой вопрос: Что подразумевается под фреймворком и почему используется Django. После того, как я много.

Для чего используется приложение сайта в django? Я запутался в этом, для чего это используется?

У меня есть следующая модель в Django: class Feedback(models.Model): solution=models.ForeignKey(Solution, related_name=’solution1′) idea=models.ForeignKey(Idea,null=True.

У меня есть ряд таблиц, определенных в моем файле Django models, и он сказал мне добавить ключевое слово related_name в небольшую группу моих полей, так как несколько полей указывают на одну и ту же.

У меня есть несколько моделей, которые имеют ForeignKey обратно к модели, которая имеет ForeignKey обратно к пользователю auth в Django. models.py class UserDetails(models.Model): user =.

у меня есть проблема с кодом в фреймворке django относительно related_name и related_query_name в django. пожалуйста, django эксперт объясните related_name в django, код ниже: related_name=’+’

Источник

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

Источник

Ссылка на поле модели ¶

Этот документ содержит все ссылки АНИ из Field включая параметры полей и типы полей Django предложений.

Параметры поля ¶

Следующие аргументы доступны для всех типов полей. Все не обязательны.

При использовании серверной части базы данных Oracle значение NULL будет сохранено для обозначения пустой строки независимо от этого атрибута.

blank ¶

choices ¶

Как правило, лучше всего определять варианты выбора внутри класса модели и определять константу с подходящим именем для каждого значения:

Хотя вы можете определить список вариантов вне класса модели, а затем ссылаться на него, определение вариантов и имен для каждого выбора внутри класса модели сохраняет всю эту информацию с классом, который ее использует, и помогает ссылаться на варианты выбора (например, Student.SOPHOMORE будет работать везде, где Student модель была импортирована).

Вы также можете объединить доступные варианты в именованные группы, которые можно использовать в организационных целях:

Для каждого установленного поля модели choices Django добавит метод для получения удобочитаемого имени для текущего значения поля. См. get_FOO_display() Документацию по API базы данных.

Новая миграция создается каждый раз при choices изменении порядка изменения.

Типы перечисления ¶

Кроме того, Django предоставляет типы перечисления, которые можно разделить на подклассы для краткого определения вариантов:

Они работают аналогично enum стандартной библиотеке Python, но с некоторыми изменениями:

Если вам не нужно переводить удобочитаемые имена, вы можете вывести их из имени члена (заменив подчеркивание пробелами и используя регистр заголовка):

Поскольку случай, когда значения перечисления должны быть целыми числами, чрезвычайно распространен, Django предоставляет IntegerChoices класс. Например:

Также можно использовать Enum Functional API с оговоркой, что метки создаются автоматически, как указано выше:

Следует помнить о некоторых дополнительных предостережениях:

db_column ¶

Имя столбца базы данных, используемого для этого поля. Если это не указано, Django будет использовать имя поля.

db_index ¶

db_tablespace ¶

default ¶

Значение по умолчанию для поля. Это может быть значение или вызываемый объект. Если вызываемый, он будет вызываться каждый раз при создании нового объекта.

Для таких полей, как ForeignKey это сопоставление с экземплярами модели, значения по умолчанию должны быть значением поля, на которое они ссылаются ( pk если to_field не установлено), а не экземплярами модели.

editable ¶

error_messages ¶

help_text ¶

Дополнительный текст «справки», отображаемый в виджете формы. Это полезно для документации, даже если ваше поле не используется в форме.

Обратите внимание, что это значение не экранируется HTML в автоматически сгенерированных формах. Это позволяет вам включать HTML, help_text если хотите. Например:

В качестве альтернативы вы можете использовать обычный текст и django.utils.html.escape() экранировать любые специальные символы HTML. Убедитесь, что вы избегаете любого текста справки, который может исходить от ненадежных пользователей, чтобы избежать атаки межсайтового скриптинга.

primary_key ¶

Если True это поле является первичным ключом для модели.

Поле первичного ключа доступно только для чтения. Если вы измените значение первичного ключа на существующем объекте, а затем сохраните его, новый объект будет создан рядом со старым.

В более старых версиях автоматически создаваемые поля первичного ключа всегда были AutoField s.

unique ¶

unique_for_date ¶

Задайте для него имя DateField или, DateTimeField чтобы это поле было уникальным для значения поля даты.

Это выполняется Model.validate_unique() во время проверки модели, но не на уровне базы данных. Если какое-либо unique_for_date ограничение включает поля, которые не являются частью ModelForm (например, если одно из полей указано exclude или имеет editable=False ), Model.validate_unique() проверка для этого конкретного ограничения будет пропущена.

unique_for_month ¶

unique_for_year ¶

verbose_name ¶

validators ¶

Список валидаторов, запускаемых для этого поля. См. Документацию по валидаторам для получения дополнительной информации.

Регистрация и получение результатов поиска ¶

Типы полей ¶

AutoField ¶

BigAutoField ¶

BigIntegerField ¶

BinaryField ¶

BinaryField имеет один дополнительный необязательный аргумент:

BooleanField ¶

CharField ¶

Строковое поле для строк от маленького до большого.

CharField имеет два дополнительных аргумента:

По желанию. Имя поля сортировки базы данных.

Имена параметров сортировки не стандартизированы. Таким образом, это не будет переносимым между несколькими бэкэндами базы данных.

DateField ¶

Дата, представленная в Python datetime.date экземпляром. Имеет несколько дополнительных необязательных аргументов:

Автоматически устанавливать для поля значение «Сейчас» каждый раз при сохранении объекта. Полезно для отметок времени «последнего изменения». Обратите внимание, что всегда используется текущая дата ; это не просто значение по умолчанию, которое вы можете изменить.

Автоматически установить для поля значение «Сейчас» при первом создании объекта. Полезно для создания отметок времени. Обратите внимание, что всегда используется текущая дата ; это не просто значение по умолчанию, которое вы можете изменить. Таким образом, даже если вы установите значение для этого поля при создании объекта, оно будет проигнорировано. Если вы хотите иметь возможность изменять это поле, вместо auto_now_add=True :

Параметры auto_now и auto_now_add всегда будут использовать дату в часовом поясе по умолчанию в момент создания или обновления. Если вам нужно что-то другое, вы можете рассмотреть возможность использования собственного вызываемого значения по умолчанию или переопределения save() вместо использования auto_now или auto_now_add ; или используя DateTimeField вместо a DateField и решая, как обрабатывать преобразование из datetime в date во время отображения.

DateTimeField ¶

DecimalField ¶

Имеет два обязательных аргумента:

Количество десятичных знаков, которые нужно сохранить вместе с номером.

Например, для хранения чисел 999 с разрешением до 2 знаков после запятой вы должны использовать:

И для хранения чисел примерно до одного миллиарда с разрешением до 10 знаков после запятой:

DurationField ¶

Арифметика с DurationField работает в большинстве случаев. Однако во всех базах данных, кроме PostgreSQL, сравнение значения a DurationField с арифметическим на DateTimeField экземплярах не будет работать должным образом.

EmailField ¶

FileField ¶

Поле для загрузки файла.

Имеет два необязательных аргумента:

Этот атрибут обеспечивает способ установки каталога загрузки и имени файла и может быть установлен двумя способами. В обоих случаях значение передается Storage.save() методу.

upload_to также может быть вызываемым, например функцией. Это будет вызвано для получения пути загрузки, включая имя файла. Этот вызываемый объект должен принимать два аргумента и возвращать путь в стиле Unix (с косой чертой) для передачи в систему хранения. Вот два аргумента:

Экземпляр модели, в FileField которой определен. В частности, это конкретный экземпляр, к которому прикрепляется текущий файл.

Объект хранения или вызываемый объект, который возвращает объект хранения. Это управляет хранением и поиском ваших файлов. См. Управление файлами для получения подробной информации о том, как предоставить этот объект.

Добавлена ​​возможность предоставлять вызываемый объект.

Использование FileField или ImageField (см. Ниже) в модели требует нескольких шагов:

Файл сохраняется как часть сохранения модели в базе данных, поэтому на фактическое имя файла, используемое на диске, нельзя полагаться до тех пор, пока модель не будет сохранена.

Относительный URL загруженного файла можно получить с помощью url атрибута. Внутри это вызывает url() метод базового Storage класса.

Обратите внимание, что всякий раз, когда вы имеете дело с загруженными файлами, вы должны обращать пристальное внимание на то, куда вы их загружаете и какой это тип файлов, чтобы избежать дыр в безопасности. Проверьте все загруженные файлы, чтобы убедиться, что они соответствуют вашим представлениям. Например, если вы слепо позволяете кому-то загружать файлы без проверки в каталог, который находится в корне документов вашего веб-сервера, то кто-то может загрузить сценарий CGI или PHP и выполнить этот сценарий, посетив его URL-адрес на вашем сайте. Не позволяй этого.

Также обратите внимание, что даже загруженный файл HTML, поскольку он может быть выполнен браузером (но не сервером), может представлять угрозы безопасности, эквивалентные атакам XSS или CSRF.

FileField экземпляры создаются в вашей базе данных в виде varchar столбцов с максимальной длиной по умолчанию 100 символов. Как и в случае с другими полями, вы можете изменить максимальную длину с помощью max_length аргумента.

FileField и FieldFile ¶

Когда вы получаете доступ к FileField модели, вам предоставляется экземпляр FieldFile в качестве прокси для доступа к базовому файлу.

Два метода этого класса save() и по delete() умолчанию сохраняют объект модели связанного FieldFile в базе данных.

Свойство только для чтения для доступа к пути к локальной файловой системе файла путем вызова path() метода базового Storage класса.

Результат базового Storage.size() метода.

Свойство только для чтения для доступа к относительному URL-адресу файла путем вызова url() метода базового Storage класса.

FieldFile. open ( режим = ‘rb’ ) ¶

Действует как стандартный file.close() метод Python и закрывает файл, связанный с этим экземпляром.

Этот метод принимает имя файла и содержимое файла и передает их классу хранения для поля, а затем связывает сохраненный файл с полем модели. Если вы хотите вручную связать данные файла с FileField экземплярами в вашей модели, этот save() метод используется для сохранения данных файла.

Или вы можете построить его из строки Python следующим образом:

FieldFile. delete ( сохранить = True ) ¶

Удаляет файл, связанный с этим экземпляром, и очищает все атрибуты поля. Примечание. Этот метод закроет файл, если он окажется открытым при delete() вызове.

Обратите внимание, что при удалении модели связанные файлы не удаляются. Если вам нужно очистить потерянные файлы, вам нужно будет обработать это самостоятельно (например, с помощью специальной команды управления, которую можно запускать вручную или по расписанию для периодического запуска, например, cron).

FilePathField ¶

A, CharField чей выбор ограничен именами файлов в определенном каталоге файловой системы. Имеет некоторые специальные аргументы, из которых требуется первый :

path также может быть вызываемым, например функцией для динамической установки пути во время выполнения. Пример:

… Будет соответствовать, /home/images/foo.png но не /home/images/foo/bar.png потому, что match применяется к базовому имени файла ( foo.png и bar.png ).

FilePathField экземпляры создаются в вашей базе данных в виде varchar столбцов с максимальной длиной по умолчанию 100 символов. Как и в случае с другими полями, вы можете изменить максимальную длину с помощью max_length аргумента.

FloatField ¶

Число с плавающей запятой, представленное в Python float экземпляром.

FloatField против. DecimalField

ImageField ¶

Для облегчения запросов к этим атрибутам ImageField есть два дополнительных необязательных аргумента:

Имя поля модели, которое будет автоматически заполняться высотой изображения при каждом сохранении экземпляра модели.

Имя поля модели, которое будет автоматически заполняться шириной изображения при каждом сохранении экземпляра модели.

ImageField экземпляры создаются в вашей базе данных в виде varchar столбцов с максимальной длиной по умолчанию 100 символов. Как и в случае с другими полями, вы можете изменить максимальную длину с помощью max_length аргумента.

IntegerField ¶

Он использует MinValueValidator и MaxValueValidator для проверки ввода на основе значений, поддерживаемых базой данных по умолчанию.

GenericIPAddressField ¶

Если вы разрешаете пустые значения, вы должны разрешить и пустые значения, поскольку пустые значения сохраняются как пустые.

JSONField ¶

JSONField поддерживается в MariaDB 10.2.7+, MySQL 5.7.8+, Oracle, PostgreSQL и SQLite (с включенным расширением JSON1 ).

Необязательный json.JSONEncoder подкласс для сериализации типов данных, не поддерживаемых стандартным сериализатором JSON (например, datetime.datetime или UUID ). Например, вы можете использовать DjangoJSONEncoder класс.

Необязательный json.JSONDecoder подкласс для десериализации значения, полученного из базы данных. Значение будет в формате, выбранном пользовательским кодировщиком (чаще всего в виде строки). При десериализации может потребоваться учет того факта, что вы не можете быть уверены в типе ввода. Например, вы рискуете вернуть a, datetime который на самом деле был строкой, которая случайно оказалась в том же формате, который был выбран для datetime s.

Oracle Database не поддерживает хранение скалярных значений JSON. Поддерживаются только объекты и массивы JSON (представленные в Python с помощью dict и list ).

NullBooleanField ¶

PositiveBigIntegerField ¶

PositiveIntegerField ¶

PositiveSmallIntegerField ¶

SlugField ¶

Как и CharField, вы можете указать max_length (прочтите примечание о переносимости базы данных и max_length в этом разделе). Если max_length не указано, Django будет использовать длину по умолчанию 50.

SmallAutoField ¶

SmallIntegerField ¶

TextField ¶

Если вы укажете max_length атрибут, он будет отражен в Textarea виджете автоматически созданного поля формы. Однако это не применяется на уровне модели или базы данных. Используйте CharField для этого.

Имя поля сортировки базы данных.

Имена параметров сортировки не стандартизированы. Таким образом, это не будет переносимым между несколькими бэкэндами базы данных.

TimeField ¶

URLField ¶

UUIDField ¶

Поиск в PostgreSQL

Поля отношений ¶

Django также определяет набор полей, представляющих отношения.

ForeignKey ¶

Отношения «многие к одному». Требуется два позиционных аргумента: класс, к которому относится модель, и on_delete параметр.

Если вам нужно создать связь в модели, которая еще не была определена, вы можете использовать имя модели, а не сам объект модели:

Такая ссылка, называемая ленивыми отношениями, может быть полезна при разрешении зависимостей циклического импорта между двумя приложениями.

Представление базы данных ¶

За кулисами Django добавляет «_id» к имени поля, чтобы создать имя столбца базы данных. В приведенном выше примере таблица базы данных для Car модели будет иметь manufacturer_id столбец. (Вы можете изменить это явно, указав db_column ) Однако ваш код никогда не должен иметь дело с именем столбца базы данных, если вы не пишете собственный SQL. Вы всегда будете иметь дело с именами полей вашего объекта модели.

Аргументы ¶

ForeignKey принимает другие аргументы, которые определяют детали того, как работает отношение.

Возможные значения on_delete находятся в django.db.models :

Каскад удаляет. Django имитирует поведение ограничения SQL ON DELETE CASCADE, а также удаляет объект, содержащий ForeignKey.

Model.delete() не вызывается на родственных моделях, но pre_delete и post_delete сигналы посылаются для всех удаленных объектов.

Рассмотрим этот набор моделей:

Не предпринимайте никаких действий. Если серверная часть вашей базы данных обеспечивает ссылочную целостность, это вызовет ошибку, IntegrityError если вы вручную не добавите ограничение SQL в поле базы данных. ON DELETE

Устанавливает предел доступных вариантов для этого поля, когда это поле отображается с помощью ModelForm или администратора (по умолчанию все объекты в наборе запросов доступны для выбора). Можно использовать словарь, Q объект или вызываемый объект, возвращающий словарь или Q объект.

Вызываемая форма может быть полезна, например, при использовании вместе с datetime модулем Python для ограничения выбора по диапазону дат. Например:

Имя, используемое для имени обратного фильтра из целевой модели. По умолчанию используется значение related_name или, default_related_name если установлено, в противном случае используется имя модели:

ManyToManyField ¶

Представление базы данных ¶

Аргументы ¶

limit_choices_to не действует при использовании ManyToManyField с пользовательской промежуточной таблицей, указанной с помощью through параметра.

Используется только в определении ManyToManyFields для себя. Рассмотрим следующую модель:

Django автоматически сгенерирует таблицу для управления отношениями «многие ко многим». Однако, если вы хотите вручную указать промежуточную таблицу, вы можете использовать эту through опцию, чтобы указать модель Django, которая представляет промежуточную таблицу, которую вы хотите использовать.

Если вы не хотите, чтобы между одними и теми же экземплярами было несколько ассоциаций, добавьте UniqueConstraint поля, включая поля from и to. Автоматически генерируемые в Django таблицы «многие ко многим» включают такое ограничение.

Если вы не укажете явную through модель, по-прежнему существует неявный through класс модели, который вы можете использовать для прямого доступа к таблице, созданной для хранения ассоциации. В нем есть три поля для связывания моделей.

Если исходная и целевая модели различаются, создаются следующие поля:

Если ManyToManyField точки от и к одной и той же модели, создаются следующие поля:

Этот класс можно использовать для запроса связанных записей для данного экземпляра модели, как в обычной модели:

Используется только в том случае, если указана настраиваемая промежуточная модель. Django обычно определяет, какие поля промежуточной модели использовать для автоматического установления связи «многие ко многим». Однако рассмотрите следующие модели:

Имя таблицы, которую нужно создать для хранения данных «многие ко многим». Если это не предусмотрено, Django примет имя по умолчанию на основе имен: таблицы для модели, определяющей отношения, и имени самого поля.

null не имеет никакого эффекта, поскольку нет возможности требовать отношения на уровне базы данных.

OneToOneField ¶

Это наиболее полезно в качестве первичного ключа модели, который каким-то образом «расширяет» другую модель; Многотабличное наследование реализуется, например, путем добавления неявного однозначного отношения от дочерней модели к родительской модели.

В следующем примере:

ваша результирующая User модель будет иметь следующие атрибуты:

Справочник по Field API ¶

A Field является подклассом RegisterLookupMixin и, следовательно, обоих, Transform и Lookup может быть зарегистрирован на нем для использования в QuerySet s (например field_name__exact=»foo» ). Все встроенные поисковые запросы регистрируются по умолчанию.

Подробное описание поля, например, для django.contrib.admindocs приложения.

Описание может иметь вид:

Чтобы сопоставить a Field с типом, зависящим от базы данных, Django предоставляет несколько методов:

Возвращает строку с именем этого поля для конкретных целей серверной части. По умолчанию он возвращает имя класса.

См. Раздел Эмуляция встроенных типов полей для использования в настраиваемых полях.

См. Раздел Пользовательские типы баз данных для использования в настраиваемых полях.

См. Раздел Пользовательские типы баз данных для использования в настраиваемых полях.

Существует три основных ситуации, когда Django необходимо взаимодействовать с серверной частью и полями базы данных:

При загрузке данных from_db_value() используются:

Этот метод не используется для большинства встроенных полей, поскольку серверная часть базы данных уже возвращает правильный тип Python или сама серверная часть выполняет преобразование.

По соображениям from_db_value производительности не реализован как запрет на работу с полями, которые не требуют этого (все поля Django). Следовательно, вы не можете использовать super свое определение.

При сохранении pre_save() и get_db_prep_save() используются:

Метод, вызываемый до того, как get_db_prep_save() подготовить значение перед сохранением (например, для DateField.auto_now ).

Он должен вернуть значение соответствующего атрибута из model_instance этого поля. Имя атрибута находится в self.attname (настраивается Field ).

Поля часто получают свои значения в виде другого типа либо в результате сериализации, либо из форм.

Помимо сохранения в базе данных, поле также должно знать, как сериализовать свое значение:

Возвращает значение поля для данного экземпляра модели.

Преобразует obj в строку. Используется для сериализации значения поля.

Возвращает 4-кортеж с достаточной информацией для воссоздания поля:

Ссылка на атрибут поля ¶

Каждый Field экземпляр содержит несколько атрибутов, позволяющих проанализировать его поведение. Используйте эти атрибуты вместо isinstance проверок, когда вам нужно написать код, зависящий от функциональности поля. Эти атрибуты можно использовать вместе с API Model._meta для сужения поиска определенных типов полей. Эти флаги должны быть реализованы в пользовательских полях модели.

Атрибуты для полей ¶

Логический флаг, указывающий, было ли поле создано автоматически, например, OneToOneField используемое при наследовании модели.

Логический флаг, который указывает, связан ли с полем столбец базы данных.

Options.get_fields() по умолчанию исключает скрытые поля. Передайте, include_hidden=True чтобы вернуть скрытые поля в результатах.

Возвращает модель, в которой определено поле. Если поле определено в суперклассе модели, оно model будет относиться к суперклассу, а не к классу экземпляра.

Атрибуты для полей с отношениями ¶

Эти атрибуты используются для запроса количества элементов и других деталей отношения. Эти атрибуты присутствуют во всех полях; однако они будут иметь только логические значения (а не None ), если поле является типом отношения ( Field.is_relation=True ).

Логический флаг, True указывающий, что поле имеет отношение «многие к одному», например a ForeignKey ; False иначе.

Логический флаг, True указывающий, что поле имеет отношение «один ко многим», например a GenericRelation или обратное a ForeignKey ; False иначе.

Логический флаг, True указывающий, что поле имеет отношение «один к одному», например a OneToOneField ; False иначе.

Источник