Provide API method for appending errors

[Daniel Pope <dan@…>]

On occasion form errors only come to light after a form has been validated. There should be an method to add errors to a form after validation is complete.

A common scenario is for unique database fields. If you test whether the value is unique when cleaning, you introduce a race condition, because the value won't be saved until later. The safe method is this:

if form.is_valid():
    try:
        form.save()
    except IntegrityError:
        form._errors['my_unique_field'] = form.error_class([u"This value already exists. Please choose again"])
    else:
        ...

This works well, but this is an implementation-specific, undocumented method. I'd propose something like

form['my_unique_field'].add_error(u"This value must be unique")

for field-specific errors and

form.add_error(u"This combination of foo and bar already exists")

for non-field errors. These would either raise an error if validation had not yet occurred, or attempt validation before appending the error.

[mrts]

Integrity errors will be fixed when #6845 is commited.

As for other errors, you should use proper field validation in your form.

[Daniel Pope <dan@…>]

#6845 does not eliminate the race condition; it merely automates what's possible with a Form.clean_foo() method now. If you check for uniqueness separately to actually committing the data, you can still get IntegrityError, because doing so is not atomic.

The operation I outlined above is atomic. The approach you've suggested is not an analogue of what I've written, so I'm reopening this ticket.

There are other situations too: filesystem operations, remote procedure invocation... database atomicity was just a very common case that I picked as an example. As I stated above, it occurs any time you cannot reliably verify that something is or is not valid at clean() time and you have to try it to find out if it will work.

This ticket is not about eliminating database integrity errors or race conditions. It just points out that errors can occur outside of form validation code, and that one of the goals of django.newforms is to display errors with user input, regardless of where those errors are detected.

[Karen Tracey <kmtracey@…>]

This has come up (again) as a question on the user's list:

​http://groups.google.com/group/django-users/browse_thread/thread/4dcd1e493d75c3da?hl=en#

Personally I don't know that a new API method is needed, but I think at least the documentation should explicitly note how this kind of thing should be done. Right now as near as I can tell you can figure it out from bits and pieces if you read carefully; it would help if it was addressed directly.

[Mark Lavin]

This seems like a duplicate of #5335 which has a patch, tests and docs.