Gestión de transacciones con Django 1.6

Si alguna vez dedicó mucho tiempo a la gestión de transacciones de la base de datos de Django, sabe lo confuso que puede llegar a ser. En el pasado, la documentación brindaba bastante profundidad, pero la comprensión solo se lograba a través de la construcción y la experimentación.

Había una plétora de decoradores con los que trabajar, como commit_on_success , commit_manually , commit_unless_managed , rollback_unless_managed , enter_transaction_management , leave_transaction_management , Sólo para nombrar unos pocos. Afortunadamente, con Django 1.6 todo sale por la puerta. Realmente solo necesita saber acerca de un par de funciones ahora. Y llegaremos a ellos en solo un segundo. Primero, abordaremos estos temas:

• ¿Qué es la gestión de transacciones?
• ¿Qué tiene de malo la gestión de transacciones antes de Django 1.6?

Antes de saltar a:

• ¿Qué tiene de bueno la gestión de transacciones en Django 1.6?

Y luego tratar con un ejemplo detallado:

• Ejemplo de franja
• Transacciones
• La forma recomendada
• Uso de un decorador
• Transacción por solicitud HTTP
• Puntos de guardado
• Transacciones anidadas

¿Qué es una transacción?

De acuerdo con SQL-92, "Una transacción SQL (a veces llamada simplemente "transacción") es una secuencia de ejecuciones de sentencias SQL que es atómica con respecto a la recuperación". En otras palabras, todas las declaraciones SQL se ejecutan y confirman juntas. Del mismo modo, cuando se revierte, todas las declaraciones se revierten juntas.

Por ejemplo:

# START
note = Note(title="my first note", text="Yay!")
note = Note(title="my second note", text="Whee!")
address1.save()
address2.save()
# COMMIT

Entonces, una transacción es una sola unidad de trabajo en una base de datos. Y esa única unidad de trabajo está delimitada por una transacción de inicio y luego una confirmación o una reversión explícita.

¿Qué tiene de malo la gestión de transacciones antes de Django 1.6?

Para responder completamente a esta pregunta, debemos abordar cómo se manejan las transacciones en la base de datos, las bibliotecas de clientes y dentro de Django.

Bases de datos

Cada declaración en una base de datos debe ejecutarse en una transacción, incluso si la transacción incluye solo una declaración.

La mayoría de las bases de datos tienen un AUTOCOMMIT configuración, que generalmente se establece en True de forma predeterminada. Este AUTOCOMMIT envuelve cada declaración en una transacción que se compromete inmediatamente si la declaración tiene éxito. Por supuesto, puede llamar manualmente a algo como START_TRANSACTION que suspenderá temporalmente el AUTOCOMMIT hasta que llames a COMMIT_TRANSACTION o ROLLBACK .

Sin embargo, lo importante aquí es que el AUTOCOMMIT la configuración aplica una confirmación implícita después de cada declaración .

Bibliotecas cliente

Luego están las bibliotecas cliente de Python. como sqlite3 y mysqldb, que permiten que los programas de Python interactúen con las propias bases de datos. Tales bibliotecas siguen un conjunto de estándares sobre cómo acceder y consultar las bases de datos. Ese estándar, DB API 2.0, se describe en PEP 249. Si bien puede ser una lectura un poco seca, una conclusión importante es que PEP 249 establece que la base de datos AUTOCOMMIT debe estar APAGADO por defecto.

Esto claramente entra en conflicto con lo que sucede dentro de la base de datos:

• Las declaraciones SQL siempre tienen que ejecutarse en una transacción, que la base de datos generalmente abre para usted a través de AUTOCOMMIT .
• Sin embargo, según PEP 249, esto no debería ocurrir.
• Las bibliotecas cliente deben reflejar lo que sucede dentro de la base de datos, pero dado que no se les permite activar AUTOCOMMIT activados de forma predeterminada, simplemente envuelven sus instrucciones SQL en una transacción, al igual que la base de datos.

Bueno. Quédate conmigo un poco más.

Django

Entra Django. Django también tiene algo que decir sobre la gestión de transacciones. En Django 1.5 y versiones anteriores, Django básicamente se ejecutaba con una transacción abierta y autocomprometía esa transacción cuando escribía datos en la base de datos. Así que cada vez que llamaste a algo como model.save() o model.update() , Django generó las sentencias SQL apropiadas y comprometió la transacción.

También en Django 1.5 y versiones anteriores, se recomendaba usar el TransactionMiddleware para vincular transacciones a solicitudes HTTP. A cada solicitud se le dio una transacción. Si la respuesta regresara sin excepciones, Django confirmaría la transacción, pero si su función de visualización arrojara un error, ROLLBACK sería llamado. Esto, en efecto, desactivó AUTOCOMMIT . Si deseaba una gestión de transacciones de estilo de confirmación automática estándar a nivel de base de datos, tenía que gestionar las transacciones usted mismo, normalmente mediante el uso de un decorador de transacciones en su función de vista como @transaction.commit_manually , o @transaction.commit_on_success .

