Enabled database-level autocommit for all backends.

        conn_params = self.get_connection_params()

        self.connection = self.get_new_connection(conn_params)

        self.init_connection_state()

        if not settings.TRANSACTIONS_MANAGED:

            self.set_autocommit()

        connection_created.send(sender=self.__class__, connection=self)

    def ensure_connection(self):

                self.connection.cursor().execute(

                        self.ops.set_time_zone_sql(), [tz])

        self.connection.set_isolation_level(self.isolation_level)

        self.set_autocommit(not settings.TRANSACTIONS_MANAGED)

    def create_cursor(self):

        cursor = self.connection.cursor()

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.

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.

.. _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 = {

        # ...

        },

    }

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

.. _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

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

.. 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.

If the default templates don't suit your tastes, you can use :ref:`custom

project and app templates <custom-app-and-project-templates>`.

Improved transaction management

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Django's transaction management was overhauled. Database-level autocommit is

now turned on by default. This makes transaction handling more explicit and

should improve performance. The existing APIs were deprecated, and new APIs

were introduced, as described in :doc:`/topics/db/transactions`.

Please review carefully the list of :ref:`known backwards-incompatibilities

<transactions-changes-from-1.5>` to determine if you need to make changes in

your code.

Persistent database connections

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

    deprecation timeline for a given feature, its removal may appear as a

    backwards incompatible change.

* Database-level autocommit is enabled by default in Django 1.6. While this

  doesn't change the general spirit of Django's transaction management, there

  are a few known backwards-incompatibities, described in the :ref:`transaction

  management docs <transactions-changes-from-1.5>`. You should review your code

  to determine if you're affected.

* In previous versions, database-level autocommit was only an option for

  PostgreSQL, and it was disabled by default. This option is now

  :ref:`ignored <postgresql-autocommit-mode>`.

* The ``django.db.models.query.EmptyQuerySet`` can't be instantiated any more -

  it is only usable as a marker class for checking if

  :meth:`~django.db.models.query.QuerySet.none` has been called: