Removed versionadded/changed annotations for 1.6.
This commit is contained in:
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
|
because attempting to set the locale needs access to settings. This condition
|
||||||
will generate a :class:`CommandError`.
|
will generate a :class:`CommandError`.
|
||||||
|
|
||||||
.. versionadded:: 1.6
|
|
||||||
|
|
||||||
The ``leave_locale_alone`` option was added in Django 1.6.
|
|
||||||
|
|
||||||
Methods
|
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
|
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.
|
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
|
Install the core Django tables
|
||||||
==============================
|
==============================
|
||||||
|
|
||||||
|
|
|
@ -213,8 +213,6 @@ RedirectView
|
||||||
|
|
||||||
.. attribute:: pattern_name
|
.. attribute:: pattern_name
|
||||||
|
|
||||||
.. versionadded:: 1.6
|
|
||||||
|
|
||||||
The name of the URL pattern to redirect to. Reversing will be done
|
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.
|
using the same args and kwargs as are passed in for this view.
|
||||||
|
|
||||||
|
@ -238,10 +236,6 @@ RedirectView
|
||||||
|
|
||||||
Constructs the target URL for redirection.
|
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
|
The default implementation uses :attr:`url` as a starting
|
||||||
string and performs expansion of ``%`` named parameters in that string
|
string and performs expansion of ``%`` named parameters in that string
|
||||||
using the named groups captured in the URL.
|
using the named groups captured in the URL.
|
||||||
|
|
|
@ -37,8 +37,6 @@ FormMixin
|
||||||
|
|
||||||
.. attribute:: prefix
|
.. attribute:: prefix
|
||||||
|
|
||||||
.. versionadded:: 1.6
|
|
||||||
|
|
||||||
The :attr:`~django.forms.Form.prefix` for the generated form.
|
The :attr:`~django.forms.Form.prefix` for the generated form.
|
||||||
|
|
||||||
.. method:: get_initial()
|
.. method:: get_initial()
|
||||||
|
@ -66,8 +64,6 @@ FormMixin
|
||||||
|
|
||||||
.. method:: get_prefix()
|
.. method:: get_prefix()
|
||||||
|
|
||||||
.. versionadded:: 1.6
|
|
||||||
|
|
||||||
Determine the :attr:`~django.forms.Form.prefix` for the generated form.
|
Determine the :attr:`~django.forms.Form.prefix` for the generated form.
|
||||||
Returns :attr:`~django.views.generic.edit.FormMixin.prefix` by default.
|
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
|
The url to redirect to when the nominated object has been
|
||||||
successfully deleted.
|
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
|
||||||
``success_url`` may contain dictionary string formatting, which
|
could use ``success_url="/parent/%(parent_id)s/"`` to redirect to a URL
|
||||||
will be interpolated against the object's field attributes. For
|
composed out of the ``parent_id`` field on a model.
|
||||||
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()
|
.. method:: get_success_url()
|
||||||
|
|
||||||
|
|
|
@ -81,8 +81,6 @@ MultipleObjectMixin
|
||||||
|
|
||||||
.. attribute:: paginate_orphans
|
.. attribute:: paginate_orphans
|
||||||
|
|
||||||
.. versionadded:: 1.6
|
|
||||||
|
|
||||||
An integer specifying the number of "overflow" objects the last page
|
An integer specifying the number of "overflow" objects the last page
|
||||||
can contain. This extends the :attr:`paginate_by` limit on the last
|
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
|
page by up to ``paginate_orphans``, in order to keep the last page from
|
||||||
|
@ -135,8 +133,6 @@ MultipleObjectMixin
|
||||||
|
|
||||||
.. method:: get_paginate_orphans()
|
.. method:: get_paginate_orphans()
|
||||||
|
|
||||||
.. versionadded:: 1.6
|
|
||||||
|
|
||||||
An integer specifying the number of "overflow" objects the last page
|
An integer specifying the number of "overflow" objects the last page
|
||||||
can contain. By default this simply returns the value of
|
can contain. By default this simply returns the value of
|
||||||
:attr:`paginate_orphans`.
|
: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
|
By default, the middleware will set the ``X-Frame-Options`` header to
|
||||||
``SAMEORIGIN`` for every outgoing ``HttpResponse``. If you want ``DENY``
|
``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
|
The admin is enabled in the default project template used by
|
||||||
:djadmin:`startproject`.
|
:djadmin:`startproject`.
|
||||||
|
|
||||||
.. versionchanged:: 1.6
|
|
||||||
|
|
||||||
In previous versions, the admin wasn't enabled by default.
|
|
||||||
|
|
||||||
For reference, here are the requirements:
|
For reference, here are the requirements:
|
||||||
|
|
||||||
1. Add ``'django.contrib.admin'`` to your :setting:`INSTALLED_APPS` setting.
|
1. Add ``'django.contrib.admin'`` to your :setting:`INSTALLED_APPS` setting.
|
||||||
|
@ -419,8 +415,6 @@ subclass::
|
||||||
|
|
||||||
.. admonition:: Note
|
.. admonition:: Note
|
||||||
|
|
||||||
.. versionchanged:: 1.6
|
|
||||||
|
|
||||||
If you define the ``Meta.model`` attribute on a
|
If you define the ``Meta.model`` attribute on a
|
||||||
:class:`~django.forms.ModelForm`, you must also define the
|
:class:`~django.forms.ModelForm`, you must also define the
|
||||||
``Meta.fields`` attribute (or the ``Meta.exclude`` attribute). However,
|
``Meta.fields`` attribute (or the ``Meta.exclude`` attribute). However,
|
||||||
|
@ -693,9 +687,7 @@ subclass::
|
||||||
list_display = ('full_name',)
|
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>``
|
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.
|
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
|
the list of objects on the admin change list page. This can save you a
|
||||||
bunch of database queries.
|
bunch of database queries.
|
||||||
|
|
||||||
.. versionchanged:: 1.6
|
|
||||||
|
|
||||||
The value should be either a boolean, a list or a tuple. Default is
|
The value should be either a boolean, a list or a tuple. Default is
|
||||||
``False``.
|
``False``.
|
||||||
|
|
||||||
|
@ -978,8 +968,6 @@ subclass::
|
||||||
|
|
||||||
.. attribute:: ModelAdmin.preserve_filters
|
.. attribute:: ModelAdmin.preserve_filters
|
||||||
|
|
||||||
.. versionadded:: 1.6
|
|
||||||
|
|
||||||
The admin now preserves filters on the list view after creating, editing
|
The admin now preserves filters on the list view after creating, editing
|
||||||
or deleting an object. You can restore the previous behavior of clearing
|
or deleting an object. You can restore the previous behavior of clearing
|
||||||
filters by setting this attribute to ``False``.
|
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)
|
.. method:: ModelAdmin.get_search_results(request, queryset, search_term)
|
||||||
|
|
||||||
.. versionadded:: 1.6
|
|
||||||
|
|
||||||
The ``get_search_results`` method modifies the list of objects displayed in
|
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
|
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.
|
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
|
.. admonition:: Note
|
||||||
|
|
||||||
.. versionchanged:: 1.6
|
|
||||||
|
|
||||||
If you define the ``Meta.model`` attribute on a
|
If you define the ``Meta.model`` attribute on a
|
||||||
:class:`~django.forms.ModelForm`, you must also define the
|
:class:`~django.forms.ModelForm`, you must also define the
|
||||||
``Meta.fields`` attribute (or the ``Meta.exclude`` attribute). However,
|
``Meta.fields`` attribute (or the ``Meta.exclude`` attribute). However,
|
||||||
|
@ -1659,10 +1643,6 @@ templates used by the :class:`ModelAdmin` views:
|
||||||
return qs
|
return qs
|
||||||
return qs.filter(author=request.user)
|
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)
|
.. 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`
|
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
|
in your own admin JavaScript without including a second copy, you can use the
|
||||||
``django.jQuery`` object on changelist and add/edit views.
|
``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
|
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
|
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
|
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
|
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.
|
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
|
:meth:`InlineModelAdmin.get_extra` also allows you to customize the number
|
||||||
of extra forms.
|
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
|
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.
|
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
|
:meth:`InlineModelAdmin.get_max_num` also allows you to customize the
|
||||||
maximum number of extra forms.
|
maximum number of extra forms.
|
||||||
|
|
||||||
|
@ -2035,8 +2007,6 @@ The ``InlineModelAdmin`` class adds:
|
||||||
|
|
||||||
.. method:: InlineModelAdmin.get_extra(request, obj=None, **kwargs)
|
.. method:: InlineModelAdmin.get_extra(request, obj=None, **kwargs)
|
||||||
|
|
||||||
.. versionadded:: 1.6
|
|
||||||
|
|
||||||
Returns the number of extra inline forms to use. By default, returns the
|
Returns the number of extra inline forms to use. By default, returns the
|
||||||
:attr:`InlineModelAdmin.extra` attribute.
|
:attr:`InlineModelAdmin.extra` attribute.
|
||||||
|
|
||||||
|
@ -2055,8 +2025,6 @@ The ``InlineModelAdmin`` class adds:
|
||||||
|
|
||||||
.. method:: InlineModelAdmin.get_max_num(request, obj=None, **kwargs)
|
.. 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 maximum number of extra inline forms to use. By default,
|
||||||
returns the :attr:`InlineModelAdmin.max_num` attribute.
|
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/(?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'),
|
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
|
(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
|
the URLs starting with ``^admin/`` before the line that includes the admin app
|
||||||
itself).
|
itself).
|
||||||
|
|
|
@ -143,23 +143,12 @@ Methods
|
||||||
:meth:`~django.contrib.auth.models.User.set_unusable_password()`
|
:meth:`~django.contrib.auth.models.User.set_unusable_password()`
|
||||||
were used.
|
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)
|
.. method:: check_password(raw_password)
|
||||||
|
|
||||||
Returns ``True`` if the given raw string is the correct password for
|
Returns ``True`` if the given raw string is the correct password for
|
||||||
the user. (This takes care of the password hashing in making the
|
the user. (This takes care of the password hashing in making the
|
||||||
comparison.)
|
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()
|
.. method:: set_unusable_password()
|
||||||
|
|
||||||
Marks the user as having no password set. This isn't the same as
|
Marks the user as having no password set. This isn't the same as
|
||||||
|
|
|
@ -291,8 +291,6 @@ model:
|
||||||
|
|
||||||
.. attribute:: GenericForeignKey.for_concrete_model
|
.. attribute:: GenericForeignKey.for_concrete_model
|
||||||
|
|
||||||
.. versionadded:: 1.6
|
|
||||||
|
|
||||||
If ``False``, the field will be able to reference proxy models. Default
|
If ``False``, the field will be able to reference proxy models. Default
|
||||||
is ``True``. This mirrors the ``for_concrete_model`` argument to
|
is ``True``. This mirrors the ``for_concrete_model`` argument to
|
||||||
:meth:`~django.contrib.contenttypes.models.ContentTypeManager.get_for_model`.
|
: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.modelformset_factory` and
|
||||||
:func:`~django.forms.models.inlineformset_factory`.
|
: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`
|
||||||
The ``for_concrete_model`` argument corresponds to the
|
argument on ``GenericForeignKey``.
|
||||||
:class:`~django.contrib.contenttypes.fields.GenericForeignKey.for_concrete_model`
|
|
||||||
argument on ``GenericForeignKey``.
|
|
||||||
|
|
||||||
.. versionchanged:: 1.7
|
.. versionchanged:: 1.7
|
||||||
|
|
||||||
|
|
|
@ -260,8 +260,6 @@ wizard's ``as_view()`` method takes a list of your
|
||||||
(r'^contact/$', ContactWizard.as_view([ContactForm1, ContactForm2])),
|
(r'^contact/$', ContactWizard.as_view([ContactForm1, ContactForm2])),
|
||||||
)
|
)
|
||||||
|
|
||||||
.. versionchanged:: 1.6
|
|
||||||
|
|
||||||
You can also pass the form list as a class attribute named ``form_list``::
|
You can also pass the form list as a class attribute named ``form_list``::
|
||||||
|
|
||||||
class ContactWizard(WizardView):
|
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})),
|
(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()`
|
The ``condition_dict`` can be passed as attribute for the ``as_view()`
|
||||||
method or as a class attribute named ``condition_dict``::
|
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)
|
.. 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
|
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
|
than the next step. By default, this method just stores the requested
|
||||||
step ``goto_step`` in the storage and then renders the new step.
|
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
|
The ``initial_dict`` can also take a list of dictionaries for a specific
|
||||||
step if the step is a ``FormSet``.
|
step if the step is a ``FormSet``.
|
||||||
|
|
||||||
.. versionchanged:: 1.6
|
|
||||||
|
|
||||||
The ``initial_dict`` can also be added as a class attribute named
|
The ``initial_dict`` can also be added as a class attribute named
|
||||||
``initial_dict`` to avoid having the initial data in the ``urls.py``.
|
``initial_dict`` to avoid having the initial data in the ``urls.py``.
|
||||||
|
|
||||||
|
|
|
@ -7,8 +7,6 @@ GeoDjango Forms API
|
||||||
.. module:: django.contrib.gis.forms
|
.. module:: django.contrib.gis.forms
|
||||||
:synopsis: GeoDjango forms API.
|
:synopsis: GeoDjango forms API.
|
||||||
|
|
||||||
.. versionadded:: 1.6
|
|
||||||
|
|
||||||
GeoDjango provides some specialized form fields and widgets in order to visually
|
GeoDjango provides some specialized form fields and widgets in order to visually
|
||||||
display and edit geolocalized data on a map. By default, they use
|
display and edit geolocalized data on a map. By default, they use
|
||||||
`OpenLayers`_-powered maps, with a base WMS layer provided by `Metacarta`_.
|
`OpenLayers`_-powered maps, with a base WMS layer provided by `Metacarta`_.
|
||||||
|
|
|
@ -354,8 +354,6 @@ example::
|
||||||
Adding messages in Class Based Views
|
Adding messages in Class Based Views
|
||||||
------------------------------------
|
------------------------------------
|
||||||
|
|
||||||
.. versionadded:: 1.6
|
|
||||||
|
|
||||||
.. class:: views.SuccessMessageMixin
|
.. class:: views.SuccessMessageMixin
|
||||||
|
|
||||||
Adds a success message attribute to
|
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
|
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:
|
To enable the sites framework, follow these steps:
|
||||||
|
|
||||||
1. Add ``'django.contrib.sites'`` to your :setting:`INSTALLED_APPS`
|
1. Add ``'django.contrib.sites'`` to your :setting:`INSTALLED_APPS`
|
||||||
|
|
|
@ -139,8 +139,6 @@ into those elements.
|
||||||
|
|
||||||
.. method:: Feed.get_context_data(**kwargs)
|
.. method:: Feed.get_context_data(**kwargs)
|
||||||
|
|
||||||
.. versionadded:: 1.6
|
|
||||||
|
|
||||||
There is also a way to pass additional information to title and description
|
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
|
templates, if you need to supply more than the two variables mentioned
|
||||||
before. You can provide your implementation of ``get_context_data`` method
|
before. You can provide your implementation of ``get_context_data`` method
|
||||||
|
|
|
@ -19,8 +19,6 @@ General notes
|
||||||
Persistent connections
|
Persistent connections
|
||||||
----------------------
|
----------------------
|
||||||
|
|
||||||
.. versionadded:: 1.6
|
|
||||||
|
|
||||||
Persistent connections avoid the overhead of re-establishing a connection to
|
Persistent connections avoid the overhead of re-establishing a connection to
|
||||||
the database in each request. They're controlled by the
|
the database in each request. They're controlled by the
|
||||||
:setting:`CONN_MAX_AGE` parameter which defines the maximum lifetime of a
|
: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
|
.. _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:
|
.. _database-isolation-level:
|
||||||
|
|
||||||
Isolation level
|
Isolation level
|
||||||
---------------
|
---------------
|
||||||
|
|
||||||
.. versionadded:: 1.6
|
|
||||||
|
|
||||||
Like PostgreSQL itself, Django defaults to the ``READ COMMITTED`` `isolation
|
Like PostgreSQL itself, Django defaults to the ``READ COMMITTED`` `isolation
|
||||||
level`_. If you need a higher isolation level such as ``REPEATABLE READ`` or
|
level`_. If you need a higher isolation level such as ``REPEATABLE READ`` or
|
||||||
``SERIALIZABLE``, set it in the :setting:`OPTIONS` part of your database
|
``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
|
||||||
django-admin.py compilemessages -l pt_BR -l fr
|
django-admin.py compilemessages -l pt_BR -l fr
|
||||||
|
|
||||||
.. versionchanged:: 1.6
|
|
||||||
|
|
||||||
Added the ability to specify multiple locales.
|
|
||||||
|
|
||||||
createcachetable
|
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
|
The :djadminopt:`--all` option may be provided to display all settings, even
|
||||||
if they have Django's default value. Such settings are prefixed by ``"###"``.
|
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 ...>
|
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
|
any foreign key and many-to-many relationship with a model that provides
|
||||||
a natural key definition.
|
a natural key definition.
|
||||||
|
|
||||||
.. versionadded:: 1.6
|
|
||||||
|
|
||||||
.. django-admin-option:: --pks
|
.. django-admin-option:: --pks
|
||||||
|
|
||||||
By default, ``dumpdata`` will output all the records of the model, but
|
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
|
The :djadminopt:`--database` option may be used to specify the
|
||||||
database to introspect.
|
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 ...>
|
loaddata <fixture fixture ...>
|
||||||
------------------------------
|
------------------------------
|
||||||
|
|
||||||
|
@ -565,10 +550,6 @@ Example usage::
|
||||||
django-admin.py makemessages -l pt_BR
|
django-admin.py makemessages -l pt_BR
|
||||||
django-admin.py makemessages -l pt_BR -l fr
|
django-admin.py makemessages -l pt_BR -l fr
|
||||||
|
|
||||||
.. versionchanged:: 1.6
|
|
||||||
|
|
||||||
Added the ability to specify multiple locales.
|
|
||||||
|
|
||||||
.. versionchanged:: 1.7
|
.. versionchanged:: 1.7
|
||||||
|
|
||||||
Added the ``--previous`` option to the ``msgmerge`` command when merging
|
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
|
.. django-admin-option:: --keep-pot
|
||||||
|
|
||||||
.. versionadded:: 1.6
|
|
||||||
|
|
||||||
Use the ``--keep-pot`` option to prevent Django from deleting the temporary
|
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
|
.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.
|
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
|
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 ...>
|
sql <app_label app_label ...>
|
||||||
-----------------------------
|
-----------------------------
|
||||||
|
|
||||||
|
@ -1043,8 +1018,6 @@ sqldropindexes <app_label app_label ...>
|
||||||
|
|
||||||
.. django-admin:: sqldropindexes
|
.. django-admin:: sqldropindexes
|
||||||
|
|
||||||
.. versionadded:: 1.6
|
|
||||||
|
|
||||||
Prints the DROP INDEX SQL statements for the given app name(s).
|
Prints the DROP INDEX SQL statements for the given app name(s).
|
||||||
|
|
||||||
The :djadminopt:`--database` option can be used to specify the database for
|
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``
|
for any other exception. If you specify ``--traceback``, ``django-admin.py``
|
||||||
will also output a full stack trace when a ``CommandError`` is raised.
|
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
|
.. django-admin-option:: --verbosity
|
||||||
|
|
||||||
Example usage::
|
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
|
both Python 2 and Python 3, although :pep:`3134` normally only applies
|
||||||
to Python 3.)
|
to Python 3.)
|
||||||
|
|
||||||
.. versionchanged:: 1.6
|
|
||||||
|
|
||||||
Previous versions of Django only wrapped ``DatabaseError`` and
|
|
||||||
``IntegrityError``, and did not provide ``__cause__``.
|
|
||||||
|
|
||||||
.. exception:: models.ProtectedError
|
.. exception:: models.ProtectedError
|
||||||
|
|
||||||
Raised to prevent deletion of referenced objects when using
|
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
|
A translatable string (defaults to a colon (``:``) in English) that will be
|
||||||
appended after any label name when a form is rendered.
|
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
|
It's possible to customize that character, or omit it entirely, using the
|
||||||
``label_suffix`` parameter::
|
``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 ``.``, ``!``, ``?``
|
label isn't a punctuation character (in English, those are ``.``, ``!``, ``?``
|
||||||
or ``:``).
|
or ``:``).
|
||||||
|
|
||||||
.. versionadded:: 1.6
|
|
||||||
|
|
||||||
You can also customize the ``label_suffix`` on a per-field basis using the
|
You can also customize the ``label_suffix`` on a per-field basis using the
|
||||||
``label_suffix`` parameter to :meth:`~django.forms.BoundField.label_tag`.
|
``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
|
auto-generated label tag. An optional ``attrs`` dictionary may contain
|
||||||
additional attributes for the ``<label>`` tag.
|
additional attributes for the ``<label>`` tag.
|
||||||
|
|
||||||
.. versionchanged:: 1.6
|
The HTML that's generated includes the form's
|
||||||
|
:attr:`~django.forms.Form.label_suffix` (a colon, by default). The optional
|
||||||
The label now includes the form's :attr:`~django.forms.Form.label_suffix`
|
``label_suffix`` parameter allows you to override the form's
|
||||||
(a colon, by default).
|
: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
|
||||||
.. versionadded:: 1.6
|
template, you could write a custom filter to allow passing parameters to
|
||||||
|
``label_tag``.
|
||||||
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
|
.. 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
|
The ``max_value`` and ``min_value`` error messages may contain
|
||||||
``%(limit_value)s``, which will be substituted by the appropriate limit.
|
``%(limit_value)s``, which will be substituted by the appropriate limit.
|
||||||
|
Similarly, the ``max_digits``, ``max_decimal_places`` and
|
||||||
.. versionchanged:: 1.6
|
``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:
|
Takes four optional arguments:
|
||||||
|
|
||||||
|
@ -1105,11 +1102,9 @@ objects (in the case of ``ModelMultipleChoiceField``) into the
|
||||||
* Error message keys: ``required``, ``list``, ``invalid_choice``,
|
* Error message keys: ``required``, ``list``, ``invalid_choice``,
|
||||||
``invalid_pk_value``
|
``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
|
||||||
The ``invalid_choice`` message may contain ``%(value)s`` and the
|
substituted by the appropriate values.
|
||||||
``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
|
Allows the selection of one or more model objects, suitable for
|
||||||
representing a many-to-many relation. As with :class:`ModelChoiceField`,
|
representing a many-to-many relation. As with :class:`ModelChoiceField`,
|
||||||
|
|
|
@ -11,10 +11,6 @@ Formset Functions
|
||||||
|
|
||||||
See :ref:`formsets` for example usage.
|
See :ref:`formsets` for example usage.
|
||||||
|
|
||||||
.. versionchanged:: 1.6
|
|
||||||
|
|
||||||
The ``validate_max`` parameter was added.
|
|
||||||
|
|
||||||
.. versionchanged:: 1.7
|
.. versionchanged:: 1.7
|
||||||
|
|
||||||
The ``min_num`` and ``validate_min`` parameters were added.
|
The ``min_num`` and ``validate_min`` parameters were added.
|
||||||
|
|
|
@ -61,11 +61,6 @@ Model Form Functions
|
||||||
|
|
||||||
See :ref:`model-formsets` for example usage.
|
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)
|
.. 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
|
Returns an ``InlineFormSet`` using :func:`modelformset_factory` with
|
||||||
|
@ -76,8 +71,3 @@ Model Form Functions
|
||||||
the ``parent_model``, you must specify a ``fk_name``.
|
the ``parent_model``, you must specify a ``fk_name``.
|
||||||
|
|
||||||
See :ref:`inline-formsets` for example usage.
|
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``
|
Raising ``ValidationError``
|
||||||
---------------------------
|
---------------------------
|
||||||
|
|
||||||
.. versionchanged:: 1.6
|
|
||||||
|
|
||||||
In order to make error messages flexible and easy to override, consider the
|
In order to make error messages flexible and easy to override, consider the
|
||||||
following guidelines:
|
following guidelines:
|
||||||
|
|
||||||
|
|
|
@ -409,8 +409,6 @@ These widgets make use of the HTML elements ``input`` and ``textarea``.
|
||||||
|
|
||||||
.. class:: NumberInput
|
.. class:: NumberInput
|
||||||
|
|
||||||
.. versionadded:: 1.6
|
|
||||||
|
|
||||||
Text input: ``<input type="number" ...>``
|
Text input: ``<input type="number" ...>``
|
||||||
|
|
||||||
Beware that not all browsers support entering localized numbers in
|
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
|
.. class:: EmailInput
|
||||||
|
|
||||||
.. versionadded:: 1.6
|
|
||||||
|
|
||||||
Text input: ``<input type="email" ...>``
|
Text input: ``<input type="email" ...>``
|
||||||
|
|
||||||
``URLInput``
|
``URLInput``
|
||||||
|
@ -431,8 +427,6 @@ These widgets make use of the HTML elements ``input`` and ``textarea``.
|
||||||
|
|
||||||
.. class:: URLInput
|
.. class:: URLInput
|
||||||
|
|
||||||
.. versionadded:: 1.6
|
|
||||||
|
|
||||||
Text input: ``<input type="url" ...>``
|
Text input: ``<input type="url" ...>``
|
||||||
|
|
||||||
``PasswordInput``
|
``PasswordInput``
|
||||||
|
@ -649,10 +643,8 @@ Selector and checkbox widgets
|
||||||
simply includes ``{{ myform.beatles }}`` -- they'll be output in a ``<ul>``
|
simply includes ``{{ myform.beatles }}`` -- they'll be output in a ``<ul>``
|
||||||
with ``<li>`` tags, as above.
|
with ``<li>`` tags, as above.
|
||||||
|
|
||||||
.. versionchanged:: 1.6
|
The outer ``<ul>`` container will receive the ``id`` attribute defined on
|
||||||
|
the widget.
|
||||||
The outer ``<ul>`` container will now receive the ``id`` attribute defined on
|
|
||||||
the widget.
|
|
||||||
|
|
||||||
.. versionchanged:: 1.7
|
.. versionchanged:: 1.7
|
||||||
|
|
||||||
|
@ -675,10 +667,8 @@ the widget.
|
||||||
...
|
...
|
||||||
</ul>
|
</ul>
|
||||||
|
|
||||||
.. versionchanged:: 1.6
|
The outer ``<ul>`` container will receive the ``id`` attribute defined on
|
||||||
|
the widget.
|
||||||
The outer ``<ul>`` container will now receive the ``id`` attribute defined on
|
|
||||||
the widget.
|
|
||||||
|
|
||||||
Like :class:`RadioSelect`, you can now loop over the individual checkboxes making
|
Like :class:`RadioSelect`, you can now loop over the individual checkboxes making
|
||||||
up the lists. See the documentation of :class:`RadioSelect` for more details.
|
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
|
fields to POST forms and checking requests for the correct value. See the
|
||||||
:doc:`Cross Site Request Forgery protection documentation </ref/contrib/csrf>`.
|
: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
|
X-Frame-Options middleware
|
||||||
--------------------------
|
--------------------------
|
||||||
|
|
||||||
|
|
|
@ -384,8 +384,6 @@ guaranteed to fit numbers from ``-9223372036854775808`` to
|
||||||
|
|
||||||
.. class:: BinaryField([**options])
|
.. class:: BinaryField([**options])
|
||||||
|
|
||||||
.. versionadded:: 1.6
|
|
||||||
|
|
||||||
A field to store raw binary data. It only supports ``bytes`` assignment. Be
|
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
|
aware that this field has limited functionality. For example, it is not possible
|
||||||
to filter a queryset on a ``BinaryField`` value.
|
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
|
If you need to accept :attr:`~Field.null` values then use
|
||||||
:class:`NullBooleanField` instead.
|
:class:`NullBooleanField` instead.
|
||||||
|
|
||||||
.. versionchanged:: 1.6
|
The default value of ``BooleanField`` is ``None`` when :attr:`Field.default`
|
||||||
|
isn't defined.
|
||||||
The default value of ``BooleanField`` was changed from ``False`` to
|
|
||||||
``None`` when :attr:`Field.default` isn't defined.
|
|
||||||
|
|
||||||
``CharField``
|
``CharField``
|
||||||
-------------
|
-------------
|
||||||
|
@ -1142,8 +1138,6 @@ define the details of how the relation works.
|
||||||
|
|
||||||
.. attribute:: ForeignKey.related_query_name
|
.. attribute:: ForeignKey.related_query_name
|
||||||
|
|
||||||
.. versionadded:: 1.6
|
|
||||||
|
|
||||||
The name to use for the reverse filter name from the target model.
|
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 value of :attr:`related_name` if it is set, otherwise it
|
||||||
defaults to the name of the model::
|
defaults to the name of the model::
|
||||||
|
@ -1163,8 +1157,6 @@ define the details of how the relation works.
|
||||||
|
|
||||||
.. attribute:: ForeignKey.db_constraint
|
.. attribute:: ForeignKey.db_constraint
|
||||||
|
|
||||||
.. versionadded:: 1.6
|
|
||||||
|
|
||||||
Controls whether or not a constraint should be created in the database for
|
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
|
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.
|
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
|
.. attribute:: ManyToManyField.related_query_name
|
||||||
|
|
||||||
.. versionadded:: 1.6
|
|
||||||
|
|
||||||
Same as :attr:`ForeignKey.related_query_name`.
|
Same as :attr:`ForeignKey.related_query_name`.
|
||||||
|
|
||||||
.. attribute:: ManyToManyField.limit_choices_to
|
.. attribute:: ManyToManyField.limit_choices_to
|
||||||
|
@ -1396,8 +1386,6 @@ that control how the relationship functions.
|
||||||
|
|
||||||
.. attribute:: ManyToManyField.db_constraint
|
.. attribute:: ManyToManyField.db_constraint
|
||||||
|
|
||||||
.. versionadded:: 1.6
|
|
||||||
|
|
||||||
Controls whether or not constraints should be created in the database for
|
Controls whether or not constraints should be created in the database for
|
||||||
the foreign keys in the intermediary table. The default is ``True``, and
|
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
|
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)
|
.. 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
|
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
|
order and raises a :exc:`~django.core.exceptions.ValidationError` that has a
|
||||||
``message_dict`` attribute containing errors from all three stages.
|
``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
|
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.
|
auto-primary-key values`_ above and `Forcing an INSERT or UPDATE`_ below.
|
||||||
|
|
||||||
.. versionchanged:: 1.6
|
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``,
|
||||||
Previously Django did a ``SELECT`` when the primary key attribute was set.
|
otherwise it did an ``INSERT``. The old algorithm results in one more query in
|
||||||
If the ``SELECT`` found a row, then Django did an ``UPDATE``, otherwise it
|
the ``UPDATE`` case. There are some rare cases where the database doesn't
|
||||||
did an ``INSERT``. The old algorithm results in one more query in the
|
report that a row was updated even if the database contains a row for the
|
||||||
``UPDATE`` case. There are some rare cases where the database doesn't
|
object's primary key value. An example is the PostgreSQL ``ON UPDATE`` trigger
|
||||||
report that a row was updated even if the database contains a row for the
|
which returns ``NULL``. In such cases it is possible to revert to the old
|
||||||
object's primary key value. An example is the PostgreSQL ``ON UPDATE``
|
algorithm by setting the :attr:`~django.db.models.Options.select_on_save`
|
||||||
trigger which returns ``NULL``. In such cases it is possible to revert to the
|
option to ``True``.
|
||||||
old algorithm by setting the :attr:`~django.db.models.Options.select_on_save`
|
|
||||||
option to ``True``.
|
|
||||||
|
|
||||||
.. _ref-models-force-insert:
|
.. _ref-models-force-insert:
|
||||||
|
|
||||||
|
|
|
@ -279,8 +279,6 @@ Django quotes column and table names behind the scenes.
|
||||||
|
|
||||||
.. attribute:: Options.select_on_save
|
.. attribute:: Options.select_on_save
|
||||||
|
|
||||||
.. versionadded:: 1.6
|
|
||||||
|
|
||||||
Determines if Django will use the pre-1.6
|
Determines if Django will use the pre-1.6
|
||||||
:meth:`django.db.models.Model.save()` algorithm. The old algorithm
|
:meth:`django.db.models.Model.save()` algorithm. The old algorithm
|
||||||
uses ``SELECT`` to determine if there is an existing row to be updated.
|
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
|
:class:`datetime.date` objects representing all available dates of a
|
||||||
particular kind within the contents of the ``QuerySet``.
|
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.
|
``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
|
``kind`` should be either ``"year"``, ``"month"`` or ``"day"``. Each
|
||||||
``datetime.date`` object in the result list is "truncated" to the given
|
``datetime.date`` object in the result list is "truncated" to the given
|
||||||
``type``.
|
``type``.
|
||||||
|
@ -624,8 +615,6 @@ Examples::
|
||||||
datetimes
|
datetimes
|
||||||
~~~~~~~~~
|
~~~~~~~~~
|
||||||
|
|
||||||
.. versionadded:: 1.6
|
|
||||||
|
|
||||||
.. method:: datetimes(field, kind, order='ASC', tzinfo=None)
|
.. method:: datetimes(field, kind, order='ASC', tzinfo=None)
|
||||||
|
|
||||||
Returns a ``DateTimeQuerySet`` — a ``QuerySet`` that evaluates to a list of
|
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
|
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.
|
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
|
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::
|
``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
|
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.
|
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
|
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 object and ``created`` is a boolean specifying whether a new object was
|
||||||
created.
|
created.
|
||||||
|
@ -1762,16 +1745,13 @@ earliest
|
||||||
|
|
||||||
.. method:: earliest(field_name=None)
|
.. method:: earliest(field_name=None)
|
||||||
|
|
||||||
.. versionadded:: 1.6
|
|
||||||
|
|
||||||
Works otherwise like :meth:`~django.db.models.query.QuerySet.latest` except
|
Works otherwise like :meth:`~django.db.models.query.QuerySet.latest` except
|
||||||
the direction is changed.
|
the direction is changed.
|
||||||
|
|
||||||
first
|
first
|
||||||
~~~~~
|
~~~~~
|
||||||
.. method:: first()
|
|
||||||
|
|
||||||
.. versionadded:: 1.6
|
.. method:: first()
|
||||||
|
|
||||||
Returns the first object matched by the queryset, or ``None`` if there
|
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
|
is no matching object. If the ``QuerySet`` has no ordering defined, then the
|
||||||
|
@ -1793,8 +1773,6 @@ last
|
||||||
~~~~
|
~~~~
|
||||||
.. method:: last()
|
.. method:: last()
|
||||||
|
|
||||||
.. versionadded:: 1.6
|
|
||||||
|
|
||||||
Works like :meth:`first()`, but returns the last object in the queryset.
|
Works like :meth:`first()`, but returns the last object in the queryset.
|
||||||
|
|
||||||
aggregate
|
aggregate
|
||||||
|
@ -2435,8 +2413,6 @@ in the database <database-time-zone-definitions>`.
|
||||||
hour
|
hour
|
||||||
~~~~
|
~~~~
|
||||||
|
|
||||||
.. versionadded:: 1.6
|
|
||||||
|
|
||||||
For datetime fields, an exact hour match. Takes an integer between 0 and 23.
|
For datetime fields, an exact hour match. Takes an integer between 0 and 23.
|
||||||
|
|
||||||
Example::
|
Example::
|
||||||
|
@ -2457,8 +2433,6 @@ zone before filtering.
|
||||||
minute
|
minute
|
||||||
~~~~~~
|
~~~~~~
|
||||||
|
|
||||||
.. versionadded:: 1.6
|
|
||||||
|
|
||||||
For datetime fields, an exact minute match. Takes an integer between 0 and 59.
|
For datetime fields, an exact minute match. Takes an integer between 0 and 59.
|
||||||
|
|
||||||
Example::
|
Example::
|
||||||
|
@ -2479,8 +2453,6 @@ zone before filtering.
|
||||||
second
|
second
|
||||||
~~~~~~
|
~~~~~~
|
||||||
|
|
||||||
.. versionadded:: 1.6
|
|
||||||
|
|
||||||
For datetime fields, an exact second match. Takes an integer between 0 and 59.
|
For datetime fields, an exact second match. Takes an integer between 0 and 59.
|
||||||
|
|
||||||
Example::
|
Example::
|
||||||
|
|
|
@ -636,8 +636,6 @@ Attributes
|
||||||
|
|
||||||
.. attribute:: HttpResponse.reason_phrase
|
.. attribute:: HttpResponse.reason_phrase
|
||||||
|
|
||||||
.. versionadded:: 1.6
|
|
||||||
|
|
||||||
The HTTP reason phrase for the response.
|
The HTTP reason phrase for the response.
|
||||||
|
|
||||||
.. attribute:: HttpResponse.streaming
|
.. attribute:: HttpResponse.streaming
|
||||||
|
@ -670,8 +668,6 @@ Methods
|
||||||
|
|
||||||
``status`` is the `HTTP status code`_ for the response.
|
``status`` is the `HTTP status code`_ for the response.
|
||||||
|
|
||||||
.. versionadded:: 1.6
|
|
||||||
|
|
||||||
``reason`` is the HTTP response phrase. If not provided, a default phrase
|
``reason`` is the HTTP response phrase. If not provided, a default phrase
|
||||||
will be used.
|
will be used.
|
||||||
|
|
||||||
|
@ -782,8 +778,6 @@ types of HTTP responses. Like ``HttpResponse``, these subclasses live in
|
||||||
|
|
||||||
.. attribute:: HttpResponseRedirect.url
|
.. attribute:: HttpResponseRedirect.url
|
||||||
|
|
||||||
.. versionadded:: 1.6
|
|
||||||
|
|
||||||
This read-only attribute represents the URL the response will redirect
|
This read-only attribute represents the URL the response will redirect
|
||||||
to (equivalent to the ``Location`` response header).
|
to (equivalent to the ``Location`` response header).
|
||||||
|
|
||||||
|
@ -954,8 +948,6 @@ Attributes
|
||||||
|
|
||||||
.. attribute:: HttpResponse.reason_phrase
|
.. attribute:: HttpResponse.reason_phrase
|
||||||
|
|
||||||
.. versionadded:: 1.6
|
|
||||||
|
|
||||||
The HTTP reason phrase for the response.
|
The HTTP reason phrase for the response.
|
||||||
|
|
||||||
.. attribute:: HttpResponse.streaming
|
.. attribute:: HttpResponse.streaming
|
||||||
|
|
|
@ -348,8 +348,6 @@ protection is safe from cross-subdomain attacks by default - please see the
|
||||||
CSRF_COOKIE_HTTPONLY
|
CSRF_COOKIE_HTTPONLY
|
||||||
--------------------
|
--------------------
|
||||||
|
|
||||||
.. versionadded:: 1.6
|
|
||||||
|
|
||||||
Default: ``False``
|
Default: ``False``
|
||||||
|
|
||||||
Whether to use ``HttpOnly`` flag on the CSRF cookie. If this is set to
|
Whether to use ``HttpOnly`` flag on the CSRF cookie. If this is set to
|
||||||
|
@ -455,8 +453,6 @@ configurations are available:
|
||||||
ATOMIC_REQUESTS
|
ATOMIC_REQUESTS
|
||||||
~~~~~~~~~~~~~~~
|
~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
.. versionadded:: 1.6
|
|
||||||
|
|
||||||
Default: ``False``
|
Default: ``False``
|
||||||
|
|
||||||
Set this to ``True`` to wrap each HTTP request in a transaction on this
|
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
|
AUTOCOMMIT
|
||||||
~~~~~~~~~~
|
~~~~~~~~~~
|
||||||
|
|
||||||
.. versionadded:: 1.6
|
|
||||||
|
|
||||||
Default: ``True``
|
Default: ``True``
|
||||||
|
|
||||||
Set this to ``False`` if you want to :ref:`disable Django's transaction
|
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
|
CONN_MAX_AGE
|
||||||
~~~~~~~~~~~~
|
~~~~~~~~~~~~
|
||||||
|
|
||||||
.. versionadded:: 1.6
|
|
||||||
|
|
||||||
Default: ``0``
|
Default: ``0``
|
||||||
|
|
||||||
The lifetime of a database connection, in seconds. Use ``0`` to close database
|
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`.
|
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
|
.. _datetime: http://docs.python.org/library/datetime.html#strftime-strptime-behavior
|
||||||
|
|
||||||
.. setting:: TIME_ZONE
|
.. setting:: TIME_ZONE
|
||||||
|
@ -2654,12 +2642,6 @@ SESSION_SERIALIZER
|
||||||
|
|
||||||
Default: ``'django.contrib.sessions.serializers.JSONSerializer'``
|
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.
|
Full import path of a serializer class to use for serializing session data.
|
||||||
Included serializers are:
|
Included serializers are:
|
||||||
|
|
||||||
|
|
|
@ -974,12 +974,8 @@ url
|
||||||
^^^
|
^^^
|
||||||
|
|
||||||
Returns an absolute path reference (a URL without the domain name) matching a
|
Returns an absolute path reference (a URL without the domain name) matching a
|
||||||
given view function and optional parameters.
|
given view function and optional parameters. Any special characters in the
|
||||||
|
resulting path will be encoded using :func:`~django.utils.encoding.iri_to_uri`.
|
||||||
.. versionchanged:: 1.6
|
|
||||||
|
|
||||||
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
|
This is a way to output links without violating the DRY principle by having to
|
||||||
hard-code URLs in your templates::
|
hard-code URLs in your templates::
|
||||||
|
|
|
@ -117,8 +117,6 @@ handler400
|
||||||
|
|
||||||
.. data:: handler400
|
.. data:: handler400
|
||||||
|
|
||||||
.. versionadded:: 1.6
|
|
||||||
|
|
||||||
A callable, or a string representing the full Python import path to the view
|
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
|
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.
|
condition and a response with a status code of 400.
|
||||||
|
|
|
@ -613,10 +613,6 @@ escaping HTML.
|
||||||
|
|
||||||
.. _bleach: https://pypi.python.org/pypi/bleach
|
.. _bleach: https://pypi.python.org/pypi/bleach
|
||||||
|
|
||||||
.. versionchanged:: 1.6
|
|
||||||
|
|
||||||
For improved safety, ``strip_tags`` is now parser-based.
|
|
||||||
|
|
||||||
.. function:: remove_tags(value, tags)
|
.. function:: remove_tags(value, tags)
|
||||||
|
|
||||||
Removes a space-separated list of [X]HTML tag names from the output.
|
Removes a space-separated list of [X]HTML tag names from the output.
|
||||||
|
@ -696,15 +692,11 @@ escaping HTML.
|
||||||
|
|
||||||
.. function:: urlsafe_base64_encode(s)
|
.. function:: urlsafe_base64_encode(s)
|
||||||
|
|
||||||
.. versionadded:: 1.6
|
|
||||||
|
|
||||||
Encodes a bytestring in base64 for use in URLs, stripping any trailing
|
Encodes a bytestring in base64 for use in URLs, stripping any trailing
|
||||||
equal signs.
|
equal signs.
|
||||||
|
|
||||||
.. function:: urlsafe_base64_decode(s)
|
.. function:: urlsafe_base64_decode(s)
|
||||||
|
|
||||||
.. versionadded:: 1.6
|
|
||||||
|
|
||||||
Decodes a base64 encoded string, adding back any trailing equal signs that
|
Decodes a base64 encoded string, adding back any trailing equal signs that
|
||||||
might have been stripped.
|
might have been stripped.
|
||||||
|
|
||||||
|
@ -733,7 +725,6 @@ Functions for working with Python modules.
|
||||||
|
|
||||||
.. function:: import_by_path(dotted_path, error_prefix='')
|
.. function:: import_by_path(dotted_path, error_prefix='')
|
||||||
|
|
||||||
.. versionadded:: 1.6
|
|
||||||
.. deprecated:: 1.7
|
.. deprecated:: 1.7
|
||||||
Use :meth:`~django.utils.module_loading.import_string` instead.
|
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
|
When using managed transactions -- that is, anything but the default
|
||||||
autocommit mode -- it is important when a transaction is marked as
|
autocommit mode -- it is important when a transaction is marked as
|
||||||
"dirty". Dirty transactions are committed by the
|
"dirty". Dirty transactions are committed by the ``commit_on_success``
|
||||||
:func:`~django.db.transaction.commit_on_success` decorator or the
|
decorator or the ``django.middleware.transaction.TransactionMiddleware``, and
|
||||||
:class:`~django.middleware.transaction.TransactionMiddleware`, and
|
``commit_manually`` forces them to be closed explicitly; clean transactions
|
||||||
:func:`~django.db.transaction.commit_manually` forces them to be
|
"get a pass", which means they are usually rolled back at the end of a request
|
||||||
closed explicitly; clean transactions "get a pass", which means they
|
when the connection is closed.
|
||||||
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
|
Until Django 1.3, transactions were only marked dirty when Django was
|
||||||
aware of a modifying operation performed in them; that is, either some
|
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
|
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, and it was disabled by default. This option is now ignored and can
|
||||||
<postgresql-autocommit-mode>` and can be removed.
|
be removed.
|
||||||
|
|
||||||
.. _new-test-runner:
|
.. _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
|
username and password is valid in multiple backends, Django will stop
|
||||||
processing at the first positive match.
|
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::
|
.. note::
|
||||||
|
|
||||||
Once a user has authenticated, Django stores which backend was used to
|
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
|
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()``.
|
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
|
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()`
|
:meth:`~django.contrib.auth.models.AbstractBaseUser.set_unusable_password()`
|
||||||
were used.
|
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)
|
.. method:: models.AbstractBaseUser.check_password(raw_password)
|
||||||
|
|
||||||
Returns ``True`` if the given raw string is the correct password for
|
Returns ``True`` if the given raw string is the correct password for
|
||||||
the user. (This takes care of the password hashing in making the
|
the user. (This takes care of the password hashing in making the
|
||||||
comparison.)
|
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()
|
.. method:: models.AbstractBaseUser.set_unusable_password()
|
||||||
|
|
||||||
Marks the user as having no password set. This isn't the same as
|
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."
|
"Run tests for a simple extension of the built-in User."
|
||||||
self.assertSomething()
|
self.assertSomething()
|
||||||
|
|
||||||
.. versionchanged:: 1.6
|
|
||||||
|
|
||||||
In Django 1.5, it wasn't necessary to explicitly import the test User models.
|
|
||||||
|
|
||||||
A full example
|
A full example
|
||||||
--------------
|
--------------
|
||||||
|
|
||||||
|
|
|
@ -851,11 +851,6 @@ patterns.
|
||||||
error message since this would expose their account's existence but no
|
error message since this would expose their account's existence but no
|
||||||
mail will be sent either.
|
mail will be sent either.
|
||||||
|
|
||||||
.. versionchanged:: 1.6
|
|
||||||
|
|
||||||
Previously, error messages indicated whether a given email was
|
|
||||||
registered.
|
|
||||||
|
|
||||||
**URL name:** ``password_reset``
|
**URL name:** ``password_reset``
|
||||||
|
|
||||||
**Optional arguments:**
|
**Optional arguments:**
|
||||||
|
@ -936,15 +931,9 @@ patterns.
|
||||||
Someone asked for password reset for email {{ email }}. Follow the link below:
|
Someone asked for password reset for email {{ email }}. Follow the link below:
|
||||||
{{ protocol}}://{{ domain }}{% url 'password_reset_confirm' uidb64=uid token=token %}
|
{{ 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
|
The same template context is used for subject template. Subject must be
|
||||||
single line plain text string.
|
single line plain text string.
|
||||||
|
|
||||||
|
|
||||||
.. function:: password_reset_done(request[, template_name, current_app, extra_context])
|
.. 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
|
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``.
|
* ``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
|
* ``token``: Token to check that the password is valid. Defaults to
|
||||||
``None``.
|
``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
|
However, Django can only upgrade passwords that use algorithms mentioned in
|
||||||
:setting:`PASSWORD_HASHERS`, so as you upgrade to new systems you should make
|
: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
|
sure never to *remove* entries from this list. If you do, users using
|
||||||
unmentioned algorithms won't be able to upgrade.
|
unmentioned algorithms won't be able to upgrade. Passwords will be upgraded
|
||||||
|
when changing the PBKDF2 iteration count.
|
||||||
.. versionadded:: 1.6
|
|
||||||
|
|
||||||
Passwords will be upgraded when changing the PBKDF2 iteration count.
|
|
||||||
|
|
||||||
.. _sha1: http://en.wikipedia.org/wiki/SHA1
|
.. _sha1: http://en.wikipedia.org/wiki/SHA1
|
||||||
.. _pbkdf2: http://en.wikipedia.org/wiki/PBKDF2
|
.. _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``
|
database to check against, and returns ``True`` if they match, ``False``
|
||||||
otherwise.
|
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])
|
.. function:: make_password(password[, salt, hashers])
|
||||||
|
|
||||||
Creates a hashed password in the format used by this application. It takes
|
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
|
It's the number of seconds the value should be stored in the cache. Passing in
|
||||||
``None`` for ``timeout`` will cache the value forever.
|
``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``::
|
If the object doesn't exist in the cache, ``cache.get()`` returns ``None``::
|
||||||
|
|
||||||
# Wait 30 seconds for 'my_key' to expire...
|
# 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
|
``get_queryset()`` results in an inability to retrieve objects you'd like to
|
||||||
work with.
|
work with.
|
||||||
|
|
||||||
.. versionchanged:: 1.6
|
|
||||||
|
|
||||||
The ``get_queryset`` method was previously named ``get_query_set``.
|
|
||||||
|
|
||||||
.. _managers-for-related-objects:
|
.. _managers-for-related-objects:
|
||||||
|
|
||||||
Using managers for related object access
|
Using managers for related object access
|
||||||
|
|
|
@ -197,13 +197,6 @@ argument.
|
||||||
|
|
||||||
__ http://en.wikipedia.org/wiki/SQL_injection
|
__ 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:
|
||||||
|
|
||||||
Executing custom SQL directly
|
Executing custom SQL directly
|
||||||
|
@ -236,13 +229,6 @@ For example::
|
||||||
|
|
||||||
return row
|
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
|
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::
|
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
|
Django's :class:`~django.test.TestCase` class also wraps each test in a
|
||||||
transaction for performance reasons.
|
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:
|
||||||
|
|
||||||
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.
|
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
|
Controlling transactions explicitly
|
||||||
-----------------------------------
|
-----------------------------------
|
||||||
|
|
||||||
.. versionadded:: 1.6
|
|
||||||
|
|
||||||
Django provides a single API to control database transactions.
|
Django provides a single API to control database transactions.
|
||||||
|
|
||||||
.. function:: atomic(using=None, savepoint=True)
|
.. function:: atomic(using=None, savepoint=True)
|
||||||
|
@ -251,11 +239,6 @@ on.
|
||||||
To avoid this, you can :ref:`deactivate the transaction management
|
To avoid this, you can :ref:`deactivate the transaction management
|
||||||
<deactivate-transaction-management>`, but it isn't recommended.
|
<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:
|
.. _deactivate-transaction-management:
|
||||||
|
|
||||||
Deactivating 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
|
where you want to run your own transaction-controlling middleware or do
|
||||||
something really strange.
|
something really strange.
|
||||||
|
|
||||||
.. versionchanged:: 1.6
|
|
||||||
|
|
||||||
This used to be controlled by the ``TRANSACTIONS_MANAGED`` setting.
|
|
||||||
|
|
||||||
Low-level APIs
|
Low-level APIs
|
||||||
==============
|
==============
|
||||||
|
|
||||||
|
@ -292,8 +271,6 @@ Low-level APIs
|
||||||
Autocommit
|
Autocommit
|
||||||
----------
|
----------
|
||||||
|
|
||||||
.. versionadded:: 1.6
|
|
||||||
|
|
||||||
Django provides a straightforward API in the :mod:`django.db.transaction`
|
Django provides a straightforward API in the :mod:`django.db.transaction`
|
||||||
module to manage the autocommit state of each database connection.
|
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
|
provide the ability to perform a fine-grained rollback, rather than the full
|
||||||
rollback that would be performed by ``transaction.rollback()``.
|
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`
|
||||||
When the :func:`atomic` decorator is nested, it creates a savepoint to allow
|
rather than the functions described below, but they're still part of the
|
||||||
partial commit or rollback. You're strongly encouraged to use :func:`atomic`
|
public API, and there's no plan to deprecate them.
|
||||||
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
|
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
|
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)
|
transaction.savepoint_rollback(sid)
|
||||||
# open transaction now contains only a.save()
|
# open transaction now contains only a.save()
|
||||||
|
|
||||||
.. versionadded:: 1.6
|
|
||||||
|
|
||||||
Savepoints may be used to recover from a database error by performing a partial
|
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
|
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
|
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
|
:func:`~django.forms.formsets.formset_factory`, then ``max_num`` will affect
|
||||||
validation. See :ref:`validate_max`.
|
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
|
Formset validation
|
||||||
------------------
|
------------------
|
||||||
|
|
||||||
|
@ -169,8 +162,6 @@ the expected error message appears for the second item.
|
||||||
|
|
||||||
.. method:: BaseFormSet.total_error_count()
|
.. method:: BaseFormSet.total_error_count()
|
||||||
|
|
||||||
.. versionadded:: 1.6
|
|
||||||
|
|
||||||
To check how many errors there are in the formset, we can use the
|
To check how many errors there are in the formset, we can use the
|
||||||
``total_error_count`` method::
|
``total_error_count`` method::
|
||||||
|
|
||||||
|
@ -344,11 +335,6 @@ excessive.
|
||||||
truncated entirely. This is to protect against memory exhaustion attacks
|
truncated entirely. This is to protect against memory exhaustion attacks
|
||||||
using forged POST requests.
|
using forged POST requests.
|
||||||
|
|
||||||
.. versionchanged:: 1.6
|
|
||||||
|
|
||||||
The ``validate_max`` parameter was added to
|
|
||||||
:func:`~django.forms.formsets.formset_factory`.
|
|
||||||
|
|
||||||
``validate_min``
|
``validate_min``
|
||||||
~~~~~~~~~~~~~~~~
|
~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
|
|
|
@ -317,14 +317,11 @@ attributes, which can be useful in your templates:
|
||||||
The label of the field, e.g. ``Email address``.
|
The label of the field, e.g. ``Email address``.
|
||||||
|
|
||||||
``{{ field.label_tag }}``
|
``{{ 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
|
<label for="id_email">Email address:</label>
|
||||||
|
|
||||||
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>
|
|
||||||
|
|
||||||
``{{ field.id_for_label }}``
|
``{{ field.id_for_label }}``
|
||||||
The ID that will be used for this field (``id_email`` in the example
|
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.,
|
The ``widgets`` dictionary accepts either widget instances (e.g.,
|
||||||
``Textarea(...)``) or classes (e.g., ``Textarea``).
|
``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``
|
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.
|
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
|
Enabling localization of fields
|
||||||
-------------------------------
|
-------------------------------
|
||||||
|
|
||||||
.. versionadded:: 1.6
|
|
||||||
|
|
||||||
By default, the fields in a ``ModelForm`` will not localize their data. To
|
By default, the fields in a ``ModelForm`` will not localize their data. To
|
||||||
enable localization for fields, you can use the ``localized_fields``
|
enable localization for fields, you can use the ``localized_fields``
|
||||||
attribute on the ``Meta`` class.
|
attribute on the ``Meta`` class.
|
||||||
|
@ -818,8 +812,6 @@ exclude::
|
||||||
Specifying widgets to use in the form with ``widgets``
|
Specifying widgets to use in the form with ``widgets``
|
||||||
------------------------------------------------------
|
------------------------------------------------------
|
||||||
|
|
||||||
.. versionadded:: 1.6
|
|
||||||
|
|
||||||
Using the ``widgets`` parameter, you can specify a dictionary of values to
|
Using the ``widgets`` parameter, you can specify a dictionary of values to
|
||||||
customize the ``ModelForm``’s widget class for a particular field. This
|
customize the ``ModelForm``’s widget class for a particular field. This
|
||||||
works the same way as the ``widgets`` dictionary on the inner ``Meta``
|
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``
|
Enabling localization for fields with ``localized_fields``
|
||||||
----------------------------------------------------------
|
----------------------------------------------------------
|
||||||
|
|
||||||
.. versionadded:: 1.6
|
|
||||||
|
|
||||||
Using the ``localized_fields`` parameter, you can enable localization for
|
Using the ``localized_fields`` parameter, you can enable localization for
|
||||||
fields in the form.
|
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
|
Specifying widgets to use in the inline form
|
||||||
--------------------------------------------
|
--------------------------------------------
|
||||||
|
|
||||||
.. versionadded:: 1.6
|
|
||||||
|
|
||||||
``inlineformset_factory`` uses ``modelformset_factory`` and passes most
|
``inlineformset_factory`` uses ``modelformset_factory`` and passes most
|
||||||
of its arguments to ``modelformset_factory``. This means you can use
|
of its arguments to ``modelformset_factory``. This means you can use
|
||||||
the ``widgets`` parameter in much the same way as passing it to
|
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
|
Each middleware component is responsible for doing some specific function. For
|
||||||
example, Django includes a middleware component,
|
example, Django includes a middleware component,
|
||||||
:class:`~django.middleware.transaction.TransactionMiddleware`, that wraps the
|
:class:`~django.contrib.auth.middleware.AuthenticationMiddleware`, that
|
||||||
processing of each HTTP request in a database transaction.
|
associates users with requests using sessions.
|
||||||
|
|
||||||
This document explains how middleware works, how you activate middleware, and
|
This document explains how middleware works, how you activate middleware, and
|
||||||
how to write your own middleware. Django ships with some built-in middleware
|
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
|
Session serialization
|
||||||
---------------------
|
---------------------
|
||||||
|
|
||||||
.. versionchanged:: 1.6
|
|
||||||
|
|
||||||
Before version 1.6, Django defaulted to using :mod:`pickle` to serialize
|
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
|
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
|
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
|
The 400 (bad request) view
|
||||||
--------------------------
|
--------------------------
|
||||||
|
|
||||||
.. versionadded:: 1.6
|
|
||||||
|
|
||||||
.. function:: django.views.defaults.bad_request(request, template_name='400.html')
|
.. function:: django.views.defaults.bad_request(request, template_name='400.html')
|
||||||
|
|
||||||
When a :exc:`~django.core.exceptions.SuspiciousOperation` is raised in Django,
|
When a :exc:`~django.core.exceptions.SuspiciousOperation` is raised in Django,
|
||||||
|
|
|
@ -433,8 +433,6 @@ helper function described next.
|
||||||
Lazy translations and plural
|
Lazy translations and plural
|
||||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
.. versionadded:: 1.6
|
|
||||||
|
|
||||||
When using lazy translation for a plural string (``[u]n[p]gettext_lazy``), you
|
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
|
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
|
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
|
sensitive information to be filtered out of error reports -- learn more on
|
||||||
:ref:`Filtering error reports<filtering-error-reports>`.
|
:ref:`Filtering error reports<filtering-error-reports>`.
|
||||||
|
|
||||||
.. versionadded:: 1.6
|
|
||||||
|
|
||||||
By setting the ``email_backend`` argument of ``AdminEmailHandler``, the
|
By setting the ``email_backend`` argument of ``AdminEmailHandler``, the
|
||||||
:ref:`email backend <topic-email-backends>` that is being used by the
|
:ref:`email backend <topic-email-backends>` that is being used by the
|
||||||
handler can be overridden, like this::
|
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
|
If the ``pk`` attribute in the serialized data doesn't exist or is
|
||||||
null, a new instance will be saved to the database.
|
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
|
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
|
data in your serialized representation doesn't match what's currently in the
|
||||||
database. Usually, working with these ``DeserializedObject`` instances looks
|
database. Usually, working with these ``DeserializedObject`` instances looks
|
||||||
|
|
|
@ -166,8 +166,6 @@ Advanced features of ``TransactionTestCase``
|
||||||
|
|
||||||
.. attribute:: TransactionTestCase.available_apps
|
.. attribute:: TransactionTestCase.available_apps
|
||||||
|
|
||||||
.. versionadded:: 1.6
|
|
||||||
|
|
||||||
.. warning::
|
.. warning::
|
||||||
|
|
||||||
This attribute is a private API. It may be changed or removed without
|
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
|
.. currentmodule:: django.test.runner
|
||||||
|
|
||||||
.. versionadded:: 1.6
|
|
||||||
|
|
||||||
A test runner is a class defining a ``run_tests()`` method. Django ships
|
A test runner is a class defining a ``run_tests()`` method. Django ships
|
||||||
with a ``DiscoverRunner`` class that defines the default Django testing
|
with a ``DiscoverRunner`` class that defines the default Django testing
|
||||||
behavior. This class defines the ``run_tests()`` entry point, plus a
|
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``,
|
: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.
|
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.
|
For more details about :mod:`unittest`, see the Python documentation.
|
||||||
|
|
||||||
.. warning::
|
.. warning::
|
||||||
|
@ -120,15 +114,6 @@ You can specify a custom filename pattern match using the ``-p`` (or
|
||||||
|
|
||||||
$ ./manage.py test --pattern="tests_*.py"
|
$ ./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
|
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.
|
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
|
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`.
|
* Using the :attr:`~SimpleTestCase.client` :class:`~django.test.Client`.
|
||||||
* Custom test-time :attr:`URL maps <SimpleTestCase.urls>`.
|
* 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
|
If you need any of the other more complex and heavyweight Django-specific
|
||||||
features like:
|
features like:
|
||||||
|
|
||||||
|
@ -1281,8 +1276,6 @@ your test suite.
|
||||||
|
|
||||||
.. method:: SimpleTestCase.assertFormsetError(response, formset, form_index, field, errors, msg_prefix='')
|
.. 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
|
Asserts that the ``formset`` raises the provided list of errors when
|
||||||
rendered.
|
rendered.
|
||||||
|
|
||||||
|
@ -1459,16 +1452,12 @@ your test suite.
|
||||||
By default, the comparison is also ordering dependent. If ``qs`` doesn't
|
By default, the comparison is also ordering dependent. If ``qs`` doesn't
|
||||||
provide an implicit ordering, you can set the ``ordered`` parameter to
|
provide an implicit ordering, you can set the ``ordered`` parameter to
|
||||||
``False``, which turns the comparison into a Python set comparison.
|
``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.
|
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
|
.. versionchanged:: 1.7
|
||||||
|
|
||||||
The method now accepts a ``msg`` parameter to allow customization of
|
The method now accepts a ``msg`` parameter to allow customization of
|
||||||
|
|
Loading…
Reference in New Issue