Gestione delle transazioni con Django 1.6

Se hai mai dedicato molto tempo alla gestione delle transazioni del database di Django, sai quanto può creare confusione. In passato, la documentazione forniva un po' di approfondimento, ma la comprensione veniva solo costruendo e sperimentando.

C'era una pletora di decoratori con cui lavorare, come commit_on_success , commit_manually , commit_unless_managed , rollback_unless_managed , enter_transaction_management , leave_transaction_management , solo per citarne alcuni. Fortunatamente, con Django 1.6 tutto esce dalla porta. Hai davvero bisogno di conoscere solo un paio di funzioni ora. E arriveremo a quelli in appena un secondo. In primo luogo, affronteremo questi argomenti:

• Cos'è la gestione delle transazioni?
• Cosa c'è che non va nella gestione delle transazioni prima di Django 1.6?

Prima di entrare in:

• Cosa c'è di giusto nella gestione delle transazioni in Django 1.6?

E poi fare un esempio dettagliato:

• Esempio di strisce
• Transazioni
• Il modo consigliato
• Utilizzo di un decoratore
• Transazione per richiesta HTTP
• Punti di risparmio
• Transazioni nidificate

Cos'è una transazione?

Secondo SQL-92, "Una transazione SQL (a volte chiamata semplicemente "transazione") è una sequenza di esecuzioni di istruzioni SQL atomica rispetto al ripristino". In altre parole, tutte le istruzioni SQL vengono eseguite e salvate insieme. Allo stesso modo, quando viene eseguito il rollback, tutte le istruzioni vengono ripristinate insieme.

Ad esempio:

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

Quindi una transazione è una singola unità di lavoro in un database. E quella singola unità di lavoro è delimitata da una transazione iniziale e quindi da un commit o da un rollback esplicito.

Cosa c'è che non va nella gestione delle transazioni prima di Django 1.6?

Per rispondere pienamente a questa domanda, dobbiamo affrontare il modo in cui le transazioni vengono gestite nel database, nelle librerie client e all'interno di Django.

Banche dati

Ogni istruzione in un database deve essere eseguita in una transazione, anche se la transazione include una sola istruzione.

La maggior parte dei database ha un AUTOCOMMIT impostazione, che di solito è impostata su True come impostazione predefinita. Questo AUTOCOMMIT avvolge ogni istruzione in una transazione che viene immediatamente salvata se l'istruzione ha esito positivo. Ovviamente puoi chiamare manualmente qualcosa come START_TRANSACTION che sospenderà temporaneamente l'AUTOCOMMIT finché non chiami COMMIT_TRANSACTION o ROLLBACK .

Tuttavia, il take away qui è che l'AUTOCOMMIT l'impostazione applica un commit implicito dopo ogni istruzione .

Librerie client

Poi ci sono le librerie client di Python come sqlite3 e mysqldb, che consentono ai programmi Python di interfacciarsi con i database stessi. Tali librerie seguono una serie di standard su come accedere e interrogare i database. Quello standard, DB API 2.0, è descritto in PEP 249. Sebbene possa fornire una lettura leggermente secca, un aspetto importante è che PEP 249 afferma che il database AUTOCOMMIT dovrebbe essere OFF per impostazione predefinita.

Questo è chiaramente in conflitto con ciò che sta accadendo all'interno del database:

• Le istruzioni SQL devono sempre essere eseguite in una transazione, che generalmente il database apre per te tramite AUTOCOMMIT .
• Tuttavia, secondo PEP 249, questo non dovrebbe accadere.
• Le librerie client devono rispecchiare ciò che accade all'interno del database, ma poiché non sono autorizzate a girare AUTOCOMMIT per impostazione predefinita, avvolgono semplicemente le tue istruzioni SQL in una transazione, proprio come il database.

Bene. Resta con me ancora un po'.

Django

Entra Django. Django ha anche qualcosa da dire sulla gestione delle transazioni. In Django 1.5 e versioni precedenti, Django funzionava sostanzialmente con una transazione aperta e si impegnava automaticamente per quella transazione quando scrivevi i dati nel database. Quindi ogni volta che hai chiamato qualcosa come model.save() o model.update() , Django ha generato le istruzioni SQL appropriate e ha eseguito il commit della transazione.

Anche in Django 1.5 e precedenti, si consigliava di utilizzare TransactionMiddleware per associare le transazioni alle richieste HTTP. Ad ogni richiesta è stata assegnata una transazione. Se la risposta viene restituita senza eccezioni, Django commetterà la transazione ma se la tua funzione di visualizzazione genera un errore, ROLLBACK verrebbe chiamato. Questo in effetti ha disattivato AUTOCOMMIT . Se volevi una gestione delle transazioni in stile autocommit standard a livello di database, dovevi gestire le transazioni tu stesso, di solito utilizzando un decoratore di transazioni sulla tua funzione di visualizzazione come @transaction.commit_manually o @transaction.commit_on_success .

Prendi un respiro. O due.

Cosa significa?

Sì, c'è molto da fare e si scopre che la maggior parte degli sviluppatori vuole solo il commit automatico a livello di database standard, il che significa che le transazioni rimangono dietro le quinte, facendo le loro cose, finché non è necessario regolarle manualmente.

Cosa c'è di giusto nella gestione delle transazioni in Django 1.6?

Ora, benvenuto in Django 1.6. Fai del tuo meglio per dimenticare tutto ciò di cui abbiamo appena parlato e ricorda semplicemente che in Django 1.6 usi il database AUTOCOMMIT e gestire le transazioni manualmente quando necessario. In sostanza, abbiamo un modello molto più semplice che fondamentalmente fa ciò per cui il database è stato progettato in primo luogo.

Basta teoria. Codifichiamo.

Esempio di strisce

Qui abbiamo questa funzione di visualizzazione di esempio che gestisce la registrazione di un utente e la chiamata a Stripe per l'elaborazione della carta di credito.

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)
    )

Questa vista chiama prima Customer.create che in realtà chiama Stripe per gestire l'elaborazione della carta di credito. Quindi creiamo un nuovo utente. Se riceviamo una risposta da Stripe, aggiorniamo il cliente appena creato con stripe_id . Se non riavremo un cliente (Stripe è inattivo), aggiungeremo una voce a UnpaidUsers tabella con l'e-mail dei clienti appena creati, in modo da poter chiedere loro di riprovare i dati della carta di credito in un secondo momento.

L'idea è che anche se Stripe non funziona, l'utente può comunque registrarsi e iniziare a utilizzare il nostro sito. Chiederemo loro di nuovo in un secondo momento le informazioni sulla carta di credito.

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)