Opened 16 years ago

Closed 13 years ago

#7444 closed New feature (duplicate)

Provide API method for appending errors

Reported by: Daniel Pope <dan@…> Owned by: nobody
Component: Forms Version: dev
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

Description

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.

Change History (7)

comment:1 by mrts, 16 years ago

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 by Daniel Pope <dan@…>, 16 years ago

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 by Torsten Bronger, 16 years ago

Cc: bronger@… added

comment:4 by Karen Tracey <kmtracey@…>, 16 years ago

Triage Stage: UnreviewedDesign decision needed

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.

comment:5 by Luke Plant, 13 years ago

Severity: Normal
Type: New feature

comment:6 by Mark Lavin, 13 years ago

Easy pickings: unset
UI/UX: unset

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

comment:7 by Karen Tracey, 13 years ago

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