使用Python的Django架構實現事務交易管理的教程

如果你花費了很多的時間去進行Django資料庫交易處理的話，你將會瞭解到這是讓人暈頭轉向的。

在過去，只是提供了簡單的基礎文檔，要想清楚知道它是怎麼使用的，還必須要通過建立和執行Django的交易處理。

這裡有眾多的Django交易處理的名詞，例如：commit_on_success , commit_manually , commit_unless_maneged，rollback_unless_managed,enter_transaction_management,leace_transaction_management，這些只是其中的一部分而已。

最讓人感到幸運的是，Django 1.6版本發布後。現在你可以緊緊使用幾個函數就可以實現交易處理了，在我們進入學習這些函數的幾秒之前。首先，我們要明確下面這些問題：

• 什麼是交易處理呢？
• Django 1.6中的出現了那些新的事物處理優先權?

在進入“要怎麼才是Django 1.6版本中正確的交易處理”之前，請先瞭解一下下面的詳細案例：

帶狀案例

事務

• 推薦的方式
• 使用分隔字元
• 每一個HTTP請求事務

儲存點

嵌套的事務

事務是什嗎？

根據SQL-92所說，"一個SQL事務(有時簡稱為事務)是一個可以原子性恢複的SQL語句執行序列"。換句話說，所有的SQL語句一起執行和提交。同樣的，當復原時，所有語句也一併復原。

例如：

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

所以一個事務是 資料庫中單個的工作單元。它是由一個start transaction開始和一個commit或者顯式的rollback結束。

Django 1.6之前的交易管理有什麼問題?

為了完整地回答這個問題，我們必須闡述一下事務在資料庫、用戶端以及Django中是如何處理的。

資料庫

資料庫中的每一條語句都運行在一個事務中，這個事務甚至可以只包含一條語句。

幾乎所有的資料庫都有一個AUTOCOMMIT設定，通常它被預設設定為True。AUTOCOMMIT將所有語句封裝到一個事務裡，只要語句成功執行，這個事務就立即被提交。當然你也可以手動調用START_TRANSACTION，它會暫時將AUTOCOMMIT掛起，直到你調用COMMIT_TRANSACTION或者ROLLBACK。

然後，這種方式將會使AUTOCOMMIT設定的作用於每條語句後的隱式提交失效。

然而，有諸如像sqlite3和mysqldb的python用戶端庫，它允許python程式與資料庫本身相串連。這些庫遵循一套如何訪問與查詢資料庫的標準。該DB API 2.0標準，被描述在PEP 249之中。雖然它可能讓人閱讀稍幹一些。一個重要帶走的是，在PEP 249狀態之中，預設資料庫應該關閉自動認可功能。

這明顯與資料庫內發生了什麼矛盾衝突：

• 資料庫語句總是要在一個事務中運行。此資料庫一般會為你開啟自動認可功能。
• 不過，根據PEP 249，這不應該發生。
• 用戶端庫必須反映在資料庫之中發生了什嗎？但由於他們不允許預設開啟自動認可功能。他們只是簡單地在一個事務中包裹sql語句。就像資料庫。

好啦，在我身邊呆久一些吧。

Django

進入Django,Django也有關於交易處理的話要說。在Django 1.5和更早的版本。當你寫資料到資料庫時，Django基本上是運行一個開放的事務和自動認可該事務功能。所以每次你所稱謂的像諸如model.save() 或者model.update()的東西，Django產生相應的sql語句，並提交該事務。

也有在Django 1.5和更早的版本，它是建議你使用TransactionMiddleware綁定http請求事務。每個請求提供了一個事務。如果返回的響應沒有異常，Django會提交此事務。但如果你的視圖功能拋出一個錯誤，復原將被調用。這實際上說明，它關閉了自動認可功能。如果你想要標準化，資料庫層級自動認可風格式的交易管理，你必須管理你自己的交易-通常是通過使用事務裝飾你的視圖功能，例如@transaction.commit_manually,或者@transaction.commit_on_success.

吸一口氣，或者兩口。

這意味著什嗎？

是啊，在那兒有許多事情要做，而事實證明，大多數開發人員正需要這個標準資料庫級的自動認可功能-有意義的事務往往是留在幕後處理的。做你自己的事，直到你需要手動調整他們。

在Django 1.6版本之中，什麼是正確關於交易管理呢？

現在，歡迎來到Django 1.6.儘力忘掉一切吧，我們只是談論而已，只是記得在Django 1.6中，你可以使用資料庫，需要時可以手動自動認可和管理事務。從本質上來說，我們有一個更簡單的模型，基本上是要把設計什麼樣的資料庫擺在首位。

好啦！大功告成，讓我們寫代碼吧？

Stripe案例

下面，我們使用處理一個使用者註冊的例子，調用了Stripe來處理信用卡進程。

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

