General flow for forms should develop to this:
form = MyModelForm(data)
if form.is_valid():
try:
form.save()
except ValidationError, error:
form.add_error(None, error)
else:
return redirect('success')
return render_failure(form)
While handling such case in
> Append form's non_field_errors with message like
Given that the IntegrityError doesn't occur until the point of .save(),
it's not obvious how that'd work in terms of the Forms API.
You're absolutely correct that there's a class of constraints that can fail
here, but it's not evident to me
Hi guys,
to answer Tim's questions:
> Would Django itself ever raise ValidationError in Model.save()?
That can be possible. Currently I have no clear opinion of where
IntegrityError and other errors should be changed to ValidationError.
> I wonder how you propose converting something like an
I'm also in favor of some solution here. I used to raise a ValidationError
with either a particular field if I was able to extract the particular
error via regex matches, or as non_field_errors. That was my best I had
instead of resulting in a 5xx. In most cases for example a unique race
Would Django itself ever raise ValidationError in Model.save()?
I wonder how you propose converting something like an IntegrityError from
the database into an "friendly" exception for the user?
On Wednesday, November 25, 2015 at 9:23:05 AM UTC-5, Vlastimil Zíma wrote:
>
> Django assumes that
Django assumes that all input data in forms can be validated by
`Form.is_valid()` which in some cases is not true. Database contraints,
e.g. unique, can fail even though they are checked. An application may
require communication with other servers while processing data which can
lead to
