mirrors/django
1
0
Fork 0
mirror of https://github.com/django/django.git synced 2025-10-24 14:16:09 +00:00
Code Issues 32 Releases Wiki Activity

Removed versionadded/changed annotations for 1.6.

Browse Source
This commit is contained in:
Tim Graham
2014-03-24 11:42:56 -04:00
parent ec08d62a20
commit 51c8045145
54 changed files with 70 additions and 550 deletions
Download Patch File Download Diff File Expand all files Collapse all files

4
docs/topics/db/managers.txt
View File

@@ -179,10 +179,6 @@ your choice of default manager in order to avoid a situation where overriding
``get_queryset()`` results in an inability to retrieve objects you'd like to
work with.
.. versionchanged:: 1.6
The ``get_queryset`` method was previously named ``get_query_set``.
.. _managers-for-related-objects:
Using managers for related object access

14
docs/topics/db/sql.txt
View File

@@ -197,13 +197,6 @@ argument.
__ http://en.wikipedia.org/wiki/SQL_injection
.. versionchanged:: 1.6
In Django 1.5 and earlier, you could pass parameters as dictionaries
when using PostgreSQL or MySQL, although this wasn't documented. Now
you can also do this when using Oracle, and it is officially supported.
.. _executing-custom-sql:
Executing custom SQL directly
@@ -236,13 +229,6 @@ For example::
return row
.. versionchanged:: 1.6
In Django 1.5 and earlier, after performing a data changing operation, you
had to call ``transaction.commit_unless_managed()`` to ensure your changes
were committed to the database. Since Django now defaults to database-level
autocommit, this isn't necessary any longer.
Note that if you want to include literal percent signs in the query, you have to
double them in the case you are passing parameters::

35
docs/topics/db/transactions.txt
View File

@@ -24,11 +24,6 @@ integrity of ORM operations that require multiple queries, especially
Django's :class:`~django.test.TestCase` class also wraps each test in a
transaction for performance reasons.
.. versionchanged:: 1.6
Previous version of Django featured :ref:`a more complicated default
behavior <transactions-upgrading-from-1.5>`.
.. _tying-transactions-to-http-requests:
Tying transactions to HTTP requests
@@ -93,16 +88,9 @@ still possible to prevent views from running in a transaction.
It only works if it's applied to the view itself.
.. versionchanged:: 1.6
Django used to provide this feature via ``TransactionMiddleware``, which is
now deprecated.
Controlling transactions explicitly
-----------------------------------
.. versionadded:: 1.6
Django provides a single API to control database transactions.
.. function:: atomic(using=None, savepoint=True)
@@ -251,11 +239,6 @@ on.
To avoid this, you can :ref:`deactivate the transaction management
<deactivate-transaction-management>`, but it isn't recommended.
.. versionchanged:: 1.6
Before Django 1.6, autocommit was turned off, and it was emulated by
forcing a commit after write operations in the ORM.
.. _deactivate-transaction-management:
Deactivating transaction management
@@ -272,10 +255,6 @@ by Django or by third-party libraries. Thus, this is best used in situations
where you want to run your own transaction-controlling middleware or do
something really strange.
.. versionchanged:: 1.6
This used to be controlled by the ``TRANSACTIONS_MANAGED`` setting.
Low-level APIs
==============
@@ -292,8 +271,6 @@ Low-level APIs
Autocommit
----------
.. versionadded:: 1.6
Django provides a straightforward API in the :mod:`django.db.transaction`
module to manage the autocommit state of each database connection.
@@ -360,12 +337,10 @@ you issue a rollback, the entire transaction is rolled back. Savepoints
provide the ability to perform a fine-grained rollback, rather than the full
rollback that would be performed by ``transaction.rollback()``.
.. versionchanged:: 1.6
When the :func:`atomic` decorator is nested, it creates a savepoint to allow
partial commit or rollback. You're strongly encouraged to use :func:`atomic`
rather than the functions described below, but they're still part of the
public API, and there's no plan to deprecate them.
When the :func:`atomic` decorator is nested, it creates a savepoint to allow
partial commit or rollback. You're strongly encouraged to use :func:`atomic`
rather than the functions described below, but they're still part of the
public API, and there's no plan to deprecate them.
Each of these functions takes a ``using`` argument which should be the name of
a database for which the behavior applies. If no ``using`` argument is
@@ -419,8 +394,6 @@ The following example demonstrates the use of savepoints::
transaction.savepoint_rollback(sid)
# open transaction now contains only a.save()
.. versionadded:: 1.6
Savepoints may be used to recover from a database error by performing a partial
rollback. If you're doing this inside an :func:`atomic` block, the entire block
will still be rolled back, because it doesn't know you've handled the situation