Django rest framework это поле не может быть пустым

Обновлено: 05.07.2024

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

Я мысль required=False выполнит работу обхода поля, если оно не существует. Однако в документации упоминается, что это влияет на десериализацию, а не на сериализацию.

Я получаю следующую ошибку:

что происходит, когда я пытаюсь получить доступ к .data сериализованного экземпляра. (Не означает ли это, что это десериализация, которая поднимает это?)

это происходит для случаев, которые не имеют Classification . Если я опущу Classification из класса сериализатора он работает просто отлично.

как мне правильно это сделать? Сериализовать объект с помощью необязательных полей.

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

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

обновление для REST framework 3.0 serializer.fields можно изменить на инстанцированный сериализатор. Когда требуются динамические классы сериализатора, я бы, вероятно, предложил изменить поля в пользовательском Serializer.__init__() метод.

или вы также можете сделать что-то подобное для сериализатора моделей, где вы возитесь с Meta.поля в сериализаторе init:

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

Django Rest Framework
Попробуйте что-то вроде этого:

Несколько Сериализаторов

другим подходом было бы создание нескольких сериализаторов с разными наборами полей. Один сериализатор наследует от другого и добавляет дополнительные поля. Тогда вы можете выбрать соответствующий сериализатор в представлении с get_serializer_class метод. Вот реальный пример того, как я использую этот подход для вызова разных сериализаторов для представления разных пользовательских данных, если объект user совпадает с пользователем запроса.

удаление полей из представления

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

и тогда в вашей сериализатор, вызовите этот метод как

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

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

используемая версия DRF = djangorestframework (3.1.0)

Из" это ужасный Хак, полагающийся на конкретные детали реализации как DRF, так и Django, но он работает (по крайней мере, на данный момент) "файлы, вот подход, который я использовал для включения некоторых дополнительных данных отладки в ответ от реализации метода" create " на сериализаторе:

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

и это сделает трюк.

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

Я использую эту модель разрешений в своем settings.py :

Когда я использую операцию POST на интерфейсе DRF (в форме HTML), я заполнил все поля элемента приложения. Как вы можете видеть, параметр "required" параметра "nom" имеет значение True. И вот в чем проблема: даже если 'nom' не пусто, DRF говорит "this field is required!". Таким образом, я не могу POST новый элемент приложения. Я не понимаю, почему это не работает. Где же ошибка?

2 ответа

Я пытаюсь использовать Django Rest Framework 3.1.1 для создания пользователя в POST. Мне нужно использовать встроенный метод для создания зашифрованного пароля, поэтому я попытался переопределить метод сохранения на ModelSerializer, но я явно не знаю Django / DRF достаточно хорошо, чтобы сделать.

Ошибка, которую вы получили, связана с Django Model(Application) . Он терпел неудачу на уровне модели, а не на уровне сериализатора. Добавьте null=True и blank=True в поле name в модели Application .

Старайтесь, чтобы ваш код был на английском языке, вы можете использовать Django's i18n для перевода материала, а также использовать пробел и null для поля вашего имени:

Давайте оставим потоки на потом, так как у вас даже нет для них отношения модели.

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

Без Django Rest Framework, которые я использовал для создания формы / POST запросы вроде так: <form method=post action=/register/> . </form> но я.

Мы начинаем использовать Angular в нашем существующем приложении Django, и я видел упоминание о библиотеке Django Rest Framework, а также Django-Angular. DRF был очень прост в использовании и.

Есть ли способ разрешить пустые поля в серилайзере Django REST для полей Boolean и Int? class InputAttributes(serializers.Serializer): make = serializers.BooleanField(required=False) speed =.

Я пытаюсь использовать Django Rest Framework 3.1.1 для создания пользователя в POST. Мне нужно использовать встроенный метод для создания зашифрованного пароля, поэтому я попытался переопределить.

При использовании HTML form renderer в DRF кто-нибудь может придумать хороший способ автоматически сгенерировать некоторую индикацию поля required в DRF, всеми правдами и неправдами? Я имею в виду.

Я передаю сериализованные данные из таблицы Django rest framework в таблицу Javascript pivot на своем сайте. Если у меня есть переменная с именем 'created_on', то DRF использует ее в качестве имени.

Нужно ли мне иметь веб-сайт django, чтобы использовать django rest framework, или я могу использовать DRF сам по себе как отдельное приложение? Извините, но для меня это не так очевидно. спасибо за.

У меня возникли некоторые проблемы с получением следующего звонка AJAX на работу. Я использую D3 версии 5, чтобы сделать следующий запрос POST к представлению Django REST Framework (DRF).

В последние недели жизнь тесно познакомила меня с самым популярным фреймворком для быстрой разработки веб-приложений на Питоне — Django. В нём много любопытного, чем я время от времени намерен делиться ツ

Допустим, у вас в приложении есть сущность «Клиент», а у клиента поле «Имя». Клиенты указывают имя при регистрации, но поскольку это не обязательно — многие предпочитают оставлять поле пустым. Как в таких случаях должно имя храниться в базе данных?

Я всегда полагал, что на этот вопрос может быть единственный ответ — использовать специальное значение NULL . Оно ведь ровно для этого и предназначено: показать, что поле не заполнено, его значение неизвестно.

NULL vs пустая строка

Создатели «Джанги», однако, пошли против вековой мудрости разработчиков, и норовят сохранять отсутствующее значение как пустую строку. За это отвечает специальная настройка ( null=False ). Менять её не рекомендуют — мол, путаница от этого возникнет:

If True , Django will store empty values as NULL in the database. Default is False .

Avoid using null on string-based fields because empty string values will always be stored as empty strings, not as NULL .

