Enabled database-level autocommit for all backends.

This is mostly a documentation change.

It has the same backwards-incompatibility consequences as those
described for PostgreSQL in a previous commit.

2 files changed, 15 insertions, 47 deletions

diff --git a/docs/ref/databases.txt b/docs/ref/databases.txt
index 4e435949a2..4dafb3774f 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
@@ -457,7 +425,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.
+Django until version 1.4 when such support was added.
 
 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/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.