在過去，只是提供了簡單的基礎文檔，要想清楚知道它是怎么使用的，還必須要通過創建和執行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版本中正確的事務處理”之前，請先了解一下下面的詳細案例：
帶狀案例
事務
保存點
嵌套的事務
事務是什么？
根據SQL-92所說，"一個SQL事務(有時簡稱為事務)是一個可以原子性恢復的SQL語句執行序列"。換句話說，所有的SQL語句一起執行和提交。同樣的，當回滾時，所有語句也一并回滾。
例如：
# START note = 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狀態之中，默認數據庫應該關閉自動提交功能。
這明顯與數據庫內發生了什么矛盾沖突：
好啦，在我身邊呆久一些吧。
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_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:
你能發現問題了嗎？如果“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 updated unpaid = 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之中管理的事務處理。
聲明：本網頁內容旨在傳播知識，若有侵權等問題請及時與本網聯系，我們將在第一時間刪除處理。TEL:177 7030 7066 E-MAIL:11247931@qq.com
Copyright ? 2019-2025 51dongshi.com 版權所有
違法及侵權請聯系：TEL:177 7030 7066 E-MAIL:11247931@qq.com 本站由北京市萬商天勤律師事務所王興未律師提供法律服務