例子首先調用了Customer.create,實際上就是調用Stripe來處理信用卡進程，然後我們建立一個新使用者。如果我們得到來自Stripe的響應，我們就用stripe_id更新新建立的使用者。如果我們沒有得到響應（Stripe已關閉），我們將用新建立使用者的email向UnpaidUsers表增加一個新條目，這樣我們可以讓他們稍後重試他們信用卡資訊。

思路是這樣的：如果Stripe沒有響應，使用者依然可以註冊，然後開始使用我們的網站。我們將在稍後的時候讓使用者提供信用卡的資訊。

“我明白這是一個特殊的例子，並且這也不是我想完成的功能的方式，但是它的目的是展示交易”

考慮交易，牢記住在Django1.6中提供了對於資料庫的“AUTOCOMMIT”功能。接下來看一下資料庫相關的代碼：

cd = form.cleaned_datatry:  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:

你能發現問題了嗎？如果“UnpaidUsers(email=cd['email']).save()” 運行失敗，會發生什嗎？

有一個使用者，註冊了系統；然後系統認為已經核對過信用卡了。但是事實上，系統並沒有核對過。

我們僅僅想得到其中一種結果：

1.在資料庫中建立了使用者，並有了stripe_id

2.在資料庫中建立了使用者，但是沒有stripe_id。同時在相關的“UnpaidUsers”行，存有相同的郵件地址

這就意味著，我們想要的是分開的資料庫語句頭完成任務或者復原。這個例子很好的說明了這個交易。

首先，我們寫一些測試案例來驗證事情是否按照我們想象的方式運行：

@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' : 'python@rocks.com',             '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="python@rocks.com")    self.assertEquals(len(users), 0)     #check the associated table also didn't get updated    unpaid = UnpaidUsers.objects.filter(email="python@rocks.com")    self.assertEquals(len(unpaid), 0)

當我們嘗試去儲存“UnpaidUsers”，測試上方的解譯器就會跑出異常'IntegrityError' 。

接下來是解釋這個問題的答案，“當“UnpaidUsers(email=cd['email']).save()”啟動並執行時候到底發生了什嗎？” 下面一段代碼建立了一段對話，我們需要在註冊函數中給出一些合適的資訊。然後“with mock.patch” 會強制系統去認為Stripe沒響應，最終就跳到我們的測試案例中。

resp = register(self.request)

上面這段話僅僅是調用我們的註冊視圖去傳遞請求。然後我們僅僅需要去核對錶是否有更新:

#assert there is no record in the database without stripe_id.users = User.objects.filter(email="python@rocks.com")self.assertEquals(len(users), 0) #check the associated table also didn't get updatedunpaid = UnpaidUsers.objects.filter(email="python@rocks.com")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 ----------------------------------------------------------------------

贊。這就是我們最終想要的結果。

記住：我們這裡已經練習了“測試驅動開發”的能力。錯誤資訊提示我們：使用者資訊已經被儲存到資料庫中，但是這個並不是我們想要的，因為我們並沒有付費!

事務交易用於挽救這樣問題 ...

事務

對於Django1.6,有很多種方式來建立事務。

這裡簡單介紹幾種。
推薦的方法

依據Django1.6的文檔，“Django提供了一種簡單的API去控制資料庫的事務交易...原子操作用來定義資料庫事務的屬性。原子操作允許我們在資料庫保證的前提下，建立一堆代碼。如果這些代碼被成功的執行，所對應的改變也會提交到資料庫中。如果有異常發生，那麼操作就會復原。”

原子操作可以被用於解釋操作或者是內容管理。所以如果我們用作為內容管理的時候，我們的註冊函數的代碼就會如下：

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

注意在“with transaction.atomic()”這一行。這塊代碼將會在事務內部執行。所以如果我們重新運行了我們的測試，他們都將會通過。

記住：事務是一個工作單元，所以當“UnpaidUsers”調用失敗的時候，內容管理的所有操作都會被一起復原。

使用裝飾器

除了上面的做法，我們能使用Python的裝飾器特性來使用事務。

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

如果我們重新跑一次測試，那還是會一樣失敗。

為啥呢？為啥事務沒有正確復原呢？原因在與transaction.atomic會嘗試捕獲某種異常，而我們代碼裡人肉捕抓了（例如 try-except 代碼塊裡的IntegrityError 異常），所以 transaction.atomic 永遠看不到這個異常，所以標準的AUTOCOMMIT 流程就此無效掉。

但是，刪掉try-catch語句會導致異常沒有捕獲，然後代碼流程十有八九會就此亂掉。所以啊，也就是說不能去掉try-catch。

所以，技巧是將原子上下文管理器放入我們在第一個解決方案中的 try-catch 程式碼片段裡。

再看一下正確的代碼：

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

