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
|
||||
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
|
||||
|
||||
The ``max_length`` argument was added.
|
||||
|
|
|
@ -2,8 +2,6 @@
|
|||
Custom Lookups
|
||||
==============
|
||||
|
||||
.. versionadded:: 1.7
|
||||
|
||||
.. currentmodule:: django.db.models
|
||||
|
||||
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)
|
||||
|
||||
.. versionadded:: 1.7
|
||||
|
||||
Uses the system check framework to inspect the entire Django project for
|
||||
potential problems. Serious problems are raised as a :class:`CommandError`;
|
||||
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
|
||||
--------------------
|
||||
|
||||
.. 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
|
||||
``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
|
||||
|
@ -590,11 +584,8 @@ valid Django filter lookups: ``exact``, ``iexact``, ``contains``, ``icontains``,
|
|||
``endswith``, ``iendswith``, ``range``, ``year``, ``month``, ``day``,
|
||||
``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
|
||||
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
|
||||
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
|
||||
==========
|
||||
|
||||
|
|
|
@ -62,11 +62,6 @@ This will download and install Django.
|
|||
After the installation has completed, you can verify your Django installation
|
||||
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
|
||||
with Django.
|
||||
|
||||
|
|
|
@ -39,17 +39,6 @@ sample settings module that uses the SQLite database. To run the tests:
|
|||
$ cd django-repo/tests
|
||||
$ 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
|
||||
checkout to your ``PYTHONPATH`` or by installing the source checkout using pip.
|
||||
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`.
|
||||
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
|
||||
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
|
||||
|
|
|
@ -4,8 +4,6 @@ Applications
|
|||
|
||||
.. module:: django.apps
|
||||
|
||||
.. versionadded:: 1.7
|
||||
|
||||
Django contains a registry of installed applications that stores configuration
|
||||
and provides introspection. It also maintains a list of available :doc:`models
|
||||
</topics/db/models>`.
|
||||
|
|
|
@ -2,8 +2,6 @@
|
|||
System check framework
|
||||
======================
|
||||
|
||||
.. versionadded:: 1.7
|
||||
|
||||
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.
|
||||
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])
|
||||
|
||||
.. versionadded:: 1.7
|
||||
|
||||
There is also a decorator for registering your ``ModelAdmin`` classes::
|
||||
|
||||
from django.contrib import admin
|
||||
|
@ -134,15 +132,11 @@ application and imports it.
|
|||
|
||||
.. class:: apps.AdminConfig
|
||||
|
||||
.. versionadded:: 1.7
|
||||
|
||||
This is the default :class:`~django.apps.AppConfig` class for the admin.
|
||||
It calls :func:`~django.contrib.admin.autodiscover()` when Django starts.
|
||||
|
||||
.. class:: apps.SimpleAdminConfig
|
||||
|
||||
.. versionadded:: 1.7
|
||||
|
||||
This class works like :class:`~django.contrib.admin.apps.AdminConfig`,
|
||||
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
|
||||
application. Such modules are expected to register models with the admin.
|
||||
|
||||
.. versionchanged:: 1.7
|
||||
|
||||
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.
|
||||
Typically you won't need to call this function directly as
|
||||
:class:`~django.contrib.admin.apps.AdminConfig` calls it when Django starts.
|
||||
|
||||
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
|
||||
|
@ -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
|
||||
``'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
|
||||
----------------------
|
||||
|
||||
|
@ -661,8 +643,6 @@ subclass::
|
|||
The above will tell Django to order by the ``first_name`` field when
|
||||
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
|
||||
hyphen prefix on the field name. Using the above example, this would
|
||||
look like::
|
||||
|
@ -737,10 +717,6 @@ subclass::
|
|||
list_display = ('timestamp', 'message')
|
||||
list_display_links = None
|
||||
|
||||
.. versionchanged:: 1.7
|
||||
|
||||
``None`` was added as a valid ``list_display_links`` value.
|
||||
|
||||
.. _admin-list-editable:
|
||||
|
||||
.. attribute:: ModelAdmin.list_editable
|
||||
|
@ -1176,8 +1152,6 @@ subclass::
|
|||
|
||||
.. attribute:: ModelAdmin.view_on_site
|
||||
|
||||
.. versionadded:: 1.7
|
||||
|
||||
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.
|
||||
|
||||
|
@ -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
|
||||
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)
|
||||
|
||||
.. versionadded:: 1.7
|
||||
|
||||
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
|
||||
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)
|
||||
|
||||
.. versionadded:: 1.7
|
||||
|
||||
The ``get_search_fields`` method is given the ``HttpRequest`` and is expected
|
||||
to return the same kind of sequence type as for the
|
||||
: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)
|
||||
|
||||
.. versionadded:: 1.7
|
||||
|
||||
Determines the :class:`~django.http.HttpResponse` for the
|
||||
:meth:`delete_view` stage.
|
||||
|
||||
|
@ -1744,8 +1708,6 @@ templates used by the :class:`ModelAdmin` views:
|
|||
|
||||
.. method:: ModelAdmin.get_changeform_initial_data(request)
|
||||
|
||||
.. versionadded:: 1.7
|
||||
|
||||
A hook for the initial data on admin change forms. By default, fields are
|
||||
given initial values from ``GET`` parameters. For instance,
|
||||
``?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
|
||||
|
||||
.. versionadded:: 1.7
|
||||
|
||||
This controls the minimum number of forms to show in the inline.
|
||||
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)
|
||||
|
||||
.. versionadded:: 1.7
|
||||
|
||||
Returns the minimum number of inline forms to use. By default,
|
||||
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
|
||||
|
||||
.. versionadded:: 1.7
|
||||
|
||||
The text to put at the top of each admin page, as an ``<h1>`` (a string).
|
||||
By default, this is "Django administration".
|
||||
|
||||
.. attribute:: AdminSite.site_title
|
||||
|
||||
.. versionadded:: 1.7
|
||||
|
||||
The text to put at the end of each admin page's ``<title>`` (a string). By
|
||||
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
|
||||
|
||||
.. versionadded:: 1.7
|
||||
|
||||
The text to put at the top of the admin index page (a string). By default,
|
||||
this is "Site administration".
|
||||
|
||||
|
@ -2514,8 +2466,6 @@ Templates can override or extend base admin templates as described in
|
|||
|
||||
.. method:: AdminSite.each_context(request)
|
||||
|
||||
.. versionadded:: 1.7
|
||||
|
||||
Returns a dictionary of variables to put in the template context for
|
||||
every page in the admin site.
|
||||
|
||||
|
|
|
@ -215,12 +215,8 @@ Methods
|
|||
.. method:: email_user(subject, message, from_email=None, **kwargs)
|
||||
|
||||
Sends an email to the user. If ``from_email`` is ``None``, Django uses
|
||||
the :setting:`DEFAULT_FROM_EMAIL`.
|
||||
|
||||
.. versionchanged:: 1.7
|
||||
|
||||
Any ``**kwargs`` are passed to the underlying
|
||||
:meth:`~django.core.mail.send_mail()` call.
|
||||
the :setting:`DEFAULT_FROM_EMAIL`. Any ``**kwargs`` are passed to the
|
||||
underlying :meth:`~django.core.mail.send_mail()` call.
|
||||
|
||||
Manager methods
|
||||
---------------
|
||||
|
|
|
@ -366,8 +366,6 @@ Reverse generic relations
|
|||
|
||||
.. attribute:: related_query_name
|
||||
|
||||
.. versionadded:: 1.7
|
||||
|
||||
The relation on the related object back to this object doesn't exist by
|
||||
default. Setting ``related_query_name`` creates a relation from the
|
||||
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()
|
||||
[<TaggedItem: django>, <TaggedItem: python>]
|
||||
|
||||
.. versionadded:: 1.7
|
||||
|
||||
Defining :class:`~django.contrib.contenttypes.fields.GenericRelation` with
|
||||
``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`
|
||||
argument on ``GenericForeignKey``.
|
||||
|
||||
.. versionchanged:: 1.7
|
||||
|
||||
``min_num`` and ``validate_min`` were added.
|
||||
|
||||
|
||||
.. module:: django.contrib.contenttypes.admin
|
||||
|
||||
Generic relations in admin
|
||||
------------------------------------
|
||||
--------------------------
|
||||
|
||||
The :mod:`django.contrib.contenttypes.admin` module provides
|
||||
:class:`~django.contrib.contenttypes.admin.GenericTabularInline` and
|
||||
|
|
|
@ -737,16 +737,12 @@ For example::
|
|||
|
||||
.. method:: crosses(other)
|
||||
|
||||
.. versionadded:: 1.7
|
||||
|
||||
.. note::
|
||||
|
||||
GEOS 3.3 is *required* to use this predicate.
|
||||
|
||||
.. method:: disjoint(other)
|
||||
|
||||
.. versionadded:: 1.7
|
||||
|
||||
.. note::
|
||||
|
||||
GEOS 3.3 is *required* to use this predicate.
|
||||
|
@ -755,24 +751,18 @@ For example::
|
|||
|
||||
.. method:: overlaps(other)
|
||||
|
||||
.. versionadded:: 1.7
|
||||
|
||||
.. note::
|
||||
|
||||
GEOS 3.3 is *required* to use this predicate.
|
||||
|
||||
.. method:: touches(other)
|
||||
|
||||
.. versionadded:: 1.7
|
||||
|
||||
.. note::
|
||||
|
||||
GEOS 3.3 is *required* to use this predicate.
|
||||
|
||||
.. method:: within(other)
|
||||
|
||||
.. versionadded:: 1.7
|
||||
|
||||
.. note::
|
||||
|
||||
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
|
||||
for the next request.
|
||||
|
||||
.. versionadded:: 1.7
|
||||
|
||||
The context processor also provides a ``DEFAULT_MESSAGE_LEVELS`` variable which
|
||||
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>
|
||||
{% endif %}
|
||||
|
||||
|
||||
|
||||
**Outside of templates**, you can use
|
||||
:func:`~django.contrib.messages.get_messages`::
|
||||
|
||||
|
@ -253,8 +249,6 @@ The ``Message`` class
|
|||
* ``extra_tags``: A string containing custom tags for this message,
|
||||
separated by spaces. It's empty by default.
|
||||
|
||||
.. versionadded:: 1.7
|
||||
|
||||
* ``level_tag``: The string representation of the level. By default, it's
|
||||
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.
|
||||
|
@ -438,8 +432,6 @@ behavior:
|
|||
* :setting:`MESSAGE_STORAGE`
|
||||
* :setting:`MESSAGE_TAGS`
|
||||
|
||||
.. versionadded:: 1.7
|
||||
|
||||
For backends that use cookies, the settings for the cookie are taken from
|
||||
the session cookie settings:
|
||||
|
||||
|
|
|
@ -89,20 +89,14 @@ Middleware
|
|||
|
||||
.. attribute:: response_gone_class
|
||||
|
||||
.. versionadded:: 1.7
|
||||
|
||||
The :class:`~django.http.HttpResponse` class used when a
|
||||
:class:`~django.contrib.redirects.models.Redirect` is not
|
||||
found for the requested path or has a blank ``new_path``
|
||||
value.
|
||||
:class:`~django.contrib.redirects.models.Redirect` is not found for the
|
||||
requested path or has a blank ``new_path`` value.
|
||||
|
||||
Defaults to :class:`~django.http.HttpResponseGone`.
|
||||
|
||||
.. 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`.
|
||||
|
|
|
@ -181,8 +181,6 @@ Sitemap class reference
|
|||
representing the last-modified date/time for *every* object returned by
|
||||
:attr:`~Sitemap.items()`.
|
||||
|
||||
.. versionadded:: 1.7
|
||||
|
||||
If all items in a sitemap have a :attr:`~Sitemap.lastmod`, the sitemap
|
||||
generated by :func:`views.sitemap` will have a ``Last-Modified``
|
||||
header equal to the latest ``lastmod``. You can activate the
|
||||
|
|
|
@ -389,8 +389,6 @@ define :class:`~django.contrib.sites.managers.CurrentSiteManager`.
|
|||
Site middleware
|
||||
===============
|
||||
|
||||
.. versionadded:: 1.7
|
||||
|
||||
If you often use this pattern::
|
||||
|
||||
from django.contrib.sites.models import Site
|
||||
|
|
|
@ -78,13 +78,6 @@ respectively. For example::
|
|||
Then set the :setting:`STATICFILES_STORAGE` setting to
|
||||
``'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
|
||||
|
||||
Some commonly used options are:
|
||||
|
@ -174,10 +167,6 @@ get all the directories which were searched::
|
|||
/home/polls.com/core/static
|
||||
/some/other/path/static
|
||||
|
||||
.. versionadded:: 1.7
|
||||
|
||||
The additional output of which directories were searched was added.
|
||||
|
||||
.. _staticfiles-runserver:
|
||||
|
||||
runserver
|
||||
|
@ -244,8 +233,6 @@ counterparts and update the cache appropriately.
|
|||
ManifestStaticFilesStorage
|
||||
--------------------------
|
||||
|
||||
.. versionadded:: 1.7
|
||||
|
||||
.. class:: storage.ManifestStaticFilesStorage
|
||||
|
||||
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')
|
||||
searched_locations = finders.searched_locations
|
||||
|
||||
.. versionadded:: 1.7
|
||||
|
||||
The ``searched_locations`` attribute was added.
|
||||
|
||||
Other Helpers
|
||||
=============
|
||||
|
||||
|
@ -423,12 +406,6 @@ This view function serves static files in development.
|
|||
**insecure**. This is only intended for local development, and should
|
||||
**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::
|
||||
|
||||
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
|
||||
``staticfiles`` finders. This means you don't need to run
|
||||
: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`.
|
||||
* ``categories`` should be a sequence of Unicode objects.
|
||||
|
||||
.. versionadded:: 1.7
|
||||
|
||||
The optional ``updateddate`` argument was added.
|
||||
|
||||
:meth:`.SyndicationFeed.write`
|
||||
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.
|
||||
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.
|
||||
``manage.py`` is a thin wrapper around ``django-admin`` that takes care of
|
||||
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.
|
||||
|
||||
.. 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
|
||||
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
|
||||
|
@ -105,8 +96,6 @@ check <appname appname ...>
|
|||
|
||||
.. django-admin:: check
|
||||
|
||||
.. versionchanged:: 1.7
|
||||
|
||||
Uses the :doc:`system check framework </ref/checks>` to inspect
|
||||
the entire Django project for common problems.
|
||||
|
||||
|
@ -192,18 +181,13 @@ createcachetable
|
|||
|
||||
.. django-admin:: createcachetable
|
||||
|
||||
Creates the cache tables for use with the database cache backend. See
|
||||
:doc:`/topics/cache` for more information.
|
||||
Creates the cache tables for use with the database cache backend using the
|
||||
information from your settings file. See :doc:`/topics/cache` for more
|
||||
information.
|
||||
|
||||
The :djadminopt:`--database` option can be used to specify the database
|
||||
onto which the cachetable will be installed.
|
||||
|
||||
.. 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.
|
||||
onto which the cache table will be installed, but since this information is
|
||||
pulled from your settings by default, it's typically not needed.
|
||||
|
||||
dbshell
|
||||
-------
|
||||
|
@ -286,8 +270,6 @@ from which data will be dumped.
|
|||
|
||||
.. django-admin-option:: --natural-foreign
|
||||
|
||||
.. versionadded:: 1.7
|
||||
|
||||
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
|
||||
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
|
||||
|
||||
.. versionadded:: 1.7
|
||||
|
||||
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
|
||||
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
|
||||
for fixtures in rather than looking through all apps.
|
||||
|
||||
.. versionchanged:: 1.7
|
||||
|
||||
``--app`` was added.
|
||||
|
||||
.. versionchanged:: 1.8
|
||||
|
||||
``--ignorenonexistent`` also ignores non-existent models.
|
||||
|
@ -605,12 +581,6 @@ Example usage::
|
|||
django-admin makemessages -x pt_BR
|
||||
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
|
||||
|
||||
Use the ``--domain`` or ``-d`` option to change the domain of the messages files.
|
||||
|
@ -671,8 +641,6 @@ makemigrations [<app_label>]
|
|||
|
||||
.. django-admin:: makemigrations
|
||||
|
||||
.. versionadded:: 1.7
|
||||
|
||||
Creates new migrations based on the changes detected to your models.
|
||||
Migrations, their relationship with apps and more are covered in depth in
|
||||
:doc:`the migrations documentation</topics/migrations>`.
|
||||
|
@ -722,8 +690,6 @@ migrate [<app_label> [<migrationname>]]
|
|||
|
||||
.. django-admin:: migrate
|
||||
|
||||
.. versionadded:: 1.7
|
||||
|
||||
Synchronizes the database state with the current set of models and migrations.
|
||||
Migrations, their relationship with apps and more are covered in depth in
|
||||
: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
|
||||
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
|
||||
autoreload the server (rather than polling file modification timestamps each
|
||||
second). This offers better scaling to large projects, reduction in response
|
||||
|
@ -800,10 +762,6 @@ reduction.
|
|||
|
||||
.. _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
|
||||
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
|
||||
|
@ -1468,8 +1426,6 @@ that ``django-admin`` should print to the console.
|
|||
|
||||
.. django-admin-option:: --no-color
|
||||
|
||||
.. versionadded:: 1.7
|
||||
|
||||
Example usage::
|
||||
|
||||
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
|
||||
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/
|
||||
|
||||
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
|
||||
with ``sql``.
|
||||
|
||||
|
||||
See :doc:`/howto/custom-management-commands` for how to add customized actions.
|
||||
|
||||
|
||||
==========================================
|
||||
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
|
||||
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
|
||||
|
||||
The file system permissions that the directory will receive when it is
|
||||
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::
|
||||
|
||||
The ``FileSystemStorage.delete()`` method will not raise
|
||||
|
@ -129,15 +118,6 @@ The Storage Class
|
|||
7 character 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
|
||||
|
||||
The ``max_length`` argument was added.
|
||||
|
|
|
@ -57,8 +57,6 @@ Here are some useful attributes of ``UploadedFile``:
|
|||
|
||||
.. attribute:: UploadedFile.content_type_extra
|
||||
|
||||
.. versionadded:: 1.7
|
||||
|
||||
A dictionary containing extra parameters passed to the ``content-type``
|
||||
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
|
||||
|
@ -220,10 +218,6 @@ attributes:
|
|||
This method may raise a ``StopFutureHandlers`` exception to prevent
|
||||
future handlers from handling this file.
|
||||
|
||||
.. versionadded:: 1.7
|
||||
|
||||
The ``content_type_extra`` parameter was added.
|
||||
|
||||
.. method:: FileUploadHandler.upload_complete()
|
||||
|
||||
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()
|
||||
|
||||
.. versionadded:: 1.7
|
||||
|
||||
Returns a ``dict`` that maps fields to their original ``ValidationError``
|
||||
instances.
|
||||
|
||||
|
@ -150,8 +148,6 @@ messages in ``Form.errors``.
|
|||
|
||||
.. method:: Form.errors.as_json(escape_html=False)
|
||||
|
||||
.. versionadded:: 1.7
|
||||
|
||||
Returns the errors serialized as JSON.
|
||||
|
||||
>>> f.errors.as_json()
|
||||
|
@ -171,8 +167,6 @@ directly in HTML.
|
|||
|
||||
.. method:: Form.add_error(field, error)
|
||||
|
||||
.. versionadded:: 1.7
|
||||
|
||||
This method allows adding errors to specific fields from within the
|
||||
``Form.clean()`` method, or from outside the form altogether; for instance
|
||||
from a view.
|
||||
|
@ -762,10 +756,6 @@ Python 2)::
|
|||
<p>Sender: <input type="email" name="sender" value="invalid email address" /></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
|
||||
~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
|
@ -1017,10 +1007,8 @@ classes::
|
|||
<li>Instrument: <input type="text" name="instrument" /></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
|
||||
|
||||
|
|
|
@ -970,8 +970,6 @@ Slightly complex built-in ``Field`` classes
|
|||
|
||||
.. attribute:: require_all_fields
|
||||
|
||||
.. versionadded:: 1.7
|
||||
|
||||
Defaults to ``True``, in which case a ``required`` validation error
|
||||
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.
|
||||
|
||||
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)
|
||||
|
||||
.. versionadded:: 1.7
|
||||
|
||||
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
|
||||
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 "
|
||||
"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
|
||||
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 widget.
|
||||
|
||||
.. versionchanged:: 1.7
|
||||
|
||||
When looping over the radio buttons, the ``label`` and ``input`` tags include
|
||||
``for`` and ``id`` attributes, respectively. Each radio button has an
|
||||
``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
|
||||
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
|
||||
``id_for_label`` attribute to output the element's ID.
|
||||
When looping over the checkboxes, the ``label`` and ``input`` tags include
|
||||
``for`` and ``id`` attributes, respectively. Each checkbox has an
|
||||
``id_for_label`` attribute to output the element's ID.
|
||||
|
||||
.. _file-upload-widgets:
|
||||
|
||||
|
@ -769,8 +765,6 @@ Composite widgets
|
|||
|
||||
.. attribute:: SelectDateWidget.months
|
||||
|
||||
.. versionadded:: 1.7
|
||||
|
||||
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
|
||||
|
|
|
@ -354,8 +354,6 @@ Site middleware
|
|||
|
||||
.. class:: CurrentSiteMiddleware
|
||||
|
||||
.. versionadded:: 1.7
|
||||
|
||||
Adds the ``site`` attribute representing the current site to every incoming
|
||||
``HttpRequest`` object. See the :ref:`sites documentation <site-middleware>`.
|
||||
|
||||
|
@ -378,8 +376,6 @@ Middleware for utilizing Web server provided authentication. See
|
|||
|
||||
.. class:: SessionAuthenticationMiddleware
|
||||
|
||||
.. versionadded:: 1.7
|
||||
|
||||
Allows a user's sessions to be invalidated when their password changes. See
|
||||
:ref:`session-invalidation-on-password-change` for details. This middleware must
|
||||
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
|
||||
field like ``models.IntegerField()`` on most databases.
|
||||
|
||||
.. versionchanged:: 1.7.1
|
||||
|
||||
The ``preserve_default`` argument was added.
|
||||
|
||||
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
|
||||
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
|
||||
|
||||
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,
|
||||
variables, and even other expressions.
|
||||
|
||||
.. versionadded:: 1.7
|
||||
|
||||
Support for the power operator ``**`` was added.
|
||||
|
||||
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
|
||||
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
|
||||
:attr:`~Field.default` then a label containing ``"---------"`` will be rendered
|
||||
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
|
||||
specified for each field in the `Field types`_ section below.
|
||||
|
||||
.. versionadded:: 1.7
|
||||
|
||||
The ``unique_for_date`` error message key was added.
|
||||
|
||||
``help_text``
|
||||
-------------
|
||||
|
||||
|
@ -592,10 +586,6 @@ Has two optional arguments:
|
|||
|
||||
.. 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`
|
||||
setting to determine the value of the
|
||||
: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
|
||||
: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.
|
||||
However it is not enforced at the model or database level. Use a
|
||||
:class:`CharField` for that.
|
||||
If you specify a ``max_length`` attribute, it will be reflected in the
|
||||
:class:`~django.forms.Textarea` widget of the auto-generated form field.
|
||||
However it is not enforced at the model or database level. Use a
|
||||
:class:`CharField` for that.
|
||||
|
||||
.. 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
|
||||
``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::
|
||||
|
||||
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
|
||||
|
||||
.. versionadded:: 1.7
|
||||
|
||||
Controls the migration framework's reaction if this :class:`ForeignKey`
|
||||
is pointing at a swappable model. If it is ``True`` - the default -
|
||||
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
|
||||
|
||||
.. versionadded:: 1.7
|
||||
|
||||
Only used when a custom intermediary model is specified. Django will
|
||||
normally determine which fields of the intermediary model to use in order
|
||||
to establish a many-to-many relationship automatically. However,
|
||||
|
@ -1470,8 +1449,6 @@ that control how the relationship functions.
|
|||
|
||||
.. attribute:: ManyToManyField.swappable
|
||||
|
||||
.. versionadded:: 1.7
|
||||
|
||||
Controls the migration framework's reaction if this :class:`ManyToManyField`
|
||||
is pointing at a swappable model. If it is ``True`` - the default -
|
||||
then if the :class:`ManyToManyField` is pointing at a model which matches
|
||||
|
@ -1699,8 +1676,6 @@ Field API reference
|
|||
``"year"``, ``"month"``, ``"day"``, ``"isnull"``, ``"search"``,
|
||||
``"regex"``, and ``"iregex"``.
|
||||
|
||||
.. versionadded:: 1.7
|
||||
|
||||
If you are using :doc:`Custom lookups </ref/models/lookups>` the
|
||||
``lookup_type`` can be any ``lookup_name`` registered in the field.
|
||||
|
||||
|
@ -1752,8 +1727,6 @@ Field API reference
|
|||
|
||||
.. method:: deconstruct()
|
||||
|
||||
.. versionadded:: 1.7
|
||||
|
||||
Returns a 4-tuple with enough information to recreate the field:
|
||||
|
||||
1. The name of the field on the model.
|
||||
|
|
|
@ -683,11 +683,6 @@ For example::
|
|||
MyModel(id=1) != MultitableInherited(id=1)
|
||||
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__``
|
||||
------------
|
||||
|
||||
|
@ -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
|
||||
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__
|
||||
|
||||
``get_absolute_url``
|
||||
|
|
|
@ -7,8 +7,6 @@ Lookup API reference
|
|||
|
||||
.. currentmodule:: django.db.models
|
||||
|
||||
.. versionadded:: 1.7
|
||||
|
||||
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
|
||||
:doc:`/topics/db/queries`; to learn how to *create* new lookups, see
|
||||
|
|
|
@ -24,17 +24,12 @@ Available ``Meta`` options
|
|||
|
||||
.. attribute:: Options.app_label
|
||||
|
||||
If a model exists outside of the standard locations (:file:`models.py` or
|
||||
a ``models`` package in an app), the model must define which app it is part
|
||||
of::
|
||||
If a model exists outside of an application in :setting:`INSTALLED_APPS` or
|
||||
if it's imported before its application was loaded, it must define which
|
||||
app it is part of::
|
||||
|
||||
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``
|
||||
------------
|
||||
|
||||
|
@ -275,8 +270,6 @@ Django quotes column and table names behind the scenes.
|
|||
|
||||
.. attribute:: Options.default_permissions
|
||||
|
||||
.. versionadded:: 1.7
|
||||
|
||||
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
|
||||
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
|
||||
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``
|
||||
------------------
|
||||
|
@ -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
|
||||
``CREATE INDEX`` statement will be issued.)
|
||||
|
||||
.. versionchanged:: 1.7
|
||||
|
||||
For convenience, ``index_together`` can be a single list when dealing with a single
|
||||
set of fields::
|
||||
|
||||
|
|
|
@ -329,11 +329,6 @@ the cost of a JOIN, by referring to the ``_id`` of the related field::
|
|||
# Join
|
||||
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
|
||||
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
|
||||
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
|
||||
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.
|
||||
|
@ -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
|
||||
``select_related('foo').select_related('bar')``.
|
||||
|
||||
.. versionchanged:: 1.7
|
||||
|
||||
Previously the latter would have been equivalent to
|
||||
``select_related('bar')``.
|
||||
|
||||
prefetch_related
|
||||
~~~~~~~~~~~~~~~~
|
||||
|
||||
|
@ -1011,8 +995,6 @@ profile for your use case!
|
|||
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.
|
||||
|
||||
.. versionadded:: 1.7
|
||||
|
||||
You can use the :class:`~django.db.models.Prefetch` object to further control
|
||||
the prefetch operation.
|
||||
|
||||
|
@ -1483,11 +1465,6 @@ a transaction outside of one.
|
|||
Using ``select_for_update()`` on backends which do not support
|
||||
``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::
|
||||
|
||||
Although ``select_for_update()`` normally fails in autocommit mode, since
|
||||
|
@ -1503,11 +1480,6 @@ raw
|
|||
|
||||
.. 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
|
||||
``django.db.models.query.RawQuerySet`` instance. This ``RawQuerySet`` instance
|
||||
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)
|
||||
|
||||
.. versionadded:: 1.7
|
||||
|
||||
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)
|
||||
pairs used to update the object.
|
||||
|
@ -2119,8 +2089,6 @@ as_manager
|
|||
|
||||
.. classmethod:: as_manager()
|
||||
|
||||
.. versionadded:: 1.7
|
||||
|
||||
Class method that returns an instance of :class:`~django.db.models.Manager`
|
||||
with a copy of the ``QuerySet``’s methods. See
|
||||
:ref:`create-manager-with-queryset-methods` for more details.
|
||||
|
@ -2175,12 +2143,9 @@ SQL equivalents::
|
|||
iexact
|
||||
~~~~~~
|
||||
|
||||
Case-insensitive exact match.
|
||||
|
||||
.. versionchanged:: 1.7
|
||||
|
||||
If the value provided for comparison is ``None``, it will be interpreted
|
||||
as an SQL ``NULL`` (see :lookup:`isnull` for more details).
|
||||
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
|
||||
details).
|
||||
|
||||
Example::
|
||||
|
||||
|
@ -2890,8 +2855,6 @@ in particular, it is not otherwise possible to use ``OR`` in ``QuerySets``.
|
|||
``Prefetch()`` objects
|
||||
----------------------
|
||||
|
||||
.. versionadded:: 1.7
|
||||
|
||||
.. class:: Prefetch(lookup, queryset=None, to_attr=None)
|
||||
|
||||
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
|
||||
|
||||
.. versionadded:: 1.7
|
||||
|
||||
A string representing the scheme of the request (``http`` or ``https``
|
||||
usually).
|
||||
|
||||
|
@ -865,8 +863,6 @@ types of HTTP responses. Like ``HttpResponse``, these subclasses live in
|
|||
JsonResponse objects
|
||||
====================
|
||||
|
||||
.. versionadded:: 1.7
|
||||
|
||||
.. class:: JsonResponse
|
||||
|
||||
.. 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
|
||||
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
|
||||
|
||||
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
|
||||
:setting:`MIDDLEWARE_CLASSES`).
|
||||
|
||||
.. versionchanged:: 1.7
|
||||
|
||||
In previous versions of Django, if you wanted to also allow the
|
||||
`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.
|
||||
Django also allows the `fully qualified domain name (FQDN)`_ of any entries.
|
||||
Some browsers include a trailing dot in the ``Host`` header which Django
|
||||
strips when performing host validation.
|
||||
|
||||
.. _`fully qualified domain name (FQDN)`: http://en.wikipedia.org/wiki/Fully_qualified_domain_name
|
||||
|
||||
|
@ -270,11 +253,8 @@ TIMEOUT
|
|||
|
||||
Default: 300
|
||||
|
||||
The number of seconds before a cache entry is considered stale.
|
||||
|
||||
.. versionadded:: 1.7
|
||||
|
||||
If the value of this settings is ``None``, cache entries will not expire.
|
||||
The number of seconds before a cache entry is considered stale. If the value of
|
||||
this settings is ``None``, cache entries will not expire.
|
||||
|
||||
.. setting:: CACHES-VERSION
|
||||
|
||||
|
@ -329,8 +309,6 @@ See :doc:`/topics/cache`.
|
|||
CSRF_COOKIE_AGE
|
||||
---------------
|
||||
|
||||
.. versionadded:: 1.7
|
||||
|
||||
Default: ``31449600`` (1 year, 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
|
||||
~~~~
|
||||
|
||||
.. 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: ``{}``
|
||||
|
||||
A dictionary of settings for test databases; for more details about the
|
||||
|
@ -703,8 +671,6 @@ See :ref:`the-test-database`.
|
|||
SERIALIZE
|
||||
^^^^^^^^^
|
||||
|
||||
.. versionadded:: 1.7.1
|
||||
|
||||
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
|
||||
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
|
||||
-------------
|
||||
|
||||
.. versionadded:: 1.7
|
||||
|
||||
Default: ``False``
|
||||
|
||||
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
|
||||
---------------------------------
|
||||
|
||||
.. versionadded:: 1.7
|
||||
|
||||
Default: ``None``
|
||||
|
||||
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>`.
|
||||
|
||||
.. versionchanged:: 1.7
|
||||
|
||||
:setting:`INSTALLED_APPS` now supports application configurations.
|
||||
|
||||
.. admonition:: Use the application registry for introspection
|
||||
|
||||
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
|
||||
-------------------
|
||||
|
||||
.. versionadded:: 1.7
|
||||
|
||||
Default: ``None`` (expires at browser close)
|
||||
|
||||
The age of the language cookie, in seconds.
|
||||
|
@ -1570,8 +1526,6 @@ The age of the language cookie, in seconds.
|
|||
LANGUAGE_COOKIE_DOMAIN
|
||||
----------------------
|
||||
|
||||
.. versionadded:: 1.7
|
||||
|
||||
Default: ``None``
|
||||
|
||||
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
|
||||
--------------------
|
||||
|
||||
.. versionadded:: 1.7
|
||||
|
||||
Default: ``/``
|
||||
|
||||
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
|
||||
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
|
||||
|
||||
.. setting:: MANAGERS
|
||||
|
@ -1792,13 +1740,6 @@ Default::
|
|||
|
||||
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
|
||||
|
||||
MIGRATION_MODULES
|
||||
|
@ -2177,8 +2118,6 @@ See also the :doc:`/topics/signing` documentation.
|
|||
SILENCED_SYSTEM_CHECKS
|
||||
----------------------
|
||||
|
||||
.. versionadded:: 1.7
|
||||
|
||||
Default: ``[]``
|
||||
|
||||
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
|
||||
------------------------
|
||||
|
||||
.. versionadded:: 1.7
|
||||
|
||||
Default: ``[]``
|
||||
|
||||
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
|
||||
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
|
||||
|
||||
.. setting:: SESSION_COOKIE_NAME
|
||||
|
@ -2951,10 +2884,6 @@ requests and that's a good thing.
|
|||
|
||||
.. _Firesheep: http://codebutler.com/firesheep
|
||||
|
||||
.. versionadded:: 1.7
|
||||
|
||||
This setting also affects cookies set by :mod:`django.contrib.messages`.
|
||||
|
||||
.. setting:: SESSION_ENGINE
|
||||
|
||||
SESSION_ENGINE
|
||||
|
|
|
@ -34,7 +34,7 @@ model system.
|
|||
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`.
|
||||
|
||||
.. versionadded:: 1.7
|
||||
.. note::
|
||||
|
||||
Model signals ``sender`` model can be lazily referenced when connecting a
|
||||
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``.
|
||||
|
||||
``enter``
|
||||
.. versionadded:: 1.7
|
||||
|
||||
A boolean; ``True`` if the setting is applied, ``False`` if restored.
|
||||
|
||||
template_rendered
|
||||
|
|
|
@ -442,8 +442,6 @@ If you ``pop()`` too much, it'll raise
|
|||
...
|
||||
ContextPopException
|
||||
|
||||
.. versionadded:: 1.7
|
||||
|
||||
You can also use ``push()`` as a context manager to ensure a matching ``pop()``
|
||||
is called.
|
||||
|
||||
|
@ -490,8 +488,6 @@ tags <howto-writing-custom-template-tags>`.
|
|||
|
||||
.. method:: Context.flatten()
|
||||
|
||||
.. versionadded:: 1.7
|
||||
|
||||
Using ``flatten()`` method you can get whole ``Context`` stack as one dictionary
|
||||
including builtin variables.
|
||||
|
||||
|
@ -705,10 +701,6 @@ variables:
|
|||
* ``DEFAULT_MESSAGE_LEVELS`` -- A mapping of the message level names to
|
||||
:ref:`their numeric value <message-level-constants>`.
|
||||
|
||||
.. versionchanged:: 1.7
|
||||
|
||||
The ``DEFAULT_MESSAGE_LEVELS`` variable was added.
|
||||
|
||||
Writing your own context processors
|
||||
-----------------------------------
|
||||
|
||||
|
@ -941,8 +933,6 @@ the template source, and returns a tuple: ``(template, template_origin)``.
|
|||
Template origin
|
||||
===============
|
||||
|
||||
.. versionadded:: 1.7
|
||||
|
||||
When an :class:`~django.template.Engine` is initialized with ``debug=True``,
|
||||
its templates have an ``origin`` attribute depending on the source they are
|
||||
loaded from. For engines initialized by Django, ``debug`` defaults to the
|
||||
|
|
|
@ -665,11 +665,8 @@ the variable ``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
|
||||
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 %}
|
||||
{% 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
|
||||
|
||||
with
|
||||
|
@ -2153,11 +2146,6 @@ When used without a format string::
|
|||
...the formatting string defined in the :setting:`TIME_FORMAT` setting will be
|
||||
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
|
||||
|
||||
timesince
|
||||
|
@ -2235,8 +2223,6 @@ If ``value`` is ``"Joel is a slug"``, the output will be ``"Joel i..."``.
|
|||
truncatechars_html
|
||||
^^^^^^^^^^^^^^^^^^
|
||||
|
||||
.. versionadded:: 1.7
|
||||
|
||||
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
|
||||
are closed immediately after the truncation.
|
||||
|
|
|
@ -345,10 +345,6 @@ SyndicationFeed
|
|||
objects except ``pubdate`` and ``updateddate``, which are ``datetime.datetime``
|
||||
objects, and ``enclosure``, which is an instance of the ``Enclosure`` class.
|
||||
|
||||
.. versionadded:: 1.7
|
||||
|
||||
The optional ``updateddate`` argument was added.
|
||||
|
||||
.. method:: num_items()
|
||||
|
||||
.. method:: root_attributes()
|
||||
|
@ -742,8 +738,6 @@ Functions for working with Python modules.
|
|||
|
||||
.. function:: import_string(dotted_path)
|
||||
|
||||
.. versionadded:: 1.7
|
||||
|
||||
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
|
||||
example::
|
||||
|
@ -849,15 +843,11 @@ appropriate entities.
|
|||
|
||||
.. class:: FixedOffset(offset=None, name=None)
|
||||
|
||||
.. versionadded:: 1.7
|
||||
|
||||
A :class:`~datetime.tzinfo` subclass modeling a fixed offset from UTC.
|
||||
``offset`` is an integer number of minutes east of UTC.
|
||||
|
||||
.. function:: get_fixed_timezone(offset)
|
||||
|
||||
.. versionadded:: 1.7
|
||||
|
||||
Returns a :class:`~datetime.tzinfo` instance that represents a time zone
|
||||
with a fixed offset from UTC.
|
||||
|
||||
|
|
|
@ -102,18 +102,14 @@ to, or in lieu of custom ``field.clean()`` methods.
|
|||
|
||||
.. attribute:: inverse_match
|
||||
|
||||
.. versionadded:: 1.7
|
||||
|
||||
The match mode for :attr:`regex`. Defaults to ``False``.
|
||||
|
||||
.. 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, and :attr:`flags` is overridden,
|
||||
:exc:`TypeError` is raised.
|
||||
Defaults to `0`.
|
||||
The flags used when compiling the regular expression string
|
||||
:attr:`regex`. If :attr:`regex` is a pre-compiled regular expression,
|
||||
and :attr:`flags` is overridden, :exc:`TypeError` is raised. Defaults
|
||||
to ``0``.
|
||||
|
||||
``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
|
||||
|
||||
.. versionchanged:: 1.7
|
||||
|
||||
The optional ``schemes`` attribute was added.
|
||||
|
||||
.. versionchanged:: 1.8
|
||||
|
||||
Support for IPv6 addresses, unicode domains, and URLs containing
|
||||
|
|
|
@ -436,10 +436,8 @@ different User model.
|
|||
class Article(models.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.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()
|
||||
|
||||
.. versionadded:: 1.7
|
||||
|
||||
Returns an HMAC of the password field. Used for
|
||||
: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
|
||||
passwords.
|
||||
|
||||
.. versionadded:: 1.7
|
||||
|
||||
Changing a user's password will log out all their sessions if the
|
||||
:class:`~django.contrib.auth.middleware.SessionAuthenticationMiddleware` is
|
||||
enabled. See :ref:`session-invalidation-on-password-change` for details.
|
||||
|
@ -560,11 +558,13 @@ The permission_required decorator
|
|||
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>"``
|
||||
(i.e. ``polls.can_vote`` for a permission on a model in the ``polls``
|
||||
application).
|
||||
|
||||
The decorator may also take a list of permissions.
|
||||
|
||||
Note that :func:`~django.contrib.auth.decorators.permission_required()`
|
||||
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
|
||||
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
|
||||
|
@ -603,8 +598,6 @@ To apply a permission to a :doc:`class-based generic view
|
|||
Session invalidation on password change
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
.. versionadded:: 1.7
|
||||
|
||||
.. warning::
|
||||
|
||||
This protection only applies if
|
||||
|
@ -986,10 +979,6 @@ patterns.
|
|||
for generating a ``text/html`` multipart email with the password reset
|
||||
link. By default, HTML email is not sent.
|
||||
|
||||
.. versionadded:: 1.7
|
||||
|
||||
``html_email_template_name`` was added.
|
||||
|
||||
.. deprecated:: 1.8
|
||||
|
||||
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)
|
||||
|
||||
.. versionadded:: 1.7
|
||||
|
||||
By default, ``AuthenticationForm`` rejects users whose ``is_active`` flag
|
||||
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
|
||||
|
|
|
@ -206,13 +206,6 @@ If you are using multiple databases, :djadmin:`createcachetable` observes the
|
|||
Like :djadmin:`migrate`, :djadmin:`createcachetable` won't touch an existing
|
||||
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
|
||||
~~~~~~~~~~~~~~~~~~
|
||||
|
||||
|
@ -369,9 +362,6 @@ behavior. These arguments are provided as additional keys in the
|
|||
|
||||
* :setting:`TIMEOUT <CACHES-TIMEOUT>`: The default timeout, in
|
||||
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
|
||||
expire.
|
||||
|
||||
|
@ -662,12 +652,10 @@ equivalent:
|
|||
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.
|
||||
|
||||
.. 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 select an alternate cache backend to use with
|
||||
the ``using`` keyword argument, which must be the last argument to the tag.
|
||||
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
|
||||
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
|
||||
|
||||
|
@ -719,8 +707,6 @@ Accessing the cache
|
|||
|
||||
.. data:: django.core.cache.caches
|
||||
|
||||
.. versionadded:: 1.7
|
||||
|
||||
You can access the caches configured in the :setting:`CACHES` setting
|
||||
through a dict-like object: ``django.core.cache.caches``. Repeated
|
||||
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``
|
||||
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
|
||||
:func:`django.views.decorators.vary.vary_on_headers` view decorator, like so::
|
||||
|
||||
|
|
|
@ -2,8 +2,6 @@
|
|||
System check framework
|
||||
======================
|
||||
|
||||
.. versionadded:: 1.7
|
||||
|
||||
.. module:: django.core.checks
|
||||
|
||||
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
|
||||
----------------------------------------------
|
||||
|
||||
.. versionadded:: 1.7
|
||||
|
||||
In lieu of the above approach which requires duplicating methods on both the
|
||||
``QuerySet`` and the ``Manager``, :meth:`QuerySet.as_manager()
|
||||
<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
|
||||
: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
|
||||
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
|
||||
|
@ -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
|
||||
coming from.
|
||||
|
||||
.. versionchanged:: 1.7
|
||||
|
||||
Before Django 1.7, inheriting from multiple models that had an ``id`` primary
|
||||
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::
|
||||
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
|
||||
use an explicit :class:`~django.db.models.AutoField` in the base models::
|
||||
|
||||
class Article(models.Model):
|
||||
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)
|
||||
|
||||
.. versionadded:: 1.7
|
||||
|
||||
The power operator ``**`` was added.
|
||||
|
||||
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
|
||||
query::
|
||||
|
@ -1149,8 +1145,6 @@ above example code would look like this::
|
|||
Using a custom reverse manager
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
.. versionadded:: 1.7
|
||||
|
||||
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 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
|
||||
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::
|
||||
|
||||
with connection.cursor() as c:
|
||||
|
|
|
@ -74,10 +74,6 @@ are required.
|
|||
The return value will be the number of successfully delivered messages (which
|
||||
can be ``0`` or ``1`` since it can only send one message).
|
||||
|
||||
.. versionadded:: 1.7
|
||||
|
||||
The ``html_message`` parameter was added.
|
||||
|
||||
send_mass_mail()
|
||||
================
|
||||
|
||||
|
@ -333,8 +329,6 @@ The class has the following methods:
|
|||
|
||||
message.attach('design.png', img_data, 'image/png')
|
||||
|
||||
.. versionchanged:: 1.7
|
||||
|
||||
If you specify a ``mimetype`` of ``message/rfc822``, it will also accept
|
||||
: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'
|
||||
|
||||
.. versionadded:: 1.7
|
||||
|
||||
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).
|
||||
If unspecified, the default ``timeout`` will be the one provided by
|
||||
:func:`socket.getdefaulttimeout()`, which defaults to ``None`` (no timeout).
|
||||
|
||||
.. versionchanged:: 1.8
|
||||
|
||||
|
|
|
@ -343,8 +343,6 @@ excessive.
|
|||
``validate_min``
|
||||
~~~~~~~~~~~~~~~~
|
||||
|
||||
.. versionadded:: 1.7
|
||||
|
||||
If ``validate_min=True`` is passed to
|
||||
:func:`~django.forms.formsets.formset_factory`, validation will also check
|
||||
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()
|
||||
['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
|
||||
-------------------------------------------
|
||||
|
||||
|
@ -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
|
||||
``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
|
||||
:attr:`formset.deleted_objects
|
||||
<django.forms.models.BaseModelFormSet.deleted_objects>` to actually delete
|
||||
them::
|
||||
If you call ``formset.save(commit=False)``, objects will not be deleted
|
||||
automatically. You'll need to call ``delete()`` on each of the
|
||||
:attr:`formset.deleted_objects
|
||||
<django.forms.models.BaseModelFormSet.deleted_objects>` to actually delete
|
||||
them::
|
||||
|
||||
>>> instances = formset.save(commit=False)
|
||||
>>> for obj in formset.deleted_objects:
|
||||
... 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
|
||||
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.
|
||||
|
|
|
@ -275,8 +275,6 @@ Error messages defined on :attr:`model fields
|
|||
<validating-objects>` step and no corresponding error messages are defined at
|
||||
the form level.
|
||||
|
||||
.. versionadded:: 1.7
|
||||
|
||||
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
|
||||
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
|
||||
``Meta`` of the first parent, etc.
|
||||
|
||||
.. versionchanged:: 1.7
|
||||
|
||||
* It's possible to inherit from both ``Form`` and ``ModelForm`` simultaneously,
|
||||
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
|
||||
one metaclass.
|
||||
|
||||
.. 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.
|
||||
|
||||
|
|
|
@ -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
|
||||
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
|
||||
-------------------------
|
||||
|
||||
|
|
|
@ -77,10 +77,6 @@ Optional arguments
|
|||
The ``current_app`` argument is deprecated. Instead you should set
|
||||
``request.current_app``.
|
||||
|
||||
.. versionchanged:: 1.7
|
||||
|
||||
The ``dirs`` parameter was added.
|
||||
|
||||
.. deprecated:: 1.8
|
||||
|
||||
The ``dirs`` parameter was deprecated.
|
||||
|
@ -167,10 +163,6 @@ Optional arguments
|
|||
|
||||
The ``status`` parameter was added.
|
||||
|
||||
.. versionchanged:: 1.7
|
||||
|
||||
The ``dirs`` parameter was added.
|
||||
|
||||
.. deprecated:: 1.8
|
||||
|
||||
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
|
||||
permanent redirect.
|
||||
|
||||
.. versionchanged:: 1.7
|
||||
|
||||
The ability to use relative URLs was added.
|
||||
|
||||
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``
|
||||
option had not been specified.
|
||||
|
||||
.. versionchanged:: 1.7
|
||||
|
||||
The ``trimmed`` option was added.
|
||||
|
||||
|
||||
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
|
||||
``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. That is, a string extracted from a file of an app containing a
|
||||
``locale`` directory will go in a message file under that directory.
|
||||
A string extracted from a file of an app without any ``locale`` directory
|
||||
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.
|
||||
When you run ``makemessages`` from the root directory of your project, the
|
||||
extracted strings will be automatically distributed to the proper message files.
|
||||
That is, a string extracted from a file of an app containing a ``locale``
|
||||
directory will go in a message file under that directory. A string extracted
|
||||
from a file of an app without any ``locale`` directory 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
|
||||
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:
|
||||
|
||||
* :setting:`LANGUAGE_COOKIE_NAME`
|
||||
|
||||
.. versionadded:: 1.7
|
||||
|
||||
* :setting:`LANGUAGE_COOKIE_AGE`
|
||||
* :setting:`LANGUAGE_COOKIE_DOMAIN`
|
||||
* :setting:`LANGUAGE_COOKIE_PATH`
|
||||
|
||||
|
||||
Implementation notes
|
||||
====================
|
||||
|
||||
|
@ -1716,11 +1704,6 @@ following this algorithm:
|
|||
* Failing that, it looks for the :data:`~django.utils.translation.LANGUAGE_SESSION_KEY`
|
||||
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.
|
||||
|
||||
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``
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
.. versionadded:: 1.7
|
||||
|
||||
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
|
||||
queries executed by :class:`~django.db.migrations.operations.RunPython`.
|
||||
|
|
|
@ -5,8 +5,6 @@ Migrations
|
|||
.. module:: django.db.migrations
|
||||
:synopsis: Schema migration support for Django models
|
||||
|
||||
.. versionadded:: 1.7
|
||||
|
||||
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
|
||||
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)
|
||||
- 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:
|
||||
|
||||
- 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
|
||||
as a natural key.
|
||||
|
||||
.. versionadded:: 1.7
|
||||
|
||||
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
|
||||
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
|
||||
: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::
|
||||
|
||||
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
|
||||
the engine's :setting:`NAME <TEMPLATES-NAME>` in the ``using`` argument.
|
||||
|
||||
.. versionchanged:: 1.7
|
||||
|
||||
The ``dirs`` parameter was added.
|
||||
|
||||
.. deprecated:: 1.8
|
||||
|
||||
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
|
||||
template that exists.
|
||||
|
||||
.. versionchanged:: 1.7
|
||||
|
||||
The ``dirs`` parameter was added.
|
||||
|
||||
.. deprecated:: 1.8
|
||||
|
||||
The ``dirs`` parameter was deprecated.
|
||||
|
|
|
@ -414,16 +414,12 @@ Attributes
|
|||
|
||||
.. attribute:: DiscoverRunner.test_suite
|
||||
|
||||
.. versionadded:: 1.7
|
||||
|
||||
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
|
||||
different logic for collecting tests.
|
||||
|
||||
.. attribute:: DiscoverRunner.test_runner
|
||||
|
||||
.. versionadded:: 1.7
|
||||
|
||||
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
|
||||
``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
|
||||
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
|
||||
the :setting:`SERIALIZE <TEST_SERIALIZE>` entry in the
|
||||
:setting:`TEST <DATABASE-TEST>` dictionary
|
||||
the :setting:`SERIALIZE <TEST_SERIALIZE>` entry in the :setting:`TEST
|
||||
<DATABASE-TEST>` dictionary.
|
||||
|
||||
``keepdb`` determines if the test run should use an 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
|
||||
database.
|
||||
|
||||
.. versionchanged:: 1.7
|
||||
|
||||
The ``serialize`` argument was added.
|
||||
|
||||
.. versionchanged:: 1.8
|
||||
|
||||
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>`
|
||||
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
|
||||
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
|
||||
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
|
||||
|
||||
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 code* anyway - rewrite your code so that it doesn't do this.
|
||||
|
||||
.. versionadded:: 1.7
|
||||
|
||||
This also applies to customized implementations of
|
||||
: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)
|
||||
|
||||
.. versionadded:: 1.7
|
||||
|
||||
The ``secure`` argument was added.
|
||||
|
||||
Makes a GET request on the provided ``path`` and returns a ``Response``
|
||||
object, which is documented below.
|
||||
|
||||
|
@ -435,8 +431,6 @@ Specifically, a ``Response`` object has the following attributes:
|
|||
|
||||
.. attribute:: wsgi_request
|
||||
|
||||
.. versionadded:: 1.7
|
||||
|
||||
The ``WSGIRequest`` instance generated by the test handler that
|
||||
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
|
||||
.. _Firefox: http://www.mozilla.com/firefox/
|
||||
|
||||
.. versionchanged:: 1.7
|
||||
.. tip::
|
||||
|
||||
Before Django 1.7 ``LiveServerTestCase`` used to rely on the
|
||||
:doc:`staticfiles contrib app </howto/static-files/index>` to get 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
|
||||
If you use the :mod:`~django.contrib.staticfiles` app in your project and
|
||||
need to perform live testing, then you might want to use the
|
||||
:class:`~django.contrib.staticfiles.testing.StaticLiveServerTestCase`
|
||||
subclass shipped with it instead because it's the one that implements the
|
||||
original behavior now. See :ref:`the relevant documentation
|
||||
<staticfiles-testing-support>` for more details.
|
||||
subclass which transparently serves all the assets during execution of
|
||||
its tests in a way very similar to what we get at development time with
|
||||
``DEBUG=True``, i.e. without having to collect them using
|
||||
:djadmin:`collectstatic`.
|
||||
|
||||
.. note::
|
||||
|
||||
|
@ -1135,8 +1119,6 @@ in the ``with`` block and reset its value to the previous state afterwards.
|
|||
|
||||
.. method:: SimpleTestCase.modify_settings()
|
||||
|
||||
.. versionadded:: 1.7
|
||||
|
||||
It can prove unwieldy to redefine settings that contain a list of values. In
|
||||
practice, adding or removing values is often sufficient. The
|
||||
: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/')
|
||||
self.assertRedirects(response, '/other/login/?next=/sekrit/')
|
||||
|
||||
.. versionchanged:: 1.7
|
||||
|
||||
Previously, ``override_settings`` was imported from ``django.test.utils``.
|
||||
|
||||
.. function:: modify_settings
|
||||
|
||||
.. versionadded:: 1.7
|
||||
|
||||
Likewise, Django provides the :func:`~django.test.modify_settings`
|
||||
decorator::
|
||||
|
||||
|
@ -1265,11 +1241,6 @@ have been overridden, like this::
|
|||
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
|
||||
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`
|
||||
|
@ -1445,14 +1416,10 @@ your test suite.
|
|||
host (for example, initializing the test client with
|
||||
``Client(HTTP_HOST="testhost")``.
|
||||
|
||||
.. versionadded:: 1.7
|
||||
|
||||
If ``fetch_redirect_response`` is ``False``, the final page won't be
|
||||
loaded. Since the test client can't fetch externals URLs, this is
|
||||
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
|
||||
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
|
||||
|
@ -1564,11 +1531,6 @@ your test suite.
|
|||
|
||||
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)
|
||||
|
||||
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):
|
||||
# ... conditional test code
|
||||
|
||||
.. versionchanged:: 1.7
|
||||
|
||||
``skipIfDBFeature`` can now be used to decorate a ``TestCase`` class.
|
||||
|
||||
.. versionchanged:: 1.8
|
||||
|
||||
``skipIfDBFeature`` can accept multiple feature strings.
|
||||
|
@ -1727,10 +1685,6 @@ under MySQL with MyISAM tables)::
|
|||
def test_transaction_behavior(self):
|
||||
# ... conditional test code
|
||||
|
||||
.. versionchanged:: 1.7
|
||||
|
||||
``skipUnlessDBFeature`` can now be used to decorate a ``TestCase`` class.
|
||||
|
||||
.. versionchanged:: 1.8
|
||||
|
||||
``skipUnlessDBFeature`` can accept multiple feature strings.
|
||||
|
|
Loading…
Reference in New Issue