Spec-Zone.ru › Django 5.2

Справочник по полям модели

В этом документе содержатся все API-справочные материалы по Field, включая опции полей и типы полей, предлагаемые Django.

См. также

Если встроенные поля не подходят, вы можете попробовать django-localflavor (документация), который содержит различные фрагменты кода, полезные для определенных стран и культур.

Также вы можете легко написать собственные пользовательские поля моделей.

Примечание

Поля определяются в django.db.models.fields, но для удобства они импортируются в django.db.models. Стандартная конвенция заключается в использовании from django.db import models и ссылке на поля как на models.<Foo>Field.

Опции общих полей модели

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

null

Field.null

Если True, Django будет сохранять пустые значения как NULL в базе данных. Значение по умолчанию — False.

Избегайте использования null для строковых полей, таких как CharField и TextField. Конвенция Django заключается в использовании пустой строки, а не NULL, в качестве состояния «нет данных» для строковых полей. Если строковое поле имеет null=False, пустые строки всё равно могут сохраняться для «нет данных». Если строковое поле имеет null=True, это означает, что у него есть два возможных значения для «нет данных»: NULL и пустая строка. В большинстве случаев наличие двух возможных значений для «нет данных» избыточно. Исключением является случай, когда CharField имеет одновременно unique=True и blank=True. В этом случае необходимо установить null=True, чтобы избежать нарушений уникальных ограничений при сохранении нескольких объектов с пустыми значениями.

Для строковых и нестроковых полей также необходимо установить blank=True, если вы хотите разрешить пустые значения в формах, так как параметр null влияет только на хранение в базе данных (см. blank).

Примечание

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

blank

Field.blank

Если True, поле допускает пустые значения. Значение по умолчанию — False.

Обратите внимание, что это отличается от null. null — чисто база данных, а blank — валидация. Если поле имеет blank=True, валидация формы позволит ввести пустое значение. Если поле имеет blank=False, поле является обязательным.

Поставка пропущенных значений

blank=True может использоваться с полями, имеющими null=False, но это потребует реализации clean() в модели для программатической поставки отсутствующих значений.

choices

Field.choices [source]

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

Если задано сопоставление, то первый элемент — фактическое значение, которое будет установлено в модели, а второй — читаемое пользователем имя. Например:

YEAR_IN_SCHOOL_CHOICES = {
    "FR": "Freshman",
    "SO": "Sophomore",
    "JR": "Junior",
    "SR": "Senior",
    "GR": "Graduate",
}

Также можно передать последовательность, состоящую из итерируемых объектов ровно из двух элементов (например, [(A1, B1), (A2, B2), …]). Первый элемент в каждой кортеже — фактическое значение, которое будет установлено в модели, а второй — читаемое пользователем имя. Например:

YEAR_IN_SCHOOL_CHOICES = [
    ("FR", "Freshman"),
    ("SO", "Sophomore"),
    ("JR", "Junior"),
    ("SR", "Senior"),
    ("GR", "Graduate"),
]

choices также может быть определён как вызываемый объект, не принимающий аргументов и возвращающий любой из описанных выше форматов. Например:

def get_currencies():
    return {i: i for i in settings.CURRENCIES}


class Expense(models.Model):
    amount = models.DecimalField(max_digits=10, decimal_places=2)
    currency = models.CharField(max_length=3, choices=get_currencies)

Передача вызываемого объекта для choices особенно полезна, когда, например, варианты являются:

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

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

from django.db import models


class Student(models.Model):
    FRESHMAN = "FR"
    SOPHOMORE = "SO"
    JUNIOR = "JR"
    SENIOR = "SR"
    GRADUATE = "GR"
    YEAR_IN_SCHOOL_CHOICES = {
        FRESHMAN: "Freshman",
        SOPHOMORE: "Sophomore",
        JUNIOR: "Junior",
        SENIOR: "Senior",
        GRADUATE: "Graduate",
    }
    year_in_school = models.CharField(
        max_length=2,
        choices=YEAR_IN_SCHOOL_CHOICES,
        default=FRESHMAN,
    )

    def is_upperclass(self):
        return self.year_in_school in {self.JUNIOR, self.SENIOR}

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

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

MEDIA_CHOICES = {
    "Audio": {
        "vinyl": "Vinyl",
        "cd": "CD",
    },
    "Video": {
        "vhs": "VHS Tape",
        "dvd": "DVD",
    },
    "unknown": "Unknown",
}

Ключом сопоставления является имя, применяемое к группе, а значением — варианты внутри этой группы, состоящие из значения поля и читаемого пользователем имени для варианта. Группированные варианты могут сочетаться с негруппированными вариантами в одном сопоставлении (например, вариант "unknown" в этом примере).

Также можно использовать последовательность, например, список кортежей из 2 элементов:

MEDIA_CHOICES = [
    (
        "Audio",
        (
            ("vinyl", "Vinyl"),
            ("cd", "CD"),
        ),
    ),
    (
        "Video",
        (
            ("vhs", "VHS Tape"),
            ("dvd", "DVD"),
        ),
    ),
    ("unknown", "Unknown"),
]

Обратите внимание, что варианты могут быть любым объектом последовательности — не обязательно списком или кортежем. Это позволяет динамически создавать варианты. Но если вы обнаружите, что взламываете choices, чтобы он был динамичным, вам, вероятно, лучше использовать правильную таблицу базы данных с ForeignKey. choices предназначен для статических данных, которые мало меняются, если вообще меняются.

Примечание

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

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

Если blank=False установлено для поля вместе с default, то будет отображаться метка, содержащая "---------", вместе с выпадающим списком. Чтобы переопределить это поведение, добавьте кортеж в choices, содержащий None; например, (None, 'Your String For Display'). В качестве альтернативы, вы можете использовать пустую строку вместо None, где это имеет смысл — например, в CharField.

Типы перечислений

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

from django.utils.translation import gettext_lazy as _


class Student(models.Model):
    class YearInSchool(models.TextChoices):
        FRESHMAN = "FR", _("Freshman")
        SOPHOMORE = "SO", _("Sophomore")
        JUNIOR = "JR", _("Junior")
        SENIOR = "SR", _("Senior")
        GRADUATE = "GR", _("Graduate")

    year_in_school = models.CharField(
        max_length=2,
        choices=YearInSchool,
        default=YearInSchool.FRESHMAN,
    )

    def is_upperclass(self):
        return self.year_in_school in {
            self.YearInSchool.JUNIOR,
            self.YearInSchool.SENIOR,
        }

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

  • Значения элементов перечисления — кортеж аргументов для использования при построении конкретного типа данных. Django поддерживает добавление дополнительного строкового значения в конец этого кортежа для использования в качестве читаемого пользователем имени, или label. Значение label может быть ленивой переводимой строкой. Таким образом, в большинстве случаев значение элемента будет (value, label) кортежем из 2 элементов. См. ниже пример подклассирования вариантов с более сложным типом данных. Если кортеж не предоставлен или последний элемент не является (ленивой) строкой, label автоматически генерируется из имени элемента.
  • Добавляется свойство .label для значений, возвращающее читаемое пользователем имя.
  • К классам перечислений добавлен ряд пользовательских свойств — .choices, .labels, .values и .names — чтобы упростить доступ к отдельным частям перечисления.

    Предупреждение

    Эти имена свойств нельзя использовать в качестве имён элементов, так как они будут конфликтовать.

  • Использование enum.unique() обязательно для обеспечения того, что значения не могут быть определены несколько раз. Это маловероятно для вариантов поля.

