What is the point of ATOMIC_REQUEST in Django 1.6

155 views
Skip to first unread message

j1z0

unread,
Dec 19, 2013, 8:45:25 AM12/19/13
to django...@googlegroups.com
Guys,

Looking for a little bit of help here understanding ATOMIC_REQUEST in Django 1.6

I've posted the question on Stack Overflow


But I thought I would try here as well.  I'll copy the question below (would appreciate any advice):  

given the following code:

from django.db import transaction

@transaction.atomic
def viewfunc(request):
    # This code executes inside a transaction.
    do_stuff()

From my understanding of transactions in Django 1.6 if do_stuff throws an exception, say an IntegrityError, then the transaction will be rolled back right. But since Django itself is calling the view nothing will stop the IntegrityError from rising up the call stack and causing an HTTP 500 error yes? Let's assume that's not what we want, as we want to gracefully handle the error, but still get the rollback functionality.

So I guess the obvious thought is well, don't do that, use transaction.atomic as a context manager that is wrapped in a try except block like the example here:

try:
    with transaction.atomic():
        generate_relationships()
except IntegrityError:
    handle_exception()

Fine. But then if you want to use the Transaction per HTTP Request functionality by setting ATOMIC_REQUEST = True in your db config, which means django will in effect just add thetransaction.atomic decorate to your view, which won't catch any exceptions. How is ATOMIC_REQUEST even useful? Why would you ever want to let your Database errors propagate all the way up to the user?

So my question is.

  1. What am I missing here or is my understanding correct?
  2. If I'm correct what is a use case for using ATOMIC_REQUEST? Am I expected to write aurls.hadler500 or should I implement some middle wear to catch the errors?

Someone please shed some light on this for me.

Thanks in advance.

j1z0

Reply all
Reply to author
Forward
0 new messages