Opened 10 years ago

Closed 6 years ago

#7444 closed New feature (duplicate)

Provide API method for appending errors

Reported by: Daniel Pope <dan@…> Owned by: nobody
Component: Forms Version: master
Severity: Normal Keywords:
Cc: bronger@… Triage Stage: Design decision needed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no


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():
    except IntegrityError:
        form._errors['my_unique_field'] = form.error_class([u"This value already exists. Please choose again"])

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.

Change History (7)

comment:1 Changed 10 years ago by mrts

Resolution: invalid
Status: newclosed

Integrity errors will be fixed when #6845 is commited.

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

comment:2 Changed 10 years ago by Daniel Pope <dan@…>

Resolution: invalid
Status: closedreopened

#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.

comment:3 Changed 10 years ago by Torsten Bronger

Cc: bronger@… added

comment:4 Changed 10 years ago by Karen Tracey <kmtracey@…>

Triage Stage: UnreviewedDesign decision needed

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

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.

comment:5 Changed 7 years ago by Luke Plant

Severity: Normal
Type: New feature

comment:6 Changed 6 years ago by Mark Lavin

Easy pickings: unset
UI/UX: unset

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

comment:7 Changed 6 years ago by Karen Tracey

Resolution: duplicate
Status: reopenedclosed
Note: See TracTickets for help on using tickets.
Back to Top