Tomar un respiro. O dos.

¿Qué significa esto?

Sí, están sucediendo muchas cosas allí, y resulta que la mayoría de los desarrolladores solo quieren las confirmaciones automáticas de nivel de base de datos estándar, lo que significa que las transacciones permanecen detrás de escena, haciendo lo suyo, hasta que necesite ajustarlas manualmente.

¿Qué tiene de bueno la gestión de transacciones en Django 1.6?

Ahora, bienvenido a Django 1.6. Haz tu mejor esfuerzo para olvidar todo lo que acabamos de hablar y simplemente recuerda que en Django 1.6, usas la base de datos AUTOCOMMIT y gestione las transacciones manualmente cuando sea necesario. Esencialmente, tenemos un modelo mucho más simple que básicamente hace lo que la base de datos fue diseñada para hacer en primer lugar.

Basta de teoría. Codifiquemos.

Ejemplo de rayas

Aquí tenemos esta función de vista de ejemplo que maneja el registro de un usuario y llama a Stripe para el procesamiento de tarjetas de crédito.

def register(request):
    user = None
    if request.method == 'POST':
        form = UserForm(request.POST)
        if form.is_valid():

            customer = Customer.create("subscription",
              email = form.cleaned_data['email'],
              description = form.cleaned_data['name'],
              card = form.cleaned_data['stripe_token'],
              plan="gold",
            )

            cd = form.cleaned_data
            try:
                user = User.create(cd['name'], cd['email'], cd['password'],
                   cd['last_4_digits'])

                if customer:
                    user.stripe_id = customer.id
                    user.save()
                else:
                    UnpaidUsers(email=cd['email']).save()

            except IntegrityError:
                form.addError(cd['email'] + ' is already a member')
            else:
                request.session['user'] = user.pk
                return HttpResponseRedirect('/')

    else:
      form = UserForm()

    return render_to_response(
        'register.html',
        {
          'form': form,
          'months': range(1, 12),
          'publishable': settings.STRIPE_PUBLISHABLE,
          'soon': soon(),
          'user': user,
          'years': range(2011, 2036),
        },
        context_instance=RequestContext(request)
    )

Esta vista primero llama a Customer.create que en realidad llama a Stripe para manejar el procesamiento de la tarjeta de crédito. Luego creamos un nuevo usuario. Si recibimos una respuesta de Stripe, actualizamos el cliente recién creado con el stripe_id . Si no recuperamos a un cliente (Stripe no funciona), agregaremos una entrada a UnpaidUsers tabla con el correo electrónico de los clientes recién creados, para que podamos pedirles que vuelvan a intentar los detalles de su tarjeta de crédito más tarde.

La idea es que incluso si Stripe no funciona, el usuario aún puede registrarse y comenzar a usar nuestro sitio. Simplemente les pediremos nuevamente en una fecha posterior la información de la tarjeta de crédito.

cd = form.cleaned_data
try:
    user = User.create(
        cd['name'], cd['email'], 
        cd['password'], cd['last_4_digits'])

    if customer:
        user.stripe_id = customer.id
        user.save()
    else:
        UnpaidUsers(email=cd['email']).save()

except IntegrityError:
    # ...

@mock.patch('payments.models.UnpaidUsers.save', side_effect = IntegrityError)
def test_registering_user_when_strip_is_down_all_or_nothing(self, save_mock):

    #create the request used to test the view
    self.request.session = {}
    self.request.method='POST'
    self.request.POST = {'email' : '[email protected]',
                         'name' : 'pyRock',
                         'stripe_token' : '...',
                         'last_4_digits' : '4242',
                         'password' : 'bad_password',
                         'ver_password' : 'bad_password',
                        }

    #mock out stripe  and ask it to throw a connection error
    with mock.patch('stripe.Customer.create', side_effect =
                    socket.error("can't connect to stripe")) as stripe_mock:

        #run the test
        resp = register(self.request)

        #assert there is no record in the database without stripe id.
        users = User.objects.filter(email="[email protected]")
        self.assertEquals(len(users), 0)

        #check the associated table also didn't get updated
        unpaid = UnpaidUsers.objects.filter(email="[email protected]")
        self.assertEquals(len(unpaid), 0)

resp = register(self.request)

#assert there is no record in the database without stripe_id.
users = User.objects.filter(email="[email protected]")
self.assertEquals(len(users), 0)

#check the associated table also didn't get updated
unpaid = UnpaidUsers.objects.filter(email="[email protected]")
self.assertEquals(len(unpaid), 0)

