Безопасная проверка неверных данных в ModelChoiceField - Django 1.11

Question

У меня есть кодовая база, которую я пытаюсь перенести с Django 1.8 на 1.11.Да, я отсталPython 3.X и Django 2.X будут более поздним этапом.

При выполнении миграции мои тесты показывают, что в Django 1.8 отправка действительно неверных данных в ModelChoiceField используется для генерации ошибки наполе, а затем форма, которая возвращается в исходное состояние - теперь в Django 1.11 тот же самый ввод приводит к тому, что форма выдает ошибку DataError.

Например - если ModelChoiceField дает идентификатор данной модели (целое число) и вы введете POST, который является строкой, вы получите что-то вроде:

E DataError: недопустимый синтаксис ввода для целого числа: "плохая роль"

E LINE 1:... me "= '') AND" gbe_profile "." workeritem_ptr_id "= 'bad role' ...

для формы, которая выглядит следующим образом:

'' 'из импорта django.forms (CharField, ModelForm, HiddenInput, ModelChoiceField,) из gbe.models, импорт StaffArea из tinymce.widgets, импорт TinyMCE из gbe.forms.common_queries, импорт visible_profiles

, класс StaffAreaForm (ModelForm): required_csscss = 'required' error_css_class = 'error'

description = CharField(
    widget=TinyMCE(attrs={'cols': 80, 'rows': 20}))
staff_lead = ModelChoiceField(
    queryset=visible_profiles,
    required=False)

class Meta:
    model = StaffArea
    fields = '__all__'
    widgets = {'conference': HiddenInput()}

'' '

А модель, которая имеет типичный первичный ключ по умолчанию ( модель , длинная иподкласс, поэтому пропускаем его публикацию)

То же самое верно и в моих тестах, и в тестировании вручную, взломав форму.

Мне нужна помощь в нескольких направлениях:

• Есть ли у кого-нибудь элегантный (или даже слегка не зверский хак) для проверки синтаксиса перед выполнением SQL вМодельная форма?Это просто из-за того, что я вижу, как ошибка SQL пролетает до самого пользователя?Такое ощущение, что перед этим должен быть слой контроля валидации.
• За исключением этого - есть ли способ в значительной степени восстановить лучшую обработку ошибок?Я бы очень предпочел работу Django 1.8 здесь - это дает пользователю ошибку вокруг разбитого поля и возвращает его в безопасное состояние ввода - это лучший пользовательский опыт.Кроме того, это помогло бы мне не проводить рефакторинг тонны тестов.
• (бонусные баллы за любопытство) - почему это изменение?Всегда приятно понимать философию в изменении подхода к чему-то подобному.