slugfield django что это
SlugField — Django Forms
SlugField имеет следующий необязательный аргумент:
Синтаксис
Django form SlugField Объяснение
Refer to the following articles to check how to create a project and an app in Django.
from django import forms
Добавьте приложение гиков в INSTALLED_APPS
Теперь, чтобы преобразовать эту форму в представление, нам нужно представление и URL, сопоставленный с этим URL. Давайте сначала создадим представление в views.py приложения geeks,
from django.shortcuts import render
# Создайте свои взгляды здесь.
context[ ‘form’ ] = GeeksForm()
input type = «submit» value = «Submit» >
Наконец, URL для сопоставления с этим представлением в urls.py
from django.urls import path
# импорт видов из views..py
Давайте запустим сервер и проверим, что на самом деле произошло, Запустите
Таким образом, поле geeks_field geeks_field создается путем замены «_» на ««.
Как использовать SlugField?
SlugField используется для ввода слагов в базу данных через формы Django. Можно ввести URL-адрес slug и т. Д. До сих пор мы обсуждали, как реализовать SlugField, но как использовать его в представлении для выполнения логической части. Для выполнения некоторой логики нам нужно получить значение, введенное в поле, в экземпляр строки Python.
В views.py,
from django.shortcuts import render
# Создайте свои взгляды здесь.
context[ ‘form’ ] = form
temp = request.POST[ ‘geeks_field’ ]
Теперь давайте попробуем ввести что-то еще в поле.
Так как это нужно проверить в соответствии со слагом, давайте введем «slugfield-django-models» в поле
Теперь эти данные можно получить, используя соответствующий словарь запросов. Если метод GET, данные будут доступны в request.GET, а если post, то request.POST соответственно. В приведенном выше примере у нас есть значение в temp, которое мы можем использовать для любых целей.
Основные Полевые Аргументы
Аргументы основного поля — это аргументы, данные каждому полю для применения какого-либо ограничения или передачи определенной характеристики конкретному полю. Например, добавление аргумента required = False в SlugField позволит пользователю оставить его пустым. Каждый конструктор класса Field принимает как минимум эти аргументы. Некоторые классы Field принимают дополнительные специфичные для поля аргументы, но всегда следует принимать следующее:
Добавляем слаги (slug) к URL-адресам
На этом занятии мы сделаем отображение отдельных статей по их слагу (slug). Если кто не знает, то slug – это уникальный фрагмент URL-адреса, ассоциированный с конкретной записью и, обычно, состоит из набора маленьких латинских букв, цифр, символов подчеркивания и дефиса. Например, статья «Арифметические операции» на сайте https://proproprogs.ru доступна по следующему адресу:
Здесь slug – это последние символы, по которым и выбирается данная страница из БД. Использование слагов – рекомендуемая практика в веб-программировании. Такие страницы лучше ранжируются поисковыми системами и понятнее конечному пользователю.
Давайте вначале сделаем отображение статей по их идентификатору, а затем, заменим адрес на слаг. У нас уже есть функция-заглушка show_post() в файле women/views.py. Мы ее перепишем, следующим образом:
Здесь функция get_object_or_404 выбирает одну запись из таблицы Women, которая имеет идентификатор, равный post_id, либо генерирует исключение 404, если запись не была найдена. Это довольно частая операция, когда нужно найти какую-либо отдельную запись, а в противном случае, перенаправить пользователя на заготовленную страницу 404. Поэтому в Django для таких случаев заготовлена специальная функция.
Далее, формируется словарь из параметров шаблона и отображается страница на основе шаблона post.html. У нас пока нет такого файла, добавим его со следующим содержимым:
Здесь все достаточно очевидно. Вначале отображаем заголовок h1, затем, фотографию статьи, если она есть, ну и потом уже содержимое самой статьи.
Если теперь перейти по ссылке, то увидим полноценную статью. Если же указать неверный адрес, то получим исключение 404. Повторю еще раз, исключения в таком развернутом виде отображаются только в режиме отладки сайта. При эксплуатации с константой DEBUG = False вместо исключения отображается заготовленная страница 404.
Добавление слага
Следующим шагом сделаем отображение статей по их слагу. Но откуда нам его взять? Для этого в модели Women необходимо прописать еще одно поле, которое так и назовем – slug:
Я его определил после поля title, указал уникальным, индексируемым и имя URL, отображаемое в админке. Однако, если сейчас попытаться создать миграцию для внесения этих изменений в структуру таблицы women:
python manage.py makemigrations
то увидим предупреждение, что поле не может быть пустым (так как у нас есть записи в таблице). Чтобы таблицы были сформированы как надо, я решил создать БД заново. Поэтому сразу добавил такое же поле в модели Category:
Удалим все файлы миграций, прежний файл БД и выполним команду
python manage.py makemigrations
для создания первой мигации. Затем, с помощью команды:
python manage.py migrate
сформируем таблицы с новыми структурами. Этот пример хорошо показывает, как важно заранее продумывать структуры таблиц для сайта. Осталось восстановить записи в БД. Для этого я заново создам суперпользователя для админки:
python manage.py createsuperuser
с именем root, почтой root@coolsite.ru и паролем 1234. Запускаем веб-сервер и заходим в админ-панель.
Для начала добавим категории. Здесь нам предлагается ввести ее название и слаг (URL). Конечно, можно заполнить оба поля вручную, например, «Актрисы» и «actrisi». Но, так как слаг, обычно, повторяет заголовок, только записанный латиницей, то фреймворк Django позволяет этот процесс автоматизировать. Давайте откроем файл women/admin.py и для модели Category в классе CategoryAdmin добавим атрибут:
Это специальное свойство, которое указывает фреймворку автоматически заполнять поле slug по данным поля name.
Возвращаемся в админку, обновляем страницу и, смотрите, при вводе строки в поле name, автоматически формируется поле slug. Это очень здорово и значительно облегчает нашу работу. Теперь можно совершенно спокойно добавить две рубрики «Актрисы» и «Певицы».
Далее, прежде чем добавлять статьи, сделаем такую же связку по слагу для модели Women в классе WomenAdmin:
только здесь мы указываем поле title. Возвращаемся в админ-панель и на вкладке добавления женщин введем информацию по актрисам:
Анджелина Джоли, Дженнифер Лоуренс, Джулия Робертс, Марго Робби, Ума Турман
А также по певицам:
Ариана Гранде, Бейонсе, Кэтти Перри, Рианна, Шакира
Отлично, база данных готова и теперь можно сделать отображение статей по слагу. Для этого откроем файл women/urls.py и в списке urlpatterns изменим маршрут для постов на следующий:
Затем, в файле women/views.py немного поменяем функцию представления show_post:
И в модели Women (в файле women/models.py) будем формировать URL-адрес по параметру slug:
Все, обновляем главную страницу сайта и видим, что теперь посты доступны по слагу, а не идентификатору. Этот пример показывает как в Django легко и просто можно менять URL-адреса и вместо id использовать другие поля, в частности, слаг. При этом, мы не производили совершенно никаких изменений в шаблонах, благодаря использованию метода get_absolute_url() в модели Women. Кроме того, Django автоматически защищает такие адреса от SQL-инъекций, когда злоумышленник пытается выполнить SQL-запрос, прописывая его в адресной строке браузера. Благодаря всем этим мелочам, которые берет на себя фреймворк, даже начинающий веб-мастер может конструировать вполне безопасные сайты с богатым функционалом.
Аналогичную операцию использования слагов можно сделать и для отображения рубрик. Предлагаю вам выполнить это самостоятельно для закрепления материала.
Видео по теме
#2. Модель MTV. Маршрутизация. Функции представления
#3. Маршрутизация, обработка исключений запросов, перенаправления
#4. Определение моделей. Миграции: создание и выполнение
#6. Шаблоны (templates). Начало
#7. Подключение статических файлов. Фильтры шаблонов
#8. Формирование URL-адресов в шаблонах
#9. Создание связей между моделями через класс ForeignKey
#10. Начинаем работу с админ-панелью
#11. Пользовательские теги шаблонов
#12. Добавляем слаги (slug) к URL-адресам
#13. Использование форм, не связанных с моделями
#14. Формы, связанные с моделями. Пользовательские валидаторы
#15. Классы представлений: ListView, DetailView, CreateView
#16. Основы ORM Django за час
#18. Постраничная навигация (пагинация)
#19. Регистрация пользователей на сайте
#20. Делаем авторизацию пользователей на сайте
#21. Оптимизация сайта с Django Debug Toolbar
#22. Включаем кэширование данных
#23. Использование капчи captcha
#24. Тонкая настройка админ панели
#25. Начинаем развертывание Django-сайта на хостинге
#26. Завершаем развертывание Django-сайта на хостинге
© 2021 Частичное или полное копирование информации с данного сайта для распространения на других ресурсах, в том числе и бумажных, строго запрещено. Все тексты и изображения являются собственностью сайта
SlugField — Django Models
Slug — это, по сути, короткий ярлык для чего-либо, содержащий только буквы, цифры, подчеркивания или дефисы. Они обычно используются в URL. Например, в типичном URL записи в блоге:
Здесь последней add-the-slug-field-inside-django-model является слаг.
SlugField:
Синтаксис
SlugField имеет следующие необязательные аргументы:
Если True, поле принимает буквы Unicode в дополнение к буквам ASCII. По умолчанию False.
Модель Django SlugField Объяснение
Refer to the following articles to check how to create a project and an app in Django.
from django.db import models
from django.db.models import Model
# Создайте свои модели здесь.
geeks_field = models.SlugField(max_length = 200 )
Добавьте приложение гиков в INSTALLED_APPS
Теперь, когда мы запускаем команду makemigrations из терминала,
В каталоге geeks будет создана новая папка с именем migrations с файлом с именем 0001_initial.py
# Сгенерировано Django 2.2.5 на 2019-09-25 06:00
from django.db import migrations, models
Таким образом, поле geeks_field SlugField создается при запуске миграций в проекте.
Как использовать SlugField?
SlugField используется для хранения в основном хранения путей URL после определенного URL. Чтобы узнать больше о том, как правильно добавить SlugField в Django Project, обратитесь к этой статье — Добавьте поле slug в Django Model.
# импорт модели
# из приложения гиков
from geeks.models import GeeksModel
# создание экземпляра
# GeeksModel
Теперь давайте проверим это на административном сервере. Мы создали экземпляр GeeksModel. 
Параметры поля
Параметры поля — это аргументы, данные каждому полю для применения некоторого ограничения или передачи определенной характеристики конкретному полю. Например, добавление аргумента null = True в SlugField позволит ему хранить пустые значения для этой таблицы в реляционной базе данных.
Вот параметры поля и атрибуты, которые может использовать SlugField.
Документация Django 1.9
Этот раздел содержит все существующие подробности о всех параметрах поля и типах полей в Django.
Если существующие поля не предоставляют необходимого функционала, вы можете поискать в django-localflavor, который содержит дополнительный функционал полезный для различных стран.
Параметры поля¶
Приведенные аргументы доступны для всех полей. Все они не обязательны.
Для всех типов полей, вы также должны указать blank=True если вы хотите разрешить пустые значения в формах, т.к. параметр null влияет только на сохранение в базе данных (смотрите blank ).
При использовании Oracle, NULL будет использоваться для пустой строки независимо от значения этого параметра.
blank ¶
choices ¶
Первый элемент каждого кортежа – это значение, которое будет сохранено в базе данных. Второй элемент – название, которое будет отображаться для пользователей. Например:
Значения лучше указать в константах внутри модели:
Можно указать список значений и не в модели, но так все данные будут связаны с моделью, и к значениям можно легко обратиться (например, Student.SOPHOMORE можно использовать импортировав модель Student ).
Вы можете сгруппировать значения в именованные группы:
Первый элемент каждого кортежа – это название группы. Второй элемент – итератор с двух-элементными кортежами содержащими значение и отображаемое название. Сгруппированные опции могут комбинироваться с не сгруппированными (как unknown в примере выше).
db_column ¶
Имя колонки в базе данных для хранения данных этого поля. Если этот параметр не указан, Django будет использовать название поля.
Если имя колонки это зарезервированное SQL слово, или содержит символы запрещенные в названиях переменной в Python – в частности, дефис – все нормально. Django автоматически экранирует название колонок и таблиц.
db_index ¶
При True для поля будет создан индекс в базе данных.
db_tablespace ¶
Имя “tablespace” базы данных используемое для индекса поля, если поле имеет индекс. По-умолчанию используется значение настройки DEFAULT_INDEX_TABLESPACE проекта, если оно указано, иначе db_tablespace модели. Если база данных не поддерживает “tablespace” для индексов, этот параметр будет проигнорирован.
default ¶
Значение по умолчанию для поля. Это может быть значение или вызываемый(callable) объект. Если это вызываемый объект, он будет вызван при создании нового объекта.
Значение по умолчанию не может быть изменяемым значением (экземпляр модели, список, множество и т.д.), т.к. все объекты модели будут ссылаться на этот объект и использовать его как значение по умолчанию. Вместо этого укажите функцию, которая возвращает нужное значение. Например, если у вас есть собственное поле JSONField и вы хотите указать словарь как значение по умолчанию, используйте следующую функцию:
editable ¶
error_messages ¶
error_messages позволяет переопределить сообщения ошибок возвращаемых полем. Используйте словарь с ключами соответствующими необходимым ошибкам.
help_text ¶
Подсказка, отображаемая под полем в интерфейсе администратора. Это полезно для описания поля, даже если модель не используется в форме.
Заметим, что, при отображении в форме, HTML-символы не экранируются. Это позволяет использовать HTML в help_text если вам необходимо. Например:
primary_key ¶
При True это поле будет первичным ключом.
Первичный ключ доступен только для чтения. Если вы поменяете значение для существующего объекта и сохраните его, будет создан новый объект.
unique ¶
При True значение поля должно быть уникальным.
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 ¶
BigIntegerField ¶
BinaryField ¶
BooleanField ¶
Поле хранящее значение true/false.
CharField ¶
Строковое поле для хранения коротких или длинных строк.
CharField принимает один дополнительный аргумент:
Максимальная длинна(в символах) этого поля. max_length используется для проверки данных на уровне базы данных и форм Django.
Если вы создаете независимое приложение, которое должно работать на различных базах данных, помните что существуют некоторые ограничения использования max_length для некоторых типов баз данных. Смотрите раздел про использование различных типов баз данных.
Если вы используете это поле с MySQLdb 1.2.2 и utf8_bin “collation” (которое не является значением по умолчанию), могут быть некоторые проблемы. Смотрите советы при работе с MySQL для подробностей.
CommaSeparatedIntegerField ¶
DateField ¶
Дата, представленная в виде объекта datetime.date Python. Принимает несколько дополнительных параметров:
Значение поля будет автоматически установлено в текущую дату при каждом сохранении объекта. Полезно для хранения времени последнего изменения. Заметим, что текущее время будет использовано всегда; это не просто значение по умолчанию, которое вы можете переопределить.
Значение поля будет автоматически установлено в текущую дату при создании(первом сохранении) объекта. Полезно для хранения времени создания. Заметим, что текущее время будет использовано всегда; это не просто значение по-умолчанию, которое вы можете переопределить. По этому, даже если вы укажите значение для этого поля, оно будет проигнорировано. Если вы хотите изменять значения этого поля, используйте следующее вместо auto_now_add=True :
В форме поле будет представлено как :class:`
DateTimeField ¶
DecimalField ¶
Десятичное число с фиксированной точностью, представленное объектом Decimal Python. Принимает два обязательных параметра:
Количество знаков после запятой.
Например, для хранения числа до 999 с двумя знаками после запятой, используйте:
Для хранения числа до миллиарда и 10 знаков после запятой:
DurationField ¶
Арифметика над DurationField работает в большинстве случаев. Однако, для всех баз данных, кроме PostgreSQL, арифметическое сравнение DurationField и DateTimeField работает не как ожидается.
EmailField ¶
Поле CharField для хранения правильного email-адреса. Использует EmailValidator для проверки значения.
Значение max_length по умолчанию было увеличено с 75 до 254 для совместимости с RFC3696/5321.
FileField ¶
Поле для загрузки файла.
primary_key и unique не принимаются, и вызовут исключение TypeError при использовании.
Также принимается два дополнительных параметра:
upload_to также принимается вызываемый объект, такой как функция, который будет вызван для получения пути к загруженному файлу, включая имя файла. Вызываемый объект должен принимать два обязательных аргумента, и возвращать путь в стиле Unix (с прямыми слэшами), который будет передан в систему хранения файлов(storage). Два аргумента это:
Оригинальное имя файла. Вы можете его учитывать, или проигнорировать при определении окончательного пути к файлу.
Объект “storage”, который отвечает за хранение и получение файлов. Смотрите Управление файлами для подробной информации.
Использование FileField или ImageField (смотрите ниже) требует некоторых дополнительных действий:
Если вам нужны название файла или его размер, используйте атрибуты name и size соответственно; больше информации о доступных методах и атрибутах вы найдете в справке о File и разделе документации Управление файлами.
Процесс сохранения файла – часть процесса сохранения объекта, таким образом имя файла, сохраненного на диске, не будет доступно, пока объект не будет сохранен.
Заметим, что при загрузке файлов, вы должны обращать внимание, куда вы загружаете файлы и какие типы файлов загружаются, чтобы предотвратить возможные уязвимости в защите системы. Проверяйте все загружаемые файлы. Например, если вы разрешите загрузить файл без проверки в каталог, который обрабатывается сервером, кто-нибудь сможет загрузить CGI или PHP скрипт и выполнить его, посетив его URL на вашем сайте. Не допускайте это.
Также заметим что это относится и к HTML файлам, так как они могу быть выполнены в браузере(хоть и не на сервере), и нести угрозу XSS или CSRF атаки.
FileField и FieldFile¶
При доступе к FileField модели, вы получаете экземпляр FieldFile как “proxy” для работы с файлом. Этот класс содержит несколько дополнительных атрибутов и методов для работы с файлом, кроме унаследованных от django.core.files.File :
FieldFile. open (mode=’rb’)¶
Работает так же как и метод file.close() в Python и закрывает файл связанный с объектом.
Этот метод принимает имя файла и содержимое и передает его в экземпляр класса “storage” этого поля, потом добавляет файл в модель. Если вы хотите самостоятельно добавить содержимое файла в поле FileField вашей модели, метод save() то, что вам нужно.
Или же создать из строки с содержимым файла:
FieldFile. delete (save=True)¶
Обратите внимание, когда объект модели удаляется, связанные файлы не удаляются. Если вам необходимо удалять их, делайте это самостоятельно (например, используя команду, запущенную через cron).
FilePathField ¶
Поле CharField значение которого ограничено именем файла из определенного каталога. Принимает три дополнительных аргумента, первый из них обязателен:
Конечно же можно использовать все аргумента вместе.
Следует помнить, что match применяется к имени файла, а не абсолютному пути. Таким образом:
FloatField ¶
FloatField или DecimalField
ImageField ¶
Для определения этих аргументов ImageField принимает дополнительные аргументы:
Имя поля, которому автоматически будет присвоено значение высоты изображения при каждом сохранении объекта.
Имя поля, которому автоматически будет присвоено значение ширины изображения при каждом сохранении объекта.
IntegerField ¶
GenericIPAddressField ¶
NullBooleanField ¶
PositiveIntegerField ¶
PositiveSmallIntegerField ¶
SlugField ¶
Slug – газетный термин. “Slug” – это короткое название-метка, которое содержит только буквы, числа, подчеркивание или дефис. В основном используются в URL.
SmallIntegerField ¶
TextField ¶
Если вы используете это поле с MySQLdb 1.2.1p2 и utf8_bin “collation” (которое не является значением по умолчанию), могут быть некоторые проблемы. Смотрите советы при работе с MySQL для подробностей.
TimeField ¶
URLField ¶
UUIDField ¶
Поля отношений¶
Django предоставляет набор полей для определения связей между моделями.
ForeignKey ¶
Связь многое-к-одному. Принимает позиционный аргумент: класс связанной модели.
on_delete может теперь использоваться как второй позиционный аргумент (ранее использовался только как именованный аргумент). Будет обязательным аргументом в Django 2.0.
Если вам необходимо добавить связь на модель, которая еще не определена, вы можете использовать имя модели вместо класса:
Такой способ позволяет создать циклическую зависимость между моделями из разных приложений.
Представление в базе данных¶
Параметры¶
ForeignKey принимает дополнительные аргументы, которые определяют, как должна работать связь.
Возможные значения для on_delete находятся в django.db.models :
Каскадное удаление. Django эмулирует поведение SQL правила ON DELETE CASCADE и так же удаляет объекты, связанные через ForeignKey.
Препятствует удалению связанного объекта вызывая исключение django.db.models.ProtectedError`(подкласс :exc:`django.db.IntegrityError ).
Указание функции может быть полезно, если используется объект Python datetime для фильтрации. Например:
Поле связанной модели, которое используется для создания связи между таблицами. По-умолчанию, Django использует первичный ключ.
Указывает создавать ли “constraint” для внешнего ключа в базе данных. По умолчанию True и в большинстве случает это то, что вам нужно. Указав False вы рискуете целостностью данных. Некоторые ситуации, когда вам может быть это необходимо:
Вам досталась в наследство нецелостная база данных
Вы используете шардинг базы данных.
ManyToManyField ¶
Представление в базе данных¶
Параметры¶
ManyToManyField принимает дополнительные аргументы – все не обязательны – которые определяют как должна работать связь.
limit_choices_to«не работает для «ManyToManyField переопределенной через through промежуточной моделью.
Используется только при рекурсивной связи. Например, есть модель:
Django автоматически создает промежуточную таблицу для хранения связи. Однако, если вы хотите самостоятельно определить промежуточную таблицу, используйте параметр through указав модель Django, которая будет хранить связь между моделями.
Если вы не указали through модель, вы все равно может обратиться к неявно промежуточной модели, которая была автоматически создана. Она содержит три поля, связывающие модели.
Если связанные модели разные, создаются следующие поля:
id : первичный ключ для связи.
Если ManyToManyField ссылается на одну и ту же модель, будут созданы поля:
id : первичный ключ для связи.
from_ _id : id объекта основной модели (исходный объект).
to_ _id : id объекта, на который указывает связь (целевой объект).
Этот класс может использоваться для получения связей.
Используется, если явно указана промежуточная модель для связи многое-ко-многим. Обычно Django самостоятельно определяется какие поля использовать для создания связи. Однако, возьмем такой пример:
Рекурсивные связи, использующие промежуточную модель, всегда считаются несимметричными – то есть с symmetrical=False – поэтому существуют понятия “источник” и “цель” связи. В этом случае ‘field1’ будет “источником” связи, а ‘field2’ – “целью”.
Имя промежуточной таблицы для хранения связей многое-ко-многим. Если не указан, Django самостоятельно создаст название по умолчанию используя название таблицы определяющей связь и название поля.
Указывает создавать ли “constraint” для внешних ключей в промежуточной таблице в базе данных. По умолчанию True и в большинстве случает это то, что вам нужно. Указав False вы рискуете целостностью данных. Некоторые ситуации, когда вам может быть это необходимо:
Вам досталась в наследство нецелостная база данных
Вы используете шардинг базы данных.
Нельзя указать db_constraint и through одновременно.
null не влияет на работу поля т.к. нет способа сделать связь обязательной на уровне базы данных.
OneToOneField ¶
on_delete может теперь использоваться как второй позиционный аргумент (ранее использовался только как именованный аргумент). Будет обязательным аргументом в Django 2.0.
В основном применяется как первичный ключ модели, которая “расширяет” другую модель. Например, Multi-table наследование работает через неявное добавление связи один-к-одному от дочерней модели к родительской.
модель User будет содержать следующие атрибуты:
При True и связанной модели, которая наследуется от другой модели, определяет, что должна сохраняться связь на родительскую модель, а не поле OneToOneField дочерней модели, которое используется для организации наследования моделей.
Смотрите примеров использования OneToOneField в Связь один к одному.
Справочник по полям модели¶
Field – абстрактный класс, отображающий колонку в таблице в базе данных. Django используется поля для создания таблицы в базе данных ( db_type() ), для преобразования типов Python в типа в базе данных ( get_prep_value() ) и наоборот ( from_db_value() ), и для применения Lookup API reference ( get_prep_lookup() ).
Может использовать форматирование:
Аргументы будут подставляется из значений __dict__ поля.
Для преобразования типа Field в тип базы данных Django используется два метода:
Возвращает текстовое название типа поля для использования в бэкендах баз данных. По умолчанию возвращает название класса.
Существует три основных ситуации, когда Django используется преобразование типа поля:
value – значение атрибута поля модели. Метод должен вернуть значение, которое можно использовать как параметр в запросе.
get_db_prep_value (value, connection, prepared=False)¶
При загрузке данных используется from_db_value() :
from_db_value (value, expression, connection, context)¶
Для большинства встроенных полей этот метод не используется т.к. бэкенд базы данных возвращает уже правильный объект Python, или же бэкенд сам выполняет необходимые преобразования.
При сохранении используются методы pre_save() и get_db_prep_save() :
get_db_prep_save (value, connection)¶
pre_save (model_instance, add)¶
model_instance – объект модели, к которому принадлежит поле, add – указывает сохраняется ли объект первый раз в базу данных.
При использовании фильтрации по полю, может быть необходимо “приготовить” значение. Django используется для этого два метода:
get_prep_lookup (lookup_type, value)¶
get_db_prep_lookup (lookup_type, value, connection, prepared=False)¶
Поля часто принимает значения разных типов из сериализатора, или формы
Кроме сохранения в базу данных, поле также должно знать как сериализовать свое значение:
Преобразует obj в строку. Используется при сериализации значения поля.
При использовании django.forms.ModelForm Field должно указать, какое поле формы необходимо использовать для его представления в форме:
formfield (form_class=None, choices_form_class=None, **kwargs)¶
Возвращает 4-х элементный кортеж с информацией, как воссоздать поле:
Название поля в модели.
Путь для импорта класса поля (например, «django.db.models.IntegerField» ). Должен возвращаться максимально переносимый между платформами и версиями вариант.
Список позиционных аргументов.
Словарь именованных аргументов.
Этот метод должен быть добавлен полям, созданным до 1.7, для использования Миграции.
Атрибуты поля¶
Атрибуты поля¶
Флаг, который указывает было ли поле создано автоматически, например OneToOneField при наследовании моделей.
Флаг, который указывает представлено ли поле колонкой в таблице в базе данных.
Флаг, который указывает, что поле скрыто и используется для работы другого не скрытого поля (например, поля content_type и object_id используются для работы GenericForeignKey ). Флаг hidden используется, чтобы выделить публичные поля модели из всех полей.
Содержит модель, в которой это поле определено. Если поле определено в родительском классе, model будет ссылаться на этот класс, а не класс экземпляра модели.
Атрибуты связывающих полей¶
Атрибуты, определяющие связь поля. Эти атрибуты присутствуют во всех полях, однако, только для связывающих полей( Field.is_relation=True ) они содержат булевы значения(а не None ).