Kaydet (Commit) 941f947b authored tarafından Shai Berger's avatar Shai Berger

[1.7.x] Documentation fixes for the select_for_update change.

Refs #22343; thanks Tim Graham for the fixes.

Backport of 59b1d309 from master
üst 3a9a4570
......@@ -1378,7 +1378,7 @@ do not support ``nowait``, such as MySQL, will cause a
:exc:`~django.db.DatabaseError` to be raised. This is in order to prevent code
unexpectedly blocking.
Executing a queryset with ``select_for_update`` in autocommit mode is
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.
......
......@@ -17,19 +17,19 @@ executed in autocommit mode, outside of a transaction. Before Django
lock records until the next write operation. Django 1.6 introduced
database-level autocommit; since then, execution in such a context
voids the effect of ``select_for_update()``. It is, therefore, assumed
now to be an error, and raises an exception.
This change may cause test failures if you use ``select_for_update()``
in a test class which is a subclass of
:class:`~django.test.TransactionTestCase` rather than
:class:`~django.test.TestCase`.
now to be an error and raises an exception.
This change was made because such errors can be caused by including an
app which expects global transactions (e.g. :setting:`ATOMIC_REQUESTS
<DATABASE-ATOMIC_REQUESTS>` set to True), or Django's old autocommit
<DATABASE-ATOMIC_REQUESTS>` set to ``True``), or Django's old autocommit
behavior, in a project which runs without them; and further, such
errors may manifest as data-corruption bugs.
This change may cause test failures if you use ``select_for_update()``
in a test class which is a subclass of
:class:`~django.test.TransactionTestCase` rather than
:class:`~django.test.TestCase`.
Other bugfixes and changes
==========================
......
......@@ -1096,20 +1096,19 @@ executed in autocommit mode, outside of a transaction. Before Django
lock records until the next write operation. Django 1.6 introduced
database-level autocommit; since then, execution in such a context
voids the effect of ``select_for_update()``. It is, therefore, assumed
now to be an error, and raises an exception.
This change may cause test failures if you use ``select_for_update()``
in a test class which is a subclass of
:class:`~django.test.TransactionTestCase` rather than
:class:`~django.test.TestCase`.
now to be an error and raises an exception.
This change was made because such errors can be caused by including an
app which expects global transactions (e.g. :setting:`ATOMIC_REQUESTS
<DATABASE-ATOMIC_REQUESTS>` set to True), or Django's old autocommit
<DATABASE-ATOMIC_REQUESTS>` set to ``True``), or Django's old autocommit
behavior, in a project which runs without them; and further, such
errors may manifest as data-corruption bugs.
errors may manifest as data-corruption bugs. It was also made in
Django 1.6.3.
This was also fixed in Django 1.6.3.
This change may cause test failures if you use ``select_for_update()``
in a test class which is a subclass of
:class:`~django.test.TransactionTestCase` rather than
:class:`~django.test.TestCase`.
Miscellaneous
~~~~~~~~~~~~~
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment