Removed versionadded/changed notes for 1.7.
This commit is contained in:
parent
0e60912492
commit
c79faae761
|
@ -109,14 +109,6 @@ free unique filename cannot be found, a :exc:`SuspiciousFileOperation
|
||||||
If a file with ``name`` already exists, an underscore plus a random 7 character
|
If a file with ``name`` already exists, an underscore plus a random 7 character
|
||||||
alphanumeric string is appended to the filename before the extension.
|
alphanumeric string is appended to the filename before the extension.
|
||||||
|
|
||||||
.. versionchanged:: 1.7
|
|
||||||
|
|
||||||
Previously, an underscore followed by a number (e.g. ``"_1"``, ``"_2"``,
|
|
||||||
etc.) was appended to the filename until an available name in the destination
|
|
||||||
directory was found. A malicious user could exploit this deterministic
|
|
||||||
algorithm to create a denial-of-service attack. This change was also made
|
|
||||||
in Django 1.6.6, 1.5.9, and 1.4.14.
|
|
||||||
|
|
||||||
.. versionchanged:: 1.8
|
.. versionchanged:: 1.8
|
||||||
|
|
||||||
The ``max_length`` argument was added.
|
The ``max_length`` argument was added.
|
||||||
|
|
|
@ -2,8 +2,6 @@
|
||||||
Custom Lookups
|
Custom Lookups
|
||||||
==============
|
==============
|
||||||
|
|
||||||
.. versionadded:: 1.7
|
|
||||||
|
|
||||||
.. currentmodule:: django.db.models
|
.. currentmodule:: django.db.models
|
||||||
|
|
||||||
Django offers a wide variety of :ref:`built-in lookups <field-lookups>` for
|
Django offers a wide variety of :ref:`built-in lookups <field-lookups>` for
|
||||||
|
|
|
@ -351,8 +351,6 @@ the :meth:`~BaseCommand.handle` method must be implemented.
|
||||||
|
|
||||||
.. method:: BaseCommand.check(app_configs=None, tags=None, display_num_errors=False)
|
.. method:: BaseCommand.check(app_configs=None, tags=None, display_num_errors=False)
|
||||||
|
|
||||||
.. versionadded:: 1.7
|
|
||||||
|
|
||||||
Uses the system check framework to inspect the entire Django project for
|
Uses the system check framework to inspect the entire Django project for
|
||||||
potential problems. Serious problems are raised as a :class:`CommandError`;
|
potential problems. Serious problems are raised as a :class:`CommandError`;
|
||||||
warnings are output to stderr; minor notifications are output to stdout.
|
warnings are output to stderr; minor notifications are output to stdout.
|
||||||
|
|
|
@ -230,12 +230,6 @@ meaning they do for normal Django fields. See the :doc:`field documentation
|
||||||
Field deconstruction
|
Field deconstruction
|
||||||
--------------------
|
--------------------
|
||||||
|
|
||||||
.. versionadded:: 1.7
|
|
||||||
|
|
||||||
``deconstruct()`` is part of the migrations framework in Django 1.7 and
|
|
||||||
above. If you have custom fields from previous versions they will
|
|
||||||
need this method added before you can use them with migrations.
|
|
||||||
|
|
||||||
The counterpoint to writing your ``__init__()`` method is writing the
|
The counterpoint to writing your ``__init__()`` method is writing the
|
||||||
``deconstruct()`` method. This method tells Django how to take an instance
|
``deconstruct()`` method. This method tells Django how to take an instance
|
||||||
of your new field and reduce it to a serialized form - in particular, what
|
of your new field and reduce it to a serialized form - in particular, what
|
||||||
|
@ -590,11 +584,8 @@ valid Django filter lookups: ``exact``, ``iexact``, ``contains``, ``icontains``,
|
||||||
``endswith``, ``iendswith``, ``range``, ``year``, ``month``, ``day``,
|
``endswith``, ``iendswith``, ``range``, ``year``, ``month``, ``day``,
|
||||||
``isnull``, ``search``, ``regex``, and ``iregex``.
|
``isnull``, ``search``, ``regex``, and ``iregex``.
|
||||||
|
|
||||||
.. versionadded:: 1.7
|
If you are using :doc:`custom lookups </howto/custom-lookups>`, the
|
||||||
|
``lookup_type`` can be any ``lookup_name`` used by the project's custom lookups.
|
||||||
If you are using :doc:`Custom lookups </howto/custom-lookups>` the
|
|
||||||
``lookup_type`` can be any ``lookup_name`` used by the project's custom
|
|
||||||
lookups.
|
|
||||||
|
|
||||||
Your method must be prepared to handle all of these ``lookup_type`` values and
|
Your method must be prepared to handle all of these ``lookup_type`` values and
|
||||||
should raise either a ``ValueError`` if the ``value`` is of the wrong sort (a
|
should raise either a ``ValueError`` if the ``value`` is of the wrong sort (a
|
||||||
|
|
|
@ -158,12 +158,6 @@ during execution of these tests in a way very similar to what we get at
|
||||||
development time with ``DEBUG = True``, i.e. without having to collect them
|
development time with ``DEBUG = True``, i.e. without having to collect them
|
||||||
using :djadmin:`collectstatic` first.
|
using :djadmin:`collectstatic` first.
|
||||||
|
|
||||||
.. versionadded:: 1.7
|
|
||||||
|
|
||||||
:class:`django.contrib.staticfiles.testing.StaticLiveServerTestCase` is new
|
|
||||||
in Django 1.7. Previously its functionality was provided by
|
|
||||||
:class:`django.test.LiveServerTestCase`.
|
|
||||||
|
|
||||||
Deployment
|
Deployment
|
||||||
==========
|
==========
|
||||||
|
|
||||||
|
|
|
@ -62,11 +62,6 @@ This will download and install Django.
|
||||||
After the installation has completed, you can verify your Django installation
|
After the installation has completed, you can verify your Django installation
|
||||||
by executing ``django-admin --version`` in the command prompt.
|
by executing ``django-admin --version`` in the command prompt.
|
||||||
|
|
||||||
.. versionchanged:: 1.7
|
|
||||||
|
|
||||||
In Django 1.7, a ``.exe`` has been introduced, so just use
|
|
||||||
``django-admin`` in place of ``django-admin.py`` in the command prompt.
|
|
||||||
|
|
||||||
See :ref:`database-installation` for information on database installation
|
See :ref:`database-installation` for information on database installation
|
||||||
with Django.
|
with Django.
|
||||||
|
|
||||||
|
|
|
@ -39,17 +39,6 @@ sample settings module that uses the SQLite database. To run the tests:
|
||||||
$ cd django-repo/tests
|
$ cd django-repo/tests
|
||||||
$ PYTHONPATH=..:$PYTHONPATH ./runtests.py
|
$ PYTHONPATH=..:$PYTHONPATH ./runtests.py
|
||||||
|
|
||||||
.. versionchanged:: 1.7
|
|
||||||
|
|
||||||
Older versions of Django required specifying a settings file:
|
|
||||||
|
|
||||||
.. code-block:: bash
|
|
||||||
|
|
||||||
$ PYTHONPATH=..:$PYTHONPATH python ./runtests.py --settings=test_sqlite
|
|
||||||
|
|
||||||
``runtests.py`` now uses ``test_sqlite`` by default if settings aren't
|
|
||||||
provided through either ``--settings`` or :envvar:`DJANGO_SETTINGS_MODULE`.
|
|
||||||
|
|
||||||
You can avoid typing the ``PYTHONPATH`` bit each time by adding your Django
|
You can avoid typing the ``PYTHONPATH`` bit each time by adding your Django
|
||||||
checkout to your ``PYTHONPATH`` or by installing the source checkout using pip.
|
checkout to your ``PYTHONPATH`` or by installing the source checkout using pip.
|
||||||
See :ref:`installing-development-version`.
|
See :ref:`installing-development-version`.
|
||||||
|
@ -95,12 +84,6 @@ Test databases get their names by prepending ``test_`` to the value of the
|
||||||
:setting:`NAME` settings for the databases defined in :setting:`DATABASES`.
|
:setting:`NAME` settings for the databases defined in :setting:`DATABASES`.
|
||||||
These test databases are deleted when the tests are finished.
|
These test databases are deleted when the tests are finished.
|
||||||
|
|
||||||
.. versionchanged:: 1.7
|
|
||||||
|
|
||||||
Before Django 1.7, the :setting:`NAME` setting was mandatory and had to
|
|
||||||
be the name of an existing database to which the given user had permission
|
|
||||||
to connect.
|
|
||||||
|
|
||||||
You will also need to ensure that your database uses UTF-8 as the default
|
You will also need to ensure that your database uses UTF-8 as the default
|
||||||
character set. If your database server doesn't use UTF-8 as a default charset,
|
character set. If your database server doesn't use UTF-8 as a default charset,
|
||||||
you will need to include a value for :setting:`TEST_CHARSET` in the settings
|
you will need to include a value for :setting:`TEST_CHARSET` in the settings
|
||||||
|
|
|
@ -4,8 +4,6 @@ Applications
|
||||||
|
|
||||||
.. module:: django.apps
|
.. module:: django.apps
|
||||||
|
|
||||||
.. versionadded:: 1.7
|
|
||||||
|
|
||||||
Django contains a registry of installed applications that stores configuration
|
Django contains a registry of installed applications that stores configuration
|
||||||
and provides introspection. It also maintains a list of available :doc:`models
|
and provides introspection. It also maintains a list of available :doc:`models
|
||||||
</topics/db/models>`.
|
</topics/db/models>`.
|
||||||
|
|
|
@ -2,8 +2,6 @@
|
||||||
System check framework
|
System check framework
|
||||||
======================
|
======================
|
||||||
|
|
||||||
.. versionadded:: 1.7
|
|
||||||
|
|
||||||
The system check framework is a set of static checks for validating Django
|
The system check framework is a set of static checks for validating Django
|
||||||
projects. It detects common problems and provides hints for how to fix them.
|
projects. It detects common problems and provides hints for how to fix them.
|
||||||
The framework is extensible so you can easily add your own checks.
|
The framework is extensible so you can easily add your own checks.
|
||||||
|
|
|
@ -102,8 +102,6 @@ The register decorator
|
||||||
|
|
||||||
.. function:: register(*models, [site=django.admin.sites.site])
|
.. function:: register(*models, [site=django.admin.sites.site])
|
||||||
|
|
||||||
.. versionadded:: 1.7
|
|
||||||
|
|
||||||
There is also a decorator for registering your ``ModelAdmin`` classes::
|
There is also a decorator for registering your ``ModelAdmin`` classes::
|
||||||
|
|
||||||
from django.contrib import admin
|
from django.contrib import admin
|
||||||
|
@ -134,15 +132,11 @@ application and imports it.
|
||||||
|
|
||||||
.. class:: apps.AdminConfig
|
.. class:: apps.AdminConfig
|
||||||
|
|
||||||
.. versionadded:: 1.7
|
|
||||||
|
|
||||||
This is the default :class:`~django.apps.AppConfig` class for the admin.
|
This is the default :class:`~django.apps.AppConfig` class for the admin.
|
||||||
It calls :func:`~django.contrib.admin.autodiscover()` when Django starts.
|
It calls :func:`~django.contrib.admin.autodiscover()` when Django starts.
|
||||||
|
|
||||||
.. class:: apps.SimpleAdminConfig
|
.. class:: apps.SimpleAdminConfig
|
||||||
|
|
||||||
.. versionadded:: 1.7
|
|
||||||
|
|
||||||
This class works like :class:`~django.contrib.admin.apps.AdminConfig`,
|
This class works like :class:`~django.contrib.admin.apps.AdminConfig`,
|
||||||
except it doesn't call :func:`~django.contrib.admin.autodiscover()`.
|
except it doesn't call :func:`~django.contrib.admin.autodiscover()`.
|
||||||
|
|
||||||
|
@ -151,12 +145,8 @@ application and imports it.
|
||||||
This function attempts to import an ``admin`` module in each installed
|
This function attempts to import an ``admin`` module in each installed
|
||||||
application. Such modules are expected to register models with the admin.
|
application. Such modules are expected to register models with the admin.
|
||||||
|
|
||||||
.. versionchanged:: 1.7
|
Typically you won't need to call this function directly as
|
||||||
|
:class:`~django.contrib.admin.apps.AdminConfig` calls it when Django starts.
|
||||||
Previous versions of Django recommended calling this function directly
|
|
||||||
in the URLconf. As of Django 1.7 this isn't needed anymore.
|
|
||||||
:class:`~django.contrib.admin.apps.AdminConfig` takes care of running
|
|
||||||
the auto-discovery automatically.
|
|
||||||
|
|
||||||
If you are using a custom ``AdminSite``, it is common to import all of the
|
If you are using a custom ``AdminSite``, it is common to import all of the
|
||||||
``ModelAdmin`` subclasses into your code and register them to the custom
|
``ModelAdmin`` subclasses into your code and register them to the custom
|
||||||
|
@ -164,14 +154,6 @@ If you are using a custom ``AdminSite``, it is common to import all of the
|
||||||
put ``'django.contrib.admin.apps.SimpleAdminConfig'`` instead of
|
put ``'django.contrib.admin.apps.SimpleAdminConfig'`` instead of
|
||||||
``'django.contrib.admin'`` in your :setting:`INSTALLED_APPS` setting.
|
``'django.contrib.admin'`` in your :setting:`INSTALLED_APPS` setting.
|
||||||
|
|
||||||
.. versionchanged:: 1.7
|
|
||||||
|
|
||||||
In previous versions, the admin needed to be instructed to look for
|
|
||||||
``admin.py`` files with :func:`~django.contrib.admin.autodiscover()`.
|
|
||||||
As of Django 1.7, auto-discovery is enabled by default and must be
|
|
||||||
explicitly disabled when it's undesirable.
|
|
||||||
|
|
||||||
|
|
||||||
``ModelAdmin`` options
|
``ModelAdmin`` options
|
||||||
----------------------
|
----------------------
|
||||||
|
|
||||||
|
@ -661,8 +643,6 @@ subclass::
|
||||||
The above will tell Django to order by the ``first_name`` field when
|
The above will tell Django to order by the ``first_name`` field when
|
||||||
trying to sort by ``colored_first_name`` in the admin.
|
trying to sort by ``colored_first_name`` in the admin.
|
||||||
|
|
||||||
.. versionadded:: 1.7
|
|
||||||
|
|
||||||
To indicate descending order with ``admin_order_field`` you can use a
|
To indicate descending order with ``admin_order_field`` you can use a
|
||||||
hyphen prefix on the field name. Using the above example, this would
|
hyphen prefix on the field name. Using the above example, this would
|
||||||
look like::
|
look like::
|
||||||
|
@ -737,10 +717,6 @@ subclass::
|
||||||
list_display = ('timestamp', 'message')
|
list_display = ('timestamp', 'message')
|
||||||
list_display_links = None
|
list_display_links = None
|
||||||
|
|
||||||
.. versionchanged:: 1.7
|
|
||||||
|
|
||||||
``None`` was added as a valid ``list_display_links`` value.
|
|
||||||
|
|
||||||
.. _admin-list-editable:
|
.. _admin-list-editable:
|
||||||
|
|
||||||
.. attribute:: ModelAdmin.list_editable
|
.. attribute:: ModelAdmin.list_editable
|
||||||
|
@ -1176,8 +1152,6 @@ subclass::
|
||||||
|
|
||||||
.. attribute:: ModelAdmin.view_on_site
|
.. attribute:: ModelAdmin.view_on_site
|
||||||
|
|
||||||
.. versionadded:: 1.7
|
|
||||||
|
|
||||||
Set ``view_on_site`` to control whether or not to display the "View on site" link.
|
Set ``view_on_site`` to control whether or not to display the "View on site" link.
|
||||||
This link should bring you to a URL where you can display the saved object.
|
This link should bring you to a URL where you can display the saved object.
|
||||||
|
|
||||||
|
@ -1373,14 +1347,8 @@ templates used by the :class:`ModelAdmin` views:
|
||||||
names on the changelist that will be linked to the change view, as described
|
names on the changelist that will be linked to the change view, as described
|
||||||
in the :attr:`ModelAdmin.list_display_links` section.
|
in the :attr:`ModelAdmin.list_display_links` section.
|
||||||
|
|
||||||
.. versionchanged:: 1.7
|
|
||||||
|
|
||||||
``None`` was added as a valid ``get_list_display_links()`` return value.
|
|
||||||
|
|
||||||
.. method:: ModelAdmin.get_fields(request, obj=None)
|
.. method:: ModelAdmin.get_fields(request, obj=None)
|
||||||
|
|
||||||
.. versionadded:: 1.7
|
|
||||||
|
|
||||||
The ``get_fields`` method is given the ``HttpRequest`` and the ``obj``
|
The ``get_fields`` method is given the ``HttpRequest`` and the ``obj``
|
||||||
being edited (or ``None`` on an add form) and is expected to return a list
|
being edited (or ``None`` on an add form) and is expected to return a list
|
||||||
of fields, as described above in the :attr:`ModelAdmin.fields` section.
|
of fields, as described above in the :attr:`ModelAdmin.fields` section.
|
||||||
|
@ -1400,8 +1368,6 @@ templates used by the :class:`ModelAdmin` views:
|
||||||
|
|
||||||
.. method:: ModelAdmin.get_search_fields(request)
|
.. method:: ModelAdmin.get_search_fields(request)
|
||||||
|
|
||||||
.. versionadded:: 1.7
|
|
||||||
|
|
||||||
The ``get_search_fields`` method is given the ``HttpRequest`` and is expected
|
The ``get_search_fields`` method is given the ``HttpRequest`` and is expected
|
||||||
to return the same kind of sequence type as for the
|
to return the same kind of sequence type as for the
|
||||||
:attr:`~ModelAdmin.search_fields` attribute.
|
:attr:`~ModelAdmin.search_fields` attribute.
|
||||||
|
@ -1723,8 +1689,6 @@ templates used by the :class:`ModelAdmin` views:
|
||||||
|
|
||||||
.. method:: ModelAdmin.response_delete(request, obj_display, obj_id)
|
.. method:: ModelAdmin.response_delete(request, obj_display, obj_id)
|
||||||
|
|
||||||
.. versionadded:: 1.7
|
|
||||||
|
|
||||||
Determines the :class:`~django.http.HttpResponse` for the
|
Determines the :class:`~django.http.HttpResponse` for the
|
||||||
:meth:`delete_view` stage.
|
:meth:`delete_view` stage.
|
||||||
|
|
||||||
|
@ -1744,8 +1708,6 @@ templates used by the :class:`ModelAdmin` views:
|
||||||
|
|
||||||
.. method:: ModelAdmin.get_changeform_initial_data(request)
|
.. method:: ModelAdmin.get_changeform_initial_data(request)
|
||||||
|
|
||||||
.. versionadded:: 1.7
|
|
||||||
|
|
||||||
A hook for the initial data on admin change forms. By default, fields are
|
A hook for the initial data on admin change forms. By default, fields are
|
||||||
given initial values from ``GET`` parameters. For instance,
|
given initial values from ``GET`` parameters. For instance,
|
||||||
``?name=initial_value`` will set the ``name`` field's initial value to be
|
``?name=initial_value`` will set the ``name`` field's initial value to be
|
||||||
|
@ -2021,8 +1983,6 @@ The ``InlineModelAdmin`` class adds:
|
||||||
|
|
||||||
.. attribute:: InlineModelAdmin.min_num
|
.. attribute:: InlineModelAdmin.min_num
|
||||||
|
|
||||||
.. versionadded:: 1.7
|
|
||||||
|
|
||||||
This controls the minimum number of forms to show in the inline.
|
This controls the minimum number of forms to show in the inline.
|
||||||
See :func:`~django.forms.models.modelformset_factory` for more information.
|
See :func:`~django.forms.models.modelformset_factory` for more information.
|
||||||
|
|
||||||
|
@ -2114,8 +2074,6 @@ The ``InlineModelAdmin`` class adds:
|
||||||
|
|
||||||
.. method:: InlineModelAdmin.get_min_num(request, obj=None, **kwargs)
|
.. method:: InlineModelAdmin.get_min_num(request, obj=None, **kwargs)
|
||||||
|
|
||||||
.. versionadded:: 1.7
|
|
||||||
|
|
||||||
Returns the minimum number of inline forms to use. By default,
|
Returns the minimum number of inline forms to use. By default,
|
||||||
returns the :attr:`InlineModelAdmin.min_num` attribute.
|
returns the :attr:`InlineModelAdmin.min_num` attribute.
|
||||||
|
|
||||||
|
@ -2451,15 +2409,11 @@ Templates can override or extend base admin templates as described in
|
||||||
|
|
||||||
.. attribute:: AdminSite.site_header
|
.. attribute:: AdminSite.site_header
|
||||||
|
|
||||||
.. versionadded:: 1.7
|
|
||||||
|
|
||||||
The text to put at the top of each admin page, as an ``<h1>`` (a string).
|
The text to put at the top of each admin page, as an ``<h1>`` (a string).
|
||||||
By default, this is "Django administration".
|
By default, this is "Django administration".
|
||||||
|
|
||||||
.. attribute:: AdminSite.site_title
|
.. attribute:: AdminSite.site_title
|
||||||
|
|
||||||
.. versionadded:: 1.7
|
|
||||||
|
|
||||||
The text to put at the end of each admin page's ``<title>`` (a string). By
|
The text to put at the end of each admin page's ``<title>`` (a string). By
|
||||||
default, this is "Django site admin".
|
default, this is "Django site admin".
|
||||||
|
|
||||||
|
@ -2472,8 +2426,6 @@ Templates can override or extend base admin templates as described in
|
||||||
|
|
||||||
.. attribute:: AdminSite.index_title
|
.. attribute:: AdminSite.index_title
|
||||||
|
|
||||||
.. versionadded:: 1.7
|
|
||||||
|
|
||||||
The text to put at the top of the admin index page (a string). By default,
|
The text to put at the top of the admin index page (a string). By default,
|
||||||
this is "Site administration".
|
this is "Site administration".
|
||||||
|
|
||||||
|
@ -2514,8 +2466,6 @@ Templates can override or extend base admin templates as described in
|
||||||
|
|
||||||
.. method:: AdminSite.each_context(request)
|
.. method:: AdminSite.each_context(request)
|
||||||
|
|
||||||
.. versionadded:: 1.7
|
|
||||||
|
|
||||||
Returns a dictionary of variables to put in the template context for
|
Returns a dictionary of variables to put in the template context for
|
||||||
every page in the admin site.
|
every page in the admin site.
|
||||||
|
|
||||||
|
|
|
@ -215,12 +215,8 @@ Methods
|
||||||
.. method:: email_user(subject, message, from_email=None, **kwargs)
|
.. method:: email_user(subject, message, from_email=None, **kwargs)
|
||||||
|
|
||||||
Sends an email to the user. If ``from_email`` is ``None``, Django uses
|
Sends an email to the user. If ``from_email`` is ``None``, Django uses
|
||||||
the :setting:`DEFAULT_FROM_EMAIL`.
|
the :setting:`DEFAULT_FROM_EMAIL`. Any ``**kwargs`` are passed to the
|
||||||
|
underlying :meth:`~django.core.mail.send_mail()` call.
|
||||||
.. versionchanged:: 1.7
|
|
||||||
|
|
||||||
Any ``**kwargs`` are passed to the underlying
|
|
||||||
:meth:`~django.core.mail.send_mail()` call.
|
|
||||||
|
|
||||||
Manager methods
|
Manager methods
|
||||||
---------------
|
---------------
|
||||||
|
|
|
@ -366,8 +366,6 @@ Reverse generic relations
|
||||||
|
|
||||||
.. attribute:: related_query_name
|
.. attribute:: related_query_name
|
||||||
|
|
||||||
.. versionadded:: 1.7
|
|
||||||
|
|
||||||
The relation on the related object back to this object doesn't exist by
|
The relation on the related object back to this object doesn't exist by
|
||||||
default. Setting ``related_query_name`` creates a relation from the
|
default. Setting ``related_query_name`` creates a relation from the
|
||||||
related object back to this one. This allows querying and filtering
|
related object back to this one. This allows querying and filtering
|
||||||
|
@ -392,8 +390,6 @@ be used to retrieve their associated ``TaggedItems``::
|
||||||
>>> b.tags.all()
|
>>> b.tags.all()
|
||||||
[<TaggedItem: django>, <TaggedItem: python>]
|
[<TaggedItem: django>, <TaggedItem: python>]
|
||||||
|
|
||||||
.. versionadded:: 1.7
|
|
||||||
|
|
||||||
Defining :class:`~django.contrib.contenttypes.fields.GenericRelation` with
|
Defining :class:`~django.contrib.contenttypes.fields.GenericRelation` with
|
||||||
``related_query_name`` set allows querying from the related object::
|
``related_query_name`` set allows querying from the related object::
|
||||||
|
|
||||||
|
@ -502,15 +498,10 @@ The :mod:`django.contrib.contenttypes.forms` module provides:
|
||||||
:class:`~django.contrib.contenttypes.fields.GenericForeignKey.for_concrete_model`
|
:class:`~django.contrib.contenttypes.fields.GenericForeignKey.for_concrete_model`
|
||||||
argument on ``GenericForeignKey``.
|
argument on ``GenericForeignKey``.
|
||||||
|
|
||||||
.. versionchanged:: 1.7
|
|
||||||
|
|
||||||
``min_num`` and ``validate_min`` were added.
|
|
||||||
|
|
||||||
|
|
||||||
.. module:: django.contrib.contenttypes.admin
|
.. module:: django.contrib.contenttypes.admin
|
||||||
|
|
||||||
Generic relations in admin
|
Generic relations in admin
|
||||||
------------------------------------
|
--------------------------
|
||||||
|
|
||||||
The :mod:`django.contrib.contenttypes.admin` module provides
|
The :mod:`django.contrib.contenttypes.admin` module provides
|
||||||
:class:`~django.contrib.contenttypes.admin.GenericTabularInline` and
|
:class:`~django.contrib.contenttypes.admin.GenericTabularInline` and
|
||||||
|
|
|
@ -737,16 +737,12 @@ For example::
|
||||||
|
|
||||||
.. method:: crosses(other)
|
.. method:: crosses(other)
|
||||||
|
|
||||||
.. versionadded:: 1.7
|
|
||||||
|
|
||||||
.. note::
|
.. note::
|
||||||
|
|
||||||
GEOS 3.3 is *required* to use this predicate.
|
GEOS 3.3 is *required* to use this predicate.
|
||||||
|
|
||||||
.. method:: disjoint(other)
|
.. method:: disjoint(other)
|
||||||
|
|
||||||
.. versionadded:: 1.7
|
|
||||||
|
|
||||||
.. note::
|
.. note::
|
||||||
|
|
||||||
GEOS 3.3 is *required* to use this predicate.
|
GEOS 3.3 is *required* to use this predicate.
|
||||||
|
@ -755,24 +751,18 @@ For example::
|
||||||
|
|
||||||
.. method:: overlaps(other)
|
.. method:: overlaps(other)
|
||||||
|
|
||||||
.. versionadded:: 1.7
|
|
||||||
|
|
||||||
.. note::
|
.. note::
|
||||||
|
|
||||||
GEOS 3.3 is *required* to use this predicate.
|
GEOS 3.3 is *required* to use this predicate.
|
||||||
|
|
||||||
.. method:: touches(other)
|
.. method:: touches(other)
|
||||||
|
|
||||||
.. versionadded:: 1.7
|
|
||||||
|
|
||||||
.. note::
|
.. note::
|
||||||
|
|
||||||
GEOS 3.3 is *required* to use this predicate.
|
GEOS 3.3 is *required* to use this predicate.
|
||||||
|
|
||||||
.. method:: within(other)
|
.. method:: within(other)
|
||||||
|
|
||||||
.. versionadded:: 1.7
|
|
||||||
|
|
||||||
.. note::
|
.. note::
|
||||||
|
|
||||||
GEOS 3.3 is *required* to use this predicate.
|
GEOS 3.3 is *required* to use this predicate.
|
||||||
|
|
|
@ -198,8 +198,6 @@ Even if you know there is only just one message, you should still iterate over
|
||||||
the ``messages`` sequence, because otherwise the message storage will not be cleared
|
the ``messages`` sequence, because otherwise the message storage will not be cleared
|
||||||
for the next request.
|
for the next request.
|
||||||
|
|
||||||
.. versionadded:: 1.7
|
|
||||||
|
|
||||||
The context processor also provides a ``DEFAULT_MESSAGE_LEVELS`` variable which
|
The context processor also provides a ``DEFAULT_MESSAGE_LEVELS`` variable which
|
||||||
is a mapping of the message level names to their numeric value::
|
is a mapping of the message level names to their numeric value::
|
||||||
|
|
||||||
|
@ -214,8 +212,6 @@ is a mapping of the message level names to their numeric value::
|
||||||
</ul>
|
</ul>
|
||||||
{% endif %}
|
{% endif %}
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
**Outside of templates**, you can use
|
**Outside of templates**, you can use
|
||||||
:func:`~django.contrib.messages.get_messages`::
|
:func:`~django.contrib.messages.get_messages`::
|
||||||
|
|
||||||
|
@ -253,8 +249,6 @@ The ``Message`` class
|
||||||
* ``extra_tags``: A string containing custom tags for this message,
|
* ``extra_tags``: A string containing custom tags for this message,
|
||||||
separated by spaces. It's empty by default.
|
separated by spaces. It's empty by default.
|
||||||
|
|
||||||
.. versionadded:: 1.7
|
|
||||||
|
|
||||||
* ``level_tag``: The string representation of the level. By default, it's
|
* ``level_tag``: The string representation of the level. By default, it's
|
||||||
the lowercase version of the name of the associated constant, but this
|
the lowercase version of the name of the associated constant, but this
|
||||||
can be changed if you need by using the :setting:`MESSAGE_TAGS` setting.
|
can be changed if you need by using the :setting:`MESSAGE_TAGS` setting.
|
||||||
|
@ -438,8 +432,6 @@ behavior:
|
||||||
* :setting:`MESSAGE_STORAGE`
|
* :setting:`MESSAGE_STORAGE`
|
||||||
* :setting:`MESSAGE_TAGS`
|
* :setting:`MESSAGE_TAGS`
|
||||||
|
|
||||||
.. versionadded:: 1.7
|
|
||||||
|
|
||||||
For backends that use cookies, the settings for the cookie are taken from
|
For backends that use cookies, the settings for the cookie are taken from
|
||||||
the session cookie settings:
|
the session cookie settings:
|
||||||
|
|
||||||
|
|
|
@ -89,20 +89,14 @@ Middleware
|
||||||
|
|
||||||
.. attribute:: response_gone_class
|
.. attribute:: response_gone_class
|
||||||
|
|
||||||
.. versionadded:: 1.7
|
|
||||||
|
|
||||||
The :class:`~django.http.HttpResponse` class used when a
|
The :class:`~django.http.HttpResponse` class used when a
|
||||||
:class:`~django.contrib.redirects.models.Redirect` is not
|
:class:`~django.contrib.redirects.models.Redirect` is not found for the
|
||||||
found for the requested path or has a blank ``new_path``
|
requested path or has a blank ``new_path`` value.
|
||||||
value.
|
|
||||||
|
|
||||||
Defaults to :class:`~django.http.HttpResponseGone`.
|
Defaults to :class:`~django.http.HttpResponseGone`.
|
||||||
|
|
||||||
.. attribute:: response_redirect_class
|
.. attribute:: response_redirect_class
|
||||||
|
|
||||||
.. versionadded:: 1.7
|
The :class:`~django.http.HttpResponse` class that handles the redirect.
|
||||||
|
|
||||||
The :class:`~django.http.HttpResponse` class that handles the
|
|
||||||
redirect.
|
|
||||||
|
|
||||||
Defaults to :class:`~django.http.HttpResponsePermanentRedirect`.
|
Defaults to :class:`~django.http.HttpResponsePermanentRedirect`.
|
||||||
|
|
|
@ -181,8 +181,6 @@ Sitemap class reference
|
||||||
representing the last-modified date/time for *every* object returned by
|
representing the last-modified date/time for *every* object returned by
|
||||||
:attr:`~Sitemap.items()`.
|
:attr:`~Sitemap.items()`.
|
||||||
|
|
||||||
.. versionadded:: 1.7
|
|
||||||
|
|
||||||
If all items in a sitemap have a :attr:`~Sitemap.lastmod`, the sitemap
|
If all items in a sitemap have a :attr:`~Sitemap.lastmod`, the sitemap
|
||||||
generated by :func:`views.sitemap` will have a ``Last-Modified``
|
generated by :func:`views.sitemap` will have a ``Last-Modified``
|
||||||
header equal to the latest ``lastmod``. You can activate the
|
header equal to the latest ``lastmod``. You can activate the
|
||||||
|
|
|
@ -389,8 +389,6 @@ define :class:`~django.contrib.sites.managers.CurrentSiteManager`.
|
||||||
Site middleware
|
Site middleware
|
||||||
===============
|
===============
|
||||||
|
|
||||||
.. versionadded:: 1.7
|
|
||||||
|
|
||||||
If you often use this pattern::
|
If you often use this pattern::
|
||||||
|
|
||||||
from django.contrib.sites.models import Site
|
from django.contrib.sites.models import Site
|
||||||
|
|
|
@ -78,13 +78,6 @@ respectively. For example::
|
||||||
Then set the :setting:`STATICFILES_STORAGE` setting to
|
Then set the :setting:`STATICFILES_STORAGE` setting to
|
||||||
``'path.to.MyStaticFilesStorage'``.
|
``'path.to.MyStaticFilesStorage'``.
|
||||||
|
|
||||||
.. versionadded:: 1.7
|
|
||||||
|
|
||||||
The ability to override ``file_permissions_mode`` and
|
|
||||||
``directory_permissions_mode`` is new in Django 1.7. Previously the file
|
|
||||||
permissions always used :setting:`FILE_UPLOAD_PERMISSIONS` and the directory
|
|
||||||
permissions always used :setting:`FILE_UPLOAD_DIRECTORY_PERMISSIONS`.
|
|
||||||
|
|
||||||
.. highlight:: console
|
.. highlight:: console
|
||||||
|
|
||||||
Some commonly used options are:
|
Some commonly used options are:
|
||||||
|
@ -174,10 +167,6 @@ get all the directories which were searched::
|
||||||
/home/polls.com/core/static
|
/home/polls.com/core/static
|
||||||
/some/other/path/static
|
/some/other/path/static
|
||||||
|
|
||||||
.. versionadded:: 1.7
|
|
||||||
|
|
||||||
The additional output of which directories were searched was added.
|
|
||||||
|
|
||||||
.. _staticfiles-runserver:
|
.. _staticfiles-runserver:
|
||||||
|
|
||||||
runserver
|
runserver
|
||||||
|
@ -244,8 +233,6 @@ counterparts and update the cache appropriately.
|
||||||
ManifestStaticFilesStorage
|
ManifestStaticFilesStorage
|
||||||
--------------------------
|
--------------------------
|
||||||
|
|
||||||
.. versionadded:: 1.7
|
|
||||||
|
|
||||||
.. class:: storage.ManifestStaticFilesStorage
|
.. class:: storage.ManifestStaticFilesStorage
|
||||||
|
|
||||||
A subclass of the :class:`~django.contrib.staticfiles.storage.StaticFilesStorage`
|
A subclass of the :class:`~django.contrib.staticfiles.storage.StaticFilesStorage`
|
||||||
|
@ -370,10 +357,6 @@ of directory paths in which the finders searched. Example usage::
|
||||||
result = finders.find('css/base.css')
|
result = finders.find('css/base.css')
|
||||||
searched_locations = finders.searched_locations
|
searched_locations = finders.searched_locations
|
||||||
|
|
||||||
.. versionadded:: 1.7
|
|
||||||
|
|
||||||
The ``searched_locations`` attribute was added.
|
|
||||||
|
|
||||||
Other Helpers
|
Other Helpers
|
||||||
=============
|
=============
|
||||||
|
|
||||||
|
@ -423,12 +406,6 @@ This view function serves static files in development.
|
||||||
**insecure**. This is only intended for local development, and should
|
**insecure**. This is only intended for local development, and should
|
||||||
**never be used in production**.
|
**never be used in production**.
|
||||||
|
|
||||||
.. versionchanged:: 1.7
|
|
||||||
|
|
||||||
This view will now raise an :exc:`~django.http.Http404` exception instead
|
|
||||||
of :exc:`~django.core.exceptions.ImproperlyConfigured` when
|
|
||||||
:setting:`DEBUG` is ``False``.
|
|
||||||
|
|
||||||
.. note::
|
.. note::
|
||||||
|
|
||||||
To guess the served files' content types, this view relies on the
|
To guess the served files' content types, this view relies on the
|
||||||
|
@ -502,8 +479,3 @@ But given the fact that it makes use of the
|
||||||
transparently overlay at test execution-time the assets provided by the
|
transparently overlay at test execution-time the assets provided by the
|
||||||
``staticfiles`` finders. This means you don't need to run
|
``staticfiles`` finders. This means you don't need to run
|
||||||
:djadmin:`collectstatic` before or as a part of your tests setup.
|
:djadmin:`collectstatic` before or as a part of your tests setup.
|
||||||
|
|
||||||
.. versionadded:: 1.7
|
|
||||||
|
|
||||||
``StaticLiveServerTestCase`` is new in Django 1.7. Previously its
|
|
||||||
functionality was provided by :class:`django.test.LiveServerTestCase`.
|
|
||||||
|
|
|
@ -954,10 +954,6 @@ They share this interface:
|
||||||
:class:`django.utils.feedgenerator.Enclosure`.
|
:class:`django.utils.feedgenerator.Enclosure`.
|
||||||
* ``categories`` should be a sequence of Unicode objects.
|
* ``categories`` should be a sequence of Unicode objects.
|
||||||
|
|
||||||
.. versionadded:: 1.7
|
|
||||||
|
|
||||||
The optional ``updateddate`` argument was added.
|
|
||||||
|
|
||||||
:meth:`.SyndicationFeed.write`
|
:meth:`.SyndicationFeed.write`
|
||||||
Outputs the feed in the given encoding to outfile, which is a file-like object.
|
Outputs the feed in the given encoding to outfile, which is a file-like object.
|
||||||
|
|
||||||
|
|
|
@ -5,11 +5,6 @@ django-admin and manage.py
|
||||||
``django-admin`` is Django's command-line utility for administrative tasks.
|
``django-admin`` is Django's command-line utility for administrative tasks.
|
||||||
This document outlines all it can do.
|
This document outlines all it can do.
|
||||||
|
|
||||||
.. versionchanged:: 1.7
|
|
||||||
|
|
||||||
Prior to Django 1.7, ``django-admin`` was only installed as
|
|
||||||
``django-admin.py``.
|
|
||||||
|
|
||||||
In addition, ``manage.py`` is automatically created in each Django project.
|
In addition, ``manage.py`` is automatically created in each Django project.
|
||||||
``manage.py`` is a thin wrapper around ``django-admin`` that takes care of
|
``manage.py`` is a thin wrapper around ``django-admin`` that takes care of
|
||||||
several things for you before delegating to ``django-admin``:
|
several things for you before delegating to ``django-admin``:
|
||||||
|
@ -21,10 +16,6 @@ several things for you before delegating to ``django-admin``:
|
||||||
|
|
||||||
* It calls :func:`django.setup()` to initialize various internals of Django.
|
* It calls :func:`django.setup()` to initialize various internals of Django.
|
||||||
|
|
||||||
.. versionadded:: 1.7
|
|
||||||
|
|
||||||
:func:`django.setup()` didn't exist in previous versions of Django.
|
|
||||||
|
|
||||||
The ``django-admin`` script should be on your system path if you installed
|
The ``django-admin`` script should be on your system path if you installed
|
||||||
Django via its ``setup.py`` utility. If it's not on your path, you can find it
|
Django via its ``setup.py`` utility. If it's not on your path, you can find it
|
||||||
in ``site-packages/django/bin`` within your Python installation. Consider
|
in ``site-packages/django/bin`` within your Python installation. Consider
|
||||||
|
@ -105,8 +96,6 @@ check <appname appname ...>
|
||||||
|
|
||||||
.. django-admin:: check
|
.. django-admin:: check
|
||||||
|
|
||||||
.. versionchanged:: 1.7
|
|
||||||
|
|
||||||
Uses the :doc:`system check framework </ref/checks>` to inspect
|
Uses the :doc:`system check framework </ref/checks>` to inspect
|
||||||
the entire Django project for common problems.
|
the entire Django project for common problems.
|
||||||
|
|
||||||
|
@ -192,18 +181,13 @@ createcachetable
|
||||||
|
|
||||||
.. django-admin:: createcachetable
|
.. django-admin:: createcachetable
|
||||||
|
|
||||||
Creates the cache tables for use with the database cache backend. See
|
Creates the cache tables for use with the database cache backend using the
|
||||||
:doc:`/topics/cache` for more information.
|
information from your settings file. See :doc:`/topics/cache` for more
|
||||||
|
information.
|
||||||
|
|
||||||
The :djadminopt:`--database` option can be used to specify the database
|
The :djadminopt:`--database` option can be used to specify the database
|
||||||
onto which the cachetable will be installed.
|
onto which the cache table will be installed, but since this information is
|
||||||
|
pulled from your settings by default, it's typically not needed.
|
||||||
.. versionchanged:: 1.7
|
|
||||||
|
|
||||||
It is no longer necessary to provide the cache table name or the
|
|
||||||
:djadminopt:`--database` option. Django takes this information from your
|
|
||||||
settings file. If you have configured multiple caches or multiple databases,
|
|
||||||
all cache tables are created.
|
|
||||||
|
|
||||||
dbshell
|
dbshell
|
||||||
-------
|
-------
|
||||||
|
@ -286,8 +270,6 @@ from which data will be dumped.
|
||||||
|
|
||||||
.. django-admin-option:: --natural-foreign
|
.. django-admin-option:: --natural-foreign
|
||||||
|
|
||||||
.. versionadded:: 1.7
|
|
||||||
|
|
||||||
When this option is specified, Django will use the ``natural_key()`` model
|
When this option is specified, Django will use the ``natural_key()`` model
|
||||||
method to serialize any foreign key and many-to-many relationship to objects of
|
method to serialize any foreign key and many-to-many relationship to objects of
|
||||||
the type that defines the method. If you are dumping ``contrib.auth``
|
the type that defines the method. If you are dumping ``contrib.auth``
|
||||||
|
@ -298,8 +280,6 @@ and the next option.
|
||||||
|
|
||||||
.. django-admin-option:: --natural-primary
|
.. django-admin-option:: --natural-primary
|
||||||
|
|
||||||
.. versionadded:: 1.7
|
|
||||||
|
|
||||||
When this option is specified, Django will not provide the primary key in the
|
When this option is specified, Django will not provide the primary key in the
|
||||||
serialized data of this object since it can be calculated during
|
serialized data of this object since it can be calculated during
|
||||||
deserialization.
|
deserialization.
|
||||||
|
@ -415,10 +395,6 @@ models that may have been removed since the fixture was originally generated.
|
||||||
The :djadminopt:`--app` option can be used to specify a single app to look
|
The :djadminopt:`--app` option can be used to specify a single app to look
|
||||||
for fixtures in rather than looking through all apps.
|
for fixtures in rather than looking through all apps.
|
||||||
|
|
||||||
.. versionchanged:: 1.7
|
|
||||||
|
|
||||||
``--app`` was added.
|
|
||||||
|
|
||||||
.. versionchanged:: 1.8
|
.. versionchanged:: 1.8
|
||||||
|
|
||||||
``--ignorenonexistent`` also ignores non-existent models.
|
``--ignorenonexistent`` also ignores non-existent models.
|
||||||
|
@ -605,12 +581,6 @@ Example usage::
|
||||||
django-admin makemessages -x pt_BR
|
django-admin makemessages -x pt_BR
|
||||||
django-admin makemessages -x pt_BR -x fr
|
django-admin makemessages -x pt_BR -x fr
|
||||||
|
|
||||||
|
|
||||||
.. versionchanged:: 1.7
|
|
||||||
|
|
||||||
Added the ``--previous`` option to the ``msgmerge`` command when merging
|
|
||||||
with existing po files.
|
|
||||||
|
|
||||||
.. django-admin-option:: --domain
|
.. django-admin-option:: --domain
|
||||||
|
|
||||||
Use the ``--domain`` or ``-d`` option to change the domain of the messages files.
|
Use the ``--domain`` or ``-d`` option to change the domain of the messages files.
|
||||||
|
@ -671,8 +641,6 @@ makemigrations [<app_label>]
|
||||||
|
|
||||||
.. django-admin:: makemigrations
|
.. django-admin:: makemigrations
|
||||||
|
|
||||||
.. versionadded:: 1.7
|
|
||||||
|
|
||||||
Creates new migrations based on the changes detected to your models.
|
Creates new migrations based on the changes detected to your models.
|
||||||
Migrations, their relationship with apps and more are covered in depth in
|
Migrations, their relationship with apps and more are covered in depth in
|
||||||
:doc:`the migrations documentation</topics/migrations>`.
|
:doc:`the migrations documentation</topics/migrations>`.
|
||||||
|
@ -722,8 +690,6 @@ migrate [<app_label> [<migrationname>]]
|
||||||
|
|
||||||
.. django-admin:: migrate
|
.. django-admin:: migrate
|
||||||
|
|
||||||
.. versionadded:: 1.7
|
|
||||||
|
|
||||||
Synchronizes the database state with the current set of models and migrations.
|
Synchronizes the database state with the current set of models and migrations.
|
||||||
Migrations, their relationship with apps and more are covered in depth in
|
Migrations, their relationship with apps and more are covered in depth in
|
||||||
:doc:`the migrations documentation</topics/migrations>`.
|
:doc:`the migrations documentation</topics/migrations>`.
|
||||||
|
@ -788,10 +754,6 @@ needed. You don't need to restart the server for code changes to take effect.
|
||||||
However, some actions like adding files don't trigger a restart, so you'll
|
However, some actions like adding files don't trigger a restart, so you'll
|
||||||
have to restart the server in these cases.
|
have to restart the server in these cases.
|
||||||
|
|
||||||
.. versionchanged:: 1.7
|
|
||||||
|
|
||||||
Compiling translation files now also restarts the development server.
|
|
||||||
|
|
||||||
If you are using Linux and install `pyinotify`_, kernel signals will be used to
|
If you are using Linux and install `pyinotify`_, kernel signals will be used to
|
||||||
autoreload the server (rather than polling file modification timestamps each
|
autoreload the server (rather than polling file modification timestamps each
|
||||||
second). This offers better scaling to large projects, reduction in response
|
second). This offers better scaling to large projects, reduction in response
|
||||||
|
@ -800,10 +762,6 @@ reduction.
|
||||||
|
|
||||||
.. _pyinotify: https://pypi.python.org/pypi/pyinotify/
|
.. _pyinotify: https://pypi.python.org/pypi/pyinotify/
|
||||||
|
|
||||||
.. versionadded:: 1.7
|
|
||||||
|
|
||||||
``pyinotify`` support was added.
|
|
||||||
|
|
||||||
When you start the server, and each time you change Python code while the
|
When you start the server, and each time you change Python code while the
|
||||||
server is running, the server will check your entire Django project for errors (see
|
server is running, the server will check your entire Django project for errors (see
|
||||||
the :djadmin:`check` command). If any errors are found, they will be printed
|
the :djadmin:`check` command). If any errors are found, they will be printed
|
||||||
|
@ -1468,8 +1426,6 @@ that ``django-admin`` should print to the console.
|
||||||
|
|
||||||
.. django-admin-option:: --no-color
|
.. django-admin-option:: --no-color
|
||||||
|
|
||||||
.. versionadded:: 1.7
|
|
||||||
|
|
||||||
Example usage::
|
Example usage::
|
||||||
|
|
||||||
django-admin sqlall --no-color
|
django-admin sqlall --no-color
|
||||||
|
@ -1620,12 +1576,6 @@ would specify the use of all the colors in the light color palette,
|
||||||
*except* for the colors for errors and notices which would be
|
*except* for the colors for errors and notices which would be
|
||||||
overridden as specified.
|
overridden as specified.
|
||||||
|
|
||||||
.. versionadded:: 1.7
|
|
||||||
|
|
||||||
Support for color-coded output from ``django-admin`` / ``manage.py``
|
|
||||||
utilities on Windows by relying on the ANSICON application was added in Django
|
|
||||||
1.7.
|
|
||||||
|
|
||||||
.. _ANSICON: http://adoxa.altervista.org/ansicon/
|
.. _ANSICON: http://adoxa.altervista.org/ansicon/
|
||||||
|
|
||||||
Bash completion
|
Bash completion
|
||||||
|
@ -1641,10 +1591,8 @@ distribution. It enables tab-completion of ``django-admin`` and
|
||||||
* Type ``sql``, then [TAB], to see all available options whose names start
|
* Type ``sql``, then [TAB], to see all available options whose names start
|
||||||
with ``sql``.
|
with ``sql``.
|
||||||
|
|
||||||
|
|
||||||
See :doc:`/howto/custom-management-commands` for how to add customized actions.
|
See :doc:`/howto/custom-management-commands` for how to add customized actions.
|
||||||
|
|
||||||
|
|
||||||
==========================================
|
==========================================
|
||||||
Running management commands from your code
|
Running management commands from your code
|
||||||
==========================================
|
==========================================
|
||||||
|
|
|
@ -51,22 +51,11 @@ The FileSystemStorage Class
|
||||||
The file system permissions that the file will receive when it is
|
The file system permissions that the file will receive when it is
|
||||||
saved. Defaults to :setting:`FILE_UPLOAD_PERMISSIONS`.
|
saved. Defaults to :setting:`FILE_UPLOAD_PERMISSIONS`.
|
||||||
|
|
||||||
.. versionadded:: 1.7
|
|
||||||
|
|
||||||
The ``file_permissions_mode`` attribute was added. Previously files
|
|
||||||
always received :setting:`FILE_UPLOAD_PERMISSIONS` permissions.
|
|
||||||
|
|
||||||
.. attribute:: directory_permissions_mode
|
.. attribute:: directory_permissions_mode
|
||||||
|
|
||||||
The file system permissions that the directory will receive when it is
|
The file system permissions that the directory will receive when it is
|
||||||
saved. Defaults to :setting:`FILE_UPLOAD_DIRECTORY_PERMISSIONS`.
|
saved. Defaults to :setting:`FILE_UPLOAD_DIRECTORY_PERMISSIONS`.
|
||||||
|
|
||||||
.. versionadded:: 1.7
|
|
||||||
|
|
||||||
The ``directory_permissions_mode`` attribute was added. Previously
|
|
||||||
directories always received
|
|
||||||
:setting:`FILE_UPLOAD_DIRECTORY_PERMISSIONS` permissions.
|
|
||||||
|
|
||||||
.. note::
|
.. note::
|
||||||
|
|
||||||
The ``FileSystemStorage.delete()`` method will not raise
|
The ``FileSystemStorage.delete()`` method will not raise
|
||||||
|
@ -129,15 +118,6 @@ The Storage Class
|
||||||
7 character alphanumeric string is appended to the filename before
|
7 character alphanumeric string is appended to the filename before
|
||||||
the extension.
|
the extension.
|
||||||
|
|
||||||
.. versionchanged:: 1.7
|
|
||||||
|
|
||||||
Previously, an underscore followed by a number (e.g. ``"_1"``,
|
|
||||||
``"_2"``, etc.) was appended to the filename until an available
|
|
||||||
name in the destination directory was found. A malicious user could
|
|
||||||
exploit this deterministic algorithm to create a denial-of-service
|
|
||||||
attack. This change was also made in Django 1.6.6, 1.5.9, and
|
|
||||||
1.4.14.
|
|
||||||
|
|
||||||
.. versionchanged:: 1.8
|
.. versionchanged:: 1.8
|
||||||
|
|
||||||
The ``max_length`` argument was added.
|
The ``max_length`` argument was added.
|
||||||
|
|
|
@ -57,8 +57,6 @@ Here are some useful attributes of ``UploadedFile``:
|
||||||
|
|
||||||
.. attribute:: UploadedFile.content_type_extra
|
.. attribute:: UploadedFile.content_type_extra
|
||||||
|
|
||||||
.. versionadded:: 1.7
|
|
||||||
|
|
||||||
A dictionary containing extra parameters passed to the ``content-type``
|
A dictionary containing extra parameters passed to the ``content-type``
|
||||||
header. This is typically provided by services, such as Google App Engine,
|
header. This is typically provided by services, such as Google App Engine,
|
||||||
that intercept and handle file uploads on your behalf. As a result your
|
that intercept and handle file uploads on your behalf. As a result your
|
||||||
|
@ -220,10 +218,6 @@ attributes:
|
||||||
This method may raise a ``StopFutureHandlers`` exception to prevent
|
This method may raise a ``StopFutureHandlers`` exception to prevent
|
||||||
future handlers from handling this file.
|
future handlers from handling this file.
|
||||||
|
|
||||||
.. versionadded:: 1.7
|
|
||||||
|
|
||||||
The ``content_type_extra`` parameter was added.
|
|
||||||
|
|
||||||
.. method:: FileUploadHandler.upload_complete()
|
.. method:: FileUploadHandler.upload_complete()
|
||||||
|
|
||||||
Callback signaling that the entire upload (all files) has completed.
|
Callback signaling that the entire upload (all files) has completed.
|
||||||
|
|
|
@ -125,8 +125,6 @@ if validation has side effects, those side effects will only be triggered once.
|
||||||
|
|
||||||
.. method:: Form.errors.as_data()
|
.. method:: Form.errors.as_data()
|
||||||
|
|
||||||
.. versionadded:: 1.7
|
|
||||||
|
|
||||||
Returns a ``dict`` that maps fields to their original ``ValidationError``
|
Returns a ``dict`` that maps fields to their original ``ValidationError``
|
||||||
instances.
|
instances.
|
||||||
|
|
||||||
|
@ -150,8 +148,6 @@ messages in ``Form.errors``.
|
||||||
|
|
||||||
.. method:: Form.errors.as_json(escape_html=False)
|
.. method:: Form.errors.as_json(escape_html=False)
|
||||||
|
|
||||||
.. versionadded:: 1.7
|
|
||||||
|
|
||||||
Returns the errors serialized as JSON.
|
Returns the errors serialized as JSON.
|
||||||
|
|
||||||
>>> f.errors.as_json()
|
>>> f.errors.as_json()
|
||||||
|
@ -171,8 +167,6 @@ directly in HTML.
|
||||||
|
|
||||||
.. method:: Form.add_error(field, error)
|
.. method:: Form.add_error(field, error)
|
||||||
|
|
||||||
.. versionadded:: 1.7
|
|
||||||
|
|
||||||
This method allows adding errors to specific fields from within the
|
This method allows adding errors to specific fields from within the
|
||||||
``Form.clean()`` method, or from outside the form altogether; for instance
|
``Form.clean()`` method, or from outside the form altogether; for instance
|
||||||
from a view.
|
from a view.
|
||||||
|
@ -762,10 +756,6 @@ Python 2)::
|
||||||
<p>Sender: <input type="email" name="sender" value="invalid email address" /></p>
|
<p>Sender: <input type="email" name="sender" value="invalid email address" /></p>
|
||||||
<p>Cc myself: <input checked="checked" type="checkbox" name="cc_myself" /></p>
|
<p>Cc myself: <input checked="checked" type="checkbox" name="cc_myself" /></p>
|
||||||
|
|
||||||
.. versionchanged:: 1.7
|
|
||||||
|
|
||||||
``django.forms.util`` was renamed to ``django.forms.utils``.
|
|
||||||
|
|
||||||
More granular output
|
More granular output
|
||||||
~~~~~~~~~~~~~~~~~~~~
|
~~~~~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
|
@ -1017,10 +1007,8 @@ classes::
|
||||||
<li>Instrument: <input type="text" name="instrument" /></li>
|
<li>Instrument: <input type="text" name="instrument" /></li>
|
||||||
<li>Haircut type: <input type="text" name="haircut_type" /></li>
|
<li>Haircut type: <input type="text" name="haircut_type" /></li>
|
||||||
|
|
||||||
.. versionadded:: 1.7
|
It's possible to declaratively remove a ``Field`` inherited from a parent class
|
||||||
|
by setting the name to be ``None`` on the subclass. For example::
|
||||||
* It's possible to declaratively remove a ``Field`` inherited from a parent
|
|
||||||
class by setting the name to be ``None`` on the subclass. For example::
|
|
||||||
|
|
||||||
>>> from django import forms
|
>>> from django import forms
|
||||||
|
|
||||||
|
|
|
@ -970,8 +970,6 @@ Slightly complex built-in ``Field`` classes
|
||||||
|
|
||||||
.. attribute:: require_all_fields
|
.. attribute:: require_all_fields
|
||||||
|
|
||||||
.. versionadded:: 1.7
|
|
||||||
|
|
||||||
Defaults to ``True``, in which case a ``required`` validation error
|
Defaults to ``True``, in which case a ``required`` validation error
|
||||||
will be raised if no value is supplied for any field.
|
will be raised if no value is supplied for any field.
|
||||||
|
|
||||||
|
|
|
@ -13,7 +13,3 @@ Formset API reference. For introductory material about formsets, see the
|
||||||
Returns a ``FormSet`` class for the given ``form`` class.
|
Returns a ``FormSet`` class for the given ``form`` class.
|
||||||
|
|
||||||
See :ref:`formsets` for example usage.
|
See :ref:`formsets` for example usage.
|
||||||
|
|
||||||
.. versionchanged:: 1.7
|
|
||||||
|
|
||||||
The ``min_num`` and ``validate_min`` parameters were added.
|
|
||||||
|
|
|
@ -179,8 +179,6 @@ to override your error message you can still opt for the less verbose::
|
||||||
|
|
||||||
ValidationError(_('Invalid value: %s') % value)
|
ValidationError(_('Invalid value: %s') % value)
|
||||||
|
|
||||||
.. versionadded:: 1.7
|
|
||||||
|
|
||||||
The :meth:`Form.errors.as_data() <django.forms.Form.errors.as_data()>` and
|
The :meth:`Form.errors.as_data() <django.forms.Form.errors.as_data()>` and
|
||||||
:meth:`Form.errors.as_json() <django.forms.Form.errors.as_json()>` methods
|
:meth:`Form.errors.as_json() <django.forms.Form.errors.as_json()>` methods
|
||||||
greatly benefit from fully featured ``ValidationError``\s (with a ``code`` name
|
greatly benefit from fully featured ``ValidationError``\s (with a ``code`` name
|
||||||
|
@ -369,12 +367,6 @@ example::
|
||||||
raise forms.ValidationError("Did not send for 'help' in "
|
raise forms.ValidationError("Did not send for 'help' in "
|
||||||
"the subject despite CC'ing yourself.")
|
"the subject despite CC'ing yourself.")
|
||||||
|
|
||||||
.. versionchanged:: 1.7
|
|
||||||
|
|
||||||
In previous versions of Django, ``form.clean()`` was required to return
|
|
||||||
a dictionary of ``cleaned_data``. This method may still return a dictionary
|
|
||||||
of data to be used, but it's no longer required.
|
|
||||||
|
|
||||||
In this code, if the validation error is raised, the form will display an
|
In this code, if the validation error is raised, the form will display an
|
||||||
error message at the top of the form (normally) describing the problem.
|
error message at the top of the form (normally) describing the problem.
|
||||||
|
|
||||||
|
|
|
@ -650,8 +650,6 @@ Selector and checkbox widgets
|
||||||
The outer ``<ul>`` container will receive the ``id`` attribute defined on
|
The outer ``<ul>`` container will receive the ``id`` attribute defined on
|
||||||
the widget.
|
the widget.
|
||||||
|
|
||||||
.. versionchanged:: 1.7
|
|
||||||
|
|
||||||
When looping over the radio buttons, the ``label`` and ``input`` tags include
|
When looping over the radio buttons, the ``label`` and ``input`` tags include
|
||||||
``for`` and ``id`` attributes, respectively. Each radio button has an
|
``for`` and ``id`` attributes, respectively. Each radio button has an
|
||||||
``id_for_label`` attribute to output the element's ID.
|
``id_for_label`` attribute to output the element's ID.
|
||||||
|
@ -677,11 +675,9 @@ Selector and checkbox widgets
|
||||||
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.
|
||||||
|
|
||||||
.. versionchanged:: 1.7
|
When looping over the checkboxes, the ``label`` and ``input`` tags include
|
||||||
|
``for`` and ``id`` attributes, respectively. Each checkbox has an
|
||||||
When looping over the checkboxes, the ``label`` and ``input`` tags include
|
``id_for_label`` attribute to output the element's ID.
|
||||||
``for`` and ``id`` attributes, respectively. Each checkbox has an
|
|
||||||
``id_for_label`` attribute to output the element's ID.
|
|
||||||
|
|
||||||
.. _file-upload-widgets:
|
.. _file-upload-widgets:
|
||||||
|
|
||||||
|
@ -769,8 +765,6 @@ Composite widgets
|
||||||
|
|
||||||
.. attribute:: SelectDateWidget.months
|
.. attribute:: SelectDateWidget.months
|
||||||
|
|
||||||
.. versionadded:: 1.7
|
|
||||||
|
|
||||||
An optional dict of months to use in the "months" select box.
|
An optional dict of months to use in the "months" select box.
|
||||||
|
|
||||||
The keys of the dict correspond to the month number (1-indexed) and
|
The keys of the dict correspond to the month number (1-indexed) and
|
||||||
|
|
|
@ -354,8 +354,6 @@ Site middleware
|
||||||
|
|
||||||
.. class:: CurrentSiteMiddleware
|
.. class:: CurrentSiteMiddleware
|
||||||
|
|
||||||
.. versionadded:: 1.7
|
|
||||||
|
|
||||||
Adds the ``site`` attribute representing the current site to every incoming
|
Adds the ``site`` attribute representing the current site to every incoming
|
||||||
``HttpRequest`` object. See the :ref:`sites documentation <site-middleware>`.
|
``HttpRequest`` object. See the :ref:`sites documentation <site-middleware>`.
|
||||||
|
|
||||||
|
@ -378,8 +376,6 @@ Middleware for utilizing Web server provided authentication. See
|
||||||
|
|
||||||
.. class:: SessionAuthenticationMiddleware
|
.. class:: SessionAuthenticationMiddleware
|
||||||
|
|
||||||
.. versionadded:: 1.7
|
|
||||||
|
|
||||||
Allows a user's sessions to be invalidated when their password changes. See
|
Allows a user's sessions to be invalidated when their password changes. See
|
||||||
:ref:`session-invalidation-on-password-change` for details. This middleware must
|
:ref:`session-invalidation-on-password-change` for details. This middleware must
|
||||||
appear after :class:`django.contrib.auth.middleware.AuthenticationMiddleware`
|
appear after :class:`django.contrib.auth.middleware.AuthenticationMiddleware`
|
||||||
|
|
|
@ -188,10 +188,6 @@ Note that not all changes are possible on all databases - for example, you
|
||||||
cannot change a text-type field like ``models.TextField()`` into a number-type
|
cannot change a text-type field like ``models.TextField()`` into a number-type
|
||||||
field like ``models.IntegerField()`` on most databases.
|
field like ``models.IntegerField()`` on most databases.
|
||||||
|
|
||||||
.. versionchanged:: 1.7.1
|
|
||||||
|
|
||||||
The ``preserve_default`` argument was added.
|
|
||||||
|
|
||||||
RenameField
|
RenameField
|
||||||
-----------
|
-----------
|
||||||
|
|
||||||
|
@ -240,11 +236,6 @@ The optional ``hints`` argument will be passed as ``**hints`` to the
|
||||||
routing decisions. See :ref:`topics-db-multi-db-hints` for more details on
|
routing decisions. See :ref:`topics-db-multi-db-hints` for more details on
|
||||||
database hints.
|
database hints.
|
||||||
|
|
||||||
.. versionchanged:: 1.7.1
|
|
||||||
|
|
||||||
If you want to include literal percent signs in a query without parameters
|
|
||||||
you don't need to double them anymore.
|
|
||||||
|
|
||||||
.. versionchanged:: 1.8
|
.. versionchanged:: 1.8
|
||||||
|
|
||||||
The ability to pass parameters to the ``sql`` and ``reverse_sql`` queries
|
The ability to pass parameters to the ``sql`` and ``reverse_sql`` queries
|
||||||
|
|
|
@ -17,10 +17,6 @@ Django supports addition, subtraction, multiplication, division, modulo
|
||||||
arithmetic, and the power operator on query expressions, using Python constants,
|
arithmetic, and the power operator on query expressions, using Python constants,
|
||||||
variables, and even other expressions.
|
variables, and even other expressions.
|
||||||
|
|
||||||
.. versionadded:: 1.7
|
|
||||||
|
|
||||||
Support for the power operator ``**`` was added.
|
|
||||||
|
|
||||||
Some examples
|
Some examples
|
||||||
=============
|
=============
|
||||||
|
|
||||||
|
|
|
@ -156,8 +156,6 @@ This lets you construct choices dynamically. But if you find yourself hacking
|
||||||
database table with a :class:`ForeignKey`. :attr:`~Field.choices` is meant for
|
database table with a :class:`ForeignKey`. :attr:`~Field.choices` is meant for
|
||||||
static data that doesn't change much, if ever.
|
static data that doesn't change much, if ever.
|
||||||
|
|
||||||
.. versionadded:: 1.7
|
|
||||||
|
|
||||||
Unless :attr:`blank=False<Field.blank>` is set on the field along with a
|
Unless :attr:`blank=False<Field.blank>` is set on the field along with a
|
||||||
:attr:`~Field.default` then a label containing ``"---------"`` will be rendered
|
:attr:`~Field.default` then a label containing ``"---------"`` will be rendered
|
||||||
with the select box. To override this behavior, add a tuple to ``choices``
|
with the select box. To override this behavior, add a tuple to ``choices``
|
||||||
|
@ -241,10 +239,6 @@ Error message keys include ``null``, ``blank``, ``invalid``, ``invalid_choice``,
|
||||||
``unique``, and ``unique_for_date``. Additional error message keys are
|
``unique``, and ``unique_for_date``. Additional error message keys are
|
||||||
specified for each field in the `Field types`_ section below.
|
specified for each field in the `Field types`_ section below.
|
||||||
|
|
||||||
.. versionadded:: 1.7
|
|
||||||
|
|
||||||
The ``unique_for_date`` error message key was added.
|
|
||||||
|
|
||||||
``help_text``
|
``help_text``
|
||||||
-------------
|
-------------
|
||||||
|
|
||||||
|
@ -592,10 +586,6 @@ Has two optional arguments:
|
||||||
|
|
||||||
.. attribute:: FileField.upload_to
|
.. attribute:: FileField.upload_to
|
||||||
|
|
||||||
.. versionchanged:: 1.7
|
|
||||||
|
|
||||||
``upload_to`` was required in older versions of Django.
|
|
||||||
|
|
||||||
A local filesystem path that will be appended to your :setting:`MEDIA_ROOT`
|
A local filesystem path that will be appended to your :setting:`MEDIA_ROOT`
|
||||||
setting to determine the value of the
|
setting to determine the value of the
|
||||||
:attr:`~django.db.models.fields.files.FieldFile.url` attribute.
|
:attr:`~django.db.models.fields.files.FieldFile.url` attribute.
|
||||||
|
@ -987,12 +977,10 @@ databases supported by Django.
|
||||||
A large text field. The default form widget for this field is a
|
A large text field. The default form widget for this field is a
|
||||||
:class:`~django.forms.Textarea`.
|
:class:`~django.forms.Textarea`.
|
||||||
|
|
||||||
.. versionchanged:: 1.7
|
If you specify a ``max_length`` attribute, it will be reflected in the
|
||||||
|
:class:`~django.forms.Textarea` widget of the auto-generated form field.
|
||||||
If you specify a ``max_length`` attribute, it will be reflected in the
|
However it is not enforced at the model or database level. Use a
|
||||||
:class:`~django.forms.Textarea` widget of the auto-generated form field.
|
:class:`CharField` for that.
|
||||||
However it is not enforced at the model or database level. Use a
|
|
||||||
:class:`CharField` for that.
|
|
||||||
|
|
||||||
.. admonition:: MySQL users
|
.. admonition:: MySQL users
|
||||||
|
|
||||||
|
@ -1156,11 +1144,6 @@ define the details of how the relation works.
|
||||||
:attr:`~django.contrib.admin.ModelAdmin.raw_id_fields` in the
|
:attr:`~django.contrib.admin.ModelAdmin.raw_id_fields` in the
|
||||||
``ModelAdmin`` for the model.
|
``ModelAdmin`` for the model.
|
||||||
|
|
||||||
.. versionchanged:: 1.7
|
|
||||||
|
|
||||||
Previous versions of Django do not allow passing a callable as a value
|
|
||||||
for ``limit_choices_to``.
|
|
||||||
|
|
||||||
.. note::
|
.. note::
|
||||||
|
|
||||||
If a callable is used for ``limit_choices_to``, it will be invoked
|
If a callable is used for ``limit_choices_to``, it will be invoked
|
||||||
|
@ -1280,8 +1263,6 @@ The possible values for :attr:`~ForeignKey.on_delete` are found in
|
||||||
|
|
||||||
.. attribute:: ForeignKey.swappable
|
.. attribute:: ForeignKey.swappable
|
||||||
|
|
||||||
.. versionadded:: 1.7
|
|
||||||
|
|
||||||
Controls the migration framework's reaction if this :class:`ForeignKey`
|
Controls the migration framework's reaction if this :class:`ForeignKey`
|
||||||
is pointing at a swappable model. If it is ``True`` - the default -
|
is pointing at a swappable model. If it is ``True`` - the default -
|
||||||
then if the :class:`ForeignKey` is pointing at a model which matches
|
then if the :class:`ForeignKey` is pointing at a model which matches
|
||||||
|
@ -1400,8 +1381,6 @@ that control how the relationship functions.
|
||||||
|
|
||||||
.. attribute:: ManyToManyField.through_fields
|
.. attribute:: ManyToManyField.through_fields
|
||||||
|
|
||||||
.. versionadded:: 1.7
|
|
||||||
|
|
||||||
Only used when a custom intermediary model is specified. Django will
|
Only used when a custom intermediary model is specified. Django will
|
||||||
normally determine which fields of the intermediary model to use in order
|
normally determine which fields of the intermediary model to use in order
|
||||||
to establish a many-to-many relationship automatically. However,
|
to establish a many-to-many relationship automatically. However,
|
||||||
|
@ -1470,8 +1449,6 @@ that control how the relationship functions.
|
||||||
|
|
||||||
.. attribute:: ManyToManyField.swappable
|
.. attribute:: ManyToManyField.swappable
|
||||||
|
|
||||||
.. versionadded:: 1.7
|
|
||||||
|
|
||||||
Controls the migration framework's reaction if this :class:`ManyToManyField`
|
Controls the migration framework's reaction if this :class:`ManyToManyField`
|
||||||
is pointing at a swappable model. If it is ``True`` - the default -
|
is pointing at a swappable model. If it is ``True`` - the default -
|
||||||
then if the :class:`ManyToManyField` is pointing at a model which matches
|
then if the :class:`ManyToManyField` is pointing at a model which matches
|
||||||
|
@ -1699,8 +1676,6 @@ Field API reference
|
||||||
``"year"``, ``"month"``, ``"day"``, ``"isnull"``, ``"search"``,
|
``"year"``, ``"month"``, ``"day"``, ``"isnull"``, ``"search"``,
|
||||||
``"regex"``, and ``"iregex"``.
|
``"regex"``, and ``"iregex"``.
|
||||||
|
|
||||||
.. versionadded:: 1.7
|
|
||||||
|
|
||||||
If you are using :doc:`Custom lookups </ref/models/lookups>` the
|
If you are using :doc:`Custom lookups </ref/models/lookups>` the
|
||||||
``lookup_type`` can be any ``lookup_name`` registered in the field.
|
``lookup_type`` can be any ``lookup_name`` registered in the field.
|
||||||
|
|
||||||
|
@ -1752,8 +1727,6 @@ Field API reference
|
||||||
|
|
||||||
.. method:: deconstruct()
|
.. method:: deconstruct()
|
||||||
|
|
||||||
.. versionadded:: 1.7
|
|
||||||
|
|
||||||
Returns a 4-tuple with enough information to recreate the field:
|
Returns a 4-tuple with enough information to recreate the field:
|
||||||
|
|
||||||
1. The name of the field on the model.
|
1. The name of the field on the model.
|
||||||
|
|
|
@ -683,11 +683,6 @@ For example::
|
||||||
MyModel(id=1) != MultitableInherited(id=1)
|
MyModel(id=1) != MultitableInherited(id=1)
|
||||||
MyModel(id=1) != MyModel(id=2)
|
MyModel(id=1) != MyModel(id=2)
|
||||||
|
|
||||||
.. versionchanged:: 1.7
|
|
||||||
|
|
||||||
In previous versions only instances of the exact same class and same
|
|
||||||
primary key value were considered equal.
|
|
||||||
|
|
||||||
``__hash__``
|
``__hash__``
|
||||||
------------
|
------------
|
||||||
|
|
||||||
|
@ -700,11 +695,6 @@ method would return different values before and after the instance is
|
||||||
saved, but changing the ``__hash__`` value of an instance `is forbidden
|
saved, but changing the ``__hash__`` value of an instance `is forbidden
|
||||||
in Python`_).
|
in Python`_).
|
||||||
|
|
||||||
.. versionchanged:: 1.7
|
|
||||||
|
|
||||||
In previous versions instance's without primary key value were
|
|
||||||
hashable.
|
|
||||||
|
|
||||||
.. _is forbidden in Python: https://docs.python.org/reference/datamodel.html#object.__hash__
|
.. _is forbidden in Python: https://docs.python.org/reference/datamodel.html#object.__hash__
|
||||||
|
|
||||||
``get_absolute_url``
|
``get_absolute_url``
|
||||||
|
|
|
@ -7,8 +7,6 @@ Lookup API reference
|
||||||
|
|
||||||
.. currentmodule:: django.db.models
|
.. currentmodule:: django.db.models
|
||||||
|
|
||||||
.. versionadded:: 1.7
|
|
||||||
|
|
||||||
This document has the API references of lookups, the Django API for building
|
This document has the API references of lookups, the Django API for building
|
||||||
the ``WHERE`` clause of a database query. To learn how to *use* lookups, see
|
the ``WHERE`` clause of a database query. To learn how to *use* lookups, see
|
||||||
:doc:`/topics/db/queries`; to learn how to *create* new lookups, see
|
:doc:`/topics/db/queries`; to learn how to *create* new lookups, see
|
||||||
|
|
|
@ -24,17 +24,12 @@ Available ``Meta`` options
|
||||||
|
|
||||||
.. attribute:: Options.app_label
|
.. attribute:: Options.app_label
|
||||||
|
|
||||||
If a model exists outside of the standard locations (:file:`models.py` or
|
If a model exists outside of an application in :setting:`INSTALLED_APPS` or
|
||||||
a ``models`` package in an app), the model must define which app it is part
|
if it's imported before its application was loaded, it must define which
|
||||||
of::
|
app it is part of::
|
||||||
|
|
||||||
app_label = 'myapp'
|
app_label = 'myapp'
|
||||||
|
|
||||||
.. versionadded:: 1.7
|
|
||||||
|
|
||||||
``app_label`` is no longer required for models that are defined
|
|
||||||
outside the ``models`` module of an application.
|
|
||||||
|
|
||||||
``db_table``
|
``db_table``
|
||||||
------------
|
------------
|
||||||
|
|
||||||
|
@ -275,8 +270,6 @@ Django quotes column and table names behind the scenes.
|
||||||
|
|
||||||
.. attribute:: Options.default_permissions
|
.. attribute:: Options.default_permissions
|
||||||
|
|
||||||
.. versionadded:: 1.7
|
|
||||||
|
|
||||||
Defaults to ``('add', 'change', 'delete')``. You may customize this list,
|
Defaults to ``('add', 'change', 'delete')``. You may customize this list,
|
||||||
for example, by setting this to an empty list if your app doesn't require
|
for example, by setting this to an empty list if your app doesn't require
|
||||||
any of the default permissions. It must be specified on the model before
|
any of the default permissions. It must be specified on the model before
|
||||||
|
@ -336,10 +329,8 @@ Django quotes column and table names behind the scenes.
|
||||||
:class:`~django.db.models.ManyToManyField`, try using a signal or
|
:class:`~django.db.models.ManyToManyField`, try using a signal or
|
||||||
an explicit :attr:`through <ManyToManyField.through>` model.
|
an explicit :attr:`through <ManyToManyField.through>` model.
|
||||||
|
|
||||||
.. versionchanged:: 1.7
|
The ``ValidationError`` raised during model validation when the constraint
|
||||||
|
is violated has the ``unique_together`` error code.
|
||||||
The ``ValidationError`` raised during model validation when the
|
|
||||||
constraint is violated has the ``unique_together`` error code.
|
|
||||||
|
|
||||||
``index_together``
|
``index_together``
|
||||||
------------------
|
------------------
|
||||||
|
@ -355,8 +346,6 @@ Django quotes column and table names behind the scenes.
|
||||||
This list of fields will be indexed together (i.e. the appropriate
|
This list of fields will be indexed together (i.e. the appropriate
|
||||||
``CREATE INDEX`` statement will be issued.)
|
``CREATE INDEX`` statement will be issued.)
|
||||||
|
|
||||||
.. versionchanged:: 1.7
|
|
||||||
|
|
||||||
For convenience, ``index_together`` can be a single list when dealing with a single
|
For convenience, ``index_together`` can be a single list when dealing with a single
|
||||||
set of fields::
|
set of fields::
|
||||||
|
|
||||||
|
|
|
@ -329,11 +329,6 @@ the cost of a JOIN, by referring to the ``_id`` of the related field::
|
||||||
# Join
|
# Join
|
||||||
Entry.objects.order_by('blog__id')
|
Entry.objects.order_by('blog__id')
|
||||||
|
|
||||||
.. versionadded:: 1.7
|
|
||||||
|
|
||||||
The ability to order a queryset by a related field, without incurring
|
|
||||||
the cost of a JOIN was added.
|
|
||||||
|
|
||||||
You can also order by :doc:`query expressions </ref/models/expressions>` by
|
You can also order by :doc:`query expressions </ref/models/expressions>` by
|
||||||
calling ``asc()`` or ``desc()`` on the expression::
|
calling ``asc()`` or ``desc()`` on the expression::
|
||||||
|
|
||||||
|
@ -579,12 +574,6 @@ A few subtleties that are worth mentioning:
|
||||||
* Calling :meth:`only()` and :meth:`defer()` after ``values()`` doesn't make
|
* Calling :meth:`only()` and :meth:`defer()` after ``values()`` doesn't make
|
||||||
sense, so doing so will raise a ``NotImplementedError``.
|
sense, so doing so will raise a ``NotImplementedError``.
|
||||||
|
|
||||||
.. versionadded:: 1.7
|
|
||||||
|
|
||||||
The last point above is new. Previously, calling :meth:`only()` and
|
|
||||||
:meth:`defer()` after ``values()`` was allowed, but it either crashed or
|
|
||||||
returned incorrect results.
|
|
||||||
|
|
||||||
It is useful when you know you're only going to need values from a small number
|
It is useful when you know you're only going to need values from a small number
|
||||||
of the available fields and you won't need the functionality of a model
|
of the available fields and you won't need the functionality of a model
|
||||||
instance object. It's more efficient to select only the fields you need to use.
|
instance object. It's more efficient to select only the fields you need to use.
|
||||||
|
@ -856,11 +845,6 @@ Chaining ``select_related`` calls works in a similar way to other methods -
|
||||||
that is that ``select_related('foo', 'bar')`` is equivalent to
|
that is that ``select_related('foo', 'bar')`` is equivalent to
|
||||||
``select_related('foo').select_related('bar')``.
|
``select_related('foo').select_related('bar')``.
|
||||||
|
|
||||||
.. versionchanged:: 1.7
|
|
||||||
|
|
||||||
Previously the latter would have been equivalent to
|
|
||||||
``select_related('bar')``.
|
|
||||||
|
|
||||||
prefetch_related
|
prefetch_related
|
||||||
~~~~~~~~~~~~~~~~
|
~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
|
@ -1011,8 +995,6 @@ profile for your use case!
|
||||||
Note that if you use ``iterator()`` to run the query, ``prefetch_related()``
|
Note that if you use ``iterator()`` to run the query, ``prefetch_related()``
|
||||||
calls will be ignored since these two optimizations do not make sense together.
|
calls will be ignored since these two optimizations do not make sense together.
|
||||||
|
|
||||||
.. versionadded:: 1.7
|
|
||||||
|
|
||||||
You can use the :class:`~django.db.models.Prefetch` object to further control
|
You can use the :class:`~django.db.models.Prefetch` object to further control
|
||||||
the prefetch operation.
|
the prefetch operation.
|
||||||
|
|
||||||
|
@ -1483,11 +1465,6 @@ a transaction outside of one.
|
||||||
Using ``select_for_update()`` on backends which do not support
|
Using ``select_for_update()`` on backends which do not support
|
||||||
``SELECT ... FOR UPDATE`` (such as SQLite) will have no effect.
|
``SELECT ... FOR UPDATE`` (such as SQLite) will have no effect.
|
||||||
|
|
||||||
.. versionchanged:: 1.6.3
|
|
||||||
|
|
||||||
It is now an error to execute a query with ``select_for_update()`` in
|
|
||||||
autocommit mode. With earlier releases in the 1.6 series it was a no-op.
|
|
||||||
|
|
||||||
.. warning::
|
.. warning::
|
||||||
|
|
||||||
Although ``select_for_update()`` normally fails in autocommit mode, since
|
Although ``select_for_update()`` normally fails in autocommit mode, since
|
||||||
|
@ -1503,11 +1480,6 @@ raw
|
||||||
|
|
||||||
.. method:: raw(raw_query, params=None, translations=None)
|
.. method:: raw(raw_query, params=None, translations=None)
|
||||||
|
|
||||||
.. versionchanged:: 1.7
|
|
||||||
|
|
||||||
``raw`` was moved to the ``QuerySet`` class. It was previously only on
|
|
||||||
:class:`~django.db.models.Manager`.
|
|
||||||
|
|
||||||
Takes a raw SQL query, executes it, and returns a
|
Takes a raw SQL query, executes it, and returns a
|
||||||
``django.db.models.query.RawQuerySet`` instance. This ``RawQuerySet`` instance
|
``django.db.models.query.RawQuerySet`` instance. This ``RawQuerySet`` instance
|
||||||
can be iterated over just like an normal ``QuerySet`` to provide object instances.
|
can be iterated over just like an normal ``QuerySet`` to provide object instances.
|
||||||
|
@ -1703,8 +1675,6 @@ update_or_create
|
||||||
|
|
||||||
.. method:: update_or_create(defaults=None, **kwargs)
|
.. method:: update_or_create(defaults=None, **kwargs)
|
||||||
|
|
||||||
.. versionadded:: 1.7
|
|
||||||
|
|
||||||
A convenience method for updating an object with the given ``kwargs``, creating
|
A convenience method for updating an object with the given ``kwargs``, creating
|
||||||
a new one if necessary. The ``defaults`` is a dictionary of (field, value)
|
a new one if necessary. The ``defaults`` is a dictionary of (field, value)
|
||||||
pairs used to update the object.
|
pairs used to update the object.
|
||||||
|
@ -2119,8 +2089,6 @@ as_manager
|
||||||
|
|
||||||
.. classmethod:: as_manager()
|
.. classmethod:: as_manager()
|
||||||
|
|
||||||
.. versionadded:: 1.7
|
|
||||||
|
|
||||||
Class method that returns an instance of :class:`~django.db.models.Manager`
|
Class method that returns an instance of :class:`~django.db.models.Manager`
|
||||||
with a copy of the ``QuerySet``’s methods. See
|
with a copy of the ``QuerySet``’s methods. See
|
||||||
:ref:`create-manager-with-queryset-methods` for more details.
|
:ref:`create-manager-with-queryset-methods` for more details.
|
||||||
|
@ -2175,12 +2143,9 @@ SQL equivalents::
|
||||||
iexact
|
iexact
|
||||||
~~~~~~
|
~~~~~~
|
||||||
|
|
||||||
Case-insensitive exact match.
|
Case-insensitive exact match. If the value provided for comparison is ``None``,
|
||||||
|
it will be interpreted as an SQL ``NULL`` (see :lookup:`isnull` for more
|
||||||
.. versionchanged:: 1.7
|
details).
|
||||||
|
|
||||||
If the value provided for comparison is ``None``, it will be interpreted
|
|
||||||
as an SQL ``NULL`` (see :lookup:`isnull` for more details).
|
|
||||||
|
|
||||||
Example::
|
Example::
|
||||||
|
|
||||||
|
@ -2890,8 +2855,6 @@ in particular, it is not otherwise possible to use ``OR`` in ``QuerySets``.
|
||||||
``Prefetch()`` objects
|
``Prefetch()`` objects
|
||||||
----------------------
|
----------------------
|
||||||
|
|
||||||
.. versionadded:: 1.7
|
|
||||||
|
|
||||||
.. class:: Prefetch(lookup, queryset=None, to_attr=None)
|
.. class:: Prefetch(lookup, queryset=None, to_attr=None)
|
||||||
|
|
||||||
The ``Prefetch()`` object can be used to control the operation of
|
The ``Prefetch()`` object can be used to control the operation of
|
||||||
|
|
|
@ -34,8 +34,6 @@ All attributes should be considered read-only, unless stated otherwise below.
|
||||||
|
|
||||||
.. attribute:: HttpRequest.scheme
|
.. attribute:: HttpRequest.scheme
|
||||||
|
|
||||||
.. versionadded:: 1.7
|
|
||||||
|
|
||||||
A string representing the scheme of the request (``http`` or ``https``
|
A string representing the scheme of the request (``http`` or ``https``
|
||||||
usually).
|
usually).
|
||||||
|
|
||||||
|
@ -865,8 +863,6 @@ types of HTTP responses. Like ``HttpResponse``, these subclasses live in
|
||||||
JsonResponse objects
|
JsonResponse objects
|
||||||
====================
|
====================
|
||||||
|
|
||||||
.. versionadded:: 1.7
|
|
||||||
|
|
||||||
.. class:: JsonResponse
|
.. class:: JsonResponse
|
||||||
|
|
||||||
.. method:: JsonResponse.__init__(data, encoder=DjangoJSONEncoder, safe=True, **kwargs)
|
.. method:: JsonResponse.__init__(data, encoder=DjangoJSONEncoder, safe=True, **kwargs)
|
||||||
|
|
|
@ -40,11 +40,6 @@ a model object and return its URL. This is a way of inserting or overriding
|
||||||
Note that the model name used in this setting should be all lower-case, regardless
|
Note that the model name used in this setting should be all lower-case, regardless
|
||||||
of the case of the actual model class name.
|
of the case of the actual model class name.
|
||||||
|
|
||||||
.. versionchanged:: 1.7.1
|
|
||||||
|
|
||||||
``ABSOLUTE_URL_OVERRIDES`` now works on models that don't declare
|
|
||||||
``get_absolute_url()``.
|
|
||||||
|
|
||||||
.. setting:: ADMINS
|
.. setting:: ADMINS
|
||||||
|
|
||||||
ADMINS
|
ADMINS
|
||||||
|
@ -85,21 +80,9 @@ responsible to provide your own validation of the ``Host`` header (perhaps in a
|
||||||
middleware; if so this middleware must be listed first in
|
middleware; if so this middleware must be listed first in
|
||||||
:setting:`MIDDLEWARE_CLASSES`).
|
:setting:`MIDDLEWARE_CLASSES`).
|
||||||
|
|
||||||
.. versionchanged:: 1.7
|
Django also allows the `fully qualified domain name (FQDN)`_ of any entries.
|
||||||
|
Some browsers include a trailing dot in the ``Host`` header which Django
|
||||||
In previous versions of Django, if you wanted to also allow the
|
strips when performing host validation.
|
||||||
`fully qualified domain name (FQDN)`_, which some browsers can send in the
|
|
||||||
``Host`` header, you had to explicitly add another ``ALLOWED_HOSTS`` entry
|
|
||||||
that included a trailing period. This entry could also be a subdomain
|
|
||||||
wildcard::
|
|
||||||
|
|
||||||
ALLOWED_HOSTS = [
|
|
||||||
'.example.com', # Allow domain and subdomains
|
|
||||||
'.example.com.', # Also allow FQDN and subdomains
|
|
||||||
]
|
|
||||||
|
|
||||||
In Django 1.7, the trailing dot is stripped when performing host validation,
|
|
||||||
thus an entry with a trailing dot isn't required.
|
|
||||||
|
|
||||||
.. _`fully qualified domain name (FQDN)`: http://en.wikipedia.org/wiki/Fully_qualified_domain_name
|
.. _`fully qualified domain name (FQDN)`: http://en.wikipedia.org/wiki/Fully_qualified_domain_name
|
||||||
|
|
||||||
|
@ -270,11 +253,8 @@ TIMEOUT
|
||||||
|
|
||||||
Default: 300
|
Default: 300
|
||||||
|
|
||||||
The number of seconds before a cache entry is considered stale.
|
The number of seconds before a cache entry is considered stale. If the value of
|
||||||
|
this settings is ``None``, cache entries will not expire.
|
||||||
.. versionadded:: 1.7
|
|
||||||
|
|
||||||
If the value of this settings is ``None``, cache entries will not expire.
|
|
||||||
|
|
||||||
.. setting:: CACHES-VERSION
|
.. setting:: CACHES-VERSION
|
||||||
|
|
||||||
|
@ -329,8 +309,6 @@ See :doc:`/topics/cache`.
|
||||||
CSRF_COOKIE_AGE
|
CSRF_COOKIE_AGE
|
||||||
---------------
|
---------------
|
||||||
|
|
||||||
.. versionadded:: 1.7
|
|
||||||
|
|
||||||
Default: ``31449600`` (1 year, in seconds)
|
Default: ``31449600`` (1 year, in seconds)
|
||||||
|
|
||||||
The age of CSRF cookies, in seconds.
|
The age of CSRF cookies, in seconds.
|
||||||
|
@ -608,16 +586,6 @@ The username to use when connecting to the database. Not used with SQLite.
|
||||||
TEST
|
TEST
|
||||||
~~~~
|
~~~~
|
||||||
|
|
||||||
.. versionchanged:: 1.7
|
|
||||||
|
|
||||||
All :setting:`TEST <DATABASE-TEST>` sub-entries used to be independent
|
|
||||||
entries in the database settings dictionary, with a ``TEST_`` prefix.
|
|
||||||
For backwards compatibility with older versions of Django, you can define
|
|
||||||
both versions of the settings as long as they match.
|
|
||||||
Further, ``TEST_CREATE``, ``TEST_USER_CREATE`` and ``TEST_PASSWD``
|
|
||||||
were changed to ``CREATE_DB``, ``CREATE_USER`` and ``PASSWORD``
|
|
||||||
respectively.
|
|
||||||
|
|
||||||
Default: ``{}``
|
Default: ``{}``
|
||||||
|
|
||||||
A dictionary of settings for test databases; for more details about the
|
A dictionary of settings for test databases; for more details about the
|
||||||
|
@ -703,8 +671,6 @@ See :ref:`the-test-database`.
|
||||||
SERIALIZE
|
SERIALIZE
|
||||||
^^^^^^^^^
|
^^^^^^^^^
|
||||||
|
|
||||||
.. versionadded:: 1.7.1
|
|
||||||
|
|
||||||
Boolean value to control whether or not the default test runner serializes the
|
Boolean value to control whether or not the default test runner serializes the
|
||||||
database into an in-memory JSON string before running tests (used to restore
|
database into an in-memory JSON string before running tests (used to restore
|
||||||
the database state between tests if you don't have transactions). You can set
|
the database state between tests if you don't have transactions). You can set
|
||||||
|
@ -1210,8 +1176,6 @@ experiencing hanging connections, see the implicit TLS setting
|
||||||
EMAIL_USE_SSL
|
EMAIL_USE_SSL
|
||||||
-------------
|
-------------
|
||||||
|
|
||||||
.. versionadded:: 1.7
|
|
||||||
|
|
||||||
Default: ``False``
|
Default: ``False``
|
||||||
|
|
||||||
Whether to use an implicit TLS (secure) connection when talking to the SMTP
|
Whether to use an implicit TLS (secure) connection when talking to the SMTP
|
||||||
|
@ -1306,8 +1270,6 @@ the file system. See :doc:`/topics/files` for details.
|
||||||
FILE_UPLOAD_DIRECTORY_PERMISSIONS
|
FILE_UPLOAD_DIRECTORY_PERMISSIONS
|
||||||
---------------------------------
|
---------------------------------
|
||||||
|
|
||||||
.. versionadded:: 1.7
|
|
||||||
|
|
||||||
Default: ``None``
|
Default: ``None``
|
||||||
|
|
||||||
The numeric mode to apply to directories created in the process of uploading
|
The numeric mode to apply to directories created in the process of uploading
|
||||||
|
@ -1486,10 +1448,6 @@ Django installation. Each string should be a dotted Python path to:
|
||||||
|
|
||||||
:doc:`Learn more about application configurations </ref/applications>`.
|
:doc:`Learn more about application configurations </ref/applications>`.
|
||||||
|
|
||||||
.. versionchanged:: 1.7
|
|
||||||
|
|
||||||
:setting:`INSTALLED_APPS` now supports application configurations.
|
|
||||||
|
|
||||||
.. admonition:: Use the application registry for introspection
|
.. admonition:: Use the application registry for introspection
|
||||||
|
|
||||||
Your code should never access :setting:`INSTALLED_APPS` directly. Use
|
Your code should never access :setting:`INSTALLED_APPS` directly. Use
|
||||||
|
@ -1559,8 +1517,6 @@ See :ref:`how-django-discovers-language-preference` for more details.
|
||||||
LANGUAGE_COOKIE_AGE
|
LANGUAGE_COOKIE_AGE
|
||||||
-------------------
|
-------------------
|
||||||
|
|
||||||
.. versionadded:: 1.7
|
|
||||||
|
|
||||||
Default: ``None`` (expires at browser close)
|
Default: ``None`` (expires at browser close)
|
||||||
|
|
||||||
The age of the language cookie, in seconds.
|
The age of the language cookie, in seconds.
|
||||||
|
@ -1570,8 +1526,6 @@ The age of the language cookie, in seconds.
|
||||||
LANGUAGE_COOKIE_DOMAIN
|
LANGUAGE_COOKIE_DOMAIN
|
||||||
----------------------
|
----------------------
|
||||||
|
|
||||||
.. versionadded:: 1.7
|
|
||||||
|
|
||||||
Default: ``None``
|
Default: ``None``
|
||||||
|
|
||||||
The domain to use for the language cookie. Set this to a string such as
|
The domain to use for the language cookie. Set this to a string such as
|
||||||
|
@ -1604,8 +1558,6 @@ you want (but should be different from :setting:`SESSION_COOKIE_NAME`). See
|
||||||
LANGUAGE_COOKIE_PATH
|
LANGUAGE_COOKIE_PATH
|
||||||
--------------------
|
--------------------
|
||||||
|
|
||||||
.. versionadded:: 1.7
|
|
||||||
|
|
||||||
Default: ``/``
|
Default: ``/``
|
||||||
|
|
||||||
The path set on the language cookie. This should either match the URL path of your
|
The path set on the language cookie. This should either match the URL path of your
|
||||||
|
@ -1712,10 +1664,6 @@ configuration method by default.
|
||||||
If you set :setting:`LOGGING_CONFIG` to ``None``, the logging
|
If you set :setting:`LOGGING_CONFIG` to ``None``, the logging
|
||||||
configuration process will be skipped.
|
configuration process will be skipped.
|
||||||
|
|
||||||
.. versionchanged:: 1.7
|
|
||||||
|
|
||||||
Previously, the default value was ``'django.utils.log.dictConfig'``.
|
|
||||||
|
|
||||||
.. _dictConfig: https://docs.python.org/library/logging.config.html#configuration-dictionary-schema
|
.. _dictConfig: https://docs.python.org/library/logging.config.html#configuration-dictionary-schema
|
||||||
|
|
||||||
.. setting:: MANAGERS
|
.. setting:: MANAGERS
|
||||||
|
@ -1792,13 +1740,6 @@ Default::
|
||||||
|
|
||||||
A tuple of middleware classes to use. See :doc:`/topics/http/middleware`.
|
A tuple of middleware classes to use. See :doc:`/topics/http/middleware`.
|
||||||
|
|
||||||
.. versionchanged:: 1.7
|
|
||||||
|
|
||||||
:class:`~django.contrib.sessions.middleware.SessionMiddleware`,
|
|
||||||
:class:`~django.contrib.auth.middleware.AuthenticationMiddleware`, and
|
|
||||||
:class:`~django.contrib.messages.middleware.MessageMiddleware` were removed
|
|
||||||
from this setting.
|
|
||||||
|
|
||||||
.. setting:: MIGRATION_MODULES
|
.. setting:: MIGRATION_MODULES
|
||||||
|
|
||||||
MIGRATION_MODULES
|
MIGRATION_MODULES
|
||||||
|
@ -2177,8 +2118,6 @@ See also the :doc:`/topics/signing` documentation.
|
||||||
SILENCED_SYSTEM_CHECKS
|
SILENCED_SYSTEM_CHECKS
|
||||||
----------------------
|
----------------------
|
||||||
|
|
||||||
.. versionadded:: 1.7
|
|
||||||
|
|
||||||
Default: ``[]``
|
Default: ``[]``
|
||||||
|
|
||||||
A list of identifiers of messages generated by the system check framework
|
A list of identifiers of messages generated by the system check framework
|
||||||
|
@ -2391,8 +2330,6 @@ The name of the class to use for starting the test suite. See
|
||||||
TEST_NON_SERIALIZED_APPS
|
TEST_NON_SERIALIZED_APPS
|
||||||
------------------------
|
------------------------
|
||||||
|
|
||||||
.. versionadded:: 1.7
|
|
||||||
|
|
||||||
Default: ``[]``
|
Default: ``[]``
|
||||||
|
|
||||||
In order to restore the database state between tests for
|
In order to restore the database state between tests for
|
||||||
|
@ -2903,10 +2840,6 @@ scripting vulnerability into full hijacking of a user's session. There's not
|
||||||
much excuse for leaving this off, either: if your code depends on reading
|
much excuse for leaving this off, either: if your code depends on reading
|
||||||
session cookies from Javascript, you're probably doing it wrong.
|
session cookies from Javascript, you're probably doing it wrong.
|
||||||
|
|
||||||
.. versionadded:: 1.7
|
|
||||||
|
|
||||||
This setting also affects cookies set by :mod:`django.contrib.messages`.
|
|
||||||
|
|
||||||
.. _HTTPOnly: https://www.owasp.org/index.php/HTTPOnly
|
.. _HTTPOnly: https://www.owasp.org/index.php/HTTPOnly
|
||||||
|
|
||||||
.. setting:: SESSION_COOKIE_NAME
|
.. setting:: SESSION_COOKIE_NAME
|
||||||
|
@ -2951,10 +2884,6 @@ requests and that's a good thing.
|
||||||
|
|
||||||
.. _Firesheep: http://codebutler.com/firesheep
|
.. _Firesheep: http://codebutler.com/firesheep
|
||||||
|
|
||||||
.. versionadded:: 1.7
|
|
||||||
|
|
||||||
This setting also affects cookies set by :mod:`django.contrib.messages`.
|
|
||||||
|
|
||||||
.. setting:: SESSION_ENGINE
|
.. setting:: SESSION_ENGINE
|
||||||
|
|
||||||
SESSION_ENGINE
|
SESSION_ENGINE
|
||||||
|
|
|
@ -34,7 +34,7 @@ model system.
|
||||||
so if your handler is a local function, it may be garbage collected. To
|
so if your handler is a local function, it may be garbage collected. To
|
||||||
prevent this, pass ``weak=False`` when you call the signal's :meth:`~django.dispatch.Signal.connect`.
|
prevent this, pass ``weak=False`` when you call the signal's :meth:`~django.dispatch.Signal.connect`.
|
||||||
|
|
||||||
.. versionadded:: 1.7
|
.. note::
|
||||||
|
|
||||||
Model signals ``sender`` model can be lazily referenced when connecting a
|
Model signals ``sender`` model can be lazily referenced when connecting a
|
||||||
receiver by specifying its full application label. For example, an
|
receiver by specifying its full application label. For example, an
|
||||||
|
@ -579,8 +579,6 @@ Arguments sent with this signal:
|
||||||
don't exist, in the "teardown" phase, ``value`` is ``None``.
|
don't exist, in the "teardown" phase, ``value`` is ``None``.
|
||||||
|
|
||||||
``enter``
|
``enter``
|
||||||
.. versionadded:: 1.7
|
|
||||||
|
|
||||||
A boolean; ``True`` if the setting is applied, ``False`` if restored.
|
A boolean; ``True`` if the setting is applied, ``False`` if restored.
|
||||||
|
|
||||||
template_rendered
|
template_rendered
|
||||||
|
|
|
@ -442,8 +442,6 @@ If you ``pop()`` too much, it'll raise
|
||||||
...
|
...
|
||||||
ContextPopException
|
ContextPopException
|
||||||
|
|
||||||
.. versionadded:: 1.7
|
|
||||||
|
|
||||||
You can also use ``push()`` as a context manager to ensure a matching ``pop()``
|
You can also use ``push()`` as a context manager to ensure a matching ``pop()``
|
||||||
is called.
|
is called.
|
||||||
|
|
||||||
|
@ -490,8 +488,6 @@ tags <howto-writing-custom-template-tags>`.
|
||||||
|
|
||||||
.. method:: Context.flatten()
|
.. method:: Context.flatten()
|
||||||
|
|
||||||
.. versionadded:: 1.7
|
|
||||||
|
|
||||||
Using ``flatten()`` method you can get whole ``Context`` stack as one dictionary
|
Using ``flatten()`` method you can get whole ``Context`` stack as one dictionary
|
||||||
including builtin variables.
|
including builtin variables.
|
||||||
|
|
||||||
|
@ -705,10 +701,6 @@ variables:
|
||||||
* ``DEFAULT_MESSAGE_LEVELS`` -- A mapping of the message level names to
|
* ``DEFAULT_MESSAGE_LEVELS`` -- A mapping of the message level names to
|
||||||
:ref:`their numeric value <message-level-constants>`.
|
:ref:`their numeric value <message-level-constants>`.
|
||||||
|
|
||||||
.. versionchanged:: 1.7
|
|
||||||
|
|
||||||
The ``DEFAULT_MESSAGE_LEVELS`` variable was added.
|
|
||||||
|
|
||||||
Writing your own context processors
|
Writing your own context processors
|
||||||
-----------------------------------
|
-----------------------------------
|
||||||
|
|
||||||
|
@ -941,8 +933,6 @@ the template source, and returns a tuple: ``(template, template_origin)``.
|
||||||
Template origin
|
Template origin
|
||||||
===============
|
===============
|
||||||
|
|
||||||
.. versionadded:: 1.7
|
|
||||||
|
|
||||||
When an :class:`~django.template.Engine` is initialized with ``debug=True``,
|
When an :class:`~django.template.Engine` is initialized with ``debug=True``,
|
||||||
its templates have an ``origin`` attribute depending on the source they are
|
its templates have an ``origin`` attribute depending on the source they are
|
||||||
loaded from. For engines initialized by Django, ``debug`` defaults to the
|
loaded from. For engines initialized by Django, ``debug`` defaults to the
|
||||||
|
|
|
@ -665,11 +665,8 @@ the variable ``template_name``::
|
||||||
|
|
||||||
{% include template_name %}
|
{% include template_name %}
|
||||||
|
|
||||||
.. versionchanged:: 1.7
|
The variable may also be any object with a ``render()`` method that accepts a
|
||||||
|
context. This allows you to reference a compiled ``Template`` in your context.
|
||||||
The variable may also be any object with a ``render()`` method that
|
|
||||||
accepts a context. This allows you to reference a compiled ``Template`` in
|
|
||||||
your context.
|
|
||||||
|
|
||||||
An included template is rendered within the context of the template that
|
An included template is rendered within the context of the template that
|
||||||
includes it. This example produces the output ``"Hello, John"``:
|
includes it. This example produces the output ``"Hello, John"``:
|
||||||
|
@ -1177,10 +1174,6 @@ variable. It can be useful, for instance, in a :ttag:`blocktrans` like this::
|
||||||
{% widthratio this_value max_value max_width as width %}
|
{% widthratio this_value max_value max_width as width %}
|
||||||
{% blocktrans %}The width is: {{ width }}{% endblocktrans %}
|
{% blocktrans %}The width is: {{ width }}{% endblocktrans %}
|
||||||
|
|
||||||
.. versionchanged:: 1.7
|
|
||||||
|
|
||||||
The ability to use "as" with this tag like in the example above was added.
|
|
||||||
|
|
||||||
.. templatetag:: with
|
.. templatetag:: with
|
||||||
|
|
||||||
with
|
with
|
||||||
|
@ -2153,11 +2146,6 @@ When used without a format string::
|
||||||
...the formatting string defined in the :setting:`TIME_FORMAT` setting will be
|
...the formatting string defined in the :setting:`TIME_FORMAT` setting will be
|
||||||
used, without applying any localization.
|
used, without applying any localization.
|
||||||
|
|
||||||
.. versionchanged:: 1.7
|
|
||||||
|
|
||||||
The ability to receive and act on values with attached timezone
|
|
||||||
information was added in Django 1.7.
|
|
||||||
|
|
||||||
.. templatefilter:: timesince
|
.. templatefilter:: timesince
|
||||||
|
|
||||||
timesince
|
timesince
|
||||||
|
@ -2235,8 +2223,6 @@ If ``value`` is ``"Joel is a slug"``, the output will be ``"Joel i..."``.
|
||||||
truncatechars_html
|
truncatechars_html
|
||||||
^^^^^^^^^^^^^^^^^^
|
^^^^^^^^^^^^^^^^^^
|
||||||
|
|
||||||
.. versionadded:: 1.7
|
|
||||||
|
|
||||||
Similar to :tfilter:`truncatechars`, except that it is aware of HTML tags. Any
|
Similar to :tfilter:`truncatechars`, except that it is aware of HTML tags. Any
|
||||||
tags that are opened in the string and not closed before the truncation point
|
tags that are opened in the string and not closed before the truncation point
|
||||||
are closed immediately after the truncation.
|
are closed immediately after the truncation.
|
||||||
|
|
|
@ -345,10 +345,6 @@ SyndicationFeed
|
||||||
objects except ``pubdate`` and ``updateddate``, which are ``datetime.datetime``
|
objects except ``pubdate`` and ``updateddate``, which are ``datetime.datetime``
|
||||||
objects, and ``enclosure``, which is an instance of the ``Enclosure`` class.
|
objects, and ``enclosure``, which is an instance of the ``Enclosure`` class.
|
||||||
|
|
||||||
.. versionadded:: 1.7
|
|
||||||
|
|
||||||
The optional ``updateddate`` argument was added.
|
|
||||||
|
|
||||||
.. method:: num_items()
|
.. method:: num_items()
|
||||||
|
|
||||||
.. method:: root_attributes()
|
.. method:: root_attributes()
|
||||||
|
@ -742,8 +738,6 @@ Functions for working with Python modules.
|
||||||
|
|
||||||
.. function:: import_string(dotted_path)
|
.. function:: import_string(dotted_path)
|
||||||
|
|
||||||
.. versionadded:: 1.7
|
|
||||||
|
|
||||||
Imports a dotted module path and returns the attribute/class designated by
|
Imports a dotted module path and returns the attribute/class designated by
|
||||||
the last name in the path. Raises ``ImportError`` if the import failed. For
|
the last name in the path. Raises ``ImportError`` if the import failed. For
|
||||||
example::
|
example::
|
||||||
|
@ -849,15 +843,11 @@ appropriate entities.
|
||||||
|
|
||||||
.. class:: FixedOffset(offset=None, name=None)
|
.. class:: FixedOffset(offset=None, name=None)
|
||||||
|
|
||||||
.. versionadded:: 1.7
|
|
||||||
|
|
||||||
A :class:`~datetime.tzinfo` subclass modeling a fixed offset from UTC.
|
A :class:`~datetime.tzinfo` subclass modeling a fixed offset from UTC.
|
||||||
``offset`` is an integer number of minutes east of UTC.
|
``offset`` is an integer number of minutes east of UTC.
|
||||||
|
|
||||||
.. function:: get_fixed_timezone(offset)
|
.. function:: get_fixed_timezone(offset)
|
||||||
|
|
||||||
.. versionadded:: 1.7
|
|
||||||
|
|
||||||
Returns a :class:`~datetime.tzinfo` instance that represents a time zone
|
Returns a :class:`~datetime.tzinfo` instance that represents a time zone
|
||||||
with a fixed offset from UTC.
|
with a fixed offset from UTC.
|
||||||
|
|
||||||
|
|
|
@ -102,18 +102,14 @@ to, or in lieu of custom ``field.clean()`` methods.
|
||||||
|
|
||||||
.. attribute:: inverse_match
|
.. attribute:: inverse_match
|
||||||
|
|
||||||
.. versionadded:: 1.7
|
|
||||||
|
|
||||||
The match mode for :attr:`regex`. Defaults to ``False``.
|
The match mode for :attr:`regex`. Defaults to ``False``.
|
||||||
|
|
||||||
.. attribute:: flags
|
.. attribute:: flags
|
||||||
|
|
||||||
.. versionadded:: 1.7
|
The flags used when compiling the regular expression string
|
||||||
|
:attr:`regex`. If :attr:`regex` is a pre-compiled regular expression,
|
||||||
The flags used when compiling the regular expression string :attr:`regex`.
|
and :attr:`flags` is overridden, :exc:`TypeError` is raised. Defaults
|
||||||
If :attr:`regex` is a pre-compiled regular expression, and :attr:`flags` is overridden,
|
to ``0``.
|
||||||
:exc:`TypeError` is raised.
|
|
||||||
Defaults to `0`.
|
|
||||||
|
|
||||||
``EmailValidator``
|
``EmailValidator``
|
||||||
------------------
|
------------------
|
||||||
|
@ -165,10 +161,6 @@ to, or in lieu of custom ``field.clean()`` methods.
|
||||||
|
|
||||||
.. _valid URI schemes: https://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml
|
.. _valid URI schemes: https://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml
|
||||||
|
|
||||||
.. versionchanged:: 1.7
|
|
||||||
|
|
||||||
The optional ``schemes`` attribute was added.
|
|
||||||
|
|
||||||
.. versionchanged:: 1.8
|
.. versionchanged:: 1.8
|
||||||
|
|
||||||
Support for IPv6 addresses, unicode domains, and URLs containing
|
Support for IPv6 addresses, unicode domains, and URLs containing
|
||||||
|
|
|
@ -436,10 +436,8 @@ different User model.
|
||||||
class Article(models.Model):
|
class Article(models.Model):
|
||||||
author = models.ForeignKey(settings.AUTH_USER_MODEL)
|
author = models.ForeignKey(settings.AUTH_USER_MODEL)
|
||||||
|
|
||||||
.. versionadded:: 1.7
|
When connecting to signals sent by the ``User`` model, you should specify
|
||||||
|
the custom model using the :setting:`AUTH_USER_MODEL` setting. For example::
|
||||||
When connecting to signals sent by the User model, you should specify the
|
|
||||||
custom model using the :setting:`AUTH_USER_MODEL` setting. For example::
|
|
||||||
|
|
||||||
from django.conf import settings
|
from django.conf import settings
|
||||||
from django.db.models.signals import post_save
|
from django.db.models.signals import post_save
|
||||||
|
@ -637,8 +635,6 @@ The following methods are available on any subclass of
|
||||||
|
|
||||||
.. method:: models.AbstractBaseUser.get_session_auth_hash()
|
.. method:: models.AbstractBaseUser.get_session_auth_hash()
|
||||||
|
|
||||||
.. versionadded:: 1.7
|
|
||||||
|
|
||||||
Returns an HMAC of the password field. Used for
|
Returns an HMAC of the password field. Used for
|
||||||
:ref:`session-invalidation-on-password-change`.
|
:ref:`session-invalidation-on-password-change`.
|
||||||
|
|
||||||
|
|
|
@ -108,8 +108,6 @@ Django also provides :ref:`views <built-in-auth-views>` and :ref:`forms
|
||||||
<built-in-auth-forms>` that may be used to allow users to change their own
|
<built-in-auth-forms>` that may be used to allow users to change their own
|
||||||
passwords.
|
passwords.
|
||||||
|
|
||||||
.. versionadded:: 1.7
|
|
||||||
|
|
||||||
Changing a user's password will log out all their sessions if the
|
Changing a user's password will log out all their sessions if the
|
||||||
:class:`~django.contrib.auth.middleware.SessionAuthenticationMiddleware` is
|
:class:`~django.contrib.auth.middleware.SessionAuthenticationMiddleware` is
|
||||||
enabled. See :ref:`session-invalidation-on-password-change` for details.
|
enabled. See :ref:`session-invalidation-on-password-change` for details.
|
||||||
|
@ -560,11 +558,13 @@ The permission_required decorator
|
||||||
def my_view(request):
|
def my_view(request):
|
||||||
...
|
...
|
||||||
|
|
||||||
As for the :meth:`~django.contrib.auth.models.User.has_perm` method,
|
Just like the :meth:`~django.contrib.auth.models.User.has_perm` method,
|
||||||
permission names take the form ``"<app label>.<permission codename>"``
|
permission names take the form ``"<app label>.<permission codename>"``
|
||||||
(i.e. ``polls.can_vote`` for a permission on a model in the ``polls``
|
(i.e. ``polls.can_vote`` for a permission on a model in the ``polls``
|
||||||
application).
|
application).
|
||||||
|
|
||||||
|
The decorator may also take a list of permissions.
|
||||||
|
|
||||||
Note that :func:`~django.contrib.auth.decorators.permission_required()`
|
Note that :func:`~django.contrib.auth.decorators.permission_required()`
|
||||||
also takes an optional ``login_url`` parameter. Example::
|
also takes an optional ``login_url`` parameter. Example::
|
||||||
|
|
||||||
|
@ -582,11 +582,6 @@ The permission_required decorator
|
||||||
(HTTP Forbidden) view<http_forbidden_view>` instead of redirecting to the
|
(HTTP Forbidden) view<http_forbidden_view>` instead of redirecting to the
|
||||||
login page.
|
login page.
|
||||||
|
|
||||||
.. versionchanged:: 1.7
|
|
||||||
|
|
||||||
The :func:`~django.contrib.auth.decorators.permission_required`
|
|
||||||
decorator can take a list of permissions as well as a single permission.
|
|
||||||
|
|
||||||
.. _applying-permissions-to-generic-views:
|
.. _applying-permissions-to-generic-views:
|
||||||
|
|
||||||
Applying permissions to generic views
|
Applying permissions to generic views
|
||||||
|
@ -603,8 +598,6 @@ To apply a permission to a :doc:`class-based generic view
|
||||||
Session invalidation on password change
|
Session invalidation on password change
|
||||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
.. versionadded:: 1.7
|
|
||||||
|
|
||||||
.. warning::
|
.. warning::
|
||||||
|
|
||||||
This protection only applies if
|
This protection only applies if
|
||||||
|
@ -986,10 +979,6 @@ patterns.
|
||||||
for generating a ``text/html`` multipart email with the password reset
|
for generating a ``text/html`` multipart email with the password reset
|
||||||
link. By default, HTML email is not sent.
|
link. By default, HTML email is not sent.
|
||||||
|
|
||||||
.. versionadded:: 1.7
|
|
||||||
|
|
||||||
``html_email_template_name`` was added.
|
|
||||||
|
|
||||||
.. deprecated:: 1.8
|
.. deprecated:: 1.8
|
||||||
|
|
||||||
The ``is_admin_site`` argument is deprecated and will be removed in
|
The ``is_admin_site`` argument is deprecated and will be removed in
|
||||||
|
@ -1177,8 +1166,6 @@ provides several built-in forms located in :mod:`django.contrib.auth.forms`:
|
||||||
|
|
||||||
.. method:: confirm_login_allowed(user)
|
.. method:: confirm_login_allowed(user)
|
||||||
|
|
||||||
.. versionadded:: 1.7
|
|
||||||
|
|
||||||
By default, ``AuthenticationForm`` rejects users whose ``is_active`` flag
|
By default, ``AuthenticationForm`` rejects users whose ``is_active`` flag
|
||||||
is set to ``False``. You may override this behavior with a custom policy to
|
is set to ``False``. You may override this behavior with a custom policy to
|
||||||
determine which users can log in. Do this with a custom form that subclasses
|
determine which users can log in. Do this with a custom form that subclasses
|
||||||
|
|
|
@ -206,13 +206,6 @@ If you are using multiple databases, :djadmin:`createcachetable` observes the
|
||||||
Like :djadmin:`migrate`, :djadmin:`createcachetable` won't touch an existing
|
Like :djadmin:`migrate`, :djadmin:`createcachetable` won't touch an existing
|
||||||
table. It will only create missing tables.
|
table. It will only create missing tables.
|
||||||
|
|
||||||
.. versionchanged:: 1.7
|
|
||||||
|
|
||||||
Before Django 1.7, :djadmin:`createcachetable` created one table at a time.
|
|
||||||
You had to pass the name of the table you wanted to create, and if you were
|
|
||||||
using multiple databases, you had to use the :djadminopt:`--database`
|
|
||||||
option. For backwards compatibility, this is still possible.
|
|
||||||
|
|
||||||
Multiple databases
|
Multiple databases
|
||||||
~~~~~~~~~~~~~~~~~~
|
~~~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
|
@ -369,9 +362,6 @@ behavior. These arguments are provided as additional keys in the
|
||||||
|
|
||||||
* :setting:`TIMEOUT <CACHES-TIMEOUT>`: The default timeout, in
|
* :setting:`TIMEOUT <CACHES-TIMEOUT>`: The default timeout, in
|
||||||
seconds, to use for the cache. This argument defaults to ``300`` seconds (5 minutes).
|
seconds, to use for the cache. This argument defaults to ``300`` seconds (5 minutes).
|
||||||
|
|
||||||
.. versionadded:: 1.7
|
|
||||||
|
|
||||||
You can set ``TIMEOUT`` to ``None`` so that, by default, cache keys never
|
You can set ``TIMEOUT`` to ``None`` so that, by default, cache keys never
|
||||||
expire.
|
expire.
|
||||||
|
|
||||||
|
@ -662,12 +652,10 @@ equivalent:
|
||||||
This feature is useful in avoiding repetition in templates. You can set the
|
This feature is useful in avoiding repetition in templates. You can set the
|
||||||
timeout in a variable, in one place, and just reuse that value.
|
timeout in a variable, in one place, and just reuse that value.
|
||||||
|
|
||||||
.. versionadded:: 1.7
|
By default, the cache tag will try to use the cache called "template_fragments".
|
||||||
|
If no such cache exists, it will fall back to using the default cache. You may
|
||||||
By default, the cache tag will try to use the cache called
|
select an alternate cache backend to use with the ``using`` keyword argument,
|
||||||
"template_fragments". If no such cache exists, it will fall back to using
|
which must be the last argument to the tag.
|
||||||
the default cache. You may select an alternate cache backend to use with
|
|
||||||
the ``using`` keyword argument, which must be the last argument to the tag.
|
|
||||||
|
|
||||||
.. code-block:: html+django
|
.. code-block:: html+django
|
||||||
|
|
||||||
|
@ -719,8 +707,6 @@ Accessing the cache
|
||||||
|
|
||||||
.. data:: django.core.cache.caches
|
.. data:: django.core.cache.caches
|
||||||
|
|
||||||
.. versionadded:: 1.7
|
|
||||||
|
|
||||||
You can access the caches configured in the :setting:`CACHES` setting
|
You can access the caches configured in the :setting:`CACHES` setting
|
||||||
through a dict-like object: ``django.core.cache.caches``. Repeated
|
through a dict-like object: ``django.core.cache.caches``. Repeated
|
||||||
requests for the same alias in the same thread will return the same
|
requests for the same alias in the same thread will return the same
|
||||||
|
@ -1048,11 +1034,6 @@ produces different content based on some difference in request headers -- such
|
||||||
as a cookie, or a language, or a user-agent -- you'll need to use the ``Vary``
|
as a cookie, or a language, or a user-agent -- you'll need to use the ``Vary``
|
||||||
header to tell caching mechanisms that the page output depends on those things.
|
header to tell caching mechanisms that the page output depends on those things.
|
||||||
|
|
||||||
.. versionchanged:: 1.7
|
|
||||||
|
|
||||||
Cache keys use the request's fully-qualified URL rather than just the path
|
|
||||||
and query string.
|
|
||||||
|
|
||||||
To do this in Django, use the convenient
|
To do this in Django, use the convenient
|
||||||
:func:`django.views.decorators.vary.vary_on_headers` view decorator, like so::
|
:func:`django.views.decorators.vary.vary_on_headers` view decorator, like so::
|
||||||
|
|
||||||
|
|
|
@ -2,8 +2,6 @@
|
||||||
System check framework
|
System check framework
|
||||||
======================
|
======================
|
||||||
|
|
||||||
.. versionadded:: 1.7
|
|
||||||
|
|
||||||
.. module:: django.core.checks
|
.. module:: django.core.checks
|
||||||
|
|
||||||
The system check framework is a set of static checks for validating Django
|
The system check framework is a set of static checks for validating Django
|
||||||
|
|
|
@ -242,8 +242,6 @@ the manager ``Person.people``.
|
||||||
Creating ``Manager`` with ``QuerySet`` methods
|
Creating ``Manager`` with ``QuerySet`` methods
|
||||||
----------------------------------------------
|
----------------------------------------------
|
||||||
|
|
||||||
.. versionadded:: 1.7
|
|
||||||
|
|
||||||
In lieu of the above approach which requires duplicating methods on both the
|
In lieu of the above approach which requires duplicating methods on both the
|
||||||
``QuerySet`` and the ``Manager``, :meth:`QuerySet.as_manager()
|
``QuerySet`` and the ``Manager``, :meth:`QuerySet.as_manager()
|
||||||
<django.db.models.query.QuerySet.as_manager>` can be used to create an instance
|
<django.db.models.query.QuerySet.as_manager>` can be used to create an instance
|
||||||
|
|
|
@ -477,12 +477,6 @@ There are a few restrictions on the intermediate model:
|
||||||
:attr:`symmetrical=False <ManyToManyField.symmetrical>` (see
|
:attr:`symmetrical=False <ManyToManyField.symmetrical>` (see
|
||||||
:ref:`the model field reference <manytomany-arguments>`).
|
:ref:`the model field reference <manytomany-arguments>`).
|
||||||
|
|
||||||
.. versionchanged:: 1.7
|
|
||||||
|
|
||||||
In Django 1.6 and earlier, intermediate models containing more than one
|
|
||||||
foreign key to any of the models involved in the many-to-many relationship
|
|
||||||
used to be prohibited.
|
|
||||||
|
|
||||||
Now that you have set up your :class:`~django.db.models.ManyToManyField` to use
|
Now that you have set up your :class:`~django.db.models.ManyToManyField` to use
|
||||||
your intermediary model (``Membership``, in this case), you're ready to start
|
your intermediary model (``Membership``, in this case), you're ready to start
|
||||||
creating some many-to-many relationships. You do this by creating instances of
|
creating some many-to-many relationships. You do this by creating instances of
|
||||||
|
@ -1303,41 +1297,9 @@ inheritance hierarchies as simple and straightforward as possible so that you
|
||||||
won't have to struggle to work out where a particular piece of information is
|
won't have to struggle to work out where a particular piece of information is
|
||||||
coming from.
|
coming from.
|
||||||
|
|
||||||
.. versionchanged:: 1.7
|
Note that inheriting from multiple models that have a common ``id`` primary
|
||||||
|
key field will raise an error. To properly use multiple inheritance, you can
|
||||||
Before Django 1.7, inheriting from multiple models that had an ``id`` primary
|
use an explicit :class:`~django.db.models.AutoField` in the base models::
|
||||||
key field did not raise an error, but could result in data loss. For example,
|
|
||||||
consider these models (which no longer validate due to the clashing ``id``
|
|
||||||
fields)::
|
|
||||||
|
|
||||||
class Article(models.Model):
|
|
||||||
headline = models.CharField(max_length=50)
|
|
||||||
body = models.TextField()
|
|
||||||
|
|
||||||
class Book(models.Model):
|
|
||||||
title = models.CharField(max_length=50)
|
|
||||||
|
|
||||||
class BookReview(Book, Article):
|
|
||||||
pass
|
|
||||||
|
|
||||||
This snippet demonstrates how creating a child object overwrote the value of a
|
|
||||||
previously created parent object::
|
|
||||||
|
|
||||||
>>> article = Article.objects.create(headline='Some piece of news.')
|
|
||||||
>>> review = BookReview.objects.create(
|
|
||||||
... headline='Review of Little Red Riding Hood.',
|
|
||||||
... title='Little Red Riding Hood')
|
|
||||||
>>>
|
|
||||||
>>> assert Article.objects.get(pk=article.pk).headline == article.headline
|
|
||||||
Traceback (most recent call last):
|
|
||||||
File "<console>", line 1, in <module>
|
|
||||||
AssertionError
|
|
||||||
>>> # the "Some piece of news." headline has been overwritten.
|
|
||||||
>>> Article.objects.get(pk=article.pk).headline
|
|
||||||
'Review of Little Red Riding Hood.'
|
|
||||||
|
|
||||||
To properly use multiple inheritance, you can use an explicit
|
|
||||||
:class:`~django.db.models.AutoField` in the base models::
|
|
||||||
|
|
||||||
class Article(models.Model):
|
class Article(models.Model):
|
||||||
article_id = models.AutoField(primary_key=True)
|
article_id = models.AutoField(primary_key=True)
|
||||||
|
|
|
@ -618,10 +618,6 @@ and with other ``F()`` objects. To find all the blog entries with more than
|
||||||
|
|
||||||
>>> Entry.objects.filter(n_comments__gt=F('n_pingbacks') * 2)
|
>>> Entry.objects.filter(n_comments__gt=F('n_pingbacks') * 2)
|
||||||
|
|
||||||
.. versionadded:: 1.7
|
|
||||||
|
|
||||||
The power operator ``**`` was added.
|
|
||||||
|
|
||||||
To find all the entries where the rating of the entry is less than the
|
To find all the entries where the rating of the entry is less than the
|
||||||
sum of the pingback count and comment count, we would issue the
|
sum of the pingback count and comment count, we would issue the
|
||||||
query::
|
query::
|
||||||
|
@ -1149,8 +1145,6 @@ above example code would look like this::
|
||||||
Using a custom reverse manager
|
Using a custom reverse manager
|
||||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
.. versionadded:: 1.7
|
|
||||||
|
|
||||||
By default the :class:`~django.db.models.fields.related.RelatedManager` used
|
By default the :class:`~django.db.models.fields.related.RelatedManager` used
|
||||||
for reverse relations is a subclass of the :ref:`default manager <manager-names>`
|
for reverse relations is a subclass of the :ref:`default manager <manager-names>`
|
||||||
for that model. If you would like to specify a different manager for a given
|
for that model. If you would like to specify a different manager for a given
|
||||||
|
|
|
@ -314,16 +314,6 @@ Also note that Django expects the ``"%s"`` placeholder, *not* the ``"?"``
|
||||||
placeholder, which is used by the SQLite Python bindings. This is for the sake
|
placeholder, which is used by the SQLite Python bindings. This is for the sake
|
||||||
of consistency and sanity.
|
of consistency and sanity.
|
||||||
|
|
||||||
.. versionchanged:: 1.7
|
|
||||||
|
|
||||||
:pep:`249` does not state whether a cursor should be usable as a context
|
|
||||||
manager. Prior to Python 2.7, a cursor was usable as a context manager due
|
|
||||||
an unexpected behavior in magic method lookups (`Python ticket #9220`_).
|
|
||||||
Django 1.7 explicitly added support to allow using a cursor as context
|
|
||||||
manager.
|
|
||||||
|
|
||||||
.. _`Python ticket #9220`: https://bugs.python.org/issue9220
|
|
||||||
|
|
||||||
Using a cursor as a context manager::
|
Using a cursor as a context manager::
|
||||||
|
|
||||||
with connection.cursor() as c:
|
with connection.cursor() as c:
|
||||||
|
|
|
@ -74,10 +74,6 @@ are required.
|
||||||
The return value will be the number of successfully delivered messages (which
|
The return value will be the number of successfully delivered messages (which
|
||||||
can be ``0`` or ``1`` since it can only send one message).
|
can be ``0`` or ``1`` since it can only send one message).
|
||||||
|
|
||||||
.. versionadded:: 1.7
|
|
||||||
|
|
||||||
The ``html_message`` parameter was added.
|
|
||||||
|
|
||||||
send_mass_mail()
|
send_mass_mail()
|
||||||
================
|
================
|
||||||
|
|
||||||
|
@ -333,8 +329,6 @@ The class has the following methods:
|
||||||
|
|
||||||
message.attach('design.png', img_data, 'image/png')
|
message.attach('design.png', img_data, 'image/png')
|
||||||
|
|
||||||
.. versionchanged:: 1.7
|
|
||||||
|
|
||||||
If you specify a ``mimetype`` of ``message/rfc822``, it will also accept
|
If you specify a ``mimetype`` of ``message/rfc822``, it will also accept
|
||||||
:class:`django.core.mail.EmailMessage` and :py:class:`email.message.Message`.
|
:class:`django.core.mail.EmailMessage` and :py:class:`email.message.Message`.
|
||||||
|
|
||||||
|
@ -468,12 +462,8 @@ SMTP backend
|
||||||
|
|
||||||
EMAIL_BACKEND = 'django.core.mail.backends.smtp.EmailBackend'
|
EMAIL_BACKEND = 'django.core.mail.backends.smtp.EmailBackend'
|
||||||
|
|
||||||
.. versionadded:: 1.7
|
If unspecified, the default ``timeout`` will be the one provided by
|
||||||
|
:func:`socket.getdefaulttimeout()`, which defaults to ``None`` (no timeout).
|
||||||
The ``timeout`` parameter was added. If unspecified, the default
|
|
||||||
``timeout`` will be the one provided by
|
|
||||||
:func:`socket.getdefaulttimeout()`, which defaults to ``None`` (no
|
|
||||||
timeout).
|
|
||||||
|
|
||||||
.. versionchanged:: 1.8
|
.. versionchanged:: 1.8
|
||||||
|
|
||||||
|
|
|
@ -343,8 +343,6 @@ excessive.
|
||||||
``validate_min``
|
``validate_min``
|
||||||
~~~~~~~~~~~~~~~~
|
~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
.. versionadded:: 1.7
|
|
||||||
|
|
||||||
If ``validate_min=True`` is passed to
|
If ``validate_min=True`` is passed to
|
||||||
:func:`~django.forms.formsets.formset_factory`, validation will also check
|
:func:`~django.forms.formsets.formset_factory`, validation will also check
|
||||||
that the number of forms in the data set, minus those marked for
|
that the number of forms in the data set, minus those marked for
|
||||||
|
@ -371,11 +369,6 @@ deletion, is greater than or equal to ``min_num``.
|
||||||
>>> formset.non_form_errors()
|
>>> formset.non_form_errors()
|
||||||
['Please submit 3 or more forms.']
|
['Please submit 3 or more forms.']
|
||||||
|
|
||||||
.. versionchanged:: 1.7
|
|
||||||
|
|
||||||
The ``min_num`` and ``validate_min`` parameters were added to
|
|
||||||
:func:`~django.forms.formsets.formset_factory`.
|
|
||||||
|
|
||||||
Dealing with ordering and deletion of forms
|
Dealing with ordering and deletion of forms
|
||||||
-------------------------------------------
|
-------------------------------------------
|
||||||
|
|
||||||
|
@ -502,30 +495,16 @@ If you are using a :class:`ModelFormSet<django.forms.models.BaseModelFormSet>`,
|
||||||
model instances for deleted forms will be deleted when you call
|
model instances for deleted forms will be deleted when you call
|
||||||
``formset.save()``.
|
``formset.save()``.
|
||||||
|
|
||||||
.. versionchanged:: 1.7
|
If you call ``formset.save(commit=False)``, objects will not be deleted
|
||||||
|
automatically. You'll need to call ``delete()`` on each of the
|
||||||
If you call ``formset.save(commit=False)``, objects will not be deleted
|
:attr:`formset.deleted_objects
|
||||||
automatically. You'll need to call ``delete()`` on each of the
|
<django.forms.models.BaseModelFormSet.deleted_objects>` to actually delete
|
||||||
:attr:`formset.deleted_objects
|
them::
|
||||||
<django.forms.models.BaseModelFormSet.deleted_objects>` to actually delete
|
|
||||||
them::
|
|
||||||
|
|
||||||
>>> instances = formset.save(commit=False)
|
>>> instances = formset.save(commit=False)
|
||||||
>>> for obj in formset.deleted_objects:
|
>>> for obj in formset.deleted_objects:
|
||||||
... obj.delete()
|
... obj.delete()
|
||||||
|
|
||||||
If you want to maintain backwards compatibility with Django 1.6 and earlier,
|
|
||||||
you can do something like this::
|
|
||||||
|
|
||||||
>>> try:
|
|
||||||
>>> # For Django 1.7+
|
|
||||||
>>> for obj in formset.deleted_objects:
|
|
||||||
>>> obj.delete()
|
|
||||||
>>> except AssertionError:
|
|
||||||
>>> # Django 1.6 and earlier already deletes the objects, trying to
|
|
||||||
>>> # delete them a second time raises an AssertionError.
|
|
||||||
>>> pass
|
|
||||||
|
|
||||||
On the other hand, if you are using a plain ``FormSet``, it's up to you to
|
On the other hand, if you are using a plain ``FormSet``, it's up to you to
|
||||||
handle ``formset.deleted_forms``, perhaps in your formset's ``save()`` method,
|
handle ``formset.deleted_forms``, perhaps in your formset's ``save()`` method,
|
||||||
as there's no general notion of what it means to delete a form.
|
as there's no general notion of what it means to delete a form.
|
||||||
|
|
|
@ -275,8 +275,6 @@ Error messages defined on :attr:`model fields
|
||||||
<validating-objects>` step and no corresponding error messages are defined at
|
<validating-objects>` step and no corresponding error messages are defined at
|
||||||
the form level.
|
the form level.
|
||||||
|
|
||||||
.. versionadded:: 1.7
|
|
||||||
|
|
||||||
You can override the error messages from ``NON_FIELD_ERRORS`` raised by model
|
You can override the error messages from ``NON_FIELD_ERRORS`` raised by model
|
||||||
validation by adding the :data:`~django.core.exceptions.NON_FIELD_ERRORS` key
|
validation by adding the :data:`~django.core.exceptions.NON_FIELD_ERRORS` key
|
||||||
to the ``error_messages`` dictionary of the ``ModelForm``’s inner ``Meta`` class::
|
to the ``error_messages`` dictionary of the ``ModelForm``’s inner ``Meta`` class::
|
||||||
|
@ -656,15 +654,11 @@ There are a couple of things to note, however.
|
||||||
used. This means the child's ``Meta``, if it exists, otherwise the
|
used. This means the child's ``Meta``, if it exists, otherwise the
|
||||||
``Meta`` of the first parent, etc.
|
``Meta`` of the first parent, etc.
|
||||||
|
|
||||||
.. versionchanged:: 1.7
|
|
||||||
|
|
||||||
* It's possible to inherit from both ``Form`` and ``ModelForm`` simultaneously,
|
* It's possible to inherit from both ``Form`` and ``ModelForm`` simultaneously,
|
||||||
however, you must ensure that ``ModelForm`` appears first in the MRO. This is
|
however, you must ensure that ``ModelForm`` appears first in the MRO. This is
|
||||||
because these classes rely on different metaclasses and a class can only have
|
because these classes rely on different metaclasses and a class can only have
|
||||||
one metaclass.
|
one metaclass.
|
||||||
|
|
||||||
.. versionadded:: 1.7
|
|
||||||
|
|
||||||
* It's possible to declaratively remove a ``Field`` inherited from a parent class by
|
* It's possible to declaratively remove a ``Field`` inherited from a parent class by
|
||||||
setting the name to be ``None`` on the subclass.
|
setting the name to be ``None`` on the subclass.
|
||||||
|
|
||||||
|
|
|
@ -95,11 +95,6 @@ session data be expunged from time to time, the ``cache`` backend is for you.
|
||||||
If you use the ``cached_db`` session backend, you also need to follow the
|
If you use the ``cached_db`` session backend, you also need to follow the
|
||||||
configuration instructions for the `using database-backed sessions`_.
|
configuration instructions for the `using database-backed sessions`_.
|
||||||
|
|
||||||
.. versionchanged:: 1.7
|
|
||||||
|
|
||||||
Before version 1.7, the ``cached_db`` backend always used the ``default``
|
|
||||||
cache rather than the :setting:`SESSION_CACHE_ALIAS`.
|
|
||||||
|
|
||||||
Using file-based sessions
|
Using file-based sessions
|
||||||
-------------------------
|
-------------------------
|
||||||
|
|
||||||
|
|
|
@ -77,10 +77,6 @@ Optional arguments
|
||||||
The ``current_app`` argument is deprecated. Instead you should set
|
The ``current_app`` argument is deprecated. Instead you should set
|
||||||
``request.current_app``.
|
``request.current_app``.
|
||||||
|
|
||||||
.. versionchanged:: 1.7
|
|
||||||
|
|
||||||
The ``dirs`` parameter was added.
|
|
||||||
|
|
||||||
.. deprecated:: 1.8
|
.. deprecated:: 1.8
|
||||||
|
|
||||||
The ``dirs`` parameter was deprecated.
|
The ``dirs`` parameter was deprecated.
|
||||||
|
@ -167,10 +163,6 @@ Optional arguments
|
||||||
|
|
||||||
The ``status`` parameter was added.
|
The ``status`` parameter was added.
|
||||||
|
|
||||||
.. versionchanged:: 1.7
|
|
||||||
|
|
||||||
The ``dirs`` parameter was added.
|
|
||||||
|
|
||||||
.. deprecated:: 1.8
|
.. deprecated:: 1.8
|
||||||
|
|
||||||
The ``dirs`` parameter was deprecated.
|
The ``dirs`` parameter was deprecated.
|
||||||
|
@ -223,10 +215,6 @@ This example is equivalent to::
|
||||||
By default issues a temporary redirect; pass ``permanent=True`` to issue a
|
By default issues a temporary redirect; pass ``permanent=True`` to issue a
|
||||||
permanent redirect.
|
permanent redirect.
|
||||||
|
|
||||||
.. versionchanged:: 1.7
|
|
||||||
|
|
||||||
The ability to use relative URLs was added.
|
|
||||||
|
|
||||||
Examples
|
Examples
|
||||||
--------
|
--------
|
||||||
|
|
||||||
|
|
|
@ -699,11 +699,6 @@ will result in the entry ``"First sentence. Second paragraph."`` in the PO file,
|
||||||
compared to ``"\n First sentence.\n Second sentence.\n"``, if the ``trimmed``
|
compared to ``"\n First sentence.\n Second sentence.\n"``, if the ``trimmed``
|
||||||
option had not been specified.
|
option had not been specified.
|
||||||
|
|
||||||
.. versionchanged:: 1.7
|
|
||||||
|
|
||||||
The ``trimmed`` option was added.
|
|
||||||
|
|
||||||
|
|
||||||
String literals passed to tags and filters
|
String literals passed to tags and filters
|
||||||
------------------------------------------
|
------------------------------------------
|
||||||
|
|
||||||
|
@ -1275,16 +1270,13 @@ is configured correctly). It creates (or updates) a message file in the
|
||||||
directory ``locale/LANG/LC_MESSAGES``. In the ``de`` example, the file will be
|
directory ``locale/LANG/LC_MESSAGES``. In the ``de`` example, the file will be
|
||||||
``locale/de/LC_MESSAGES/django.po``.
|
``locale/de/LC_MESSAGES/django.po``.
|
||||||
|
|
||||||
.. versionchanged:: 1.7
|
When you run ``makemessages`` from the root directory of your project, the
|
||||||
|
extracted strings will be automatically distributed to the proper message files.
|
||||||
When you run ``makemessages`` from the root directory of your project, the
|
That is, a string extracted from a file of an app containing a ``locale``
|
||||||
extracted strings will be automatically distributed to the proper message
|
directory will go in a message file under that directory. A string extracted
|
||||||
files. That is, a string extracted from a file of an app containing a
|
from a file of an app without any ``locale`` directory will either go in a
|
||||||
``locale`` directory will go in a message file under that directory.
|
message file under the directory listed first in :setting:`LOCALE_PATHS` or
|
||||||
A string extracted from a file of an app without any ``locale`` directory
|
will generate an error if :setting:`LOCALE_PATHS` is empty.
|
||||||
will either go in a message file under the directory listed first in
|
|
||||||
:setting:`LOCALE_PATHS` or will generate an error if :setting:`LOCALE_PATHS`
|
|
||||||
is empty.
|
|
||||||
|
|
||||||
By default :djadmin:`django-admin makemessages <makemessages>` examines every
|
By default :djadmin:`django-admin makemessages <makemessages>` examines every
|
||||||
file that has the ``.html`` or ``.txt`` file extension. In case you want to
|
file that has the ``.html`` or ``.txt`` file extension. In case you want to
|
||||||
|
@ -1627,14 +1619,10 @@ Language cookie
|
||||||
A number of settings can be used to adjust language cookie options:
|
A number of settings can be used to adjust language cookie options:
|
||||||
|
|
||||||
* :setting:`LANGUAGE_COOKIE_NAME`
|
* :setting:`LANGUAGE_COOKIE_NAME`
|
||||||
|
|
||||||
.. versionadded:: 1.7
|
|
||||||
|
|
||||||
* :setting:`LANGUAGE_COOKIE_AGE`
|
* :setting:`LANGUAGE_COOKIE_AGE`
|
||||||
* :setting:`LANGUAGE_COOKIE_DOMAIN`
|
* :setting:`LANGUAGE_COOKIE_DOMAIN`
|
||||||
* :setting:`LANGUAGE_COOKIE_PATH`
|
* :setting:`LANGUAGE_COOKIE_PATH`
|
||||||
|
|
||||||
|
|
||||||
Implementation notes
|
Implementation notes
|
||||||
====================
|
====================
|
||||||
|
|
||||||
|
@ -1716,11 +1704,6 @@ following this algorithm:
|
||||||
* Failing that, it looks for the :data:`~django.utils.translation.LANGUAGE_SESSION_KEY`
|
* Failing that, it looks for the :data:`~django.utils.translation.LANGUAGE_SESSION_KEY`
|
||||||
key in the current user's session.
|
key in the current user's session.
|
||||||
|
|
||||||
.. versionchanged:: 1.7
|
|
||||||
|
|
||||||
In previous versions, the key was named ``django_language``, and the
|
|
||||||
``LANGUAGE_SESSION_KEY`` constant did not exist.
|
|
||||||
|
|
||||||
* Failing that, it looks for a cookie.
|
* Failing that, it looks for a cookie.
|
||||||
|
|
||||||
The name of the cookie used is set by the :setting:`LANGUAGE_COOKIE_NAME`
|
The name of the cookie used is set by the :setting:`LANGUAGE_COOKIE_NAME`
|
||||||
|
|
|
@ -498,8 +498,6 @@ specific logger following this example:
|
||||||
``django.db.backends.schema``
|
``django.db.backends.schema``
|
||||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
.. versionadded:: 1.7
|
|
||||||
|
|
||||||
Logs the SQL queries that are executed during schema changes to the database by
|
Logs the SQL queries that are executed during schema changes to the database by
|
||||||
the :doc:`migrations framework </topics/migrations>`. Note that it won't log the
|
the :doc:`migrations framework </topics/migrations>`. Note that it won't log the
|
||||||
queries executed by :class:`~django.db.migrations.operations.RunPython`.
|
queries executed by :class:`~django.db.migrations.operations.RunPython`.
|
||||||
|
|
|
@ -5,8 +5,6 @@ Migrations
|
||||||
.. module:: django.db.migrations
|
.. module:: django.db.migrations
|
||||||
:synopsis: Schema migration support for Django models
|
:synopsis: Schema migration support for Django models
|
||||||
|
|
||||||
.. versionadded:: 1.7
|
|
||||||
|
|
||||||
Migrations are Django's way of propagating changes you make to your models
|
Migrations are Django's way of propagating changes you make to your models
|
||||||
(adding a field, deleting a model, etc.) into your database schema. They're
|
(adding a field, deleting a model, etc.) into your database schema. They're
|
||||||
designed to be mostly automatic, but you'll need to know when to make
|
designed to be mostly automatic, but you'll need to know when to make
|
||||||
|
@ -663,10 +661,6 @@ Django can serialize the following:
|
||||||
- Any class reference (must be in module's top-level scope)
|
- Any class reference (must be in module's top-level scope)
|
||||||
- Anything with a custom ``deconstruct()`` method (:ref:`see below <custom-deconstruct-method>`)
|
- Anything with a custom ``deconstruct()`` method (:ref:`see below <custom-deconstruct-method>`)
|
||||||
|
|
||||||
.. versionchanged:: 1.7.1
|
|
||||||
|
|
||||||
Support for serializing timezone-aware datetimes was added.
|
|
||||||
|
|
||||||
Django can serialize the following on Python 3 only:
|
Django can serialize the following on Python 3 only:
|
||||||
|
|
||||||
- Unbound methods used from within the class body (see below)
|
- Unbound methods used from within the class body (see below)
|
||||||
|
|
|
@ -405,8 +405,6 @@ into the primary key of an actual ``Person`` object.
|
||||||
fields will be effectively unique, you can still use those fields
|
fields will be effectively unique, you can still use those fields
|
||||||
as a natural key.
|
as a natural key.
|
||||||
|
|
||||||
.. versionadded:: 1.7
|
|
||||||
|
|
||||||
Deserialization of objects with no primary key will always check whether the
|
Deserialization of objects with no primary key will always check whether the
|
||||||
model's manager has a ``get_by_natural_key()`` method and if so, use it to
|
model's manager has a ``get_by_natural_key()`` method and if so, use it to
|
||||||
populate the deserialized object's primary key.
|
populate the deserialized object's primary key.
|
||||||
|
|
|
@ -140,12 +140,6 @@ Now, our ``my_callback`` function will be called each time a request finishes.
|
||||||
decorator, simply import the ``signals`` submodule inside
|
decorator, simply import the ``signals`` submodule inside
|
||||||
:meth:`~django.apps.AppConfig.ready`.
|
:meth:`~django.apps.AppConfig.ready`.
|
||||||
|
|
||||||
.. versionchanged:: 1.7
|
|
||||||
|
|
||||||
Since :meth:`~django.apps.AppConfig.ready` didn't exist in previous
|
|
||||||
versions of Django, signal registration usually happened in the
|
|
||||||
``models`` module.
|
|
||||||
|
|
||||||
.. note::
|
.. note::
|
||||||
|
|
||||||
The :meth:`~django.apps.AppConfig.ready` method may be executed more than
|
The :meth:`~django.apps.AppConfig.ready` method may be executed more than
|
||||||
|
|
|
@ -115,10 +115,6 @@ The ``django.template.loader`` module defines two functions to load templates.
|
||||||
If you want to restrict the search to a particular template engine, pass
|
If you want to restrict the search to a particular template engine, pass
|
||||||
the engine's :setting:`NAME <TEMPLATES-NAME>` in the ``using`` argument.
|
the engine's :setting:`NAME <TEMPLATES-NAME>` in the ``using`` argument.
|
||||||
|
|
||||||
.. versionchanged:: 1.7
|
|
||||||
|
|
||||||
The ``dirs`` parameter was added.
|
|
||||||
|
|
||||||
.. deprecated:: 1.8
|
.. deprecated:: 1.8
|
||||||
|
|
||||||
The ``dirs`` parameter was deprecated.
|
The ``dirs`` parameter was deprecated.
|
||||||
|
@ -138,10 +134,6 @@ The ``django.template.loader`` module defines two functions to load templates.
|
||||||
list of template names. It tries each name in order and returns the first
|
list of template names. It tries each name in order and returns the first
|
||||||
template that exists.
|
template that exists.
|
||||||
|
|
||||||
.. versionchanged:: 1.7
|
|
||||||
|
|
||||||
The ``dirs`` parameter was added.
|
|
||||||
|
|
||||||
.. deprecated:: 1.8
|
.. deprecated:: 1.8
|
||||||
|
|
||||||
The ``dirs`` parameter was deprecated.
|
The ``dirs`` parameter was deprecated.
|
||||||
|
|
|
@ -414,16 +414,12 @@ Attributes
|
||||||
|
|
||||||
.. attribute:: DiscoverRunner.test_suite
|
.. attribute:: DiscoverRunner.test_suite
|
||||||
|
|
||||||
.. versionadded:: 1.7
|
|
||||||
|
|
||||||
The class used to build the test suite. By default it is set to
|
The class used to build the test suite. By default it is set to
|
||||||
``unittest.TestSuite``. This can be overridden if you wish to implement
|
``unittest.TestSuite``. This can be overridden if you wish to implement
|
||||||
different logic for collecting tests.
|
different logic for collecting tests.
|
||||||
|
|
||||||
.. attribute:: DiscoverRunner.test_runner
|
.. attribute:: DiscoverRunner.test_runner
|
||||||
|
|
||||||
.. versionadded:: 1.7
|
|
||||||
|
|
||||||
This is the class of the low-level test runner which is used to execute
|
This is the class of the low-level test runner which is used to execute
|
||||||
the individual tests and format the results. By default it is set to
|
the individual tests and format the results. By default it is set to
|
||||||
``unittest.TextTestRunner``. Despite the unfortunate similarity in
|
``unittest.TextTestRunner``. Despite the unfortunate similarity in
|
||||||
|
@ -594,11 +590,9 @@ can be useful during testing.
|
||||||
``False`` to speed up creation time if you don't have any test classes
|
``False`` to speed up creation time if you don't have any test classes
|
||||||
with :ref:`serialized_rollback=True <test-case-serialized-rollback>`.
|
with :ref:`serialized_rollback=True <test-case-serialized-rollback>`.
|
||||||
|
|
||||||
.. versionadded:: 1.7.1
|
|
||||||
|
|
||||||
If you are using the default test runner, you can control this with the
|
If you are using the default test runner, you can control this with the
|
||||||
the :setting:`SERIALIZE <TEST_SERIALIZE>` entry in the
|
the :setting:`SERIALIZE <TEST_SERIALIZE>` entry in the :setting:`TEST
|
||||||
:setting:`TEST <DATABASE-TEST>` dictionary
|
<DATABASE-TEST>` dictionary.
|
||||||
|
|
||||||
``keepdb`` determines if the test run should use an existing
|
``keepdb`` determines if the test run should use an existing
|
||||||
database, or create a new one. If ``True``, the existing
|
database, or create a new one. If ``True``, the existing
|
||||||
|
@ -612,10 +606,6 @@ can be useful during testing.
|
||||||
:setting:`NAME` in :setting:`DATABASES` to match the name of the test
|
:setting:`NAME` in :setting:`DATABASES` to match the name of the test
|
||||||
database.
|
database.
|
||||||
|
|
||||||
.. versionchanged:: 1.7
|
|
||||||
|
|
||||||
The ``serialize`` argument was added.
|
|
||||||
|
|
||||||
.. versionchanged:: 1.8
|
.. versionchanged:: 1.8
|
||||||
|
|
||||||
The ``keepdb`` argument was added.
|
The ``keepdb`` argument was added.
|
||||||
|
|
|
@ -152,10 +152,8 @@ entirely!). If you want to use a different database name, specify
|
||||||
:setting:`NAME <TEST_NAME>` in the :setting:`TEST <DATABASE-TEST>`
|
:setting:`NAME <TEST_NAME>` in the :setting:`TEST <DATABASE-TEST>`
|
||||||
dictionary for any given database in :setting:`DATABASES`.
|
dictionary for any given database in :setting:`DATABASES`.
|
||||||
|
|
||||||
.. versionchanged:: 1.7
|
On PostgreSQL, :setting:`USER` will also need read access to the built-in
|
||||||
|
``postgres`` database.
|
||||||
On PostgreSQL, :setting:`USER` will also need read access to the built-in
|
|
||||||
``postgres`` database.
|
|
||||||
|
|
||||||
Aside from using a separate database, the test runner will otherwise
|
Aside from using a separate database, the test runner will otherwise
|
||||||
use all of the same database settings you have in your settings file:
|
use all of the same database settings you have in your settings file:
|
||||||
|
@ -175,12 +173,6 @@ If using a SQLite in-memory database with Python 3.4+ and SQLite 3.7.13+,
|
||||||
`shared cache <https://www.sqlite.org/sharedcache.html>`_ will be enabled, so
|
`shared cache <https://www.sqlite.org/sharedcache.html>`_ will be enabled, so
|
||||||
you can write tests with ability to share the database between threads.
|
you can write tests with ability to share the database between threads.
|
||||||
|
|
||||||
.. versionchanged:: 1.7
|
|
||||||
|
|
||||||
The different options in the :setting:`TEST <DATABASE-TEST>` database
|
|
||||||
setting used to be separate options in the database settings dictionary,
|
|
||||||
prefixed with ``TEST_``.
|
|
||||||
|
|
||||||
.. versionadded:: 1.8
|
.. versionadded:: 1.8
|
||||||
|
|
||||||
The ability to use SQLite with a shared cache as described above was added.
|
The ability to use SQLite with a shared cache as described above was added.
|
||||||
|
@ -194,8 +186,6 @@ you can write tests with ability to share the database between threads.
|
||||||
your tests. *It is a bad idea to have such import-time database queries in
|
your tests. *It is a bad idea to have such import-time database queries in
|
||||||
your code* anyway - rewrite your code so that it doesn't do this.
|
your code* anyway - rewrite your code so that it doesn't do this.
|
||||||
|
|
||||||
.. versionadded:: 1.7
|
|
||||||
|
|
||||||
This also applies to customized implementations of
|
This also applies to customized implementations of
|
||||||
:meth:`~django.apps.AppConfig.ready()`.
|
:meth:`~django.apps.AppConfig.ready()`.
|
||||||
|
|
||||||
|
|
|
@ -130,10 +130,6 @@ Use the ``django.test.Client`` class to make requests.
|
||||||
|
|
||||||
.. method:: Client.get(path, data=None, follow=False, secure=False, **extra)
|
.. method:: Client.get(path, data=None, follow=False, secure=False, **extra)
|
||||||
|
|
||||||
.. versionadded:: 1.7
|
|
||||||
|
|
||||||
The ``secure`` argument was added.
|
|
||||||
|
|
||||||
Makes a GET request on the provided ``path`` and returns a ``Response``
|
Makes a GET request on the provided ``path`` and returns a ``Response``
|
||||||
object, which is documented below.
|
object, which is documented below.
|
||||||
|
|
||||||
|
@ -435,8 +431,6 @@ Specifically, a ``Response`` object has the following attributes:
|
||||||
|
|
||||||
.. attribute:: wsgi_request
|
.. attribute:: wsgi_request
|
||||||
|
|
||||||
.. versionadded:: 1.7
|
|
||||||
|
|
||||||
The ``WSGIRequest`` instance generated by the test handler that
|
The ``WSGIRequest`` instance generated by the test handler that
|
||||||
generated the response.
|
generated the response.
|
||||||
|
|
||||||
|
@ -845,25 +839,15 @@ out the `full reference`_ for more details.
|
||||||
.. _full reference: http://selenium-python.readthedocs.org/en/latest/api.html
|
.. _full reference: http://selenium-python.readthedocs.org/en/latest/api.html
|
||||||
.. _Firefox: http://www.mozilla.com/firefox/
|
.. _Firefox: http://www.mozilla.com/firefox/
|
||||||
|
|
||||||
.. versionchanged:: 1.7
|
.. tip::
|
||||||
|
|
||||||
Before Django 1.7 ``LiveServerTestCase`` used to rely on the
|
If you use the :mod:`~django.contrib.staticfiles` app in your project and
|
||||||
:doc:`staticfiles contrib app </howto/static-files/index>` to get the
|
need to perform live testing, then you might want to use the
|
||||||
static assets of the application(s) under test transparently served at their
|
|
||||||
expected locations during the execution of these tests.
|
|
||||||
|
|
||||||
In Django 1.7 this dependency of core functionality on a ``contrib``
|
|
||||||
application has been removed, because of which ``LiveServerTestCase``
|
|
||||||
ability in this respect has been retrofitted to simply publish the contents
|
|
||||||
of the file system under :setting:`STATIC_ROOT` at the :setting:`STATIC_URL`
|
|
||||||
URL.
|
|
||||||
|
|
||||||
If you use the ``staticfiles`` app in your project and need to perform live
|
|
||||||
testing then you might want to consider using the
|
|
||||||
:class:`~django.contrib.staticfiles.testing.StaticLiveServerTestCase`
|
:class:`~django.contrib.staticfiles.testing.StaticLiveServerTestCase`
|
||||||
subclass shipped with it instead because it's the one that implements the
|
subclass which transparently serves all the assets during execution of
|
||||||
original behavior now. See :ref:`the relevant documentation
|
its tests in a way very similar to what we get at development time with
|
||||||
<staticfiles-testing-support>` for more details.
|
``DEBUG=True``, i.e. without having to collect them using
|
||||||
|
:djadmin:`collectstatic`.
|
||||||
|
|
||||||
.. note::
|
.. note::
|
||||||
|
|
||||||
|
@ -1135,8 +1119,6 @@ in the ``with`` block and reset its value to the previous state afterwards.
|
||||||
|
|
||||||
.. method:: SimpleTestCase.modify_settings()
|
.. method:: SimpleTestCase.modify_settings()
|
||||||
|
|
||||||
.. versionadded:: 1.7
|
|
||||||
|
|
||||||
It can prove unwieldy to redefine settings that contain a list of values. In
|
It can prove unwieldy to redefine settings that contain a list of values. In
|
||||||
practice, adding or removing values is often sufficient. The
|
practice, adding or removing values is often sufficient. The
|
||||||
:meth:`~django.test.SimpleTestCase.modify_settings` context manager makes it
|
:meth:`~django.test.SimpleTestCase.modify_settings` context manager makes it
|
||||||
|
@ -1189,14 +1171,8 @@ The decorator can also be applied to :class:`~django.test.TestCase` classes::
|
||||||
response = self.client.get('/sekrit/')
|
response = self.client.get('/sekrit/')
|
||||||
self.assertRedirects(response, '/other/login/?next=/sekrit/')
|
self.assertRedirects(response, '/other/login/?next=/sekrit/')
|
||||||
|
|
||||||
.. versionchanged:: 1.7
|
|
||||||
|
|
||||||
Previously, ``override_settings`` was imported from ``django.test.utils``.
|
|
||||||
|
|
||||||
.. function:: modify_settings
|
.. function:: modify_settings
|
||||||
|
|
||||||
.. versionadded:: 1.7
|
|
||||||
|
|
||||||
Likewise, Django provides the :func:`~django.test.modify_settings`
|
Likewise, Django provides the :func:`~django.test.modify_settings`
|
||||||
decorator::
|
decorator::
|
||||||
|
|
||||||
|
@ -1265,11 +1241,6 @@ have been overridden, like this::
|
||||||
del settings.LOGIN_URL
|
del settings.LOGIN_URL
|
||||||
...
|
...
|
||||||
|
|
||||||
.. versionchanged:: 1.7
|
|
||||||
|
|
||||||
Previously, you could only simulate the deletion of a setting which was
|
|
||||||
explicitly overridden.
|
|
||||||
|
|
||||||
When overriding settings, make sure to handle the cases in which your app's
|
When overriding settings, make sure to handle the cases in which your app's
|
||||||
code uses a cache or similar feature that retains state even if the setting is
|
code uses a cache or similar feature that retains state even if the setting is
|
||||||
changed. Django provides the :data:`django.test.signals.setting_changed`
|
changed. Django provides the :data:`django.test.signals.setting_changed`
|
||||||
|
@ -1445,14 +1416,10 @@ your test suite.
|
||||||
host (for example, initializing the test client with
|
host (for example, initializing the test client with
|
||||||
``Client(HTTP_HOST="testhost")``.
|
``Client(HTTP_HOST="testhost")``.
|
||||||
|
|
||||||
.. versionadded:: 1.7
|
|
||||||
|
|
||||||
If ``fetch_redirect_response`` is ``False``, the final page won't be
|
If ``fetch_redirect_response`` is ``False``, the final page won't be
|
||||||
loaded. Since the test client can't fetch externals URLs, this is
|
loaded. Since the test client can't fetch externals URLs, this is
|
||||||
particularly useful if ``expected_url`` isn't part of your Django app.
|
particularly useful if ``expected_url`` isn't part of your Django app.
|
||||||
|
|
||||||
.. versionadded:: 1.7
|
|
||||||
|
|
||||||
Scheme is handled correctly when making comparisons between two URLs. If
|
Scheme is handled correctly when making comparisons between two URLs. If
|
||||||
there isn't any scheme specified in the location where we are redirected to,
|
there isn't any scheme specified in the location where we are redirected to,
|
||||||
the original request's scheme is used. If present, the scheme in
|
the original request's scheme is used. If present, the scheme in
|
||||||
|
@ -1564,11 +1531,6 @@ your test suite.
|
||||||
|
|
||||||
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.7
|
|
||||||
|
|
||||||
The method now accepts a ``msg`` parameter to allow customization of
|
|
||||||
error message
|
|
||||||
|
|
||||||
.. method:: TransactionTestCase.assertNumQueries(num, func, *args, **kwargs)
|
.. method:: TransactionTestCase.assertNumQueries(num, func, *args, **kwargs)
|
||||||
|
|
||||||
Asserts that when ``func`` is called with ``*args`` and ``**kwargs`` that
|
Asserts that when ``func`` is called with ``*args`` and ``**kwargs`` that
|
||||||
|
@ -1705,10 +1667,6 @@ it would under MySQL with MyISAM tables)::
|
||||||
def test_transaction_behavior(self):
|
def test_transaction_behavior(self):
|
||||||
# ... conditional test code
|
# ... conditional test code
|
||||||
|
|
||||||
.. versionchanged:: 1.7
|
|
||||||
|
|
||||||
``skipIfDBFeature`` can now be used to decorate a ``TestCase`` class.
|
|
||||||
|
|
||||||
.. versionchanged:: 1.8
|
.. versionchanged:: 1.8
|
||||||
|
|
||||||
``skipIfDBFeature`` can accept multiple feature strings.
|
``skipIfDBFeature`` can accept multiple feature strings.
|
||||||
|
@ -1727,10 +1685,6 @@ under MySQL with MyISAM tables)::
|
||||||
def test_transaction_behavior(self):
|
def test_transaction_behavior(self):
|
||||||
# ... conditional test code
|
# ... conditional test code
|
||||||
|
|
||||||
.. versionchanged:: 1.7
|
|
||||||
|
|
||||||
``skipUnlessDBFeature`` can now be used to decorate a ``TestCase`` class.
|
|
||||||
|
|
||||||
.. versionchanged:: 1.8
|
.. versionchanged:: 1.8
|
||||||
|
|
||||||
``skipUnlessDBFeature`` can accept multiple feature strings.
|
``skipUnlessDBFeature`` can accept multiple feature strings.
|
||||||
|
|
Loading…
Reference in New Issue