Обратите внимание, что использование YearInSchool.SENIOR, YearInSchool['SENIOR'] или YearInSchool('SR') для доступа или поиска элементов перечисления работает как ожидается, как и свойства .name и .value для элементов.

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

>>> class Vehicle(models.TextChoices):
...     CAR = "C"
...     TRUCK = "T"
...     JET_SKI = "J"
...
>>> Vehicle.JET_SKI.label
'Jet Ski'

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

class Card(models.Model):
    class Suit(models.IntegerChoices):
        DIAMOND = 1
        SPADE = 2
        HEART = 3
        CLUB = 4

    suit = models.IntegerField(choices=Suit)

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

>>> MedalType = models.TextChoices("MedalType", "GOLD SILVER BRONZE")
>>> MedalType.choices
[('GOLD', 'Gold'), ('SILVER', 'Silver'), ('BRONZE', 'Bronze')]
>>> Place = models.IntegerChoices("Place", "FIRST SECOND THIRD")
>>> Place.choices
[(1, 'First'), (2, 'Second'), (3, 'Third')]

Если вам требуется поддержка конкретного типа данных, отличного от int или str, вы можете подклассировать Choices и требуемый конкретный тип данных, например, date для использования с DateField:

class MoonLandings(datetime.date, models.Choices):
    APOLLO_11 = 1969, 7, 20, "Apollo 11 (Eagle)"
    APOLLO_12 = 1969, 11, 19, "Apollo 12 (Intrepid)"
    APOLLO_14 = 1971, 2, 5, "Apollo 14 (Antares)"
    APOLLO_15 = 1971, 7, 30, "Apollo 15 (Falcon)"
    APOLLO_16 = 1972, 4, 21, "Apollo 16 (Orion)"
    APOLLO_17 = 1972, 12, 11, "Apollo 17 (Challenger)"

Есть некоторые дополнительные оговорки, о которых следует знать:

  • Типы перечислений не поддерживают именованные группы.
  • Поскольку перечисление с конкретным типом данных требует, чтобы все значения соответствовали типу, переопределение метки пустого значения не может быть достигнуто созданием элемента со значением None. Вместо этого установите атрибут __empty__ в классе:

    class Answer(models.IntegerChoices):
        NO = 0, _("No")
        YES = 1, _("Yes")
    
        __empty__ = _("(Unknown)")
    

db_column

Field.db_column

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

Если имя столбца в вашей базе данных является зарезервированным словом SQL или содержит символы, которые недопустимы в именах переменных Python — в частности, дефис — это нормально. Django цитирует имена столбцов и таблиц за кулисами.

db_comment

Field.db_comment

Комментарий к столбцу базы данных для использования с этим полем. Он полезен для документирования полей для лиц с прямым доступом к базе данных, которые могут не смотреть на ваш код Django. Например:

pub_date = models.DateTimeField(
    db_comment="Date and time when the article was published",
)

db_default

Field.db_default

Значение по умолчанию, вычисляемое базой данных для этого поля. Оно может быть литеральным значением или функцией базы данных, такой как Now:

created = models.DateTimeField(db_default=Now())

Можно использовать более сложные выражения, если они составлены из литералов и функций базы данных:

month_due = models.DateField(
    db_default=TruncMonth(
        Now() + timedelta(days=90),
        output_field=models.DateField(),
    )
)

Значения по умолчанию базы данных не могут ссылаться на другие поля или модели. Например, это некорректно:

end = models.IntegerField(db_default=F("start") + 50)

Если оба db_default и Field.default установлены, default будет иметь приоритет при создании экземпляров в коде Python. db_default всё ещё будет установлено на уровне базы данных и будет использоваться при вставке строк вне ORM или при добавлении нового поля в миграцию.

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

db_index

Field.db_index

Если True, для этого поля будет создан индекс базы данных.

Используйте параметр indexes вместо этого.

Если возможно, используйте параметр Meta.indexes вместо этого. Почти во всех случаях indexes предоставляет больше функциональности, чем db_index. db_index может быть устаревшим в будущем.

db_tablespace

Field.db_tablespace [source]

Имя пространства имён базы данных, которое нужно использовать для индекса этого поля, если это поле индексировано. По умолчанию используется значение проекта DEFAULT_INDEX_TABLESPACE, если оно задано, или db_tablespace модели, если задано. Если бэкенд не поддерживает пространства имён для индексов, этот параметр игнорируется.

default

Field.default

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

Значение по умолчанию не может быть изменяемым объектом (экземпляр модели, list, set и т. д.), так как ссылка на тот же экземпляр объекта будет использоваться в качестве значения по умолчанию для всех новых экземпляров модели. Вместо этого оберните желаемое значение по умолчанию в вызываемый объект. Например, если вы хотите указать значение по умолчанию dict для JSONField, используйте функцию:

def contact_default():
    return {"email": "to1@example.com"}


contact_info = JSONField("ContactInfo", default=contact_default)

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

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

Значение по умолчанию используется при создании новых экземпляров моделей, если для поля не указано значение. Когда поле является первичным ключом, значение по умолчанию также используется, когда поле установлено в None.

Значение по умолчанию также может быть установлено на уровне базы данных с помощью Field.db_default.

editable

Field.editable

Если False, поле не будет отображаться в админке или других ModelForm. Оно также будет пропущено при валидации модели. По умолчанию True.

error_messages

Field.error_messages [source]

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

Ключи сообщений об ошибках включают null, blank, invalid, invalid_choice, unique и unique_for_date. Дополнительные ключи сообщений об ошибках указаны для каждого поля в разделе Типы полей ниже.

Эти сообщения об ошибках часто не распространяются на формы. См. Рекомендации относительно model’s error_messages.

help_text

Field.help_text

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

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

help_text = "Please use the following format: <em>YYYY-MM-DD</em>."

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

primary_key

Field.primary_key

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

Если вы не зададите primary_key=True для какого-либо поля в своей модели и не определили составной первичный ключ, Django автоматически добавит поле для хранения первичного ключа. Поэтому вам не нужно устанавливать primary_key=True ни для одного из ваших полей, если вы не хотите переопределить поведение первичного ключа по умолчанию. Тип автоматически созданных полей первичного ключа может быть указан для каждой приложения в AppConfig.default_auto_field или глобально в настройке DEFAULT_AUTO_FIELD. Более подробная информация приведена в Автоматически создаваемые поля первичного ключа.

primary_key=True подразумевает null=False и unique=True. Только одно поле в модели может установить primary_key=True. Составные первичные ключи должны быть определены с помощью CompositePrimaryKey вместо установки этого флага в True для всех полей, чтобы сохранить это условие.

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

Поле первичного ключа устанавливается в None при deleting объекта.

Изменено в Django 5.2:

Поле CompositePrimaryKey было добавлено.

unique

Field.unique [source]

Если True, это поле должно быть уникальным в рамках всей таблицы.

Это обеспечивается на уровне базы данных и проверкой модели. Если вы попытаетесь сохранить модель с дублирующимся значением в поле unique, модель поднимет исключение django.db.IntegrityError в методе save().

Этот параметр допустим для всех типов полей, кроме ManyToManyField и OneToOneField.

Обратите внимание, что когда unique имеет значение True, вам не нужно указывать db_index, так как unique подразумевает создание индекса.

unique_for_date

Field.unique_for_date

Установите это значение в имя поля DateField или DateTimeField, чтобы потребовать, чтобы это поле было уникальным для значения даты в поле.

Например, если у вас есть поле title, которое имеет unique_for_date="pub_date", то Django не позволит ввести две записи с одинаковым title и pub_date.

Обратите внимание, что если вы зададите это значение для DateTimeField, будет учитываться только дата. Кроме того, когда USE_TZ имеет значение True, проверка будет выполнена в текущем часовом поясе в момент сохранения объекта.

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

unique_for_month

Field.unique_for_month

Аналогично unique_for_date, но требует, чтобы поле было уникальным относительно месяца.

unique_for_year

Field.unique_for_year

Аналогично unique_for_date и unique_for_month.

verbose_name

Field.verbose_name

Человекопонятное имя для поля. Если имя не указано, Django автоматически создаст его, используя имя атрибута поля, преобразуя подчеркивания в пробелы. См. Имена полей с понятным смыслом.

validators

Field.validators [source]

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

Типы полей

AutoField

class AutoField(**options) [source]

Поле IntegerField, которое автоматически увеличивается в соответствии с доступными идентификаторами. Обычно вам не нужно использовать его напрямую; поле первичного ключа автоматически добавляется в вашу модель, если вы не укажете иначе. См. Автоматические поля первичного ключа.

BigAutoField

class BigAutoField(**options) [source]

64-битное целое число, аналогичное AutoField, но гарантированно вмещает числа от 1 до 9223372036854775807.

BigIntegerField

class BigIntegerField(**options) [source]

64-битное целое число, аналогичное IntegerField, но гарантированно вмещает числа от -9223372036854775808 до 9223372036854775807. Поле по умолчанию представлено виджетом NumberInput.

BinaryField

class BinaryField(max_length=None, **options) [source]

Поле для хранения данных в бинарном формате. Ему можно присвоить bytes, bytearray или memoryview.

По умолчанию, BinaryField устанавливает editable в False, в этом случае оно не может быть включено в ModelForm.

BinaryField.max_length

Необязательно. Максимальная длина (в байтах) поля. Максимальная длина проверяется в Django с помощью MaxLengthValidator.

Использование BinaryField

Хотя вы можете подумать о хранении файлов в базе данных, имейте в виду, что в 99% случаев это плохой дизайн. Это поле не заменяет правильную обработку статических файлов.

BooleanField

class BooleanField(**options) [source]

Поле true/false.

Поле по умолчанию представлено виджетом CheckboxInput или NullBooleanSelect, если null=True.

Значение по умолчанию для BooleanField — None, если Field.default не определено.

CompositePrimaryKey

Новое в Django 5.2.
class CompositePrimaryKey(*field_names, **options) [source]

Виртуальное поле, используемое для определения составного первичного ключа.

Это поле должно быть определено как атрибут pk модели. Если оно присутствует, Django создаст базу данных модели с составным первичным ключом.

Аргумент *field_names — список позиционных имён полей, составляющих первичный ключ.

См. Составные первичные ключи для получения более подробной информации.

CharField

class CharField(max_length=None, **options) [source]

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

Для больших объёмов текста используйте TextField.

Поле по умолчанию представлено виджетом TextInput.

CharField имеет следующие дополнительные аргументы:

CharField.max_length

Максимальная длина (в символах) поля. Максимальная длина проверяется на уровне базы данных и в валидации Django с помощью MaxLengthValidator. Она требуется для всех баз данных, поставляемых с Django, кроме PostgreSQL и SQLite, которые поддерживают столбцы неограниченной длины VARCHAR.

Примечание

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

Изменено в Django 5.2:

Добавлена поддержка столбцов неограниченной длины VARCHAR для SQLite.

CharField.db_collation

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

Примечание

Имена сортировки не стандартизированы. Поэтому они не будут переносимы на разные базы данных.

Oracle

Oracle поддерживает сортировки только при установке параметра инициализации базы данных MAX_STRING_SIZE на значение EXTENDED.

DateField

class DateField(auto_now=False, auto_now_add=False, **options) [source]

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

DateField.auto_now

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

Поле обновляется только при вызове Model.save(). Поле не обновляется при внесении изменений в другие поля другими способами, такими как QuerySet.update(), хотя вы можете указать пользовательское значение для поля в таком обновлении.

DateField.auto_now_add

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

  • Для DateField: default=date.today - из datetime.date.today()
  • Для DateTimeField: default=timezone.now - из django.utils.timezone.now()

По умолчанию виджет для этого поля — DateInput. В админке добавляется календарь JavaScript и ярлык «Сегодня». Включает дополнительный invalid_date ключ сообщения об ошибке.

Опции auto_now_add, auto_now и default взаимоисключающие. Любая комбинация этих опций приведёт к ошибке.

Примечание

В текущей реализации установка auto_now или auto_now_add в True приведет к установке editable=False и blank=True для поля.

Примечание

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

Предупреждение

Всегда используйте DateField с объектом класса datetime.date.

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

DateTimeField

class DateTimeField(auto_now=False, auto_now_add=False, **options) [source]

Дата и время, представленные в Python объектом класса datetime.datetime. Принимает те же дополнительные аргументы, что и DateField.

По умолчанию виджет для этого поля — DateTimeInput. В админке используются два отдельных виджета TextInput с JavaScript-ярлыками.

Предупреждение

Всегда используйте DateTimeField с объектом класса datetime.datetime.

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

DecimalField

class DecimalField(max_digits=None, decimal_places=None, **options) [source]

Десятичное число с фиксированной точностью, представленное в Python объектом класса Decimal. Проверка ввода выполняется с помощью DecimalValidator.

Имеет следующие обязательные аргументы:

DecimalField.max_digits

Максимальное количество цифр в числе. Обратите внимание, что это число должно быть больше или равно decimal_places.

DecimalField.decimal_places

Количество десятичных знаков для хранения числа.

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

models.DecimalField(..., max_digits=5, decimal_places=2)

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

models.DecimalField(..., max_digits=19, decimal_places=10)

По умолчанию виджет для этого поля — NumberInput, если localize равно False, или TextInput в противном случае.

Примечание

Дополнительную информацию о различиях между классами FloatField и DecimalField см. в разделе FloatField vs. DecimalField. Также следует учитывать ограничения SQLite для десятичных полей.

DurationField

class DurationField(**options) [source]

Поле для хранения периодов времени, моделируемых в Python классом timedelta. При использовании с PostgreSQL используется тип данных interval, а с Oracle — INTERVAL DAY(9) TO SECOND(6). В противном случае используется bigint микросекунд.

Примечание

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

EmailField

class EmailField(max_length=254, **options) [source]

Поле CharField, которое проверяет, является ли значение корректным адресом электронной почты, используя EmailValidator.

FileField

class FileField(upload_to='', storage=None, max_length=100, **options) [source]

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

Примечание

Аргумент primary_key не поддерживается и при его использовании будет выдано сообщение об ошибке.

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

FileField.upload_to

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

Если вы укажете строковое значение или объект Path, он может содержать форматирование strftime(), которое будет заменено датой/временем загрузки файла (чтобы загруженные файлы не заполняли указанный каталог). Например:

class MyModel(models.Model):
    # file will be uploaded to MEDIA_ROOT/uploads
    upload = models.FileField(upload_to="uploads/")
    # or...
    # file will be saved to MEDIA_ROOT/uploads/2015/01/30
    upload = models.FileField(upload_to="uploads/%Y/%m/%d/")