If a string-based field has null=True , that means it has two possible values for “no data”: NULL , and the empty string. In most cases, it’s redundant to have two possible values for “no data”; the Django convention is to use the empty string, not NULL .

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

  • с одной стороны, «if True, Django will store empty values as NULL»,
  • одновременно с этим «empty string values will always be stored as empty strings, not as NULL».

Так вы храните пустые значения как NULL при включённой настройке? Или всегда-всегда как пустую строку (и на кой чёрт тогда настройка)? Определитесь уже!

На самом деле, авторы имели в виду следующее:

  • Если null=False , и вы не присвоите полю значение, «Джанга» молча присвоит ему "" и сохранит в базе как пустую строку.
  • Если null=True , и вы не присвоите полю значение, «Джанга» молча присвоит ему None и сохранит в базе как NULL .
  • Вне зависимости от настройки, если вы явно присвоите полю значение "" , «Джанга» сохранит его в базе как пустую строку.
  • Вне зависимости от настройки, если вы явно присвоите полю значение None , «Джанга» сохранит его в базе как NULL .

NOT NULL на таблице

Но это полбеды. О чём авторы совсем забыли упомянуть в документации — о том, что null=False генерирует такой SQL-код:

То есть не просто «мы будем записывать неизвестное значение в базу как пустую строку», а «мы вообще запретим этому полю иметь значение NULL ».

Это очень, очень творческое дизайнерское решение. Дело в том, что если у вас таблица на 100000 строк, и вы добавляете в неё NOT NULL столбец, то это, мягко говоря, небыстро. И полностью блокирует таблицу на всё время операции.

А если приложение развивается, новые столбцы добавляют регулярно. И с NOT NULL каждый раз при миграции таблица блокируется и полностью перезаписывается. Как вообще можно было додуматься до такого подхода?

Чтобы решить проблему, достаточно игнорировать рекомендации «Джанги» и ставить текстовым полям null=True .

Django REST Framework: REST API на Python с нуля

Термин REST API расшифровывается как Representational State Transfer Application Programming Interface. Следовательно, RESTful API — это программный интерфейс приложения, соответствующий ограничениям архитектурного стиля REST.

REST — не протокол и не стандарт. Это, как уже было сказано, архитектурное ограничение. Чтобы API считался RESTful, он должен соответствовать следующим критериям.

Благодаря вышеперечисленным архитектурным правилам REST API масштабируемый, переносимый и гибкий.

2. Что такое Django REST Framework?

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

Существует множество библиотек для Django, расширяющих его функционал. Одна из них, о которой мы поговорим сегодня, — это Django REST Framework или DRF, которая позволяет сериализовать данные из Django ORM через REST API.

Сериализация — это преобразование таблиц из базы данных в формат JSON.

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

Давайте создадим сайт бронирования отелей! Исходный код и справка доступны на GitHub.

3. Установка Django

Прежде чем приступить непосредственно к работе с REST API, сделаем краткий экскурс в Django.

3.1. Создание виртуальной среды

3.2. Установка зависимостей

3.3. Начало проекта

3.4. Изменение директории

3.5. Запуск сервера


3.6. Создание приложения

Приложения в Django — это независимые многократно используемые компоненты. Создадим приложение hotel_app .

3.7. Список приложений в проекте

Чтобы подключить к проекту hotel_reservation приложения hotel_app и rest_framework , необходимо отредактировать файл results/settings.py , указав эти приложения в списке INSTALLED_APPS :

3.8. Миграции

Теперь нужно выполнить Django-миграции — это способ Django распространять в схему базы данных все изменения, вносимые в модели, такие как добавление поля, удаление модели. Выполняйте эту команду каждый раз, когда модель или база данных сколько-нибудь меняются:

3.9. Административная панель

Django поставляется со встроенной панелью администратора, что позволяет создать суперпользователя с помощью одной команды. Заполните форму — появится учетная запись администратора:


Снова выполните миграции, авторизуйтесь.


3.10. Создание модели

Django ORM абстрагирует базу данных, позволяя легко запрашивать данные и манипулировать ими через объектно-ориентированное отображение, называемое моделью. Django ORM заставляет писать код согласно паттерну MVC (Model View Controller), который станет интуитивно понятным для вас после прохождения кривой обучения.

hotel_app/models.py :

Мы создали модель, хранящую имя студента и его оценки. Метод __str__ определяет имя объекта, отображаемое в браузере. Если пропустить определение данного метода, то вы увидите в панели администратора объект под названием <ClassName> .

3.11. Не забывайте о миграциях!

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

3.12. Добавление приложения в админ-панель

Во встроенное приложение административной панели можно добавить созданную ранее пользовательскую модель.

hotel_app/admin.py :


Теперь мы завершили ту общую часть разработки веб-приложения, которая относится к фреймворку Django. Настало время приступить к проектированию REST API.

4. Написание Django REST API

Структура директорий проекта:

Добавим в проект файлы urls.py и serializers.py . Вот новый список файлов.

4.1. Сериализатор

Сериализация — процесс перевода структуры данных в последовательность байтов. Она используется для передачи объектов по сети и для сохранения их в файлы (Википедия).

hotel_app/serializers.py :

Сериализаторы определяют, как именно и какие данные отобразит представление API. При запросе по REST API к экземпляру модели Hotel мы получим список следующих полей, взятых из самой модели при помощи сериализатора:

4.2. Представления

Файл представления определяет то, как сериализованные объекты отображаются пользователю.

4.3. URL: ссылки на ресурсы

hotel_app/urls.py :

hotel_reservation/urls.py :

Перейдя по данной ссылке, вы получите доступ ко всем ранее определенным “разделам” REST API проекта:


5. Выводы

Читайте также: