Валидаторы могут быть полезными для переиспользования валидирующей логики для различных полей.
ModelForm
.ModelForm
валидация выполняется частично в форме и частично на экземпляре модели. В REST framework валидация полностью выполняется в классе сериализатора. Это выгодно по следующим причинам:ModelSerializer
и Serializer
. Любое поведение валидации, используемое для ModelSerializer
, легко воспроизвести.repr
экземпляра сериализатора покажет вам, какие именно правила валидации он применяет. В экземпляре модели не вызывается дополнительное скрытое поведение валидации.ModelSerializer
, все это выполняется автоматически. Если вы хотите перейти к использованию классов Serializer вместо этого, вам необходимо явно определить правила валидации.ModelSerializer
, который мы можем использовать для создания или обновления экземпляров CustomerReportRecord
:manage.py shell
, мы сможемreference
. Мы видим, что ограничение уникальности явно принудительно применяется валидатором в поле сериализатора.unique=True
для полей модели. Он принимает один обязательный аргумент и необязательный аргумент messages
:queryset
обязательно - это набор запросов, для которого должна быть применена уникальность.message
- Сообщение об ошибке, которое следует использовать в случае сбоя валидации.lookup
- поиск, используемый для поиска существующего экземпляра с проверяемым значением. По умолчанию - 'exact'
.unique_together
на экземплярах модели. У него есть два обязательных аргумента и один необязательный аргумент messages
:queryset
обязательно - это набор запросов, для которого должна быть применена уникальность.fields
обязательно - список или кортеж имен полей, которые должны составлять уникальный набор. Они должны существовать как поля в классе сериализатора.message
- Сообщение об ошибке, которое следует использовать в случае сбоя валидации.UniqueTogetherValidator
всегда накладывает неявное ограничение, согласно которому все поля, к которым он применяется, всегда обрабатываются как обязательные. Поля со значением default
являются исключением, поскольку они всегда предоставляют значение, даже если они опущены при вводе пользователем.unique_for_date
, unique_for_month
и unique_for_year
для экземпляров модели. Они принимают следующие аргументы:queryset
обязательно - это набор запросов, для которого должна быть применена уникальность.field
обязательно - имя поля, уникальность которого будет проверяться в заданном диапазоне дат. Оно должно существовать как поле в классе сериализатора.date_field
обязательно - Имя поля, которое будет использоваться для определения диапазона дат для ограничения уникальности. Оно должно существовать как поле в классе сериализатора.message
- Сообщение об ошибке, которое следует использовать в случае сбоя валидации.default=...
, потому, что значение, используемое для значения по умолчанию, не будет сгенерировано до тех пор, пока не будет запущена валидация.ModelSerializer
, вы, вероятно, просто будете полагаться на значения по умолчанию, которые REST framework генерирует для вас, но если вы используете Serializer
или просто хотите более явный контроль, используйте один из стилей, показанных ниже.default
, либо установив required=True
.read_only=True
и дополнительно установите аргумент default=...
.HiddenField
. Этот тип поля не принимает вводимые пользователем данные, но вместо этого всегда возвращает значение по умолчанию для validated_data
в сериализаторе.UniqueFor<Range>Validator
налагают неявное ограничение, согласно которому поля, к которым они применяются, всегда обрабатываются как требуемые. Поля со значениями default
являются исключением, поскольку они всегда предоставляют значение, даже если они опущены при вводе пользователем.HiddenField
. Это поле будет присутствовать в validated_data
, но не будет использоваться в выходном представлении сериализатора.read_only=True
, но оно также включает аргумент default=...
. Это поле будет использоваться в выходном представлении сериализатора, но не может быть установлено пользователем напрямую.ModelSerializer
.Meta.validators
.unique_together
требует, чтобы все поля были required=True
. В некоторых случаях вам может потребоваться явное применение required=False
к одному из полей, и в этом случае желаемое поведение валидации будет неоднозначным..validate()
, либо в представлении.instance=...
при создании экземпляра сериализатора..validate()
или в представлении.ModelSerializer
, обычно рекомендуется запустить оболочку manage.py и напечатать экземпляр сериализатора, чтобы вы могли проверить поля и валидаторы, которые он автоматически создается для вас.ModelSerializer
. Это требует немного большего количества кода, но гарантирует, что результирующее поведение будет более прозрачным.serializers.ValidationError
on failure.serializers.ValidationError
в случае неудачи..validate_<field_name>
к вашему подклассу Serializer
. Это описано в Документации по сериализаторам__call__
. Валидаторы на основе классов полезны, поскольку они позволяют параметризировать и повторно использовать поведение.requires_context=True
. Затем будет вызван метод __call__
с параметром serializer_field
или serializer
в качестве дополнительного аргумента.