Если используется по умолчанию FileSystemStorage, строковое значение будет добавлен к пути MEDIA_ROOT, чтобы сформировать расположение на локальной файловой системе, где будут храниться загруженные файлы. Если используется другой механизм хранения, обратитесь к документации этого механизма, чтобы узнать, как он обрабатывает upload_to.

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

Аргумент

Описание

instance

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

В большинстве случаев этот объект еще не был сохранен в базе данных, поэтому, если он использует значение по умолчанию AutoField, у него может еще не быть значения для поля первичного ключа.

filename

Исходное имя файла. Это может или не может учитываться при определении конечного пути.

Например:

def user_directory_path(instance, filename):
    # file will be uploaded to MEDIA_ROOT/user_<id>/<filename>
    return "user_{0}/{1}".format(instance.user.id, filename)


class MyModel(models.Model):
    upload = models.FileField(upload_to=user_directory_path)
FileField.storage

Объект хранилища или вызываемый объект, возвращающий объект хранилища. Он обрабатывает хранение и извлечение файлов. Подробности о предоставлении этого объекта см. в разделе Управление файлами.

Поле по умолчанию — виджет формы ClearableFileInput.

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

  1. В файле настроек необходимо определить MEDIA_ROOT как полный путь к каталогу, где Django должен хранить загруженные файлы. (Для повышения производительности эти файлы не хранятся в базе данных.) Определите MEDIA_URL как базовый публичный URL этого каталога. Убедитесь, что этот каталог доступен для записи учетной записью веб-сервера.
  2. Добавьте FileField или ImageField в свою модель, задав параметр upload_to, чтобы указать подкаталог MEDIA_ROOT для использования загруженных файлов.
  3. В базу данных будет сохраняться только путь к файлу (относительно MEDIA_ROOT). Вероятно, вам потребуется использовать удобный атрибут url, предоставляемый Django. Например, если ваше ImageField называется mug_shot, вы можете получить абсолютный путь к вашему изображению в шаблоне с помощью {{ object.mug_shot.url }}.

Например, предположим, что MEDIA_ROOT установлено в '/home/media', а upload_to установлено в 'photos/%Y/%m/%d'. Часть '%Y/%m/%d' upload_to — это форматирование strftime(); '%Y' — это четырехзначный год, '%m' — двузначный месяц, а '%d' — двузначный день. Если вы загрузите файл 15 января 2007 года, он будет сохранен в каталоге /home/media/photos/2007/01/15.

Если вам нужно получить имя файла загруженного файла в файловой системе или его размер, можно использовать атрибуты name и size соответственно; для получения дополнительной информации об имеющихся атрибутах и методах см. справку по классу File и руководство по теме Управление файлами.

Примечание

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

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

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

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

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

FileField и FieldFile

class FieldFile [source]

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

API FieldFile аналогичен API File, с одним ключевым отличием: объект, обернутый классом, необязательно является обёрткой вокруг встроенного в Python объекта файла. Вместо этого это обёртка вокруг результата метода Storage.open(), который может быть объектом File, или реализацией API File пользовательского хранилища.

В дополнение к API, унаследованному от File, например, read() и write(), FieldFile включает несколько методов для взаимодействия с базовым файлом:

Предупреждение

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

FieldFile.name

Имя файла, включая относительный путь от корня хранилища Storage связанного FileField.

FieldFile.path [source]

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

FieldFile.size [source]

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

FieldFile.url [source]

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

FieldFile.open(mode='rb') [source]

Открывает или повторно открывает файл, связанный с этим экземпляром, в указанном mode. В отличие от стандартного метода Python open(), он не возвращает дескриптор файла.

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

FieldFile.close() [source]

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

FieldFile.save(name, content, save=True) [source]

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

Принимает два обязательных аргумента: name, которое является именем файла, и content, которое является объектом, содержащим содержимое файла. Необязательный аргумент save управляет тем, сохраняется ли экземпляр модели после изменения файла, связанного с этим полем. По умолчанию True.

Обратите внимание, что аргумент content должен быть экземпляром django.core.files.File, а не встроенным объектом файла Python. Вы можете создать File из существующего объекта файла Python так:

from django.core.files import File

# Open an existing file using Python's built-in open()
f = open("/path/to/hello.world")
myfile = File(f)

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

from django.core.files.base import ContentFile

myfile = ContentFile("hello world")

Дополнительную информацию можно найти в Управление файлами.

FieldFile.delete(save=True) [source]

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

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

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

FilePathField

class FilePathField(path='', match=None, recursive=False, allow_files=True, allow_folders=False, max_length=100, **options) [source]

A CharField whose choices are limited to the filenames in a certain directory on the file system. Has some special arguments, of which the first is required:

FilePathField.path

Required. The absolute file system path to a directory from which this FilePathField should get its choices. Example: "/home/images".

path may also be a callable, such as a function to dynamically set the path at runtime. Example:

import os
from django.conf import settings
from django.db import models


def images_path():
    return os.path.join(settings.LOCAL_FILE_DIR, "images")


class MyModel(models.Model):
    file = models.FilePathField(path=images_path)
FilePathField.match

Optional. A regular expression, as a string, that FilePathField will use to filter filenames. Note that the regex will be applied to the base filename, not the full path. Example: "foo.*\.txt$", which will match a file called foo23.txt but not bar.txt or foo23.png.

FilePathField.recursive

Optional. Either True or False. Default is False. Specifies whether all subdirectories of path should be included

FilePathField.allow_files

Optional. Either True or False. Default is True. Specifies whether files in the specified location should be included. Either this or allow_folders must be True.

FilePathField.allow_folders

Optional. Either True or False. Default is False. Specifies whether folders in the specified location should be included. Either this or allow_files must be True.

The one potential gotcha is that match applies to the base filename, not the full path. So, this example:

FilePathField(path="/home/images", match="foo.*", recursive=True)

…will match /home/images/foo.png but not /home/images/foo/bar.png because the match applies to the base filename (foo.png and bar.png).

FilePathField instances are created in your database as varchar columns with a default maximum length of 100 characters. As with other fields, you can change the maximum length using the max_length argument.

FloatField

class FloatField(**options) [source]

A floating-point number represented in Python by a float instance.

The default form widget for this field is a NumberInput when localize is False or TextInput otherwise.

FloatField vs. DecimalField

The FloatField class is sometimes mixed up with the DecimalField class. Although they both represent real numbers, they represent those numbers differently. FloatField uses Python’s float type internally, while DecimalField uses Python’s Decimal type. For information on the difference between the two, see Python’s documentation for the decimal module.

GeneratedField

class GeneratedField(expression, output_field, db_persist=None, **kwargs) [source]

A field that is always computed based on other fields in the model. This field is managed and updated by the database itself. Uses the GENERATED ALWAYS SQL syntax.

There are two kinds of generated columns: stored and virtual. A stored generated column is computed when it is written (inserted or updated) and occupies storage as if it were a regular column. A virtual generated column occupies no storage and is computed when it is read. Thus, a virtual generated column is similar to a view and a stored generated column is similar to a materialized view.

GeneratedField.expression

An Expression used by the database to automatically set the field value each time the model is changed.

The expressions should be deterministic and only reference fields within the model (in the same database table). Generated fields cannot reference other generated fields. Database backends can impose further restrictions.

GeneratedField.output_field

A model field instance to define the field’s data type.

GeneratedField.db_persist

Determines if the database column should occupy storage as if it were a real column. If False, the column acts as a virtual column and does not occupy database storage space.

PostgreSQL only supports persisted columns. Oracle only supports virtual columns.

Refresh the data

Since the database computes the value, the object must be reloaded to access the new value after save(), for example, by using refresh_from_db().

Database limitations

There are many database-specific restrictions on generated fields that Django doesn’t validate and the database may raise an error e.g. PostgreSQL requires functions and operators referenced in a generated column to be marked as IMMUTABLE.

You should always check that expression is supported on your database. Check out MariaDB, MySQL, Oracle, PostgreSQL, or SQLite docs.

GenericIPAddressField

class GenericIPAddressField(protocol='both', unpack_ipv4=False, **options) [source]

Адрес IPv4 или IPv6 в строковом формате (например, 192.0.2.30 или 2a02:42fe::4). По умолчанию для этого поля используется виджет TextInput.

Нормализация адресов IPv6 следует RFC 4291 Раздел 2.2, включая использование формата IPv4, предложенного в абзаце 3 этого раздела, например, ::ffff:192.0.2.0. Например, 2001:0::0:01 будет нормализован до 2001::1, а ::ffff:0a0a:0a0a до ::ffff:10.10.10.10. Все символы приводятся к нижнему регистру.

GenericIPAddressField.protocol

Ограничивает допустимые вводимые значения указанным протоколом. Допустимые значения — 'both' (по умолчанию), 'IPv4' или 'IPv6'. Сопоставление не учитывает регистр.

GenericIPAddressField.unpack_ipv4

Распаковывает адреса IPv4, например, ::ffff:192.0.2.1. Если этот параметр включен, указанный адрес будет распакован до 192.0.2.1. По умолчанию отключен. Может быть использован только при установке protocol в 'both'.

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

ImageField

class ImageField(upload_to=None, height_field=None, width_field=None, max_length=100, **options) [source]

Наследует все атрибуты и методы из FileField, но также проверяет, является ли загруженный объект допустимым изображением.

В дополнение к специальным атрибутам, доступным для FileField, ImageField также имеет атрибуты height и width.

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

ImageField.height_field

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

ImageField.width_field

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

Требует библиотеку pillow.

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

По умолчанию для этого поля используется виджет ClearableFileInput.

IntegerField

class IntegerField(**options) [source]

Целое число. Значения от -2147483648 до 2147483647 безопасны во всех базах данных, поддерживаемых Django.

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

По умолчанию для этого поля используется виджет NumberInput, если localize равно False, или TextInput в противном случае.

JSONField

class JSONField(encoder=None, decoder=None, **options) [source]

Поле для хранения данных, закодированных в формате JSON. В Python данные представлены в собственном формате Python: словари, списки, строки, числа, логические значения и None.

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

JSONField.encoder

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

По умолчанию json.JSONEncoder.

JSONField.decoder

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

По умолчанию json.JSONDecoder.

Для запроса JSONField в базе данных см. Запрос JSONField.

Значение по умолчанию

Если вы задаёте для поля default, убедитесь, что это вызываемый объект, такой как класс dict или функция, возвращающая новый объект каждый раз. Неправильное использование изменяемого объекта, такого как default={} или default=[], создаёт изменяемый параметр по умолчанию, который общий для всех экземпляров.

Индексирование

Index и Field.db_index оба создают индекс B-дерева, что не очень полезно при запросе к JSONField. Только в PostgreSQL можно использовать GinIndex, который более подходит.

Пользователи PostgreSQL

PostgreSQL имеет два собственных типа данных на основе JSON: json и jsonb. Основное различие между ними заключается в том, как они хранятся и как к ним можно обратиться. Поле json PostgreSQL хранится как исходное строковое представление JSON и должно быть декодировано на лету при запросе по ключам. Поле jsonb хранится на основе фактической структуры JSON, что позволяет использовать индексирование. Компромисс заключается в небольшой дополнительной стоимости записи в поле jsonb. JSONField использует jsonb.

Пользователи Oracle

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

PositiveBigIntegerField

class PositiveBigIntegerField(**options) [source]

Подобно PositiveIntegerField, но допускает только значения, меньшие определённого (зависимого от базы данных) предела. Значения от 0 до 9223372036854775807 безопасны во всех базах данных, поддерживаемых Django.

PositiveIntegerField

class PositiveIntegerField(**options) [source]

Подобно IntegerField, но должно быть положительным или нулевым (0). Значения от 0 до 2147483647 безопасны во всех базах данных, поддерживаемых Django. Значение 0 принимается для обеспечения обратной совместимости.

PositiveSmallIntegerField

class PositiveSmallIntegerField(**options) [source]

Подобно PositiveIntegerField, но допускает только значения, меньшие определённого (зависимого от базы данных) предела. Значения от 0 до 32767 безопасны во всех базах данных, поддерживаемых Django.

SlugField

class SlugField(max_length=50, **options) [source]

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

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

Подразумевает установку Field.db_index в True.

Часто бывает полезно автоматически заполнять SlugField на основе значения другого поля. Вы можете сделать это автоматически в админке, используя prepopulated_fields.

Использует validate_slug или validate_unicode_slug для проверки.

SlugField.allow_unicode

Если True, поле принимает Unicode-символы помимо ASCII. Значение по умолчанию — False.

SmallAutoField

class SmallAutoField(**options) [source]

Подобно AutoField, но допускает только значения, меньшие определённого (зависимого от базы данных) предела. Значения от 1 до 32767 безопасны во всех базах данных, поддерживаемых Django.

SmallIntegerField

class SmallIntegerField(**options) [source]

Подобно IntegerField, но допускает только значения, меньшие определённого (зависимого от базы данных) предела. Значения от -32768 до 32767 безопасны во всех базах данных, поддерживаемых Django.

TextField

class TextField(**options) [source]

Поле для хранения большого объёма текста. По умолчанию для этого поля используется виджет Textarea.

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

TextField.db_collation

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

Примечание

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

Oracle

Oracle не поддерживает сортировки для TextField.

TimeField

class TimeField(auto_now=False, auto_now_add=False, **options) [source]

Время, представленное в Python объектом типа datetime.time. Поддерживает те же параметры автоматического заполнения, что и DateField.

По умолчанию для этого поля используется виджет TimeInput. В админке добавлены некоторые JavaScript-короткоходы.

URLField

class URLField(max_length=200, **options) [source]

A CharField для URL, проверенный с помощью URLValidator.

По умолчанию для этого поля используется виджет URLInput.

Как и все подклассы CharField, URLField принимает необязательный аргумент max_length. Если max_length не указан, используется значение по умолчанию — 200.

UUIDField

class UUIDField(**options) [source]

Поле для хранения универсальных идентификаторов. Использует класс Python UUID. При использовании с PostgreSQL и MariaDB 10.7+, хранится в типе данных uuid, в противном случае в типе char(32).

Универсальные идентификаторы — хорошая альтернатива полю AutoField для primary_key. База данных не сгенерирует UUID за вас, поэтому рекомендуется использовать default:

import uuid
from django.db import models


class MyUUIDModel(models.Model):
    id = models.UUIDField(primary_key=True, default=uuid.uuid4, editable=False)
    # other fields

Обратите внимание, что вызываемый объект (с опущенными скобками) передается в default, а не экземпляр UUID.

