Django4.0 數(shù)據(jù)庫事務(wù)-特定于數(shù)據(jù)的注釋

SQLite 中的保存點

雖然 SQLite 支持保存點時，但 sqlite3 模塊中的一個設(shè)計缺陷使得它們幾乎無法使用。
當(dāng)啟用自動提交時，保存點沒有意義。當(dāng)關(guān)閉時，sqlite3 會在保存點語句之前隱式提交。（事實上，它會在除了 ?SELECT?, ?INSERT?, ?UPDATE?, ?DELETE和?REPLACE ?之前的任何語句之前提交）這個 Bug 有兩個后果：

• 保存點的底層API只能在事務(wù)中可用，即在 ?atomic()? 塊中。
• 當(dāng)關(guān)閉自動提交時，不能使用 ?atomic()? 。

MySQL 中的事務(wù)

如果你正在使用 MySQL，表可能支持或不支持事務(wù)；它取決于 MySQL 版本和表的類型。（表類型是指 "InnoDB" 或 "MyISAM" 之類的東西）MySQL 事務(wù)的特性超出了本文的范圍，但 MySQL 站點有 MySQL 事務(wù)的相關(guān)信息。

如果 MySQL 安裝時沒有支持事務(wù)，然后 Django 將始終在自動提交模式中運(yùn)行：語句將在它們調(diào)用的時候被執(zhí)行和提交。如果 MySQL 安裝時支持了事務(wù)，Django 將像本文說的那樣處理事務(wù)。

處理 PostgreSQL 事務(wù)中的異常

注解：只有在實現(xiàn)自有的事務(wù)管理時，這部分才有用。這個問題不會發(fā)生在 Django 默認(rèn)模式里，并且 ?atomic()?會自動處理它。

在一個事務(wù)里，當(dāng)對 PostgreSQL 游標(biāo)的調(diào)用引發(fā)了異常（通常是 ??IntegrityError??），在同一事務(wù)中的隨后的SQL 將會出現(xiàn) "?current transaction is aborted, queries ignored until end of transaction block?" 的錯誤 。雖然 ?save()? 的基本用法不太可能在 PostgreSQL 中引發(fā)異常，但還有更高級的用法模式，比如保存具有唯一字段的對象，保存使用?force_insert/force_update? 標(biāo)記，或調(diào)用自定義的 SQL。

有幾種方法來從這種錯誤中恢復(fù)。

事務(wù)回滾

第一個選項是回滾整個事務(wù)。比如：

a.save() # Succeeds, but may be undone by transaction rollback
try:
    b.save() # Could throw exception
except IntegrityError:
    transaction.rollback()
c.save() # Succeeds, but a.save() may have been undone

調(diào)用 ?transaction.rollback()? 回滾整個事務(wù)。任何未提交的數(shù)據(jù)庫操作會被丟棄。在這個例子里， ?a.save()? 做的改變會丟失，即使操作本身沒有引發(fā)錯誤。

保存點回滾

你可以使用 ?savepoints來控制回滾的程度。執(zhí)行可能失敗的數(shù)據(jù)庫操作之前，你可以設(shè)置或更新保存點；這樣，如果操作失敗，你可以回滾單一的錯誤操作，而不是回滾整個事務(wù)。比如：

a.save() # Succeeds, and never undone by savepoint rollback
sid = transaction.savepoint()
try:
    b.save() # Could throw exception
    transaction.savepoint_commit(sid)
except IntegrityError:
    transaction.savepoint_rollback(sid)
c.save() # Succeeds, and a.save() is never undone

在這個例子里， ?a.save()? 將不會在 ?b.save()? 引發(fā)異常的情況下被撤銷。