I have a simple model:
class InvitationRequest(models.Model):
email = models.EmailField(max_length=255, unique=True)
And a simple model form:
class InvitationRequestForm(forms.ModelForm):
class Meta:
model = InvitationRequest
Now, assuming that I attempt to process it in a standard way:
form = InvitationRequestForm(request.POST)
if form.is_valid():
form.save()
There is a race condition because validation performs a simple SELECT
query to determine whether or not such email is already stored, and if everything is fine then it proceeds to form.save()
line. If there is a concurrent process that does the same at exactly the same moment, then both forms will validate and both processes will call form.save()
thus one will succeed and the other will fail causing an IntegrityError
.
What is the standard way to handle this?
I want to have a standard error in the form object so I can pass it on to the template and notify user about the problem.
I know that:
SERIALIZABLE
transaction (in MySQL as it performs next key locking fo every select then)Model._perform_unique_checks
and make
it use select_for_update
(works with MySQL because of next key locking)None of these solutions is appealing, also I am using PostgreSQL which differs from MySQL in this area.
The standard way is to NOT handle this, as:
If, for some reason, you have to be sure that the problem won't happen, you are on your own.
I haven't analyzed the sequence of events in detail but I think that using the SERIALIZABLE isolation level won't really help, it will only cause IntegrityError
(or DatabaseError
) to be raised in a different place.
Overriding Model._perform_unique_checks
sounds to me like a bad idea, you better stay away from monkey patching if possible (and here it is possible).
As for using the table lock to prevent unlikely errors... Well, I'm not a big fan so I cannot recommend that either.
Here's a nice answer to a similar question: https://stackoverflow.com/a/3523439/176186 - I concur that catching IntegrityError
and retrying is probably the easiest sane way to deal with the problem.
EDIT: I found this: Symfony2 - how to recover from unique constraint error after form submission? and I agree with @pid's answer.
I agree with Tomasz Zielinski that common practice is to not worry about this. For most use cases it's just not worth the trouble.
If it is important, the best way is probably with optimistic concurrency. In this case it might look like (untested):
from django.forms.util import ErrorList
def handle_form(request)
form = InvitationRequestForm(request.POST)
try:
if form.is_valid():
form.save()
return HttpResponseRedirect(...) # redirect to success url
except IntegrityError:
form._errors['email'] = ErrorList()
form._errors['email'].append('Error msg')
return render(...) # re-render the form with errors
SERIALIZABLE
won't really help here. As the PostgreSQL documentation makes clear, you have to be prepared to handle serialization failures, which means that the code would look pretty much the same as above. (It would help, though, if you didn't have the unique
constraint forcing the database to throw an exception.)
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With