Поиск в PostgreSQL и MariaDB 10.7+

Использование iexact, contains, icontains, startswith, istartswith, endswith или iendswith запросы в PostgreSQL не работают для значений без дефисов, поскольку PostgreSQL и MariaDB 10.7+ хранят их в типе данных uuid с дефисами.

Связанные поля

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

ForeignKey

class ForeignKey(to, on_delete, **options) [source]

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

from django.db import models


class Manufacturer(models.Model):
    name = models.TextField()


class Car(models.Model):
    manufacturer = models.ForeignKey(Manufacturer, on_delete=models.CASCADE)

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

Подробности о втором позиционном аргументе см. в ForeignKey.on_delete.

Индекс базы данных автоматически создается для ForeignKey. Можно отключить это, установив db_index в False. Возможно, следует избегать накладных расходов на индекс, если вы создаете внешний ключ для согласованности, а не для соединений, или если вы будете создавать альтернативный индекс, такой как частичный или индекс по нескольким столбцам.

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

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

Аргументы

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

ForeignKey.on_delete

Когда объект, на который ссылается ForeignKey, удаляется, Django эмулирует поведение SQL-ограничения, указанного аргументом on_delete. Например, если у вас есть nullable ForeignKey и вы хотите, чтобы он был установлен в null при удалении связанного объекта:

user = models.ForeignKey(
    User,
    models.SET_NULL,
    blank=True,
    null=True,
)

on_delete не создаёт SQL-ограничение в базе данных. Поддержка опций каскадного удаления на уровне базы данных может быть реализована позднее.

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

  • CASCADE [source]

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

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

  • PROTECT [source]

    Запрещает удаление связанного объекта, вызывая ProtectedError, подкласс django.db.IntegrityError.

  • RESTRICT [source]

    Запрещает удаление связанного объекта, вызывая RestrictedError (подкласс django.db.IntegrityError). В отличие от PROTECT, удаление связанного объекта разрешено, если оно также ссылается на другой объект, который удаляется в той же операции, но через отношение CASCADE.

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

    class Artist(models.Model):
        name = models.CharField(max_length=10)
    
    
    class Album(models.Model):
        artist = models.ForeignKey(Artist, on_delete=models.CASCADE)
    
    
    class Song(models.Model):
        artist = models.ForeignKey(Artist, on_delete=models.CASCADE)
        album = models.ForeignKey(Album, on_delete=models.RESTRICT)
    

    Artist может быть удалён, даже если это подразумевает удаление Album, на который ссылается Song, потому что Song также ссылается на Artist через каскадное отношение. Например:

    >>> artist_one = Artist.objects.create(name="artist one")
    >>> artist_two = Artist.objects.create(name="artist two")
    >>> album_one = Album.objects.create(artist=artist_one)
    >>> album_two = Album.objects.create(artist=artist_two)
    >>> song_one = Song.objects.create(artist=artist_one, album=album_one)
    >>> song_two = Song.objects.create(artist=artist_one, album=album_two)
    >>> album_one.delete()
    # Raises RestrictedError.
    >>> artist_two.delete()
    # Raises RestrictedError.
    >>> artist_one.delete()
    (4, {'Song': 2, 'Album': 1, 'Artist': 1})
    
  • SET_NULL [source]

    Установить ForeignKey в null; это возможно только если null равно True.

  • SET_DEFAULT [source]

    Установить ForeignKey в его значение по умолчанию; значение по умолчанию для ForeignKey должно быть задано.

  • SET() [source]

    Установить ForeignKey в значение, переданное SET(), или, если передано вызываемый объект, результат вызова этого объекта. В большинстве случаев, передача вызываемого объекта потребуется, чтобы избежать выполнения запросов во время импорта вашего models.py:

    from django.conf import settings
    from django.contrib.auth import get_user_model
    from django.db import models
    
    
    def get_sentinel_user():
        return get_user_model().objects.get_or_create(username="deleted")[0]
    
    
    class MyModel(models.Model):
        user = models.ForeignKey(
            settings.AUTH_USER_MODEL,
            on_delete=models.SET(get_sentinel_user),
        )
    
  • DO_NOTHING [source]

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

ForeignKey.limit_choices_to

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

Например:

staff_member = models.ForeignKey(
    User,
    on_delete=models.CASCADE,
    limit_choices_to={"is_staff": True},
)

приводит к тому, что соответствующее поле в ModelForm отображает только Users, у которых есть is_staff=True. Это может быть полезно в Django админке.

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

def limit_pub_date_choices():
    return {"pub_date__lte": datetime.date.today()}


limit_choices_to = limit_pub_date_choices

Если limit_choices_to есть или возвращает объект Q object, что полезно для сложных запросов, тогда это повлияет только на доступные варианты в админке, когда поле не указано в raw_id_fields в ModelAdmin для модели.

Примечание

Если для limit_choices_to используется вызываемый объект, он будет вызываться каждый раз, когда создаётся новая форма. Он также может быть вызван при валидации модели, например, командными утилитами или админкой. Админка строит наборы запросов для валидации входных данных формы в различных крайних случаях несколько раз, поэтому существует вероятность, что ваш вызываемый объект может быть вызван несколько раз.

ForeignKey.related_name

Имя, используемое для связи от связанного объекта обратно к этому. Также является значением по умолчанию для related_query_name (имя для фильтра обратной связи от целевой модели). См. документацию по связанным объектам для полного объяснения и примера. Обратите внимание, что вы должны задать это значение при определении связей в абстрактных моделях; и когда вы это делаете, доступна некоторое специальное синтаксис.

Если вы хотите, чтобы Django не создавал обратную связь, установите related_name в '+' или закончите его '+'. Например, это гарантирует, что модель User не будет иметь обратную связь с этой моделью:

user = models.ForeignKey(
    User,
    on_delete=models.CASCADE,
    related_name="+",
)
ForeignKey.related_query_name

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

# Declare the ForeignKey with related_query_name
class Tag(models.Model):
    article = models.ForeignKey(
        Article,
        on_delete=models.CASCADE,
        related_name="tags",
        related_query_name="tag",
    )
    name = models.CharField(max_length=255)


# That's now the name of the reverse filter
Article.objects.filter(tag__name="important")

Как и related_name, related_query_name поддерживает интерполяцию имени приложения и класса с помощью специального синтаксиса.

ForeignKey.to_field

Поле в связанном объекте, к которому относится отношение. По умолчанию Django использует первичный ключ связанного объекта. Если вы ссылаетесь на другое поле, это поле должно иметь unique=True.

ForeignKey.db_constraint

Управляет созданием ограничения в базе данных для данного внешнего ключа. По умолчанию значение True, и это почти наверняка то, что вам нужно; установка этого значения в False может быть очень вредной для целостности данных. Тем не менее, вот некоторые сценарии, где вам может потребоваться это сделать:

  • У вас есть устаревшие данные, которые неверны.
  • Вы фрагментируете свою базу данных.

Если это значение установлено в False, обращение к связанному объекту, которого не существует, вызовет исключение DoesNotExist.

ForeignKey.swappable

Управляет реакцией механизма миграции, если этот ForeignKey указывает на взаимозаменяемую модель. Если это значение True — значение по умолчанию — то, если ForeignKey указывает на модель, которая соответствует текущему значению settings.AUTH_USER_MODEL (или другому значению взаимозаменяемой модели), отношение будет сохранено в миграции с ссылкой на параметр, а не на модель напрямую.

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

Установка значения в False не означает, что вы можете ссылаться на взаимозаменяемую модель, даже если она заменена — False означает, что миграции, сделанные с этим ForeignKey, всегда будут ссылаться на конкретную модель, которую вы указали (так что это приведет к ошибке, если пользователь попытается выполнить запуск с моделью User, которую вы не поддерживаете, например).

Если сомневаетесь, оставьте значение по умолчанию True.

ManyToManyField

class ManyToManyField(to, **options) [source]

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

Связанные объекты можно добавлять, удалять или создавать с помощью RelatedManager поля.

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

За кулисами Django создает промежуточную таблицу соединения для представления связи многие-ко-многим. По умолчанию имя этой таблицы генерируется с использованием имени поля многие-ко-многим и имени таблицы для модели, которая его содержит. Поскольку некоторые базы данных не поддерживают имена таблиц длиннее определенного предела, эти имена таблиц будут автоматически урезаны, и будет использоваться хэш уникальности, например author_books_9cdf. Вы можете вручную указать имя таблицы соединения, используя параметр db_table.

Аргументы

ManyToManyField принимает дополнительный набор аргументов — все необязательные — которые контролируют, как работает отношение.

ManyToManyField.related_name

То же, что и ForeignKey.related_name.

ManyToManyField.related_query_name

То же, что и ForeignKey.related_query_name.

ManyToManyField.limit_choices_to

То же, что и ForeignKey.limit_choices_to.

ManyToManyField.symmetrical

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

from django.db import models


class Person(models.Model):
    friends = models.ManyToManyField("self")

Когда Django обрабатывает эту модель, он определяет, что у неё есть ManyToManyField на себе, и в результате не добавляет атрибут person_set к классу Person. Вместо этого, ManyToManyField предполагается симметричным — то есть, если я твой друг, значит ты мой друг.

Если вам не нужна симметрия во взаимоотношениях многие-ко-многим с self, установите symmetrical в False. Это принудит Django добавить дескриптор для обратного отношения, позволяя отношениям ManyToManyField быть несимметричными.

ManyToManyField.through

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

Наиболее распространённое использование этой опции — когда вы хотите связать дополнительные данные с отношением многие-ко-многим.

Примечание

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

Примечание

Рекурсивные отношения с использованием промежуточной модели не могут определить имена обратных аксессоров, так как они будут одинаковыми. Вам нужно установить related_name хотя бы для одного из них. Если вы хотите, чтобы Django не создавал обратное отношение, установите related_name в '+'.

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

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

  • id: первичный ключ отношения.
  • <containing_model>_id: id модели, которая объявляет ManyToManyField.
  • <other_model>_id: id модели, к которой ManyToManyField указывает.

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

  • id: первичный ключ отношения.
  • from_<model>_id: id экземпляра, который указывает на модель (то есть исходный экземпляр).
  • to_<model>_id: id экземпляра, на который указывает отношение (то есть экземпляр целевой модели).

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

Model.m2mfield.through.objects.all()
ManyToManyField.through_fields

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

from django.db import models


class Person(models.Model):
    name = models.CharField(max_length=50)


class Group(models.Model):
    name = models.CharField(max_length=128)
    members = models.ManyToManyField(
        Person,
        through="Membership",
        through_fields=("group", "person"),
    )


class Membership(models.Model):
    group = models.ForeignKey(Group, on_delete=models.CASCADE)
    person = models.ForeignKey(Person, on_delete=models.CASCADE)
    inviter = models.ForeignKey(
        Person,
        on_delete=models.CASCADE,
        related_name="membership_invites",
    )
    invite_reason = models.CharField(max_length=64)

Membership имеет два внешних ключа к Person (person и inviter), что делает отношение неоднозначным и Django не может понять, какое использовать. В этом случае вы должны явно указать, какие внешние ключи Django должен использовать, используя through_fields, как в приведённом выше примере.

through_fields принимает 2-кортеж ('field1', 'field2'), где field1 — имя внешнего ключа к модели, на которой определён ManyToManyField (group в данном случае), и field2 — имя внешнего ключа к целевой модели (person в данном случае).

Когда у вас есть более одного внешнего ключа в промежуточной модели к любой (или даже обеим) моделям, участвующим в отношении многие-ко-многим, вы обязательно должны указать through_fields. Это также относится к рекурсивным отношениям, когда используется промежуточная модель и есть более двух внешних ключей к модели, или вы хотите явно указать, какие два Django должен использовать.

ManyToManyField.db_table

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

ManyToManyField.db_constraint

Управляет тем, будут ли созданы ограничения в базе данных для внешних ключей в промежуточной таблице. По умолчанию это True, и это почти наверняка то, что вам нужно; установка этого значения в False может быть очень вредной для целостности данных. Тем не менее, вот некоторые сценарии, где вам может потребоваться это сделать:

  • У вас есть устаревшие данные, которые недействительны.
  • Вы фрагментируете свою базу данных.

Нельзя передать оба db_constraint и through.

ManyToManyField.swappable

Управляет реакцией фреймворка миграций, если этот ManyToManyField указывает на взаимозаменяемую модель. Если это True (по умолчанию), то если ManyToManyField указывает на модель, которая соответствует текущему значению settings.AUTH_USER_MODEL (или другому параметру взаимозаменяемой модели), отношение будет сохранено в миграции с помощью ссылки на параметр, а не на модель напрямую.

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

Если сомневаетесь, оставьте значение по умолчанию True.

ManyToManyField не поддерживает validators.

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

OneToOneField

class OneToOneField(to, on_delete, parent_link=False, **options) [source]

Связь один-к-одному. По сути, она похожа на ForeignKey с unique=True, но обратная сторона связи напрямую вернёт единственный объект.

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

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

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

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

from django.conf import settings
from django.db import models


class MySpecialUser(models.Model):
    user = models.OneToOneField(
        settings.AUTH_USER_MODEL,
        on_delete=models.CASCADE,
    )
    supervisor = models.OneToOneField(
        settings.AUTH_USER_MODEL,
        on_delete=models.CASCADE,
        related_name="supervisor_of",
    )

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

>>> user = User.objects.get(pk=1)
>>> hasattr(user, "myspecialuser")
True
>>> hasattr(user, "supervisor_of")
True

Исключение RelatedObjectDoesNotExist возникает при обращении к обратной связи, если запись в связанной таблице не существует. Это подкласс исключения Model.DoesNotExist целевой модели и может быть получен как атрибут обратного аксессора. Например, если у пользователя нет руководителя, назначенного MySpecialUser:

try:
    user.supervisor_of
except User.supervisor_of.RelatedObjectDoesNotExist:
    pass

Кроме того, OneToOneField принимает все дополнительные аргументы, которые принимаются ForeignKey, плюс один дополнительный аргумент:

OneToOneField.parent_link

Когда True и используется в модели, которая наследуется от другой конкретной модели, указывает, что это поле должно использоваться в качестве ссылки обратно на родительский класс, а не дополнительного OneToOneField, который обычно неявно создаётся при наследовании.

См. Примеры связей один-к-одному для примеров использования OneToOneField.

Ленивые связи

Ленивые связи позволяют ссылаться на модели по их именам (как строки) или создавать рекурсивные связи. Строки могут использоваться в качестве первого аргумента в любом поле связи для леничной ссылки на модели. Леничная ссылка может быть либо рекурсивной, либо относительной, либо абсолютной.

