Merged branch 'database-level-autocommit'.

Fixed #2227: `atomic` supports nesting.
Fixed #6623: `commit_manually` is deprecated and `atomic` doesn't suffer from this defect.
Fixed #8320: the problem wasn't identified, but the legacy transaction management is deprecated.
Fixed #10744: the problem wasn't identified, but the legacy transaction management is deprecated.
Fixed #10813: since autocommit is enabled, it isn't necessary to rollback after errors any more.
Fixed #13742: savepoints are now implemented for SQLite.
Fixed #13870: transaction management in long running processes isn't a problem any more, and it's documented.
Fixed #14970: while it digresses on transaction management, this ticket essentially asks for autocommit on PostgreSQL.
Fixed #15694: `atomic` supports nesting.
Fixed #17887: autocommit makes it impossible for a connection to stay "idle of transaction".

4 files changed, 49 insertions, 48 deletions

diff --git a/docs/ref/databases.txt b/docs/ref/databases.txt
index 4e435949a2..78c1bb3dda 100644
--- a/docs/ref/databases.txt
+++ b/docs/ref/databases.txt
@@ -69,7 +69,6 @@ even ``0``, because it doesn't make sense to maintain a connection that's
 unlikely to be reused. This will help keep the number of simultaneous
 connections to this database small.
 
-
 The development server creates a new thread for each request it handles,
 negating the effect of persistent connections.
 
@@ -104,7 +103,8 @@ Optimizing PostgreSQL's configuration
 Django needs the following parameters for its database connections:
 
 - ``client_encoding``: ``'UTF8'``,
-- ``default_transaction_isolation``: ``'read committed'``,
+- ``default_transaction_isolation``: ``'read committed'`` by default,
+  or the value set in the connection options (see below),
 - ``timezone``: ``'UTC'`` when :setting:`USE_TZ` is ``True``, value of
   :setting:`TIME_ZONE` otherwise.
 
@@ -118,30 +118,16 @@ will do some additional queries to set these parameters.
 
 .. _ALTER ROLE: http://www.postgresql.org/docs/current/interactive/sql-alterrole.html
 
-Transaction handling
----------------------
-
-:doc:`By default </topics/db/transactions>`, Django runs with an open
-transaction which it commits automatically when any built-in, data-altering
-model function is called. The PostgreSQL backends normally operate the same as
-any other Django backend in this respect.
-
 .. _postgresql-autocommit-mode:
 
 Autocommit mode
-~~~~~~~~~~~~~~~
+---------------
 
-If your application is particularly read-heavy and doesn't make many
-database writes, the overhead of a constantly open transaction can
-sometimes be noticeable. For those situations, you can configure Django
-to use *"autocommit"* behavior for the connection, meaning that each database
-operation will normally be in its own transaction, rather than having
-the transaction extend over multiple operations. In this case, you can
-still manually start a transaction if you're doing something that
-requires consistency across multiple database operations. The
-autocommit behavior is enabled by setting the ``autocommit`` key in
-the :setting:`OPTIONS` part of your database configuration in
-:setting:`DATABASES`::
+.. versionchanged:: 1.6
+
+In previous versions of Django, database-level autocommit could be enabled by
+setting the ``autocommit`` key in the :setting:`OPTIONS` part of your database
+configuration in :setting:`DATABASES`::
 
     DATABASES = {
         # ...
@@ -150,29 +136,11 @@ the :setting:`OPTIONS` part of your database configuration in
         },
     }
 
-In this configuration, Django still ensures that :ref:`delete()
-<topics-db-queries-delete>` and :ref:`update() <topics-db-queries-update>`
-queries run inside a single transaction, so that either all the affected
-objects are changed or none of them are.
-
-.. admonition:: This is database-level autocommit
-
-    This functionality is not the same as the :ref:`autocommit
-    <topics-db-transactions-autocommit>` decorator. That decorator is
-    a Django-level implementation that commits automatically after
-    data changing operations. The feature enabled using the
-    :setting:`OPTIONS` option provides autocommit behavior at the
-    database adapter level. It commits after *every* operation.
-
-If you are using this feature and performing an operation akin to delete or
-updating that requires multiple operations, you are strongly recommended to
-wrap you operations in manual transaction handling to ensure data consistency.
-You should also audit your existing code for any instances of this behavior
-before enabling this feature. It's faster, but it provides less automatic
-protection for multi-call operations.
+Since Django 1.6, autocommit is turned on by default. This configuration is
+ignored and can be safely removed.
 
 Isolation level
