Django 1.5选择_进行升级被认为是脆弱的设计

Question

Django documentation状态

If you were relying on “automatic transactions” to provide locking between select_for_update() and a subsequent write operation — an extremely fragile design, but nonetheless possible — you must wrap the relevant code in atomic(). Since Django 1.6.3, executing a query with select_for_update() in autocommit mode will raise a TransactionManagementError.

为什么这个被认为是易碎的？我本以为这会导致适当的交易。在

Answer 1

答案就在拐角处，在select_for_update（emphasis mine）的文档中：

Evaluating a queryset with select_for_update in autocommit mode is an error because the rows are then not locked. If allowed, this would facilitate data corruption, and could easily be caused by calling, outside of any transaction, code that expects to be run in one.

换句话说，在autocommit和{}之间存在矛盾的行为，这可能导致数据损坏。这里是他们第一次提出解决这个问题的django developer's discussion，引用（同样，强调我的）：

[...] under Oracle, in autocommit mode, the automatic commit happens immediately after the command is executed and so, trying to fetch the results fails for being done in a separate transaction.

However, with any backend, select-for-update in autocommit mode makes very little sense. Even if it doesn't break (as it does on Oracle), it doesn't really lock anything. So, IMO, executing a query that is a select-for-update in autocommit mode is probably en error, and one that is likely to cause data- corruption bugs.

So I'm suggesting we change the behavior of select-for-update queries, to error out [...] This is a backwards-incompatible change [...] These projects should probably be thankful they were running with a subtle bug that is now exposed but still.

所以这是一个只有Oracle的bug，它揭示了一个与所有后端相关的更深层次的问题，所以他们决定在django中把这个错误作为一个错误。在

另一方面，Atomic只在数据库验证没有错误后才将内容提交给数据库，从而解决了问题。在