Removed versionadded/changed annotations for 1.6.
This commit is contained in:
Tim Graham
parent
ec08d62a20
commit
51c8045145
|
|
@ -269,10 +269,6 @@ All attributes can be set in your derived class and can be used in
|
|||
because attempting to set the locale needs access to settings. This condition
|
||||
will generate a :class:`CommandError`.
|
||||
|
||||
.. versionadded:: 1.6
|
||||
|
||||
The ``leave_locale_alone`` option was added in Django 1.6.
|
||||
|
||||
Methods
|
||||
-------
|
||||
|
||||
|
|
|
|||
|
|
@ -74,11 +74,6 @@ with Django you'd need to change the ``managed`` option highlighted above to
|
|||
This serves as an explicit opt-in to give your nascent Django project write
|
||||
access to your precious data on a model by model basis.
|
||||
|
||||
.. versionchanged:: 1.6
|
||||
|
||||
The behavior by which introspected models are created as unmanaged ones is new
|
||||
in Django 1.6.
|
||||
|
||||
Install the core Django tables
|
||||
==============================
|
||||
|
||||
|
|
|
|||
|
|
@ -213,8 +213,6 @@ RedirectView
|
|||
|
||||
.. attribute:: pattern_name
|
||||
|
||||
.. versionadded:: 1.6
|
||||
|
||||
The name of the URL pattern to redirect to. Reversing will be done
|
||||
using the same args and kwargs as are passed in for this view.
|
||||
|
||||
|
|
@ -238,10 +236,6 @@ RedirectView
|
|||
|
||||
Constructs the target URL for redirection.
|
||||
|
||||
.. versionchanged:: 1.6
|
||||
|
||||
The signature of this method was changed to include ``*args``.
|
||||
|
||||
The default implementation uses :attr:`url` as a starting
|
||||
string and performs expansion of ``%`` named parameters in that string
|
||||
using the named groups captured in the URL.
|
||||
|
|
|
|||
|
|
@ -37,8 +37,6 @@ FormMixin
|
|||
|
||||
.. attribute:: prefix
|
||||
|
||||
.. versionadded:: 1.6
|
||||
|
||||
The :attr:`~django.forms.Form.prefix` for the generated form.
|
||||
|
||||
.. method:: get_initial()
|
||||
|
|
@ -66,8 +64,6 @@ FormMixin
|
|||
|
||||
.. method:: get_prefix()
|
||||
|
||||
.. versionadded:: 1.6
|
||||
|
||||
Determine the :attr:`~django.forms.Form.prefix` for the generated form.
|
||||
Returns :attr:`~django.views.generic.edit.FormMixin.prefix` by default.
|
||||
|
||||
|
|
@ -234,12 +230,10 @@ DeletionMixin
|
|||
The url to redirect to when the nominated object has been
|
||||
successfully deleted.
|
||||
|
||||
.. versionadded:: 1.6
|
||||
|
||||
``success_url`` may contain dictionary string formatting, which
|
||||
will be interpolated against the object's field attributes. For
|
||||
example, you could use ``success_url="/parent/%(parent_id)s/"`` to
|
||||
redirect to a URL composed out of the ``parent_id`` field on a model.
|
||||
``success_url`` may contain dictionary string formatting, which will be
|
||||
interpolated against the object's field attributes. For example, you
|
||||
could use ``success_url="/parent/%(parent_id)s/"`` to redirect to a URL
|
||||
composed out of the ``parent_id`` field on a model.
|
||||
|
||||
.. method:: get_success_url()
|
||||
|
||||
|
|
|
|||
|
|
@ -81,8 +81,6 @@ MultipleObjectMixin
|
|||
|
||||
.. attribute:: paginate_orphans
|
||||
|
||||
.. versionadded:: 1.6
|
||||
|
||||
An integer specifying the number of "overflow" objects the last page
|
||||
can contain. This extends the :attr:`paginate_by` limit on the last
|
||||
page by up to ``paginate_orphans``, in order to keep the last page from
|
||||
|
|
@ -135,8 +133,6 @@ MultipleObjectMixin
|
|||
|
||||
.. method:: get_paginate_orphans()
|
||||
|
||||
.. versionadded:: 1.6
|
||||
|
||||
An integer specifying the number of "overflow" objects the last page
|
||||
can contain. By default this simply returns the value of
|
||||
:attr:`paginate_orphans`.
|
||||
|
|
|
|||
|
|
@ -61,10 +61,8 @@ To set the same ``X-Frame-Options`` value for all responses in your site, put
|
|||
...
|
||||
)
|
||||
|
||||
.. versionchanged:: 1.6
|
||||
|
||||
This middleware is enabled in the settings file generated by
|
||||
:djadmin:`startproject`.
|
||||
This middleware is enabled in the settings file generated by
|
||||
:djadmin:`startproject`.
|
||||
|
||||
By default, the middleware will set the ``X-Frame-Options`` header to
|
||||
``SAMEORIGIN`` for every outgoing ``HttpResponse``. If you want ``DENY``
|
||||
|
|
|
|||
|
|
@ -17,10 +17,6 @@ Overview
|
|||
The admin is enabled in the default project template used by
|
||||
:djadmin:`startproject`.
|
||||
|
||||
.. versionchanged:: 1.6
|
||||
|
||||
In previous versions, the admin wasn't enabled by default.
|
||||
|
||||
For reference, here are the requirements:
|
||||
|
||||
1. Add ``'django.contrib.admin'`` to your :setting:`INSTALLED_APPS` setting.
|
||||
|
|
@ -419,8 +415,6 @@ subclass::
|
|||
|
||||
.. admonition:: Note
|
||||
|
||||
.. versionchanged:: 1.6
|
||||
|
||||
If you define the ``Meta.model`` attribute on a
|
||||
:class:`~django.forms.ModelForm`, you must also define the
|
||||
``Meta.fields`` attribute (or the ``Meta.exclude`` attribute). However,
|
||||
|
|
@ -693,9 +687,7 @@ subclass::
|
|||
list_display = ('full_name',)
|
||||
|
||||
|
||||
* .. versionadded:: 1.6
|
||||
|
||||
The field names in ``list_display`` will also appear as CSS classes in
|
||||
* The field names in ``list_display`` will also appear as CSS classes in
|
||||
the HTML output, in the form of ``column-<field_name>`` on each ``<th>``
|
||||
element. This can be used to set column widths in a CSS file for example.
|
||||
|
||||
|
|
@ -918,8 +910,6 @@ subclass::
|
|||
the list of objects on the admin change list page. This can save you a
|
||||
bunch of database queries.
|
||||
|
||||
.. versionchanged:: 1.6
|
||||
|
||||
The value should be either a boolean, a list or a tuple. Default is
|
||||
``False``.
|
||||
|
||||
|
|
@ -978,8 +968,6 @@ subclass::
|
|||
|
||||
.. attribute:: ModelAdmin.preserve_filters
|
||||
|
||||
.. versionadded:: 1.6
|
||||
|
||||
The admin now preserves filters on the list view after creating, editing
|
||||
or deleting an object. You can restore the previous behavior of clearing
|
||||
filters by setting this attribute to ``False``.
|
||||
|
|
@ -1286,8 +1274,6 @@ templates used by the :class:`ModelAdmin` views:
|
|||
|
||||
.. method:: ModelAdmin.get_search_results(request, queryset, search_term)
|
||||
|
||||
.. versionadded:: 1.6
|
||||
|
||||
The ``get_search_results`` method modifies the list of objects displayed in
|
||||
to those that match the provided search term. It accepts the request, a
|
||||
queryset that applies the current filters, and the user-provided search term.
|
||||
|
|
@ -1598,8 +1584,6 @@ templates used by the :class:`ModelAdmin` views:
|
|||
|
||||
.. admonition:: Note
|
||||
|
||||
.. versionchanged:: 1.6
|
||||
|
||||
If you define the ``Meta.model`` attribute on a
|
||||
:class:`~django.forms.ModelForm`, you must also define the
|
||||
``Meta.fields`` attribute (or the ``Meta.exclude`` attribute). However,
|
||||
|
|
@ -1659,10 +1643,6 @@ templates used by the :class:`ModelAdmin` views:
|
|||
return qs
|
||||
return qs.filter(author=request.user)
|
||||
|
||||
.. versionchanged:: 1.6
|
||||
|
||||
The ``get_queryset`` method was previously named ``queryset``.
|
||||
|
||||
.. method:: ModelAdmin.message_user(request, message, level=messages.INFO, extra_tags='', fail_silently=False)
|
||||
|
||||
Sends a message to the user using the :mod:`django.contrib.messages`
|
||||
|
|
@ -1817,10 +1797,6 @@ To avoid conflicts with user-supplied scripts or libraries, Django's jQuery
|
|||
in your own admin JavaScript without including a second copy, you can use the
|
||||
``django.jQuery`` object on changelist and add/edit views.
|
||||
|
||||
.. versionchanged:: 1.6
|
||||
|
||||
The embedded jQuery has been upgraded from 1.4.2 to 1.9.1.
|
||||
|
||||
The :class:`ModelAdmin` class requires jQuery by default, so there is no need
|
||||
to add jQuery to your ``ModelAdmin``’s list of media resources unless you have
|
||||
a specific need. For example, if you require the jQuery library to be in the
|
||||
|
|
@ -1975,8 +1951,6 @@ The ``InlineModelAdmin`` class adds:
|
|||
The dynamic link will not appear if the number of currently displayed forms
|
||||
exceeds ``max_num``, or if the user does not have JavaScript enabled.
|
||||
|
||||
.. versionadded:: 1.6
|
||||
|
||||
:meth:`InlineModelAdmin.get_extra` also allows you to customize the number
|
||||
of extra forms.
|
||||
|
||||
|
|
@ -1988,8 +1962,6 @@ The ``InlineModelAdmin`` class adds:
|
|||
doesn't directly correlate to the number of objects, but can if the value
|
||||
is small enough. See :ref:`model-formsets-max-num` for more information.
|
||||
|
||||
.. versionadded:: 1.6
|
||||
|
||||
:meth:`InlineModelAdmin.get_max_num` also allows you to customize the
|
||||
maximum number of extra forms.
|
||||
|
||||
|
|
@ -2035,8 +2007,6 @@ The ``InlineModelAdmin`` class adds:
|
|||
|
||||
.. method:: InlineModelAdmin.get_extra(request, obj=None, **kwargs)
|
||||
|
||||
.. versionadded:: 1.6
|
||||
|
||||
Returns the number of extra inline forms to use. By default, returns the
|
||||
:attr:`InlineModelAdmin.extra` attribute.
|
||||
|
||||
|
|
@ -2055,8 +2025,6 @@ The ``InlineModelAdmin`` class adds:
|
|||
|
||||
.. method:: InlineModelAdmin.get_max_num(request, obj=None, **kwargs)
|
||||
|
||||
.. versionadded:: 1.6
|
||||
|
||||
Returns the maximum number of extra inline forms to use. By default,
|
||||
returns the :attr:`InlineModelAdmin.max_num` attribute.
|
||||
|
||||
|
|
@ -2551,11 +2519,6 @@ your URLconf. Specifically, add these four patterns:
|
|||
url(r'^reset/(?P<uidb64>[0-9A-Za-z_\-]+)/(?P<token>.+)/$', 'django.contrib.auth.views.password_reset_confirm', name='password_reset_confirm'),
|
||||
url(r'^reset/done/$', 'django.contrib.auth.views.password_reset_complete', name='password_reset_complete'),
|
||||
|
||||
.. versionchanged:: 1.6
|
||||
|
||||
The pattern for :func:`~django.contrib.auth.views.password_reset_confirm`
|
||||
changed as the ``uid`` is now base 64 encoded.
|
||||
|
||||
(This assumes you've added the admin at ``admin/`` and requires that you put
|
||||
the URLs starting with ``^admin/`` before the line that includes the admin app
|
||||
itself).
|
||||
|
|
|
|||
|
|
@ -143,23 +143,12 @@ Methods
|
|||
:meth:`~django.contrib.auth.models.User.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.
|
||||
|
||||
.. method:: 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:: set_unusable_password()
|
||||
|
||||
Marks the user as having no password set. This isn't the same as
|
||||
|
|
|
|||
|
|
@ -291,8 +291,6 @@ model:
|
|||
|
||||
.. attribute:: GenericForeignKey.for_concrete_model
|
||||
|
||||
.. versionadded:: 1.6
|
||||
|
||||
If ``False``, the field will be able to reference proxy models. Default
|
||||
is ``True``. This mirrors the ``for_concrete_model`` argument to
|
||||
:meth:`~django.contrib.contenttypes.models.ContentTypeManager.get_for_model`.
|
||||
|
|
@ -508,11 +506,9 @@ The :mod:`django.contrib.contenttypes.forms` module provides:
|
|||
:func:`~django.forms.models.modelformset_factory` and
|
||||
:func:`~django.forms.models.inlineformset_factory`.
|
||||
|
||||
.. versionadded:: 1.6
|
||||
|
||||
The ``for_concrete_model`` argument corresponds to the
|
||||
:class:`~django.contrib.contenttypes.fields.GenericForeignKey.for_concrete_model`
|
||||
argument on ``GenericForeignKey``.
|
||||
The ``for_concrete_model`` argument corresponds to the
|
||||
:class:`~django.contrib.contenttypes.fields.GenericForeignKey.for_concrete_model`
|
||||
argument on ``GenericForeignKey``.
|
||||
|
||||
.. versionchanged:: 1.7
|
||||
|
||||
|
|
|
|||
|
|
@ -260,8 +260,6 @@ wizard's ``as_view()`` method takes a list of your
|
|||
(r'^contact/$', ContactWizard.as_view([ContactForm1, ContactForm2])),
|
||||
)
|
||||
|
||||
.. versionchanged:: 1.6
|
||||
|
||||
You can also pass the form list as a class attribute named ``form_list``::
|
||||
|
||||
class ContactWizard(WizardView):
|
||||
|
|
@ -317,8 +315,6 @@ The ``urls.py`` file would contain something like::
|
|||
(r'^checkout/$', OrderWizard.as_view(FORMS, condition_dict={'cc': pay_by_credit_card})),
|
||||
)
|
||||
|
||||
.. versionchanged:: 1.6
|
||||
|
||||
The ``condition_dict`` can be passed as attribute for the ``as_view()`
|
||||
method or as a class attribute named ``condition_dict``::
|
||||
|
||||
|
|
@ -493,8 +489,6 @@ Advanced ``WizardView`` methods
|
|||
|
||||
.. method:: WizardView.render_goto_step(step, goto_step, **kwargs)
|
||||
|
||||
.. versionadded:: 1.6
|
||||
|
||||
This method is called when the step should be changed to something else
|
||||
than the next step. By default, this method just stores the requested
|
||||
step ``goto_step`` in the storage and then renders the new step.
|
||||
|
|
@ -598,8 +592,6 @@ Providing initial data for the forms
|
|||
The ``initial_dict`` can also take a list of dictionaries for a specific
|
||||
step if the step is a ``FormSet``.
|
||||
|
||||
.. versionchanged:: 1.6
|
||||
|
||||
The ``initial_dict`` can also be added as a class attribute named
|
||||
``initial_dict`` to avoid having the initial data in the ``urls.py``.
|
||||
|
||||
|
|
|
|||
|
|
@ -7,8 +7,6 @@ GeoDjango Forms API
|
|||
.. module:: django.contrib.gis.forms
|
||||
:synopsis: GeoDjango forms API.
|
||||
|
||||
.. versionadded:: 1.6
|
||||
|
||||
GeoDjango provides some specialized form fields and widgets in order to visually
|
||||
display and edit geolocalized data on a map. By default, they use
|
||||
`OpenLayers`_-powered maps, with a base WMS layer provided by `Metacarta`_.
|
||||
|
|
|
|||
|
|
@ -354,8 +354,6 @@ example::
|
|||
Adding messages in Class Based Views
|
||||
------------------------------------
|
||||
|
||||
.. versionadded:: 1.6
|
||||
|
||||
.. class:: views.SuccessMessageMixin
|
||||
|
||||
Adds a success message attribute to
|
||||
|
|
|
|||
|
|
@ -249,10 +249,6 @@ To do this, you can use the sites framework. A simple example::
|
|||
Enabling the sites framework
|
||||
============================
|
||||
|
||||
.. versionchanged:: 1.6
|
||||
|
||||
In previous versions, the sites framework was enabled by default.
|
||||
|
||||
To enable the sites framework, follow these steps:
|
||||
|
||||
1. Add ``'django.contrib.sites'`` to your :setting:`INSTALLED_APPS`
|
||||
|
|
|
|||
|
|
@ -139,8 +139,6 @@ into those elements.
|
|||
|
||||
.. method:: Feed.get_context_data(**kwargs)
|
||||
|
||||
.. versionadded:: 1.6
|
||||
|
||||
There is also a way to pass additional information to title and description
|
||||
templates, if you need to supply more than the two variables mentioned
|
||||
before. You can provide your implementation of ``get_context_data`` method
|
||||
|
|
|
|||
|
|
@ -19,8 +19,6 @@ General notes
|
|||
Persistent connections
|
||||
----------------------
|
||||
|
||||
.. versionadded:: 1.6
|
||||
|
||||
Persistent connections avoid the overhead of re-establishing a connection to
|
||||
the database in each request. They're controlled by the
|
||||
:setting:`CONN_MAX_AGE` parameter which defines the maximum lifetime of a
|
||||
|
|
@ -114,34 +112,11 @@ will do some additional queries to set these parameters.
|
|||
|
||||
.. _ALTER ROLE: http://www.postgresql.org/docs/current/interactive/sql-alterrole.html
|
||||
|
||||
.. _postgresql-autocommit-mode:
|
||||
|
||||
Autocommit mode
|
||||
---------------
|
||||
|
||||
.. 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 = {
|
||||
# ...
|
||||
'OPTIONS': {
|
||||
'autocommit': True,
|
||||
},
|
||||
}
|
||||
|
||||
Since Django 1.6, autocommit is turned on by default. This configuration is
|
||||
ignored and can be safely removed.
|
||||
|
||||
.. _database-isolation-level:
|
||||
|
||||
Isolation level
|
||||
---------------
|
||||
|
||||
.. versionadded:: 1.6
|
||||
|
||||
Like PostgreSQL itself, Django defaults to the ``READ COMMITTED`` `isolation
|
||||
level`_. If you need a higher isolation level such as ``REPEATABLE READ`` or
|
||||
``SERIALIZABLE``, set it in the :setting:`OPTIONS` part of your database
|
||||
|
|
|
|||
|
|
@ -144,10 +144,6 @@ Example usage::
|
|||
django-admin.py compilemessages -l pt_BR
|
||||
django-admin.py compilemessages -l pt_BR -l fr
|
||||
|
||||
.. versionchanged:: 1.6
|
||||
|
||||
Added the ability to specify multiple locales.
|
||||
|
||||
createcachetable
|
||||
----------------
|
||||
|
||||
|
|
@ -203,10 +199,6 @@ example, the default settings don't define :setting:`ROOT_URLCONF`, so
|
|||
The :djadminopt:`--all` option may be provided to display all settings, even
|
||||
if they have Django's default value. Such settings are prefixed by ``"###"``.
|
||||
|
||||
.. versionadded:: 1.6
|
||||
|
||||
The :djadminopt:`--all` option was added.
|
||||
|
||||
dumpdata <app_label app_label app_label.Model ...>
|
||||
--------------------------------------------------
|
||||
|
||||
|
|
@ -278,8 +270,6 @@ Use :ref:`natural keys <topics-serialization-natural-keys>` to represent
|
|||
any foreign key and many-to-many relationship with a model that provides
|
||||
a natural key definition.
|
||||
|
||||
.. versionadded:: 1.6
|
||||
|
||||
.. django-admin-option:: --pks
|
||||
|
||||
By default, ``dumpdata`` will output all the records of the model, but
|
||||
|
|
@ -363,11 +353,6 @@ access to your precious data on a model by model basis.
|
|||
The :djadminopt:`--database` option may be used to specify the
|
||||
database to introspect.
|
||||
|
||||
.. versionchanged:: 1.6
|
||||
|
||||
The behavior by which introspected models are created as unmanaged ones is new
|
||||
in Django 1.6.
|
||||
|
||||
loaddata <fixture fixture ...>
|
||||
------------------------------
|
||||
|
||||
|
|
@ -565,10 +550,6 @@ Example usage::
|
|||
django-admin.py makemessages -l pt_BR
|
||||
django-admin.py makemessages -l pt_BR -l fr
|
||||
|
||||
.. versionchanged:: 1.6
|
||||
|
||||
Added the ability to specify multiple locales.
|
||||
|
||||
.. versionchanged:: 1.7
|
||||
|
||||
Added the ``--previous`` option to the ``msgmerge`` command when merging
|
||||
|
|
@ -620,8 +601,6 @@ for technically skilled translators to understand each message's context.
|
|||
|
||||
.. django-admin-option:: --keep-pot
|
||||
|
||||
.. versionadded:: 1.6
|
||||
|
||||
Use the ``--keep-pot`` option to prevent Django from deleting the temporary
|
||||
.pot files it generates before creating the .po file. This is useful for
|
||||
debugging errors which may prevent the final language files from being created.
|
||||
|
|
@ -977,10 +956,6 @@ behavior you can use the ``--no-startup`` option. e.g.::
|
|||
|
||||
django-admin.py shell --plain --no-startup
|
||||
|
||||
.. versionadded:: 1.6
|
||||
|
||||
The ``--no-startup`` option was added in Django 1.6.
|
||||
|
||||
sql <app_label app_label ...>
|
||||
-----------------------------
|
||||
|
||||
|
|
@ -1043,8 +1018,6 @@ sqldropindexes <app_label app_label ...>
|
|||
|
||||
.. django-admin:: sqldropindexes
|
||||
|
||||
.. versionadded:: 1.6
|
||||
|
||||
Prints the DROP INDEX SQL statements for the given app name(s).
|
||||
|
||||
The :djadminopt:`--database` option can be used to specify the database for
|
||||
|
|
@ -1510,11 +1483,6 @@ By default, ``django-admin.py`` will show a simple error message whenever an
|
|||
for any other exception. If you specify ``--traceback``, ``django-admin.py``
|
||||
will also output a full stack trace when a ``CommandError`` is raised.
|
||||
|
||||
.. versionchanged:: 1.6
|
||||
|
||||
Previously, Django didn't show a full stack trace by default for exceptions
|
||||
other than ``CommandError``.
|
||||
|
||||
.. django-admin-option:: --verbosity
|
||||
|
||||
Example usage::
|
||||
|
|
|
|||
|
|
@ -187,11 +187,6 @@ information provided. (Note that this attribute is available under
|
|||
both Python 2 and Python 3, although :pep:`3134` normally only applies
|
||||
to Python 3.)
|
||||
|
||||
.. versionchanged:: 1.6
|
||||
|
||||
Previous versions of Django only wrapped ``DatabaseError`` and
|
||||
``IntegrityError``, and did not provide ``__cause__``.
|
||||
|
||||
.. exception:: models.ProtectedError
|
||||
|
||||
Raised to prevent deletion of referenced objects when using
|
||||
|
|
|
|||
|
|
@ -623,10 +623,6 @@ By default, ``auto_id`` is set to the string ``'id_%s'``.
|
|||
A translatable string (defaults to a colon (``:``) in English) that will be
|
||||
appended after any label name when a form is rendered.
|
||||
|
||||
.. versionchanged:: 1.6
|
||||
|
||||
The default ``label_suffix`` is translatable.
|
||||
|
||||
It's possible to customize that character, or omit it entirely, using the
|
||||
``label_suffix`` parameter::
|
||||
|
||||
|
|
@ -647,8 +643,6 @@ Note that the label suffix is added only if the last character of the
|
|||
label isn't a punctuation character (in English, those are ``.``, ``!``, ``?``
|
||||
or ``:``).
|
||||
|
||||
.. versionadded:: 1.6
|
||||
|
||||
You can also customize the ``label_suffix`` on a per-field basis using the
|
||||
``label_suffix`` parameter to :meth:`~django.forms.BoundField.label_tag`.
|
||||
|
||||
|
|
@ -795,18 +789,13 @@ Optionally, you can provide the ``contents`` parameter which will replace the
|
|||
auto-generated label tag. An optional ``attrs`` dictionary may contain
|
||||
additional attributes for the ``<label>`` tag.
|
||||
|
||||
.. versionchanged:: 1.6
|
||||
|
||||
The label now includes the form's :attr:`~django.forms.Form.label_suffix`
|
||||
(a colon, by default).
|
||||
|
||||
.. versionadded:: 1.6
|
||||
|
||||
The optional ``label_suffix`` parameter allows you to override the form's
|
||||
:attr:`~django.forms.Form.label_suffix`. For example, you can use an empty
|
||||
string to hide the label on selected fields. If you need to do this in a
|
||||
template, you could write a custom filter to allow passing parameters to
|
||||
``label_tag``.
|
||||
The HTML that's generated includes the form's
|
||||
:attr:`~django.forms.Form.label_suffix` (a colon, by default). The optional
|
||||
``label_suffix`` parameter allows you to override the form's
|
||||
:attr:`~django.forms.Form.label_suffix`. For example, you can use an empty
|
||||
string to hide the label on selected fields. If you need to do this in a
|
||||
template, you could write a custom filter to allow passing parameters to
|
||||
``label_tag``.
|
||||
|
||||
.. versionchanged:: 1.8
|
||||
|
||||
|
|
|
|||
|
|
@ -481,11 +481,8 @@ For each field, we describe the default widget used if you don't specify
|
|||
|
||||
The ``max_value`` and ``min_value`` error messages may contain
|
||||
``%(limit_value)s``, which will be substituted by the appropriate limit.
|
||||
|
||||
.. versionchanged:: 1.6
|
||||
|
||||
Similarly, the ``max_digits``, ``max_decimal_places`` and
|
||||
``max_whole_digits`` error messages may contain ``%(max)s``.
|
||||
Similarly, the ``max_digits``, ``max_decimal_places`` and
|
||||
``max_whole_digits`` error messages may contain ``%(max)s``.
|
||||
|
||||
Takes four optional arguments:
|
||||
|
||||
|
|
@ -1105,11 +1102,9 @@ objects (in the case of ``ModelMultipleChoiceField``) into the
|
|||
* Error message keys: ``required``, ``list``, ``invalid_choice``,
|
||||
``invalid_pk_value``
|
||||
|
||||
.. versionchanged:: 1.6
|
||||
|
||||
The ``invalid_choice`` message may contain ``%(value)s`` and the
|
||||
``invalid_pk_value`` message may contain ``%(pk)s``, which will be
|
||||
substituted by the appropriate values.
|
||||
The ``invalid_choice`` message may contain ``%(value)s`` and the
|
||||
``invalid_pk_value`` message may contain ``%(pk)s``, which will be
|
||||
substituted by the appropriate values.
|
||||
|
||||
Allows the selection of one or more model objects, suitable for
|
||||
representing a many-to-many relation. As with :class:`ModelChoiceField`,
|
||||
|
|
|
|||
|
|
@ -11,10 +11,6 @@ Formset Functions
|
|||
|
||||
See :ref:`formsets` for example usage.
|
||||
|
||||
.. versionchanged:: 1.6
|
||||
|
||||
The ``validate_max`` parameter was added.
|
||||
|
||||
.. versionchanged:: 1.7
|
||||
|
||||
The ``min_num`` and ``validate_min`` parameters were added.
|
||||
|
|
|
|||
|
|
@ -61,11 +61,6 @@ Model Form Functions
|
|||
|
||||
See :ref:`model-formsets` for example usage.
|
||||
|
||||
.. versionchanged:: 1.6
|
||||
|
||||
The ``widgets``, ``validate_max``, ``localized_fields``, ``labels``,
|
||||
``help_texts``, and ``error_messages`` parameters were added.
|
||||
|
||||
.. function:: inlineformset_factory(parent_model, model, form=ModelForm, formset=BaseInlineFormSet, fk_name=None, fields=None, exclude=None, extra=3, can_order=False, can_delete=True, max_num=None, formfield_callback=None, widgets=None, validate_max=False, localized_fields=None, labels=None, help_texts=None, error_messages=None)
|
||||
|
||||
Returns an ``InlineFormSet`` using :func:`modelformset_factory` with
|
||||
|
|
@ -76,8 +71,3 @@ Model Form Functions
|
|||
the ``parent_model``, you must specify a ``fk_name``.
|
||||
|
||||
See :ref:`inline-formsets` for example usage.
|
||||
|
||||
.. versionchanged:: 1.6
|
||||
|
||||
The ``widgets``, ``validate_max`` and ``localized_fields``, ``labels``,
|
||||
``help_texts``, and ``error_messages`` parameters were added.
|
||||
|
|
|
|||
|
|
@ -113,8 +113,6 @@ for all remaining fields are still executed.
|
|||
Raising ``ValidationError``
|
||||
---------------------------
|
||||
|
||||
.. versionchanged:: 1.6
|
||||
|
||||
In order to make error messages flexible and easy to override, consider the
|
||||
following guidelines:
|
||||
|
||||
|
|
|
|||
|
|
@ -409,8 +409,6 @@ These widgets make use of the HTML elements ``input`` and ``textarea``.
|
|||
|
||||
.. class:: NumberInput
|
||||
|
||||
.. versionadded:: 1.6
|
||||
|
||||
Text input: ``<input type="number" ...>``
|
||||
|
||||
Beware that not all browsers support entering localized numbers in
|
||||
|
|
@ -422,8 +420,6 @@ These widgets make use of the HTML elements ``input`` and ``textarea``.
|
|||
|
||||
.. class:: EmailInput
|
||||
|
||||
.. versionadded:: 1.6
|
||||
|
||||
Text input: ``<input type="email" ...>``
|
||||
|
||||
``URLInput``
|
||||
|
|
@ -431,8 +427,6 @@ These widgets make use of the HTML elements ``input`` and ``textarea``.
|
|||
|
||||
.. class:: URLInput
|
||||
|
||||
.. versionadded:: 1.6
|
||||
|
||||
Text input: ``<input type="url" ...>``
|
||||
|
||||
``PasswordInput``
|
||||
|
|
@ -649,10 +643,8 @@ Selector and checkbox widgets
|
|||
simply includes ``{{ myform.beatles }}`` -- they'll be output in a ``<ul>``
|
||||
with ``<li>`` tags, as above.
|
||||
|
||||
.. versionchanged:: 1.6
|
||||
|
||||
The outer ``<ul>`` container will now receive the ``id`` attribute defined on
|
||||
the widget.
|
||||
The outer ``<ul>`` container will receive the ``id`` attribute defined on
|
||||
the widget.
|
||||
|
||||
.. versionchanged:: 1.7
|
||||
|
||||
|
|
@ -675,10 +667,8 @@ the widget.
|
|||
...
|
||||
</ul>
|
||||
|
||||
.. versionchanged:: 1.6
|
||||
|
||||
The outer ``<ul>`` container will now receive the ``id`` attribute defined on
|
||||
the widget.
|
||||
The outer ``<ul>`` container will receive the ``id`` attribute defined on
|
||||
the widget.
|
||||
|
||||
Like :class:`RadioSelect`, you can now loop over the individual checkboxes making
|
||||
up the lists. See the documentation of :class:`RadioSelect` for more details.
|
||||
|
|
|
|||
|
|
@ -217,30 +217,6 @@ Adds protection against Cross Site Request Forgeries by adding hidden form
|
|||
fields to POST forms and checking requests for the correct value. See the
|
||||
:doc:`Cross Site Request Forgery protection documentation </ref/contrib/csrf>`.
|
||||
|
||||
Transaction middleware
|
||||
----------------------
|
||||
|
||||
.. module:: django.middleware.transaction
|
||||
:synopsis: Middleware binding a database transaction to each Web request.
|
||||
|
||||
.. class:: TransactionMiddleware
|
||||
|
||||
.. versionchanged:: 1.6
|
||||
|
||||
``TransactionMiddleware`` is deprecated. The documentation of transactions
|
||||
contains :ref:`upgrade instructions <transactions-upgrading-from-1.5>`.
|
||||
|
||||
Binds commit and rollback of the default database to the request/response
|
||||
phase. If a view function runs successfully, a commit is done. If it fails with
|
||||
an exception, a rollback is done.
|
||||
|
||||
The order of this middleware in the stack is important: middleware modules
|
||||
running outside of it run with commit-on-save - the default Django behavior.
|
||||
Middleware modules running inside it (coming later in the stack) will be under
|
||||
the same transaction control as the view functions.
|
||||
|
||||
See the :doc:`transaction management documentation </topics/db/transactions>`.
|
||||
|
||||
X-Frame-Options middleware
|
||||
--------------------------
|
||||
|
||||
|
|
|
|||
|
|
@ -384,8 +384,6 @@ guaranteed to fit numbers from ``-9223372036854775808`` to
|
|||
|
||||
.. class:: BinaryField([**options])
|
||||
|
||||
.. versionadded:: 1.6
|
||||
|
||||
A field to store raw binary data. It only supports ``bytes`` assignment. Be
|
||||
aware that this field has limited functionality. For example, it is not possible
|
||||
to filter a queryset on a ``BinaryField`` value.
|
||||
|
|
@ -409,10 +407,8 @@ The default form widget for this field is a
|
|||
If you need to accept :attr:`~Field.null` values then use
|
||||
:class:`NullBooleanField` instead.
|
||||
|
||||
.. versionchanged:: 1.6
|
||||
|
||||
The default value of ``BooleanField`` was changed from ``False`` to
|
||||
``None`` when :attr:`Field.default` isn't defined.
|
||||
The default value of ``BooleanField`` is ``None`` when :attr:`Field.default`
|
||||
isn't defined.
|
||||
|
||||
``CharField``
|
||||
-------------
|
||||
|
|
@ -1142,8 +1138,6 @@ define the details of how the relation works.
|
|||
|
||||
.. attribute:: ForeignKey.related_query_name
|
||||
|
||||
.. versionadded:: 1.6
|
||||
|
||||
The name to use for the reverse filter name from the target model.
|
||||
Defaults to the value of :attr:`related_name` if it is set, otherwise it
|
||||
defaults to the name of the model::
|
||||
|
|
@ -1163,8 +1157,6 @@ define the details of how the relation works.
|
|||
|
||||
.. attribute:: ForeignKey.db_constraint
|
||||
|
||||
.. versionadded:: 1.6
|
||||
|
||||
Controls whether or not a constraint should be created in the database for
|
||||
this foreign key. The default is ``True``, and that's almost certainly what
|
||||
you want; setting this to ``False`` can be very bad for data integrity.
|
||||
|
|
@ -1292,8 +1284,6 @@ that control how the relationship functions.
|
|||
|
||||
.. attribute:: ManyToManyField.related_query_name
|
||||
|
||||
.. versionadded:: 1.6
|
||||
|
||||
Same as :attr:`ForeignKey.related_query_name`.
|
||||
|
||||
.. attribute:: ManyToManyField.limit_choices_to
|
||||
|
|
@ -1396,8 +1386,6 @@ that control how the relationship functions.
|
|||
|
||||
.. attribute:: ManyToManyField.db_constraint
|
||||
|
||||
.. versionadded:: 1.6
|
||||
|
||||
Controls whether or not constraints should be created in the database for
|
||||
the foreign keys in the intermediary table. The default is ``True``, and
|
||||
that's almost certainly what you want; setting this to ``False`` can be
|
||||
|
|
|
|||
|
|
@ -86,14 +86,8 @@ validation errors yourself, or if you have excluded fields from the
|
|||
|
||||
.. method:: Model.full_clean(exclude=None, validate_unique=True)
|
||||
|
||||
.. versionchanged:: 1.6
|
||||
|
||||
The ``validate_unique`` parameter was added to allow skipping
|
||||
:meth:`Model.validate_unique()`. Previously, :meth:`Model.validate_unique()`
|
||||
was always called by ``full_clean``.
|
||||
|
||||
This method calls :meth:`Model.clean_fields()`, :meth:`Model.clean()`, and
|
||||
:meth:`Model.validate_unique()` (if ``validate_unique`` is ``True``, in that
|
||||
:meth:`Model.validate_unique()` (if ``validate_unique`` is ``True``), in that
|
||||
order and raises a :exc:`~django.core.exceptions.ValidationError` that has a
|
||||
``message_dict`` attribute containing errors from all three stages.
|
||||
|
||||
|
|
@ -310,17 +304,15 @@ value explicitly when saving new objects, if you cannot guarantee the
|
|||
primary-key value is unused. For more on this nuance, see `Explicitly specifying
|
||||
auto-primary-key values`_ above and `Forcing an INSERT or UPDATE`_ below.
|
||||
|
||||
.. versionchanged:: 1.6
|
||||
|
||||
Previously Django did a ``SELECT`` when the primary key attribute was set.
|
||||
If the ``SELECT`` found a row, then Django did an ``UPDATE``, otherwise it
|
||||
did an ``INSERT``. The old algorithm results in one more query in the
|
||||
``UPDATE`` case. There are some rare cases where the database doesn't
|
||||
report that a row was updated even if the database contains a row for the
|
||||
object's primary key value. An example is the PostgreSQL ``ON UPDATE``
|
||||
trigger which returns ``NULL``. In such cases it is possible to revert to the
|
||||
old algorithm by setting the :attr:`~django.db.models.Options.select_on_save`
|
||||
option to ``True``.
|
||||
In Django 1.5 and earlier, Django did a ``SELECT`` when the primary key
|
||||
attribute was set. If the ``SELECT`` found a row, then Django did an ``UPDATE``,
|
||||
otherwise it did an ``INSERT``. The old algorithm results in one more query in
|
||||
the ``UPDATE`` case. There are some rare cases where the database doesn't
|
||||
report that a row was updated even if the database contains a row for the
|
||||
object's primary key value. An example is the PostgreSQL ``ON UPDATE`` trigger
|
||||
which returns ``NULL``. In such cases it is possible to revert to the old
|
||||
algorithm by setting the :attr:`~django.db.models.Options.select_on_save`
|
||||
option to ``True``.
|
||||
|
||||
.. _ref-models-force-insert:
|
||||
|
||||
|
|
|
|||
|
|
@ -279,8 +279,6 @@ Django quotes column and table names behind the scenes.
|
|||
|
||||
.. attribute:: Options.select_on_save
|
||||
|
||||
.. versionadded:: 1.6
|
||||
|
||||
Determines if Django will use the pre-1.6
|
||||
:meth:`django.db.models.Model.save()` algorithm. The old algorithm
|
||||
uses ``SELECT`` to determine if there is an existing row to be updated.
|
||||
|
|
|
|||
|
|
@ -585,16 +585,7 @@ Returns a ``DateQuerySet`` — a ``QuerySet`` that evaluates to a list of
|
|||
:class:`datetime.date` objects representing all available dates of a
|
||||
particular kind within the contents of the ``QuerySet``.
|
||||
|
||||
.. versionchanged:: 1.6
|
||||
|
||||
``dates`` used to return a list of :class:`datetime.datetime` objects.
|
||||
|
||||
``field`` should be the name of a ``DateField`` of your model.
|
||||
|
||||
.. versionchanged:: 1.6
|
||||
|
||||
``dates`` used to accept operating on a ``DateTimeField``.
|
||||
|
||||
``kind`` should be either ``"year"``, ``"month"`` or ``"day"``. Each
|
||||
``datetime.date`` object in the result list is "truncated" to the given
|
||||
``type``.
|
||||
|
|
@ -624,8 +615,6 @@ Examples::
|
|||
datetimes
|
||||
~~~~~~~~~
|
||||
|
||||
.. versionadded:: 1.6
|
||||
|
||||
.. method:: datetimes(field, kind, order='ASC', tzinfo=None)
|
||||
|
||||
Returns a ``DateTimeQuerySet`` — a ``QuerySet`` that evaluates to a list of
|
||||
|
|
@ -769,8 +758,6 @@ follow all non-null foreign keys it can find - nullable foreign keys must be
|
|||
specified. This is not recommended in most cases as it is likely to make the
|
||||
underlying query more complex, and return more data, than is actually needed.
|
||||
|
||||
.. versionadded:: 1.6
|
||||
|
||||
If you need to clear the list of related fields added by past calls of
|
||||
``select_related`` on a ``QuerySet``, you can pass ``None`` as a parameter::
|
||||
|
||||
|
|
@ -1474,10 +1461,6 @@ get_or_create
|
|||
A convenience method for looking up an object with the given ``kwargs`` (may be
|
||||
empty if your model has defaults for all fields), creating one if necessary.
|
||||
|
||||
.. versionchanged:: 1.6
|
||||
|
||||
Older versions of Django required ``kwargs``.
|
||||
|
||||
Returns a tuple of ``(object, created)``, where ``object`` is the retrieved or
|
||||
created object and ``created`` is a boolean specifying whether a new object was
|
||||
created.
|
||||
|
|
@ -1762,16 +1745,13 @@ earliest
|
|||
|
||||
.. method:: earliest(field_name=None)
|
||||
|
||||
.. versionadded:: 1.6
|
||||
|
||||
Works otherwise like :meth:`~django.db.models.query.QuerySet.latest` except
|
||||
the direction is changed.
|
||||
|
||||
first
|
||||
~~~~~
|
||||
.. method:: first()
|
||||
|
||||
.. versionadded:: 1.6
|
||||
.. method:: first()
|
||||
|
||||
Returns the first object matched by the queryset, or ``None`` if there
|
||||
is no matching object. If the ``QuerySet`` has no ordering defined, then the
|
||||
|
|
@ -1793,8 +1773,6 @@ last
|
|||
~~~~
|
||||
.. method:: last()
|
||||
|
||||
.. versionadded:: 1.6
|
||||
|
||||
Works like :meth:`first()`, but returns the last object in the queryset.
|
||||
|
||||
aggregate
|
||||
|
|
@ -2435,8 +2413,6 @@ in the database <database-time-zone-definitions>`.
|
|||
hour
|
||||
~~~~
|
||||
|
||||
.. versionadded:: 1.6
|
||||
|
||||
For datetime fields, an exact hour match. Takes an integer between 0 and 23.
|
||||
|
||||
Example::
|
||||
|
|
@ -2457,8 +2433,6 @@ zone before filtering.
|
|||
minute
|
||||
~~~~~~
|
||||
|
||||
.. versionadded:: 1.6
|
||||
|
||||
For datetime fields, an exact minute match. Takes an integer between 0 and 59.
|
||||
|
||||
Example::
|
||||
|
|
@ -2479,8 +2453,6 @@ zone before filtering.
|
|||
second
|
||||
~~~~~~
|
||||
|
||||
.. versionadded:: 1.6
|
||||
|
||||
For datetime fields, an exact second match. Takes an integer between 0 and 59.
|
||||
|
||||
Example::
|
||||
|
|
|
|||
|
|
@ -636,8 +636,6 @@ Attributes
|
|||
|
||||
.. attribute:: HttpResponse.reason_phrase
|
||||
|
||||
.. versionadded:: 1.6
|
||||
|
||||
The HTTP reason phrase for the response.
|
||||
|
||||
.. attribute:: HttpResponse.streaming
|
||||
|
|
@ -670,8 +668,6 @@ Methods
|
|||
|
||||
``status`` is the `HTTP status code`_ for the response.
|
||||
|
||||
.. versionadded:: 1.6
|
||||
|
||||
``reason`` is the HTTP response phrase. If not provided, a default phrase
|
||||
will be used.
|
||||
|
||||
|
|
@ -782,8 +778,6 @@ types of HTTP responses. Like ``HttpResponse``, these subclasses live in
|
|||
|
||||
.. attribute:: HttpResponseRedirect.url
|
||||
|
||||
.. versionadded:: 1.6
|
||||
|
||||
This read-only attribute represents the URL the response will redirect
|
||||
to (equivalent to the ``Location`` response header).
|
||||
|
||||
|
|
@ -954,8 +948,6 @@ Attributes
|
|||
|
||||
.. attribute:: HttpResponse.reason_phrase
|
||||
|
||||
.. versionadded:: 1.6
|
||||
|
||||
The HTTP reason phrase for the response.
|
||||
|
||||
.. attribute:: HttpResponse.streaming
|
||||
|
|
|
|||
|
|
@ -348,8 +348,6 @@ protection is safe from cross-subdomain attacks by default - please see the
|
|||
CSRF_COOKIE_HTTPONLY
|
||||
--------------------
|
||||
|
||||
.. versionadded:: 1.6
|
||||
|
||||
Default: ``False``
|
||||
|
||||
Whether to use ``HttpOnly`` flag on the CSRF cookie. If this is set to
|
||||
|
|
@ -455,8 +453,6 @@ configurations are available:
|
|||
ATOMIC_REQUESTS
|
||||
~~~~~~~~~~~~~~~
|
||||
|
||||
.. versionadded:: 1.6
|
||||
|
||||
Default: ``False``
|
||||
|
||||
Set this to ``True`` to wrap each HTTP request in a transaction on this
|
||||
|
|
@ -467,8 +463,6 @@ database. See :ref:`tying-transactions-to-http-requests`.
|
|||
AUTOCOMMIT
|
||||
~~~~~~~~~~
|
||||
|
||||
.. versionadded:: 1.6
|
||||
|
||||
Default: ``True``
|
||||
|
||||
Set this to ``False`` if you want to :ref:`disable Django's transaction
|
||||
|
|
@ -535,8 +529,6 @@ file. When specifying the path, always use forward slashes, even on Windows
|
|||
CONN_MAX_AGE
|
||||
~~~~~~~~~~~~
|
||||
|
||||
.. versionadded:: 1.6
|
||||
|
||||
Default: ``0``
|
||||
|
||||
The lifetime of a database connection, in seconds. Use ``0`` to close database
|
||||
|
|
@ -2121,10 +2113,6 @@ precedence and will be applied instead.
|
|||
|
||||
See also :setting:`DATE_INPUT_FORMATS` and :setting:`DATETIME_INPUT_FORMATS`.
|
||||
|
||||
.. versionchanged:: 1.6
|
||||
|
||||
Input format with microseconds has been added.
|
||||
|
||||
.. _datetime: http://docs.python.org/library/datetime.html#strftime-strptime-behavior
|
||||
|
||||
.. setting:: TIME_ZONE
|
||||
|
|
@ -2654,12 +2642,6 @@ SESSION_SERIALIZER
|
|||
|
||||
Default: ``'django.contrib.sessions.serializers.JSONSerializer'``
|
||||
|
||||
.. versionchanged:: 1.6
|
||||
|
||||
The default switched from
|
||||
:class:`~django.contrib.sessions.serializers.PickleSerializer` to
|
||||
:class:`~django.contrib.sessions.serializers.JSONSerializer` in Django 1.6.
|
||||
|
||||
Full import path of a serializer class to use for serializing session data.
|
||||
Included serializers are:
|
||||
|
||||
|
|
|
|||
|
|
@ -974,12 +974,8 @@ url
|
|||
^^^
|
||||
|
||||
Returns an absolute path reference (a URL without the domain name) matching a
|
||||
given view function and optional parameters.
|
||||
|
||||
.. versionchanged:: 1.6
|
||||
|
||||
Any special characters in the resulting path will be encoded using
|
||||
:func:`~django.utils.encoding.iri_to_uri`.
|
||||
given view function and optional parameters. Any special characters in the
|
||||
resulting path will be encoded using :func:`~django.utils.encoding.iri_to_uri`.
|
||||
|
||||
This is a way to output links without violating the DRY principle by having to
|
||||
hard-code URLs in your templates::
|
||||
|
|
|
|||
|
|
@ -117,8 +117,6 @@ handler400
|
|||
|
||||
.. data:: handler400
|
||||
|
||||
.. versionadded:: 1.6
|
||||
|
||||
A callable, or a string representing the full Python import path to the view
|
||||
that should be called if the HTTP client has sent a request that caused an error
|
||||
condition and a response with a status code of 400.
|
||||
|
|
|
|||
|
|
@ -613,10 +613,6 @@ escaping HTML.
|
|||
|
||||
.. _bleach: https://pypi.python.org/pypi/bleach
|
||||
|
||||
.. versionchanged:: 1.6
|
||||
|
||||
For improved safety, ``strip_tags`` is now parser-based.
|
||||
|
||||
.. function:: remove_tags(value, tags)
|
||||
|
||||
Removes a space-separated list of [X]HTML tag names from the output.
|
||||
|
|
@ -696,15 +692,11 @@ escaping HTML.
|
|||
|
||||
.. function:: urlsafe_base64_encode(s)
|
||||
|
||||
.. versionadded:: 1.6
|
||||
|
||||
Encodes a bytestring in base64 for use in URLs, stripping any trailing
|
||||
equal signs.
|
||||
|
||||
.. function:: urlsafe_base64_decode(s)
|
||||
|
||||
.. versionadded:: 1.6
|
||||
|
||||
Decodes a base64 encoded string, adding back any trailing equal signs that
|
||||
might have been stripped.
|
||||
|
||||
|
|
@ -733,7 +725,6 @@ Functions for working with Python modules.
|
|||
|
||||
.. function:: import_by_path(dotted_path, error_prefix='')
|
||||
|
||||
.. versionadded:: 1.6
|
||||
.. deprecated:: 1.7
|
||||
Use :meth:`~django.utils.module_loading.import_string` instead.
|
||||
|
||||
|
|
|
|||
|
|
@ -610,13 +610,11 @@ Transaction management
|
|||
|
||||
When using managed transactions -- that is, anything but the default
|
||||
autocommit mode -- it is important when a transaction is marked as
|
||||
"dirty". Dirty transactions are committed by the
|
||||
:func:`~django.db.transaction.commit_on_success` decorator or the
|
||||
:class:`~django.middleware.transaction.TransactionMiddleware`, and
|
||||
:func:`~django.db.transaction.commit_manually` forces them to be
|
||||
closed explicitly; clean transactions "get a pass", which means they
|
||||
are usually rolled back at the end of a request when the connection is
|
||||
closed.
|
||||
"dirty". Dirty transactions are committed by the ``commit_on_success``
|
||||
decorator or the ``django.middleware.transaction.TransactionMiddleware``, and
|
||||
``commit_manually`` forces them to be closed explicitly; clean transactions
|
||||
"get a pass", which means they are usually rolled back at the end of a request
|
||||
when the connection is closed.
|
||||
|
||||
Until Django 1.3, transactions were only marked dirty when Django was
|
||||
aware of a modifying operation performed in them; that is, either some
|
||||
|
|
|
|||
|
|
@ -411,8 +411,8 @@ Autocommit option for PostgreSQL
|
|||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
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>` and can be removed.
|
||||
PostgreSQL, and it was disabled by default. This option is now ignored and can
|
||||
be removed.
|
||||
|
||||
.. _new-test-runner:
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
Loading…
Reference in New Issue