Рекурсивные

Чтобы определить связь, в которой модель ссылается на себя, используйте "self" в качестве первого аргумента поля связи:

from django.db import models


class Manufacturer(models.Model):
    name = models.TextField()
    suppliers = models.ManyToManyField("self", symmetrical=False)

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

Относительные

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

from django.db import models


class Car(models.Model):
    manufacturer = models.ForeignKey(
        "Manufacturer",
        on_delete=models.CASCADE,
    )


class Manufacturer(models.Model):
    name = models.TextField()
    suppliers = models.ManyToManyField("self", symmetrical=False)

Связи, определённые таким образом в абстрактных моделях, разрешаются, когда модель подклассируется как конкретная модель, и не относятся к app_label абстрактной модели:

products/models.py
from django.db import models


class AbstractCar(models.Model):
    manufacturer = models.ForeignKey("Manufacturer", on_delete=models.CASCADE)

    class Meta:
        abstract = True
production/models.py
from django.db import models
from products.models import AbstractCar


class Manufacturer(models.Model):
    name = models.TextField()


class Car(AbstractCar):
    pass

В этом примере связь Car.manufacturer будет разрешена до production.Manufacturer, так как она указывает на конкретную модель, определённую в файле production/models.py.

Многоразовые модели с относительными ссылками

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

Абсолютные

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

Например, если модель Manufacturer определена в другом приложении с именем thirdpartyapp, к ней можно обратиться как:

class Car(models.Model):
    manufacturer = models.ForeignKey(
        "thirdpartyapp.Manufacturer",
        on_delete=models.CASCADE,
    )

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

Справочник по API полей

class Field [source]

Field — это абстрактный класс, представляющий столбец таблицы базы данных. Django использует поля для создания таблицы базы данных (db_type()), для сопоставления типов Python с базой данных (get_prep_value()) и наоборот (from_db_value()).

Поле, таким образом, является фундаментальным элементом различных API Django, в частности, models и querysets.

В моделях поле создаётся как атрибут класса и представляет определённый столбец таблицы, см. Модели. Оно имеет атрибуты, такие как null и unique, и методы, которые Django использует для сопоставления значения поля с базами данных.

Поле является подклассом RegisterLookupMixin и, следовательно, на нём можно зарегистрировать как Transform, так и Lookup для использования в QuerySet (например, в field_name__exact="foo"). Все встроенные операции поиска регистрируются по умолчанию.

Все встроенные поля Django, такие как CharField, являются конкретными реализациями Field. Если вам нужно настраиваемое поле, вы можете либо унаследовать его от любого из встроенных полей, либо написать Field с нуля. В любом случае, см. Как создать настраиваемые поля модели.

description

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

Описание может быть в формате:

description = _("String (up to %(max_length)s)")

где аргументы интерполируются из __dict__ поля.

descriptor_class

Класс, реализующий протокол описателей, который создаётся и назначается атрибуту экземпляра модели. Конструктор должен принимать один аргумент, экземпляр Field. Переопределение этого атрибута класса позволяет настраивать поведение get и set.

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

get_internal_type() [source]

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

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

db_type(connection) [source]

Возвращает тип данных столбца базы данных для Field, учитывая connection.

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

rel_db_type(connection) [source]

Возвращает тип данных столбца базы данных для полей, таких как ForeignKey и OneToOneField, которые ссылаются на Field, учитывая connection.

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

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

  • при запросе к базе данных (значение Python -> значение бэкенда базы данных)
  • при загрузке данных из базы данных (значение бэкенда базы данных -> значение Python)
  • при сохранении в базе данных (значение Python -> значение бэкенда базы данных)

При запросе используются get_db_prep_value() и get_prep_value():

get_prep_value(value) [source]

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

См. Преобразование объектов Python в значения запроса для использования.

get_db_prep_value(value, connection, prepared=False) [source]

Преобразует value в значение, специфичное для бэкенда. По умолчанию возвращает value, если prepared=True, и get_prep_value() в противном случае.

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

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

from_db_value(value, expression, connection)

Преобразует значение, возвращённое базой данных, в объект Python. Это обратная операция к get_prep_value().

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

expression эквивалентно self.

См. Преобразование значений в объекты Python для использования.

Примечание

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

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

get_db_prep_save(value, connection) [source]

Аналогично get_db_prep_value(), но вызывается при необходимости сохранения значения поля в базе данных. По умолчанию возвращает get_db_prep_value().

pre_save(model_instance, add) [source]

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

model_instance — это экземпляр, к которому принадлежит это поле, а add — это признак того, сохраняется ли экземпляр в базу данных впервые.

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

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

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

to_python(value) [source]

Преобразует значение в соответствующий объект Python. Он действует как обратная функция value_to_string() и также вызывается в clean().

См. Преобразование значений в объекты Python для использования.

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

value_from_object(obj) [source]

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

Этот метод часто используется value_to_string().

value_to_string(obj) [source]

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

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

При использовании model forms, полю Field нужно знать, какое поле формы оно должно представлять:

formfield(form_class=None, choices_form_class=None, **kwargs) [source]

Возвращает значение по умолчанию django.forms.Field этого поля для ModelForm.

Если formfield() переопределяется для возврата None, это поле исключается из ModelForm.

По умолчанию, если оба form_class и choices_form_class являются None, используется CharField. Если у поля есть choices, и choices_form_class не указано, используется TypedChoiceField.

См. Указание поля формы для поля модели для использования.

deconstruct() [source]

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

  1. Имя поля в модели.
  2. Путь импорта поля (например, "django.db.models.IntegerField"). Это должна быть наиболее переносимая версия, поэтому менее специфичная может быть лучше.
  3. Список позиционных аргументов.
  4. Словарь ключевых аргументов.

Этот метод должен быть добавлен к полям до версии 1.7, чтобы мигрировать его данные с помощью Миграций.

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

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

Справочник по атрибутам полей

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

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

Field.auto_created

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

Field.concrete

Флаг булевого типа, указывающий, связано ли поле с столбцом базы данных.

Field.hidden

Флаг булевого типа, указывающий, скрыто ли поле и должно ли оно не возвращаться функцией Options.get_fields() по умолчанию. Пример — обратное поле для ForeignKey с related_name, начинающимся с '+'.

Field.is_relation

Флаг булевого типа, указывающий, содержит ли поле ссылки на одну или несколько других моделей для его функциональности (например, ForeignKey, ManyToManyField, OneToOneField и т. д.).

Field.model

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

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

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

Field.many_to_many

Флаг булевого типа, который равен True, если поле имеет отношение «многие ко многим»; False в противном случае. Единственное поле, включённое в Django, где это True, — это ManyToManyField.

Field.many_to_one

Флаг булевого типа, который равен True, если поле имеет отношение «многие к одному», например, ForeignKey; False в противном случае.

Field.one_to_many

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

Field.one_to_one

Флаг булевого типа, который равен True, если поле имеет отношение «один к одному», например, OneToOneField; False в противном случае.

Field.related_model

Указывает на модель, к которой относится поле. Например, Author в ForeignKey(Author, on_delete=models.CASCADE). related_model для GenericForeignKey всегда None.

© Django Software Foundation and individual contributors
Licensed under the BSD License.
https://docs.djangoproject.com/en/5.2/ref/models/fields/

Spec-Zone.ru

Настройки Оффлайн Что нового Помощь О нас
Spec-Zone .ru
спецификации, руководства, описания, API