mirror of
https://github.com/django/django.git
synced 2025-10-24 06:06:09 +00:00
Adapted uses of versionchanged/versionadded to the new form.
Refs #20104.
This commit is contained in:
committed by
Claude Paroz
parent
1ddeeb5b8e
commit
78c842a323
@@ -83,9 +83,9 @@ processing at the first positive match.
|
||||
|
||||
.. versionadded:: 1.6
|
||||
|
||||
If a backend raises a :class:`~django.core.exceptions.PermissionDenied`
|
||||
exception, authentication will immediately fail. Django won't check the
|
||||
backends that follow.
|
||||
If a backend raises a :class:`~django.core.exceptions.PermissionDenied`
|
||||
exception, authentication will immediately fail. Django won't check the
|
||||
backends that follow.
|
||||
|
||||
Writing an authentication backend
|
||||
---------------------------------
|
||||
|
||||
@@ -435,10 +435,10 @@ The login_required decorator
|
||||
|
||||
.. versionchanged:: 1.5
|
||||
|
||||
The :setting:`settings.LOGIN_URL <LOGIN_URL>` also accepts
|
||||
view function names and :ref:`named URL patterns <naming-url-patterns>`.
|
||||
This allows you to freely remap your login view within your URLconf
|
||||
without having to update the setting.
|
||||
The :setting:`settings.LOGIN_URL <LOGIN_URL>` also accepts
|
||||
view function names and :ref:`named URL patterns <naming-url-patterns>`.
|
||||
This allows you to freely remap your login view within your URLconf
|
||||
without having to update the setting.
|
||||
|
||||
.. note::
|
||||
|
||||
@@ -759,6 +759,7 @@ patterns.
|
||||
mail will be sent either.
|
||||
|
||||
.. versionchanged:: 1.6
|
||||
|
||||
Previously, error messages indicated whether a given email was
|
||||
registered.
|
||||
|
||||
@@ -1041,6 +1042,7 @@ Thus, you can check permissions in template ``{% if %}`` statements:
|
||||
{% endif %}
|
||||
|
||||
.. versionadded:: 1.5
|
||||
|
||||
Permission lookup by "if in".
|
||||
|
||||
It is possible to also look permissions up by ``{% if in %}`` statements.
|
||||
|
||||
@@ -176,6 +176,7 @@ your choice of default manager in order to avoid a situation where overriding
|
||||
work with.
|
||||
|
||||
.. versionchanged:: 1.6
|
||||
|
||||
The ``get_queryset`` method was previously named ``get_query_set``.
|
||||
|
||||
.. _managers-for-related-objects:
|
||||
|
||||
@@ -681,6 +681,7 @@ In addition, some objects are automatically created just after
|
||||
database).
|
||||
|
||||
.. versionchanged:: 1.5
|
||||
|
||||
Previously, ``ContentType`` and ``Permission`` instances were created only
|
||||
in the default database.
|
||||
|
||||
|
||||
@@ -638,6 +638,7 @@ that were modified more than 3 days after they were published::
|
||||
>>> Entry.objects.filter(mod_date__gt=F('pub_date') + timedelta(days=3))
|
||||
|
||||
.. versionadded:: 1.5
|
||||
|
||||
``.bitand()`` and ``.bitor()``
|
||||
|
||||
The ``F()`` objects now support bitwise operations by ``.bitand()`` and
|
||||
@@ -646,6 +647,7 @@ The ``F()`` objects now support bitwise operations by ``.bitand()`` and
|
||||
>>> F('somefield').bitand(16)
|
||||
|
||||
.. versionchanged:: 1.5
|
||||
|
||||
The previously undocumented operators ``&`` and ``|`` no longer produce
|
||||
bitwise operations, use ``.bitand()`` and ``.bitor()`` instead.
|
||||
|
||||
|
||||
@@ -222,6 +222,7 @@ 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
|
||||
|
||||
@@ -22,6 +22,7 @@ integrity of ORM operations that require multiple queries, especially
|
||||
<topics-db-queries-update>` queries.
|
||||
|
||||
.. versionchanged:: 1.6
|
||||
|
||||
Previous version of Django featured :ref:`a more complicated default
|
||||
behavior <transactions-upgrading-from-1.5>`.
|
||||
|
||||
@@ -78,6 +79,7 @@ Middleware run outside of the transaction, and so does the rendering of
|
||||
template responses.
|
||||
|
||||
.. versionchanged:: 1.6
|
||||
|
||||
Django used to provide this feature via ``TransactionMiddleware``, which is
|
||||
now deprecated.
|
||||
|
||||
@@ -204,6 +206,7 @@ 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.
|
||||
|
||||
@@ -224,6 +227,7 @@ 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
|
||||
@@ -312,10 +316,10 @@ 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
|
||||
@@ -354,20 +358,20 @@ The following example demonstrates the use of savepoints::
|
||||
@transaction.atomic
|
||||
def viewfunc(request):
|
||||
|
||||
a.save()
|
||||
# transaction now contains a.save()
|
||||
a.save()
|
||||
# transaction now contains a.save()
|
||||
|
||||
sid = transaction.savepoint()
|
||||
sid = transaction.savepoint()
|
||||
|
||||
b.save()
|
||||
# transaction now contains a.save() and b.save()
|
||||
b.save()
|
||||
# transaction now contains a.save() and b.save()
|
||||
|
||||
if want_to_keep_b:
|
||||
transaction.savepoint_commit(sid)
|
||||
# open transaction still contains a.save() and b.save()
|
||||
else:
|
||||
transaction.savepoint_rollback(sid)
|
||||
# open transaction now contains only a.save()
|
||||
if want_to_keep_b:
|
||||
transaction.savepoint_commit(sid)
|
||||
# open transaction still contains a.save() and b.save()
|
||||
else:
|
||||
transaction.savepoint_rollback(sid)
|
||||
# open transaction now contains only a.save()
|
||||
|
||||
Database-specific notes
|
||||
=======================
|
||||
|
||||
@@ -111,6 +111,7 @@ affect validation. If ``validate_max=True`` is passed to the
|
||||
validation. See :ref:`validate_max`.
|
||||
|
||||
.. versionchanged:: 1.6
|
||||
|
||||
The ``validate_max`` parameter was added to
|
||||
:func:`~django.forms.formsets.formset_factory`. Also, the behavior of
|
||||
``FormSet`` was brought in line with that of ``ModelFormSet`` so that it
|
||||
@@ -310,6 +311,7 @@ should use custom formset validation.
|
||||
using forged POST requests.
|
||||
|
||||
.. versionchanged:: 1.6
|
||||
|
||||
The ``validate_max`` parameter was added to
|
||||
:func:`~django.forms.formsets.formset_factory`.
|
||||
|
||||
|
||||
@@ -204,6 +204,7 @@ Dealing with streaming responses
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
.. versionchanged:: 1.5
|
||||
|
||||
``response`` may also be an :class:`~django.http.StreamingHttpResponse`
|
||||
object.
|
||||
|
||||
|
||||
@@ -71,6 +71,7 @@ default cache. To use another cache, set :setting:`SESSION_CACHE_ALIAS` to the
|
||||
name of that cache.
|
||||
|
||||
.. versionchanged:: 1.5
|
||||
|
||||
The :setting:`SESSION_CACHE_ALIAS` setting was added.
|
||||
|
||||
Once your cache is configured, you've got two choices for how to store data in
|
||||
@@ -451,6 +452,7 @@ Similarly, the ``expires`` part of a session cookie is updated each time the
|
||||
session cookie is sent.
|
||||
|
||||
.. versionchanged:: 1.5
|
||||
|
||||
The session is not saved if the response's status code is 500.
|
||||
|
||||
.. _browser-length-vs-persistent-sessions:
|
||||
|
||||
@@ -51,6 +51,7 @@ Optional arguments
|
||||
the :setting:`DEFAULT_CONTENT_TYPE` setting.
|
||||
|
||||
.. versionchanged:: 1.5
|
||||
|
||||
This parameter used to be called ``mimetype``.
|
||||
|
||||
``status``
|
||||
@@ -129,6 +130,7 @@ Optional arguments
|
||||
the :setting:`DEFAULT_CONTENT_TYPE` setting.
|
||||
|
||||
.. versionchanged:: 1.5
|
||||
|
||||
This parameter used to be called ``mimetype``.
|
||||
|
||||
|
||||
|
||||
@@ -1529,6 +1529,7 @@ selection based on data from the request. It customizes content for each user.
|
||||
``'django.middleware.locale.LocaleMiddleware'``.
|
||||
|
||||
.. versionchanged:: 1.6
|
||||
|
||||
In previous versions, ``LocaleMiddleware`` wasn't enabled by default.
|
||||
|
||||
Because middleware order matters, you should follow these guidelines:
|
||||
|
||||
@@ -252,7 +252,7 @@ Methods
|
||||
|
||||
.. versionchanged:: 1.5
|
||||
|
||||
Raises :exc:`InvalidPage` if next page doesn't exist.
|
||||
Raises :exc:`InvalidPage` if next page doesn't exist.
|
||||
|
||||
.. method:: Page.previous_page_number()
|
||||
|
||||
@@ -260,7 +260,7 @@ Methods
|
||||
|
||||
.. versionchanged:: 1.5
|
||||
|
||||
Raises :exc:`InvalidPage` if previous page doesn't exist.
|
||||
Raises :exc:`InvalidPage` if previous page doesn't exist.
|
||||
|
||||
.. method:: Page.start_index()
|
||||
|
||||
|
||||
@@ -124,8 +124,8 @@ Calling ``DeserializedObject.save()`` saves the object to the database.
|
||||
|
||||
.. versionchanged:: 1.6
|
||||
|
||||
In previous versions of Django, the ``pk`` attribute had to be present
|
||||
on the serialized data or a ``DeserializationError`` would be raised.
|
||||
In previous versions of Django, the ``pk`` attribute had to be present
|
||||
on the serialized data or a ``DeserializationError`` would be raised.
|
||||
|
||||
This ensures that deserializing is a non-destructive operation even if the
|
||||
data in your serialized representation doesn't match what's currently in the
|
||||
@@ -144,11 +144,11 @@ The Django object itself can be inspected as ``deserialized_object.object``.
|
||||
|
||||
.. versionadded:: 1.5
|
||||
|
||||
If fields in the serialized data do not exist on a model,
|
||||
a ``DeserializationError`` will be raised unless the ``ignorenonexistent``
|
||||
argument is passed in as True::
|
||||
If fields in the serialized data do not exist on a model,
|
||||
a ``DeserializationError`` will be raised unless the ``ignorenonexistent``
|
||||
argument is passed in as True::
|
||||
|
||||
serializers.deserialize("xml", data, ignorenonexistent=True)
|
||||
serializers.deserialize("xml", data, ignorenonexistent=True)
|
||||
|
||||
.. _serialization-formats:
|
||||
|
||||
|
||||
@@ -134,7 +134,7 @@ to.
|
||||
|
||||
.. versionchanged:: 1.5
|
||||
|
||||
The ability to pass a list of signals was added.
|
||||
The ability to pass a list of signals was added.
|
||||
|
||||
.. admonition:: Where should this code live?
|
||||
|
||||
|
||||
@@ -235,6 +235,7 @@ the Django test runner reorders tests in the following way:
|
||||
restoring it to its original state are run.
|
||||
|
||||
.. versionchanged:: 1.5
|
||||
|
||||
Before Django 1.5, the only guarantee was that
|
||||
:class:`~django.test.TestCase` tests were always ran first, before any other
|
||||
tests.
|
||||
@@ -612,6 +613,7 @@ Use the ``django.test.client.Client`` class to make requests.
|
||||
a ``Content-Type`` header is set to ``content_type``.
|
||||
|
||||
.. versionchanged:: 1.5
|
||||
|
||||
:meth:`Client.options` used to process ``data`` like
|
||||
:meth:`Client.get`.
|
||||
|
||||
@@ -627,6 +629,7 @@ Use the ``django.test.client.Client`` class to make requests.
|
||||
a ``Content-Type`` header is set to ``content_type``.
|
||||
|
||||
.. versionchanged:: 1.5
|
||||
|
||||
:meth:`Client.put` used to process ``data`` like
|
||||
:meth:`Client.post`.
|
||||
|
||||
@@ -650,6 +653,7 @@ Use the ``django.test.client.Client`` class to make requests.
|
||||
a ``Content-Type`` header is set to ``content_type``.
|
||||
|
||||
.. versionchanged:: 1.5
|
||||
|
||||
:meth:`Client.delete` used to process ``data`` like
|
||||
:meth:`Client.get`.
|
||||
|
||||
@@ -940,6 +944,7 @@ to test the effects of commit and rollback:
|
||||
the test has been properly updated.
|
||||
|
||||
.. versionchanged:: 1.5
|
||||
|
||||
The order in which tests are run has changed. See `Order in which tests are
|
||||
executed`_.
|
||||
|
||||
@@ -990,6 +995,7 @@ additions, including:
|
||||
errors.
|
||||
|
||||
.. versionchanged:: 1.5
|
||||
|
||||
The order in which tests are run has changed. See `Order in which tests are
|
||||
executed`_.
|
||||
|
||||
@@ -1581,6 +1587,7 @@ your test suite.
|
||||
``False``, which turns the comparison into a Python set comparison.
|
||||
|
||||
.. versionchanged:: 1.6
|
||||
|
||||
The method now checks for undefined order and raises ``ValueError``
|
||||
if undefined order is spotted. The ordering is seen as undefined if
|
||||
the given ``qs`` isn't ordered and the comparison is against more
|
||||
|
||||
Reference in New Issue
Block a user