-~~~~~~~~~~~~~~~
+---------------
 
 .. versionadded:: 1.6
 
@@ -200,7 +168,7 @@ such as ``REPEATABLE READ`` or ``SERIALIZABLE``, set it in the
 .. _postgresql-isolation-levels: http://www.postgresql.org/docs/devel/static/transaction-iso.html
 
 Indexes for ``varchar`` and ``text`` columns
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+--------------------------------------------
 
 When specifying ``db_index=True`` on your model fields, Django typically
 outputs a single ``CREATE INDEX`` statement.  However, if the database type
@@ -456,8 +424,7 @@ Savepoints
 
 Both the Django ORM and MySQL (when using the InnoDB :ref:`storage engine
 <mysql-storage-engines>`) support database :ref:`savepoints
-<topics-db-transactions-savepoints>`, but this feature wasn't available in
-Django until version 1.4 when such supports was added.
+<topics-db-transactions-savepoints>`.
 
 If you use the MyISAM storage engine please be aware of the fact that you will
 receive database-generated errors if you try to use the :ref:`savepoint-related
diff --git a/docs/ref/middleware.txt b/docs/ref/middleware.txt
index 1e6e57f720..20bb2fb751 100644
--- a/docs/ref/middleware.txt
+++ b/docs/ref/middleware.txt
@@ -205,6 +205,10 @@ Transaction middleware
 
 .. class:: TransactionMiddleware
 
+.. versionchanged:: 1.6
+    ``TransactionMiddleware`` is deprecated. The documentation of transactions
+    contains :ref:`upgrade instructions <transactions-upgrading-from-1.5>`.
+
 Binds commit and rollback of the default database to the request/response
 phase. If a view function runs successfully, a commit is done. If it fails with
 an exception, a rollback is done.
diff --git a/docs/ref/request-response.txt b/docs/ref/request-response.txt
index 30f5e87100..6f620e17e2 100644
--- a/docs/ref/request-response.txt
+++ b/docs/ref/request-response.txt
@@ -814,8 +814,8 @@ generating large CSV files.
 .. admonition:: Performance considerations
 
     Django is designed for short-lived requests. Streaming responses will tie
-    a worker process and keep a database connection idle in transaction for
-    the entire duration of the response. This may result in poor performance.
+    a worker process for the entire duration of the response. This may result
+    in poor performance.
 
     Generally speaking, you should perform expensive tasks outside of the
     request-response cycle, rather than resorting to a streamed response.
diff --git a/docs/ref/settings.txt b/docs/ref/settings.txt
index 0cd141bcef..2b80527d8b 100644
--- a/docs/ref/settings.txt
+++ b/docs/ref/settings.txt
@@ -408,6 +408,30 @@ SQLite. This can be configured using the following::
 For other database backends, or more complex SQLite configurations, other options
 will be required. The following inner options are available.
 
+.. setting:: DATABASE-ATOMIC_REQUESTS
+
+ATOMIC_REQUESTS
+~~~~~~~~~~~~~~~
+
+.. versionadded:: 1.6
+
+Default: ``False``
+
+Set this to ``True`` to wrap each HTTP request in a transaction on this
+database. See :ref:`tying-transactions-to-http-requests`.
+
+.. setting:: DATABASE-AUTOCOMMIT
+
+AUTOCOMMIT
+~~~~~~~~~~
+
+.. versionadded:: 1.6
+
+Default: ``True``
+
+Set this to ``False`` if you want to :ref:`disable Django's transaction
+management <deactivate-transaction-management>` and implement your own.
+
 .. setting:: DATABASE-ENGINE
 
 ENGINE
@@ -1807,6 +1831,12 @@ to ensure your processes are running in the correct environment.
 TRANSACTIONS_MANAGED
 --------------------
 
+.. deprecated:: 1.6
+
+    This setting was deprecated because its name is very misleading. Use the
+    :setting:`AUTOCOMMIT <DATABASE-AUTOCOMMIT>` key in :setting:`DATABASES`
+    entries instead.
+
 Default: ``False``
 
 Set this to ``True`` if you want to :ref:`disable Django's transaction