Django中关系型数据库事务处理

简单来说，几句话就可以使用关系型数据库的事务

#导包 

from django.db import transaction

#加装饰器

@transaction.atomic  # 当前视图函数中支持事务

# 开启事务

sid = transaction.savepoint()

# 回滚事务

transaction.savepoint_rollback(sid)

# 提交事务
transaction.savepoint_commit(sid)

数据库事务¶

Django 为你提供几种方法来控制如何管理数据库事务。

管理数据库事务¶

Django’s default transaction behavior¶

Django 的默认行为是运行在自动提交模式下。任何一个查询都立即被提交到数据库中，除非激活一个事务。具体细节看下面.

Django 用事务或者保存点去自动的保证复杂ORM各种查询操作的统一性,尤其是 delete() 和update() 查询.

Django’s 测试用例 也包装了事务性能原因的测试类

把事务绑定到HTTP 请求上¶

在web上一种简单处理事务的方式是把每个请求用事务包装起来.在每个你想保存这种行为的数据库的配置文件中，设置 ATOMIC_REQUESTS值为 True，

它是这样工作的。在调用一个view里面的方法之前，django开始一个事务如果发出的响应没有问题,Django就会提交这个事务。如果在view这里产生一个异常，Django就会回滚这次事务

你可能会在你的视图代码中执行一部分提交并且回滚，通常使用atomic()context管理器.但是最后你的视图，要么是所有改变都提交执行，要么是都不提交。

警告

虽然这种简洁的事物模型看上去很吸引人, 但要注意当流量增长时它会表现出较差的效率。对每个视图开启一个事务是有所耗费的。其对性能的影响依赖于应用程序对数据库的查询语句效率和数据库当前的锁竞争情况。

预请求事务和流式响应

当一个视图返回一个 StreamingHttpResponse时, 其读取的内容是由执行代码来产生的。因为视图调用已经返回，这样代码在事务的外部运行。

一般而言，在产生一个流式响应时，不建议再进行写数据库的操作，因为没有明智的方式在开始发送响应之后来处理错误。

在实际操作时，可以通过如下 atomic()装饰器把这一功能简单地加载到视图函数上。 

表示事务仅仅是在当前视图中有效，诸如模板响应之类的中间件(Middleware)操作是运行在事务之外的。

当 ATOMIC_REQUESTS被启用后，仍然有办法来阻止视图运行一个事务操作。

non_atomic_requests( using=None) [source] ¶

这个装饰器会否定一个由 ATOMIC_REQUESTS设定的视图:

from django.db import transaction

@transaction.non_atomic_requests
def my_view(request):
    do_stuff()

@transaction.non_atomic_requests(using='other')
def my_other_view(request):
    do_stuff_on_the_other_database()

它将仅工作在设定了此装饰器的视图上。

更加明确地控制事务¶

Django提供了单一的API来控制数据库事务。

atomic( using=None,  savepoint=True) [source] ¶

原子性是由数据库的事务操作来界定的。 atomic允许我们在执行代码块时，在数据库层面提供原子性保证。 如果代码块成功完成， 相应的变化会被提交到数据库进行commit；如果执行期间遇到异常，则会将该段代码所涉及的所有更改回滚。.

atomic块可以嵌套。 在下面的例子里，使用with语句，当一个内部块完成后，如果某个异常在外部块被抛出，内部块上的操作仍然可以回滚(前提是外部块也被atomic装饰过)。