mirror of
https://github.com/django/django.git
synced 2025-10-24 06:06:09 +00:00
Removed versionadded/changed annotations for 1.6.
This commit is contained in:
Tim Graham
@@ -70,6 +70,10 @@ The order of :setting:`AUTHENTICATION_BACKENDS` matters, so if the same
|
||||
username and password is valid in multiple backends, Django will stop
|
||||
processing at the first positive match.
|
||||
|
||||
If a backend raises a :class:`~django.core.exceptions.PermissionDenied`
|
||||
exception, authentication will immediately fail. Django won't check the
|
||||
backends that follow.
|
||||
|
||||
.. note::
|
||||
|
||||
Once a user has authenticated, Django stores which backend was used to
|
||||
@@ -81,12 +85,6 @@ processing at the first positive match.
|
||||
you need to force users to re-authenticate using different methods. A simple
|
||||
way to do that is simply to execute ``Session.objects.all().delete()``.
|
||||
|
||||
.. 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.
|
||||
|
||||
Writing an authentication backend
|
||||
---------------------------------
|
||||
|
||||
@@ -570,23 +568,12 @@ The following methods are available on any subclass of
|
||||
:meth:`~django.contrib.auth.models.AbstractBaseUser.set_unusable_password()`
|
||||
were used.
|
||||
|
||||
.. versionchanged:: 1.6
|
||||
|
||||
In Django 1.4 and 1.5, a blank string was unintentionally stored
|
||||
as an unusable password as well.
|
||||
|
||||
.. method:: models.AbstractBaseUser.check_password(raw_password)
|
||||
|
||||
Returns ``True`` if the given raw string is the correct password for
|
||||
the user. (This takes care of the password hashing in making the
|
||||
comparison.)
|
||||
|
||||
.. versionchanged:: 1.6
|
||||
|
||||
In Django 1.4 and 1.5, a blank string was unintentionally
|
||||
considered to be an unusable password, resulting in this method
|
||||
returning ``False`` for such a password.
|
||||
|
||||
.. method:: models.AbstractBaseUser.set_unusable_password()
|
||||
|
||||
Marks the user as having no password set. This isn't the same as
|
||||
@@ -909,10 +896,6 @@ models provided by ``auth`` app::
|
||||
"Run tests for a simple extension of the built-in User."
|
||||
self.assertSomething()
|
||||
|
||||
.. versionchanged:: 1.6
|
||||
|
||||
In Django 1.5, it wasn't necessary to explicitly import the test User models.
|
||||
|
||||
A full example
|
||||
--------------
|
||||
|
||||
|
||||
@@ -851,11 +851,6 @@ patterns.
|
||||
error message since this would expose their account's existence but no
|
||||
mail will be sent either.
|
||||
|
||||
.. versionchanged:: 1.6
|
||||
|
||||
Previously, error messages indicated whether a given email was
|
||||
registered.
|
||||
|
||||
**URL name:** ``password_reset``
|
||||
|
||||
**Optional arguments:**
|
||||
@@ -936,15 +931,9 @@ patterns.
|
||||
Someone asked for password reset for email {{ email }}. Follow the link below:
|
||||
{{ protocol}}://{{ domain }}{% url 'password_reset_confirm' uidb64=uid token=token %}
|
||||
|
||||
.. versionchanged:: 1.6
|
||||
|
||||
Reversing ``password_reset_confirm`` takes a ``uidb64`` argument instead
|
||||
of ``uidb36``.
|
||||
|
||||
The same template context is used for subject template. Subject must be
|
||||
single line plain text string.
|
||||
|
||||
|
||||
.. function:: password_reset_done(request[, template_name, current_app, extra_context])
|
||||
|
||||
The page shown after a user has been emailed a link to reset their
|
||||
@@ -976,11 +965,6 @@ patterns.
|
||||
|
||||
* ``uidb64``: The user's id encoded in base 64. Defaults to ``None``.
|
||||
|
||||
.. versionchanged:: 1.6
|
||||
|
||||
The ``uidb64`` parameter was previously base 36 encoded and named
|
||||
``uidb36``.
|
||||
|
||||
* ``token``: Token to check that the password is valid. Defaults to
|
||||
``None``.
|
||||
|
||||
|
||||
@@ -183,11 +183,8 @@ can switch to new (and better) storage algorithms as they get invented.
|
||||
However, Django can only upgrade passwords that use algorithms mentioned in
|
||||
:setting:`PASSWORD_HASHERS`, so as you upgrade to new systems you should make
|
||||
sure never to *remove* entries from this list. If you do, users using
|
||||
unmentioned algorithms won't be able to upgrade.
|
||||
|
||||
.. versionadded:: 1.6
|
||||
|
||||
Passwords will be upgraded when changing the PBKDF2 iteration count.
|
||||
unmentioned algorithms won't be able to upgrade. Passwords will be upgraded
|
||||
when changing the PBKDF2 iteration count.
|
||||
|
||||
.. _sha1: http://en.wikipedia.org/wiki/SHA1
|
||||
.. _pbkdf2: http://en.wikipedia.org/wiki/PBKDF2
|
||||
@@ -214,12 +211,6 @@ from the ``User`` model.
|
||||
database to check against, and returns ``True`` if they match, ``False``
|
||||
otherwise.
|
||||
|
||||
.. versionchanged:: 1.6
|
||||
|
||||
In Django 1.4 and 1.5, a blank string was unintentionally considered
|
||||
to be an unusable password, resulting in this method returning
|
||||
``False`` for such a password.
|
||||
|
||||
.. function:: make_password(password[, salt, hashers])
|
||||
|
||||
Creates a hashed password in the format used by this application. It takes
|
||||
|
||||
@@ -771,11 +771,6 @@ of the appropriate backend in the :setting:`CACHES` setting (explained above).
|
||||
It's the number of seconds the value should be stored in the cache. Passing in
|
||||
``None`` for ``timeout`` will cache the value forever.
|
||||
|
||||
.. versionchanged:: 1.6
|
||||
|
||||
Previously, passing ``None`` explicitly would use the default timeout
|
||||
value.
|
||||
|
||||
If the object doesn't exist in the cache, ``cache.get()`` returns ``None``::
|
||||
|
||||
# Wait 30 seconds for 'my_key' to expire...
|
||||
|
||||
@@ -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
|
||||
|
||||
@@ -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::
|
||||
|
||||
|
||||
@@ -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
|
||||
|
||||
@@ -118,13 +118,6 @@ affect validation. If ``validate_max=True`` is passed to the
|
||||
:func:`~django.forms.formsets.formset_factory`, then ``max_num`` will affect
|
||||
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
|
||||
displays initial data regardless of ``max_num``.
|
||||
|
||||
Formset validation
|
||||
------------------
|
||||
|
||||
@@ -169,8 +162,6 @@ the expected error message appears for the second item.
|
||||
|
||||
.. method:: BaseFormSet.total_error_count()
|
||||
|
||||
.. versionadded:: 1.6
|
||||
|
||||
To check how many errors there are in the formset, we can use the
|
||||
``total_error_count`` method::
|
||||
|
||||
@@ -344,11 +335,6 @@ excessive.
|
||||
truncated entirely. This is to protect against memory exhaustion attacks
|
||||
using forged POST requests.
|
||||
|
||||
.. versionchanged:: 1.6
|
||||
|
||||
The ``validate_max`` parameter was added to
|
||||
:func:`~django.forms.formsets.formset_factory`.
|
||||
|
||||
``validate_min``
|
||||
~~~~~~~~~~~~~~~~
|
||||
|
||||
|
||||
@@ -317,14 +317,11 @@ attributes, which can be useful in your templates:
|
||||
The label of the field, e.g. ``Email address``.
|
||||
|
||||
``{{ field.label_tag }}``
|
||||
The field's label wrapped in the appropriate HTML ``<label>`` tag.
|
||||
The field's label wrapped in the appropriate HTML ``<label>`` tag. This
|
||||
includes the form's :attr:`~django.forms.Form.label_suffix`. For example,
|
||||
the default ``label_suffix`` is a colon::
|
||||
|
||||
.. versionchanged:: 1.6
|
||||
|
||||
This includes the form's :attr:`~django.forms.Form.label_suffix`. For
|
||||
example, the default ``label_suffix`` is a colon::
|
||||
|
||||
<label for="id_email">Email address:</label>
|
||||
<label for="id_email">Email address:</label>
|
||||
|
||||
``{{ field.id_for_label }}``
|
||||
The ID that will be used for this field (``id_email`` in the example
|
||||
|
||||
@@ -501,10 +501,6 @@ widget::
|
||||
The ``widgets`` dictionary accepts either widget instances (e.g.,
|
||||
``Textarea(...)``) or classes (e.g., ``Textarea``).
|
||||
|
||||
.. versionadded:: 1.6
|
||||
|
||||
The ``labels``, ``help_texts`` and ``error_messages`` options were added.
|
||||
|
||||
Similarly, you can specify the ``labels``, ``help_texts`` and ``error_messages``
|
||||
attributes of the inner ``Meta`` class if you want to further customize a field.
|
||||
|
||||
@@ -610,8 +606,6 @@ the field declaratively and setting its ``validators`` parameter::
|
||||
Enabling localization of fields
|
||||
-------------------------------
|
||||
|
||||
.. versionadded:: 1.6
|
||||
|
||||
By default, the fields in a ``ModelForm`` will not localize their data. To
|
||||
enable localization for fields, you can use the ``localized_fields``
|
||||
attribute on the ``Meta`` class.
|
||||
@@ -818,8 +812,6 @@ exclude::
|
||||
Specifying widgets to use in the form with ``widgets``
|
||||
------------------------------------------------------
|
||||
|
||||
.. versionadded:: 1.6
|
||||
|
||||
Using the ``widgets`` parameter, you can specify a dictionary of values to
|
||||
customize the ``ModelForm``’s widget class for a particular field. This
|
||||
works the same way as the ``widgets`` dictionary on the inner ``Meta``
|
||||
@@ -831,8 +823,6 @@ class of a ``ModelForm`` works::
|
||||
Enabling localization for fields with ``localized_fields``
|
||||
----------------------------------------------------------
|
||||
|
||||
.. versionadded:: 1.6
|
||||
|
||||
Using the ``localized_fields`` parameter, you can enable localization for
|
||||
fields in the form.
|
||||
|
||||
@@ -1196,9 +1186,9 @@ Notice how we pass ``instance`` in both the ``POST`` and ``GET`` cases.
|
||||
Specifying widgets to use in the inline form
|
||||
--------------------------------------------
|
||||
|
||||
.. versionadded:: 1.6
|
||||
|
||||
``inlineformset_factory`` uses ``modelformset_factory`` and passes most
|
||||
of its arguments to ``modelformset_factory``. This means you can use
|
||||
the ``widgets`` parameter in much the same way as passing it to
|
||||
``modelformset_factory``. See `Specifying widgets to use in the form with widgets`_ above.
|
||||
``modelformset_factory``. See `Specifying widgets to use in the form with
|
||||
widgets`_ above.
|
||||
|
||||
@@ -8,8 +8,8 @@ or output.
|
||||
|
||||
Each middleware component is responsible for doing some specific function. For
|
||||
example, Django includes a middleware component,
|
||||
:class:`~django.middleware.transaction.TransactionMiddleware`, that wraps the
|
||||
processing of each HTTP request in a database transaction.
|
||||
:class:`~django.contrib.auth.middleware.AuthenticationMiddleware`, that
|
||||
associates users with requests using sessions.
|
||||
|
||||
This document explains how middleware works, how you activate middleware, and
|
||||
how to write your own middleware. Django ships with some built-in middleware
|
||||
|
||||
@@ -324,8 +324,6 @@ You can edit it multiple times.
|
||||
Session serialization
|
||||
---------------------
|
||||
|
||||
.. versionchanged:: 1.6
|
||||
|
||||
Before version 1.6, Django defaulted to using :mod:`pickle` to serialize
|
||||
session data before storing it in the backend. If you're using the :ref:`signed
|
||||
cookie session backend<cookie-session-backend>` and :setting:`SECRET_KEY` is
|
||||
|
||||
@@ -242,8 +242,6 @@ same way you can for the 404 and 500 views by specifying a
|
||||
The 400 (bad request) view
|
||||
--------------------------
|
||||
|
||||
.. versionadded:: 1.6
|
||||
|
||||
.. function:: django.views.defaults.bad_request(request, template_name='400.html')
|
||||
|
||||
When a :exc:`~django.core.exceptions.SuspiciousOperation` is raised in Django,
|
||||
|
||||
@@ -433,8 +433,6 @@ helper function described next.
|
||||
Lazy translations and plural
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
.. versionadded:: 1.6
|
||||
|
||||
When using lazy translation for a plural string (``[u]n[p]gettext_lazy``), you
|
||||
generally don't know the ``number`` argument at the time of the string
|
||||
definition. Therefore, you are authorized to pass a key name instead of an
|
||||
|
||||
@@ -531,8 +531,6 @@ Python logging module.
|
||||
sensitive information to be filtered out of error reports -- learn more on
|
||||
:ref:`Filtering error reports<filtering-error-reports>`.
|
||||
|
||||
.. versionadded:: 1.6
|
||||
|
||||
By setting the ``email_backend`` argument of ``AdminEmailHandler``, the
|
||||
:ref:`email backend <topic-email-backends>` that is being used by the
|
||||
handler can be overridden, like this::
|
||||
|
||||
@@ -122,11 +122,6 @@ Calling ``DeserializedObject.save()`` saves the object to the database.
|
||||
If the ``pk`` attribute in the serialized data doesn't exist or is
|
||||
null, a new instance will be saved 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.
|
||||
|
||||
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
|
||||
database. Usually, working with these ``DeserializedObject`` instances looks
|
||||
|
||||
@@ -166,8 +166,6 @@ Advanced features of ``TransactionTestCase``
|
||||
|
||||
.. attribute:: TransactionTestCase.available_apps
|
||||
|
||||
.. versionadded:: 1.6
|
||||
|
||||
.. warning::
|
||||
|
||||
This attribute is a private API. It may be changed or removed without
|
||||
@@ -295,8 +293,6 @@ Defining a test runner
|
||||
|
||||
.. currentmodule:: django.test.runner
|
||||
|
||||
.. versionadded:: 1.6
|
||||
|
||||
A test runner is a class defining a ``run_tests()`` method. Django ships
|
||||
with a ``DiscoverRunner`` class that defines the default Django testing
|
||||
behavior. This class defines the ``run_tests()`` entry point, plus a
|
||||
|
||||
@@ -58,12 +58,6 @@ test utility is to find all the test cases (that is, subclasses of
|
||||
:class:`unittest.TestCase`) in any file whose name begins with ``test``,
|
||||
automatically build a test suite out of those test cases, and run that suite.
|
||||
|
||||
.. versionchanged:: 1.6
|
||||
|
||||
Previously, Django's default test runner only discovered tests in
|
||||
``tests.py`` and ``models.py`` files within a Python package listed in
|
||||
:setting:`INSTALLED_APPS`.
|
||||
|
||||
For more details about :mod:`unittest`, see the Python documentation.
|
||||
|
||||
.. warning::
|
||||
@@ -120,15 +114,6 @@ You can specify a custom filename pattern match using the ``-p`` (or
|
||||
|
||||
$ ./manage.py test --pattern="tests_*.py"
|
||||
|
||||
.. versionchanged:: 1.6
|
||||
|
||||
Previously, test labels were in the form ``applabel``,
|
||||
``applabel.TestCase``, or ``applabel.TestCase.test_method``, rather than
|
||||
being true Python dotted paths, and tests could only be found within
|
||||
``tests.py`` or ``models.py`` files within a Python package listed in
|
||||
:setting:`INSTALLED_APPS`. The ``--pattern`` option and file paths as test
|
||||
labels are new in 1.6.
|
||||
|
||||
If you press ``Ctrl-C`` while the tests are running, the test runner will
|
||||
wait for the currently running test to complete and then exit gracefully.
|
||||
During a graceful exit the test runner will output details of any test
|
||||
|
||||
@@ -573,11 +573,6 @@ functionality like:
|
||||
* Using the :attr:`~SimpleTestCase.client` :class:`~django.test.Client`.
|
||||
* Custom test-time :attr:`URL maps <SimpleTestCase.urls>`.
|
||||
|
||||
.. versionchanged:: 1.6
|
||||
|
||||
The latter two features were moved from ``TransactionTestCase`` to
|
||||
``SimpleTestCase`` in Django 1.6.
|
||||
|
||||
If you need any of the other more complex and heavyweight Django-specific
|
||||
features like:
|
||||
|
||||
@@ -1281,8 +1276,6 @@ your test suite.
|
||||
|
||||
.. method:: SimpleTestCase.assertFormsetError(response, formset, form_index, field, errors, msg_prefix='')
|
||||
|
||||
.. versionadded:: 1.6
|
||||
|
||||
Asserts that the ``formset`` raises the provided list of errors when
|
||||
rendered.
|
||||
|
||||
@@ -1459,16 +1452,12 @@ your test suite.
|
||||
By default, the comparison is also ordering dependent. If ``qs`` doesn't
|
||||
provide an implicit ordering, you can set the ``ordered`` parameter to
|
||||
``False``, which turns the comparison into a Python set comparison.
|
||||
If the order is undefined (if the given ``qs`` isn't ordered and the
|
||||
comparison is against more than one ordered values), a ``ValueError`` is
|
||||
raised.
|
||||
|
||||
Output in case of error can be customized with the ``msg`` argument.
|
||||
|
||||
.. 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
|
||||
than one ordered values.
|
||||
|
||||
.. versionchanged:: 1.7
|
||||
|
||||
The method now accepts a ``msg`` parameter to allow customization of
|
||||
|
||||
Reference in New Issue
Block a user