Loading docs/ref/models/querysets.txt +1 −1 Original line number Diff line number Diff line Loading @@ -1365,7 +1365,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. Loading docs/releases/1.6.3.txt +7 −7 Original line number Diff line number Diff line Loading @@ -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 ========================== Loading docs/releases/1.7.txt +8 −9 Original line number Diff line number Diff line Loading @@ -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 ~~~~~~~~~~~~~ Loading Loading
docs/ref/models/querysets.txt +1 −1 Original line number Diff line number Diff line Loading @@ -1365,7 +1365,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. Loading
docs/releases/1.6.3.txt +7 −7 Original line number Diff line number Diff line Loading @@ -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 ========================== Loading
docs/releases/1.7.txt +8 −9 Original line number Diff line number Diff line Loading @@ -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 ~~~~~~~~~~~~~ Loading