當 UnpaidUsers 觸發 IntegrityError 時，上下文管理器 transaction.atomic() 會捕獲到它，並執行復原操作。此時我們的代碼在異常處理中執行（即行 theform.addErrorline），將會完成復原操作，並且，如果必要的話，也可以安全的進行資料庫調用。也要注意：任何在上下文管理器 thetransaction.atomic() 前後的資料庫調用都不會受到它的執行結果的影響。

針對每次HTTP請求的事務交易

Django1.5和1.6版本都允許使用者操作請求事務模式。在這種模式下，Django會自動在事務中，處理你的視圖函數。如果視圖函數拋出異常，Django會自動復原事務；否則Django會提交事務。

為了實現這個功能，你需要在你想要有此功能的資料庫的配置中，設定“ATOMIC_REQUEST”為真。所以在我們的“settings.py”需要有如下設定：

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

如果我們把解譯器放到視圖函數中，以上設定就會生效。所以這並沒有符合我們的想法。

但是，這裡依然值得注意的是解譯器：“ATOMIC_REQUESTS”和“@transaction.atomic”仍然會有可能在有異常拋出的時候，處理這些錯誤。為了去捕捉這些錯誤，你需要去完成一些常規的中介軟體，或者需要去覆蓋“urls.hadler500”，或者是建立新的“500.html”模板。

儲存點

儘管事務是有原子性的，但還是能夠打散為多個“儲存點”——你可看作是“部分事務”。

例如，你有個事務包含了4條SQL語句，你可以在第二個SQL之後建立一個儲存點。一旦儲存點建立成功，就算第三條或第四條SQL執行失敗，你仍舊能夠做一個部分復原，忽視後面兩條SQL，僅保留前面兩條。

基本上，這就像是提供了一個切割的能力：一個普通的事務能夠被切分為多個更“輕量”的事務，然後能進行部分復原或部分提交。

但一定要注意，小心整個事務被無端復原掉（例如由於拋出了IntegrityError異常但卻沒有捕抓，那所有的儲存點都會因此被復原掉的）

來看個範例程式碼，瞭解怎麼玩轉儲存點。

@transaction.atomic()def save_points(self,save=True):   user = User.create('jj','inception','jj','1234')  sp1 = transaction.savepoint()   user.name = 'zheli hui guadiao, T.T'  user.stripe_id = 4  user.save()   if save:    transaction.savepoint_commit(sp1)  else:    transaction.savepoint_rollback(sp1)

樣本中，整個函數都是屬於一個事務的。新User對象建立後，我們建立並得到了一個儲存點。然後後續3行語句——

  user.name = 'zheli hui guadiao, T.T'  user.stripe_id = 4  user.save()

——不屬於剛才的儲存點，因此他們有可能是屬於下面的savepoint_rollback或savepoint_commit的一部分。假設是savepoint_rollback， 那程式碼user = User.create('jj','inception','jj','1234')仍舊會成功提交到資料庫中 ，而下面三行則不會成功。

採用另外一種方法，下面的兩種測試案例描述了儲存點是如何工作的：

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

同樣，在我們提交或者復原儲存點之後，我們仍然可以繼續在同一個事務中工作。同時，這個運行結果不受之前儲存點輸出結果的影響。

例如，如果我們按照如下例子更新“save_points”函數，

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

即使無論是“savepoint_commit”或者“savepoint_rollback”被“limbo”這個使用者調用了，這個事務仍然會被成功建立。如果沒有建立成功，整個事務將會被復原。

嵌套事務

採用“savepoint()”，“savepoint_commit”和“savepoint_rollback”去手動指定儲存點，將會自動一個嵌套事務，同時這個嵌套事務會自動為我們建立一個儲存點。並且，如果我們遇到錯誤，這個事務將會復原。

下面用一個擴充的例子來說明：

@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

這裡我們可以看到：在我們處理儲存點之後，我們採用“thetransaction.atomic”的上下文管理區擦出我們建立的"limbo"這個使用者。當上下文管理被調用的時候，它會建立一個儲存點（因為我們已經在事務裡面了），同時這個儲存點將會依據已經存在的上下文管理器去被執行或者復原。

這樣下面兩個測試案例就描述了這個行文：

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)

因此，在現實之中你可以使用原子或者在事務之中建立儲存點的儲存點。使用原子，你不必要很仔細地擔心提交和會滾，當這種情況發生時，你可以完全控制其中的儲存點。
結論

如果你有任何以往使用Django更早版本交易處理的經驗，你可以看到很多更簡單地交易處理模型。如下，在預設情況下，也有自動認可功能，它是一個很好的例子，即Django與python兩者都引以為豪所提供的“理智的”預設值。對於如此多的系統，你將不需要直接地來處理事務。只是讓“自動認可功能”來完成其工作，但如果你這樣做，我將希望這個文章能提供你所需要像專家一樣在Django之中管理的交易處理。

