目录
Django 中事务的使用
Django默认的事务行为
默认情况下，在Django中事务是自动提交的。当我们运行Django内置的模板修改函数时，例如调用model.save()或model.delete()时，事务将被立即提交。这种机制和数据库的自动提交事务机制类似。记住这里没有默认的回滚机制
在HTTP请求上加事务
对于Web请求，Django官方推荐使用中件间TransactionMiddleware来处理请求和响应中的事务。它的工作原理是这样的：当一个请求到来时，Django开始一个事务，如果响应没有出错，Django提交这期间所有的事务，如果view中的函数抛出异常，那么Django会回滚这之间的事务。
为了实现这个特性，需要在MIDDLEWARE_CLASSES setting中添加TransactionMiddleware：
MIDDLEWARE_CLASSES = (
'django.middleware.cache.UpdateCacheMiddleware',
'django.contrib.sessions.middleware.SessionMiddleware',
'django.middleware.common.CommonMiddleware',
'django.middleware.transaction.TransactionMiddleware',
'django.middleware.cache.FetchFromCacheMiddleware',
)
顺序很重要，TransactionMiddleware中间件会将置于其后的中间件都包含在事务的范围之中（用于缓存的中间件除外，他们不受影响，例如CacheMiddleware，UpdateCacheMiddleware和FetchFromCacheMiddleware）。
另外需要注意的是，TransactionMiddleware只会影响DATABASES设置中的默认的数据库，对于其它的数据库，如果我们实现事务控制的话只能用别的方案了。
在View中实现事务控制
如果想在更细粒度的条件下（例如在一个view函数中）控制事务，我们可以使用django.db.transaction。有两种用法：
使用装饰器
from django.db import transaction
@transaction.commit_on_success
def viewfunc(request):
# this code executes inside a transaction使用context manager
from django.db import transaction
def viewfunc(request):
# this code executes using default transaction management
with transaction.commit_on_success():
# this code executes inside a transaction这两种方法都可以正常工作。不过如果使用的Python版本为2.5并且要使用with语法的话，还需加一句
from future import with_statement。
所以为了最大的兼容性，下面的示例使用装饰器来实现事务。
autocommit()
使用autocommit装饰器可以将view函数中的事务还原成Django默认的自动提交模式，无视全局事务的设置。
示例：
from django.db import transaction
@transaction.autocommit
def viewfunc(request):
@transaction.autocommit(using="my_other_database")
def viewfunc2(request):commit_on_success()
顾名思义，view函数成功则提交事务，否则回滚。用法同上。
commit_manually()
告诉Django我们将自己控制函数中的事务处理。并且要注意，如果在视图函数中改变了数据库的数据并且没有调用commit() 或rollback()，那么将抛出TransactionManagementError异常。
示例：
from django.db import transaction
@transaction.commit_manually
def viewfunc(request):
# You can commit/rollback however and whenever you want
transaction.commit()
# But you've got to remember to do it yourself!
try:
except:
transaction.rollback()
else:
transaction.commit()
@transaction.commit_manually(using="my_other_database")
def viewfunc2(request):transaction事务内不执行数据库的commit操作,除非手动commit
transaction最基本的功能。
代码场景:
在事务当前启动celery异步任务, 无法获取未提交的改动.
def example_view(request):
with transaction.atomic():
change_obj() # 修改对象变量
obj.save()
async_task.delay(obj.id)
def async_task(obj_id):
obj = Model.objects.get(pk=obj_id)
read_the_obj() # 读取对象信息atomic提供两种方案实现事务
在 Django 中可以通过django.db.transaction 模块提供的atomic来定义一个事务
transaction只对数据库层的操作进行事务管理,不能理解为python操作的事务管理
即使事务代码块发生了DataError,事务回滚,也仅是数据库层面的回滚,针对python的操作依然已完成.
- 装饰器用法：
from django.db import transaction
@transaction.atomic
def viewfunc(request):
# 这些代码会在一个事务中执行
......装饰器用法：整个视图中所有 MySQL 数据库的操作都看做一个事务，范围太大，不够灵活。而且无法直接作用于类视图
- with 语句用法：
from django.db import transaction
def viewfunc(request):
# 这部分代码不在事务中，会被 Django 自动提交
......
with transaction.atomic():
# 这部分代码会在事务中执行
......with 语句用法：可以灵活的有选择性的把某些 MySQL 数据库的操作看做一个事务。而且不用关心视图的类型。
- 三句话使用
from django.db import transaction
# 创建保存点
save_id = transaction.savepoint()
# 回滚到保存点
transaction.savepoint_rollback(save_id)
# 提交从保存点到当前状态的所有数据库事务操作
transaction.savepoint_commit(save_id)使用事务保存订单数据
class OrderCommitView(LoginRequiredJSONMixin, View):
"""订单提交"""
def post(self, request):
"""保存订单信息和订单商品信息"""
# 获取当前保存订单时需要的信息
......
# 显式的开启一个事务
with transaction.atomic():
# 创建事务保存点
save_id = transaction.savepoint()
# 暴力回滚
try:
# 保存订单基本信息 OrderInfo（一）
order = OrderInfo.objects.create(
order_id=order_id,
user=user,
address=address,
total_count=0,
total_amount=Decimal('0'),
freight=Decimal('10.00'),
pay_method=pay_method,
status=OrderInfo.ORDER_STATUS_ENUM['UNPAID'] if pay_method == OrderInfo.PAY_METHODS_ENUM['ALIPAY'] else
OrderInfo.ORDER_STATUS_ENUM['UNSEND']
)
# 从redis读取购物车中被勾选的商品信息
redis_conn = get_redis_connection('carts')
redis_cart = redis_conn.hgetall('carts_%s' % user.id)
selected = redis_conn.smembers('selected_%s' % user.id)
carts = {}
for sku_id in selected:
carts[int(sku_id)] = int(redis_cart[sku_id])
sku_ids = carts.keys()
# 遍历购物车中被勾选的商品信息
for sku_id in sku_ids:
# 查询SKU信息
sku = SKU.objects.get(id=sku_id)
# 判断SKU库存
sku_count = carts[sku.id]
if sku_count > sku.stock:
# 出错就回滚
transaction.savepoint_rollback(save_id)
return http.JsonResponse({
'code': RETCODE.STOCKERR,
'errmsg': '库存不足'})
# SKU减少库存，增加销量
sku.stock -= sku_count
sku.sales += sku_count
sku.save()
# 修改SPU销量
sku.goods.sales += sku_count
sku.goods.save()
# 保存订单商品信息 OrderGoods（多）
OrderGoods.objects.create(
order=order,
sku=sku,
count=sku_count,
price=sku.price,
)
# 保存商品订单中总价和总数量
order.total_count += sku_count
order.total_amount += (sku_count * sku.price)
# 添加邮费和保存订单信息
order.total_amount += order.freight
order.save()
except Exception as e:
logger.error(e)
transaction.savepoint_rollback(save_id)
return http.JsonResponse({
'code': RETCODE.DBERR,
'errmsg': '下单失败'})
# 提交订单成功，显式的提交一次事务
transaction.savepoint_commit(save_id)
# 清除购物车中已结算的商品
pl = redis_conn.pipeline()
pl.hdel('carts_%s' % user.id, *selected)
pl.srem('selected_%s' % user.id, *selected)
pl.execute()
# 响应提交订单结果
return http.JsonResponse({'code': RETCODE.OK,
'errmsg': '下单成功',
'order_id': order.order_id})
发生Dataerror异常的回滚仅在数据库层面操作,因此不可以根据model object的属性值判断是否正确完成了事务.
另外,虽然Django对数据库层面以ORM完成了很具体的抽象,但应该要清楚地意识到我们操作的model object和数据库内容本质不同,DJANGO只在查询和提交时进行数据库操作.