Zarządzanie transakcjami z Django 1.6

Jeśli kiedykolwiek poświęciłeś dużo czasu na zarządzanie transakcjami w bazie danych Django, wiesz, jak bardzo może to być zagmatwane. W przeszłości dokumentacja zapewniała sporo głębi, ale zrozumienie można było uzyskać tylko poprzez budowanie i eksperymentowanie.

Było mnóstwo dekoratorów do pracy, takich jak commit_on_success , commit_manually , commit_unless_managed , rollback_unless_managed , enter_transaction_management , leave_transaction_management , żeby wymienić tylko kilka. Na szczęście z Django 1.6 wszystko wychodzi poza drzwi. Teraz naprawdę musisz wiedzieć tylko o kilku funkcjach. A do nich dojdziemy za chwilę. Najpierw zajmiemy się tymi tematami:

• Co to jest zarządzanie transakcjami?
• Co jest nie tak z zarządzaniem transakcjami przed Django 1.6?

Przed przejściem do:

• Co jest dobrego w zarządzaniu transakcjami w Django 1.6?

A potem zajmijmy się szczegółowym przykładem:

• Przykład paska
• Transakcje
• Zalecany sposób
• Korzystanie z dekoratora
• Transakcja na żądanie HTTP
• Zapisz punkty
• Zagnieżdżone transakcje

Co to jest transakcja?

Zgodnie z SQL-92 „Transakcja SQL (czasami nazywana po prostu „transakcją”) to sekwencja wykonań instrukcji SQL, która jest niepodzielna w odniesieniu do odzyskiwania”. Innymi słowy, wszystkie instrukcje SQL są wykonywane i zatwierdzane razem. Podobnie po wycofaniu wszystkie stwierdzenia są wycofywane razem.

Na przykład:

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

Tak więc transakcja to pojedyncza jednostka pracy w bazie danych. A ta pojedyncza jednostka pracy jest odgraniczona przez transakcję początkową, a następnie zatwierdzenie lub jawne wycofanie.

Co jest nie tak z zarządzaniem transakcjami przed Django 1.6?

Aby w pełni odpowiedzieć na to pytanie, musimy zająć się sposobem obsługi transakcji w bazie danych, bibliotekach klienta i w Django.

Bazy danych

Każdy wyciąg w bazie danych musi zostać uruchomiony w transakcji, nawet jeśli transakcja zawiera tylko jeden wyciąg.

Większość baz danych ma funkcję AUTOCOMMIT ustawienie, które jest zwykle ustawione na True jako domyślne. To AUTOCOMMIT otacza każdą instrukcję w transakcji, która jest natychmiast zatwierdzana, jeśli instrukcja się powiedzie. Oczywiście możesz ręcznie wywołać coś takiego jak START_TRANSACTION co tymczasowo zawiesi AUTOCOMMIT dopóki nie zadzwonisz do COMMIT_TRANSACTION lub ROLLBACK .

Jednakże wniosek jest taki, że AUTOCOMMIT ustawienie stosuje niejawne zatwierdzenie po każdej instrukcji .

Biblioteki klienta

Są też biblioteki klienckie Pythona jak sqlite3 i mysqldb, które umożliwiają programom Pythona łączenie się z samymi bazami danych. Takie biblioteki przestrzegają zestawu standardów dotyczących dostępu do baz danych i wykonywania zapytań. Ten standard, DB API 2.0, jest opisany w PEP 249. Chociaż może to sprawić, że czytanie może być nieco suche, ważnym wnioskiem jest to, że PEP 249 stwierdza, że ​​baza danych AUTOCOMMIT powinna być WYŁĄCZONA domyślnie.

To wyraźnie koliduje z tym, co dzieje się w bazie danych:

• Wyrażenia SQL zawsze muszą być uruchamiane w transakcji, którą baza danych zazwyczaj otwiera dla Ciebie za pomocą funkcji AUTOCOMMIT .
• Jednak według PEP 249 nie powinno to mieć miejsca.
• Biblioteki klienta muszą odzwierciedlać to, co dzieje się w bazie danych, ale ponieważ nie mogą włączać funkcji AUTOCOMMIT domyślnie, po prostu zawijają twoje instrukcje SQL w transakcję, tak jak baza danych.

Dobra. Zostań ze mną trochę dłużej.

Django

Wejdź do Django. Django ma też coś do powiedzenia na temat zarządzania transakcjami. W Django 1.5 i wcześniejszych, Django zasadniczo działał z otwartą transakcją i automatycznie zatwierdzał tę transakcję, gdy zapisywałeś dane do bazy danych. Więc za każdym razem, gdy wywołałeś coś takiego jak model.save() lub model.update() , Django wygenerowało odpowiednie instrukcje SQL i zatwierdziło transakcję.

Również w Django 1.5 i wcześniejszych zalecano użycie TransactionMiddleware powiązania transakcji z żądaniami HTTP. Każde żądanie otrzymało transakcję. Jeśli odpowiedź zostanie zwrócona bez wyjątków, Django zatwierdzi transakcję, ale jeśli twoja funkcja widoku zwróci błąd, ROLLBACK zostanie nazwany. W efekcie wyłączono funkcję AUTOCOMMIT . Jeśli chciałeś standardowego zarządzania transakcjami w stylu automatycznego zatwierdzania na poziomie bazy danych, musiałeś samodzielnie zarządzać transakcjami - zwykle za pomocą dekoratora transakcji w funkcji widoku, takiego jak @transaction.commit_manually lub @transaction.commit_on_success .

Wziąć oddech. Albo dwa.

Co to oznacza?

Tak, dużo się tam dzieje i okazuje się, że większość programistów chce tylko standardowych automatycznych zatwierdzeń na poziomie bazy danych – co oznacza, że ​​transakcje pozostają w ukryciu, robiąc swoje, dopóki nie będziesz musiał ich ręcznie dostosować.

Co jest dobrego w zarządzaniu transakcjami w Django 1.6?

Witamy w Django 1.6. Postaraj się zapomnieć o wszystkim, o czym właśnie rozmawialiśmy, i po prostu pamiętaj, że w Django 1.6 używasz bazy danych AUTOCOMMIT i w razie potrzeby zarządzaj transakcjami ręcznie. Zasadniczo mamy znacznie prostszy model, który zasadniczo robi to, do czego baza danych została zaprojektowana w pierwszej kolejności.

Dość teorii. Zróbmy kod.

Przykład paska

Tutaj mamy tę przykładową funkcję widoku, która obsługuje rejestrację użytkownika i wywołanie Stripe w celu przetworzenia karty kredytowej.

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

Ten widok najpierw wywołuje Customer.create który faktycznie wywołuje Stripe do obsługi przetwarzania kart kredytowych. Następnie tworzymy nowego użytkownika. Jeśli otrzymaliśmy odpowiedź od Stripe, aktualizujemy nowo utworzonego klienta za pomocą stripe_id . Jeśli nie odzyskamy klienta (Stripe nie działa), dodamy wpis do UnpaidUsers tabela z nowo utworzonym adresem e-mail klienta, dzięki czemu możemy poprosić ich o ponowne ponowną próbę danych karty kredytowej później.

Chodzi o to, że nawet jeśli Stripe nie działa, użytkownik nadal może się zarejestrować i zacząć korzystać z naszej strony. Po prostu poprosimy ich ponownie w późniejszym terminie o dane karty kredytowej.

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)