======================================================================
FAIL: test_registering_user_when_strip_is_down_all_or_nothing (tests.payments.testViews.RegisterPageTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/j1z0/.virtualenvs/django_1.6/lib/python2.7/site-packages/mock.py", line 1201, in patched
    return func(*args, **keywargs)
  File "/Users/j1z0/Code/RealPython/mvp_for_Adv_Python_Web_Book/tests/payments/testViews.py", line 266, in test_registering_user_when_strip_is_down_all_or_nothing
    self.assertEquals(len(users), 0)
AssertionError: 1 != 0

----------------------------------------------------------------------

from django.db import transaction

try:
    with transaction.atomic():
        user = User.create(
            cd['name'], cd['email'], 
            cd['password'], cd['last_4_digits'])

        if customer:
            user.stripe_id = customer.id
            user.save()
        else:
            UnpaidUsers(email=cd['email']).save()

except IntegrityError:
    form.addError(cd['email'] + ' is already a member')

@transaction.atomic():
def register(request):
    # ...snip....

    try:
        user = User.create(
            cd['name'], cd['email'], 
            cd['password'], cd['last_4_digits'])

        if customer:
            user.stripe_id = customer.id
            user.save()
        else:
                UnpaidUsers(email=cd['email']).save()

    except IntegrityError:
        form.addError(cd['email'] + ' is already a member')

from django.db import transaction

try:
    with transaction.atomic():
        user = User.create(
            cd['name'], cd['email'], 
            cd['password'], cd['last_4_digits'])

        if customer:
            user.stripe_id = customer.id
            user.save()
        else:
            UnpaidUsers(email=cd['email']).save()

except IntegrityError:
    form.addError(cd['email'] + ' is already a member')

DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.sqlite3',
        'NAME': os.path.join(SITE_ROOT, 'test.db'),
        'ATOMIC_REQUEST': True,
    }
}

@transaction.atomic()
def save_points(self,save=True):

    user = User.create('jj','inception','jj','1234')
    sp1 = transaction.savepoint()

    user.name = 'starting down the rabbit hole'
    user.stripe_id = 4
    user.save()

    if save:
        transaction.savepoint_commit(sp1)
    else:
        transaction.savepoint_rollback(sp1)

user.name = 'starting down the rabbit hole'
user.stripe_id = 4
user.save()

def test_savepoint_rollbacks(self):

    self.save_points(False)

    #verify that everything was stored
    users = User.objects.filter(email="inception")
    self.assertEquals(len(users), 1)

    #note the values here are from the original create call
    self.assertEquals(users[0].stripe_id, '')
    self.assertEquals(users[0].name, 'jj')


def test_savepoint_commit(self):
    self.save_points(True)

    #verify that everything was stored
    users = User.objects.filter(email="inception")
    self.assertEquals(len(users), 1)

    #note the values here are from the update calls
    self.assertEquals(users[0].stripe_id, '4')
    self.assertEquals(users[0].name, 'starting down the rabbit hole')

@transaction.atomic()
def save_points(self,save=True):

    user = User.create('jj','inception','jj','1234')
    sp1 = transaction.savepoint()

    user.name = 'starting down the rabbit hole'
    user.save()

    user.stripe_id = 4
    user.save()

    if save:
        transaction.savepoint_commit(sp1)
    else:
        transaction.savepoint_rollback(sp1)

    user.create('limbo','illbehere@forever','mind blown',
           '1111')

@transaction.atomic()
def save_points(self,save=True):

    user = User.create('jj','inception','jj','1234')
    sp1 = transaction.savepoint()

    user.name = 'starting down the rabbit hole'
    user.save()

    user.stripe_id = 4
    user.save()

    if save:
        transaction.savepoint_commit(sp1)
    else:
        transaction.savepoint_rollback(sp1)

    try:
        with transaction.atomic():
            user.create('limbo','illbehere@forever','mind blown',
                   '1111')
            if not save: raise DatabaseError
    except DatabaseError:
        pass

 def test_savepoint_rollbacks(self):

    self.save_points(False)

    #verify that everything was stored
    users = User.objects.filter(email="inception")
    self.assertEquals(len(users), 1)

    #savepoint was rolled back so we should have original values
    self.assertEquals(users[0].stripe_id, '')
    self.assertEquals(users[0].name, 'jj')

    #this save point was rolled back because of DatabaseError
    limbo = User.objects.filter(email="illbehere@forever")
    self.assertEquals(len(limbo),0)

def test_savepoint_commit(self):
    self.save_points(True)

    #verify that everything was stored
    users = User.objects.filter(email="inception")
    self.assertEquals(len(users), 1)

    #savepoint was committed
    self.assertEquals(users[0].stripe_id, '4')
    self.assertEquals(users[0].name, 'starting down the rabbit hole')

    #save point was committed by exiting the context_manager without an exception
    limbo = User.objects.filter(email="illbehere@forever")
    self.assertEquals(len(limbo),1)