From 59b1d3098f393f0754b60ebb710450cba9891e6e Mon Sep 17 00:00:00 2001 From: Shai Berger Date: Thu, 10 Apr 2014 03:40:33 +0300 Subject: [PATCH] Documentation fixes for the select_for_update change. Refs #22343; thanks Tim Graham for the fixes. --- docs/ref/models/querysets.txt | 2 +- docs/releases/1.6.3.txt | 16 ++++++++-------- docs/releases/1.7.txt | 19 +++++++++---------- 3 files changed, 18 insertions(+), 19 deletions(-) diff --git a/docs/ref/models/querysets.txt b/docs/ref/models/querysets.txt index 18941773ba9..bf18017405d 100644 --- a/docs/ref/models/querysets.txt +++ b/docs/ref/models/querysets.txt @@ -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. diff --git a/docs/releases/1.6.3.txt b/docs/releases/1.6.3.txt index c6981fa96b2..f2cf2612904 100644 --- a/docs/releases/1.6.3.txt +++ b/docs/releases/1.6.3.txt @@ -17,18 +17,18 @@ 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. +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 +` 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`. - -This change was made because such errors can be caused by including an -app which expects global transactions (e.g. :setting:`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. +:class:`~django.test.TestCase`. Other bugfixes and changes ========================== diff --git a/docs/releases/1.7.txt b/docs/releases/1.7.txt index aaba82a5bfd..75e86d324bc 100644 --- a/docs/releases/1.7.txt +++ b/docs/releases/1.7.txt @@ -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. +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 +` 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. It was also made 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`. - -This change was made because such errors can be caused by including an -app which expects global transactions (e.g. :setting:`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 was also fixed in Django 1.6.3. +:class:`~django.test.TestCase`. Miscellaneous ~~~~~~~~~~~~~