Removed versionadded/changed annotations for 1.9.
This commit is contained in:
parent
1915a7e5c5
commit
46a38307c2
|
@ -113,8 +113,6 @@ override one or more of its attributes and methods.
|
|||
Using ``REMOTE_USER`` on login pages only
|
||||
=========================================
|
||||
|
||||
.. versionadded:: 1.9
|
||||
|
||||
The ``RemoteUserMiddleware`` authentication middleware assumes that the HTTP
|
||||
request header ``REMOTE_USER`` is present with all authenticated requests. That
|
||||
might be expected and practical when Basic HTTP Auth with ``htpasswd`` or other
|
||||
|
|
|
@ -94,11 +94,6 @@ the server or, if ``upload_to`` is a callable, the filename returned by that
|
|||
method after any path information is removed. Override this to customize how
|
||||
non-standard characters are converted to safe filenames.
|
||||
|
||||
.. versionchanged:: 1.9
|
||||
|
||||
In older versions, this method was not called when ``upload_to`` was a
|
||||
callable.
|
||||
|
||||
The code provided on ``Storage`` retains only alpha-numeric characters, periods
|
||||
and underscores from the original filename, removing everything else.
|
||||
|
||||
|
|
|
@ -69,8 +69,6 @@ following::
|
|||
|
||||
register = template.Library()
|
||||
|
||||
.. versionadded:: 1.9
|
||||
|
||||
Alternatively, template tag modules can be registered through the
|
||||
``'libraries'`` argument to
|
||||
:class:`~django.template.backends.django.DjangoTemplates`. This is useful if
|
||||
|
@ -445,11 +443,6 @@ code does not contain XSS vulnerabilities. For building small HTML snippets,
|
|||
use of :func:`~django.utils.html.format_html` instead of ``mark_safe()`` is
|
||||
strongly recommended.
|
||||
|
||||
.. versionchanged:: 1.9
|
||||
|
||||
Auto-escaping for ``simple_tag`` as described in the previous two paragraphs
|
||||
was added.
|
||||
|
||||
If your template tag needs to access the current context, you can use the
|
||||
``takes_context`` argument when registering your tag::
|
||||
|
||||
|
@ -490,8 +483,6 @@ positional arguments. For example:
|
|||
|
||||
{% my_tag 123 "abcd" book.title warning=message|lower profile=user.profile %}
|
||||
|
||||
.. versionadded:: 1.9
|
||||
|
||||
It's possible to store the tag results in a template variable rather than
|
||||
directly outputting it. This is done by using the ``as`` argument followed by
|
||||
the variable name. Doing so enables you to output the content yourself where
|
||||
|
|
|
@ -67,11 +67,6 @@ those are usually just people typing in broken URLs or broken Web bots. It also
|
|||
ignores 404s when the referer is equal to the requested URL, since this
|
||||
behavior is from broken Web bots too.
|
||||
|
||||
.. versionchanged:: 1.9
|
||||
|
||||
In older versions, 404s were not ignored when the referer was equal to the
|
||||
requested URL.
|
||||
|
||||
.. note::
|
||||
|
||||
:class:`~django.middleware.common.BrokenLinkEmailsMiddleware` must appear
|
||||
|
|
|
@ -307,11 +307,6 @@ test failures. You can adjust this behavior with the ``--parallel`` option::
|
|||
You can also use the ``DJANGO_TEST_PROCESSES`` environment variable for this
|
||||
purpose.
|
||||
|
||||
.. versionadded:: 1.9
|
||||
|
||||
Support for running tests in parallel and the ``--parallel`` option were
|
||||
added.
|
||||
|
||||
Tips for writing tests
|
||||
----------------------
|
||||
|
||||
|
|
|
@ -70,8 +70,6 @@ MRO is an acronym for Method Resolution Order.
|
|||
|
||||
response = MyView.as_view()(request)
|
||||
|
||||
.. versionadded:: 1.9
|
||||
|
||||
The returned view has ``view_class`` and ``view_initkwargs``
|
||||
attributes.
|
||||
|
||||
|
@ -232,11 +230,6 @@ MRO is an acronym for Method Resolution Order.
|
|||
status code 301. If ``False``, then the redirect will use status code
|
||||
302. By default, ``permanent`` is ``False``.
|
||||
|
||||
.. versionchanged:: 1.9
|
||||
|
||||
The default value of the ``permanent`` attribute changed from
|
||||
``True`` to ``False``.
|
||||
|
||||
.. attribute:: query_string
|
||||
|
||||
Whether to pass along the GET query string to the new location. If
|
||||
|
|
|
@ -89,8 +89,6 @@ The following mixins are used to construct Django's editing views:
|
|||
|
||||
.. method:: get_context_data(**kwargs)
|
||||
|
||||
.. versionadded:: 1.9
|
||||
|
||||
Calls :meth:`get_form` and adds the result to the context data with the
|
||||
name 'form'.
|
||||
|
||||
|
@ -204,11 +202,6 @@ The following mixins are used to construct Django's editing views:
|
|||
Renders a response using a context created with
|
||||
:meth:`~django.views.generic.edit.FormMixin.get_context_data`.
|
||||
|
||||
.. versionchanged:: 1.9
|
||||
|
||||
Construction of the form was moved from this method to
|
||||
:meth:`~django.views.generic.edit.FormMixin.get_context_data`.
|
||||
|
||||
.. method:: post(request, *args, **kwargs)
|
||||
|
||||
Constructs a form, checks the form for validity, and handles it
|
||||
|
|
|
@ -55,12 +55,6 @@ system along with all the fields and methods available on it. Relationships
|
|||
to other models appear as hyperlinks. Descriptions are pulled from ``help_text``
|
||||
attributes on fields or from docstrings on model methods.
|
||||
|
||||
.. versionchanged:: 1.9
|
||||
|
||||
The **models** section of the ``admindocs`` now describes methods that take
|
||||
arguments as well. In previous versions it was restricted to methods
|
||||
without arguments.
|
||||
|
||||
A model with useful documentation might look like this::
|
||||
|
||||
class BlogEntry(models.Model):
|
||||
|
|
|
@ -226,8 +226,6 @@ subclass::
|
|||
|
||||
.. attribute:: ModelAdmin.empty_value_display
|
||||
|
||||
.. versionadded:: 1.9
|
||||
|
||||
This attribute overrides the default display value for record's fields that
|
||||
are empty (``None``, empty string, etc.). The default value is ``-`` (a
|
||||
dash). For example::
|
||||
|
@ -656,10 +654,6 @@ subclass::
|
|||
|
||||
birth_date_view.empty_value_display = 'unknown'
|
||||
|
||||
.. versionadded:: 1.9
|
||||
|
||||
The ability to customize ``empty_value_display`` was added.
|
||||
|
||||
* If the string given is a method of the model, ``ModelAdmin`` or a
|
||||
callable that returns True or False Django will display a pretty
|
||||
"on" or "off" icon if you give the method a ``boolean`` attribute
|
||||
|
@ -1468,8 +1462,6 @@ templates used by the :class:`ModelAdmin` views:
|
|||
|
||||
.. method:: ModelAdmin.get_list_select_related(request)
|
||||
|
||||
.. versionadded:: 1.9
|
||||
|
||||
The ``get_list_select_related`` method is given the ``HttpRequest`` and
|
||||
should return a boolean or list as :attr:`ModelAdmin.list_select_related`
|
||||
does.
|
||||
|
@ -1579,8 +1571,6 @@ templates used by the :class:`ModelAdmin` views:
|
|||
|
||||
url(r'^my_view/$', self.admin_site.admin_view(self.my_view, cacheable=True))
|
||||
|
||||
.. versionadded:: 1.9
|
||||
|
||||
``ModelAdmin`` views have ``model_admin`` attributes. Other
|
||||
``AdminSite`` views have ``admin_site`` attributes.
|
||||
|
||||
|
@ -1926,12 +1916,6 @@ To avoid conflicts with user-supplied scripts or libraries, Django's jQuery
|
|||
in your own admin JavaScript without including a second copy, you can use the
|
||||
``django.jQuery`` object on changelist and add/edit views.
|
||||
|
||||
.. versionchanged:: 1.9
|
||||
|
||||
The embedded jQuery was upgraded from 1.11.2 to 2.1.4. This drops
|
||||
support for Internet Explorer 8 and below. You can restore support by
|
||||
:ref:`including your own version of jQuery 1.X <admin-browser-support-19>`.
|
||||
|
||||
.. versionchanged:: 1.10
|
||||
|
||||
The embedded jQuery was upgraded from 2.1.4 to 2.2.3.
|
||||
|
@ -2586,8 +2570,6 @@ Templates can override or extend base admin templates as described in
|
|||
|
||||
.. attribute:: AdminSite.empty_value_display
|
||||
|
||||
.. versionadded:: 1.9
|
||||
|
||||
The string to use for displaying empty values in the admin site's change
|
||||
list. Defaults to a dash. The value can also be overridden on a per
|
||||
``ModelAdmin`` basis and on a custom field within a ``ModelAdmin`` by
|
||||
|
@ -2649,10 +2631,6 @@ Templates can override or extend base admin templates as described in
|
|||
* ``admin_url``: admin changelist URL for the model
|
||||
* ``add_url``: admin URL to add a new model instance
|
||||
|
||||
.. versionchanged:: 1.9
|
||||
|
||||
The ``available_apps`` variable was added.
|
||||
|
||||
.. method:: AdminSite.has_permission(request)
|
||||
|
||||
Returns ``True`` if the user for the given ``HttpRequest`` has permission
|
||||
|
@ -2680,11 +2658,6 @@ In this example, we register the default ``AdminSite`` instance
|
|||
url(r'^admin/', admin.site.urls),
|
||||
]
|
||||
|
||||
.. versionchanged:: 1.9
|
||||
|
||||
In previous versions, you would pass ``admin.site.urls`` to
|
||||
:func:`~django.conf.urls.include()`.
|
||||
|
||||
.. _customizing-adminsite:
|
||||
|
||||
Customizing the :class:`AdminSite` class
|
||||
|
|
|
@ -7,8 +7,6 @@ JavaScript customizations in the admin
|
|||
Inline form events
|
||||
==================
|
||||
|
||||
.. versionadded:: 1.9
|
||||
|
||||
You may want to execute some JavaScript when an inline form is added or removed
|
||||
in the admin change form. The ``formset:added`` and ``formset:removed`` jQuery
|
||||
events allow this. The event handler is passed three arguments:
|
||||
|
|
|
@ -206,10 +206,6 @@ registering a custom ``ModelAdmin`` for ``FlatPage``::
|
|||
admin.site.unregister(FlatPage)
|
||||
admin.site.register(FlatPage, FlatPageAdmin)
|
||||
|
||||
.. versionchanged:: 1.9
|
||||
|
||||
The ``enable_comments`` field was removed from ``FlatPageAdmin``.
|
||||
|
||||
Via the Python API
|
||||
------------------
|
||||
|
||||
|
|
|
@ -103,8 +103,6 @@ objects, refer to the :ref:`GEOS tutorial <geos-tutorial>`.
|
|||
Creating and Saving Models with Raster Fields
|
||||
=============================================
|
||||
|
||||
.. versionadded:: 1.9
|
||||
|
||||
When creating raster models, the raster field will implicitly convert the input
|
||||
into a :class:`~django.contrib.gis.gdal.GDALRaster` using lazy-evaluation.
|
||||
The raster field will therefore accept any input that is accepted by the
|
||||
|
|
|
@ -5,8 +5,6 @@ Geographic Database Functions
|
|||
.. module:: django.contrib.gis.db.models.functions
|
||||
:synopsis: Geographic Database Functions
|
||||
|
||||
.. versionadded:: 1.9
|
||||
|
||||
The functions documented on this page allow users to access geographic database
|
||||
functions to be used in annotations, aggregations, or filters in Django.
|
||||
|
||||
|
|
|
@ -1122,12 +1122,6 @@ blue.
|
|||
>>> rst.bands[0].data()
|
||||
array([[0, 1]], dtype=int8)
|
||||
|
||||
.. versionchanged:: 1.9
|
||||
|
||||
``GDALRaster`` objects can now be instantiated directly from raw data.
|
||||
Setters have been added for the following properties: ``srs``,
|
||||
``geotransform``, ``origin``, ``scale``, and ``skew``.
|
||||
|
||||
.. attribute:: name
|
||||
|
||||
The name of the source which is equivalent to the input file path or the name
|
||||
|
@ -1291,8 +1285,6 @@ blue.
|
|||
|
||||
.. method:: warp(ds_input, resampling='NearestNeighbour', max_error=0.0)
|
||||
|
||||
.. versionadded:: 1.9
|
||||
|
||||
Returns a warped version of this raster.
|
||||
|
||||
The warping parameters can be specified through the ``ds_input``
|
||||
|
@ -1342,8 +1334,6 @@ blue.
|
|||
|
||||
.. method:: transform(srid, driver=None, name=None, resampling='NearestNeighbour', max_error=0.0)
|
||||
|
||||
.. versionadded:: 1.9
|
||||
|
||||
Returns a transformed version of this raster with the specified SRID.
|
||||
|
||||
This function transforms the current raster into a new spatial reference
|
||||
|
@ -1395,8 +1385,6 @@ blue.
|
|||
|
||||
.. attribute:: pixel_count
|
||||
|
||||
.. versionadded:: 1.9
|
||||
|
||||
The total number of pixels in this band. Is equal to ``width * height``.
|
||||
|
||||
.. method:: statistics(refresh=False, approximate=False)
|
||||
|
@ -1459,10 +1447,6 @@ blue.
|
|||
To delete an existing "no data" value, set this property to ``None``
|
||||
(requires GDAL ≥ 2.1).
|
||||
|
||||
.. versionchanged:: 1.9
|
||||
|
||||
This property can now be set as well.
|
||||
|
||||
.. versionchanged:: 1.10
|
||||
|
||||
The "no data" value can now be deleted by setting the
|
||||
|
@ -1479,8 +1463,6 @@ blue.
|
|||
|
||||
.. method:: data(data=None, offset=None, size=None, shape=None)
|
||||
|
||||
.. versionadded:: 1.9
|
||||
|
||||
The accessor to the pixel values of the ``GDALBand``. Returns the complete
|
||||
data array if no parameters are provided. A subset of the pixel array can
|
||||
be requested by specifying an offset and block size as tuples.
|
||||
|
|
|
@ -5,8 +5,6 @@ Geolocation with GeoIP2
|
|||
.. module:: django.contrib.gis.geoip2
|
||||
:synopsis: Python interface for MaxMind's GeoIP2 databases.
|
||||
|
||||
.. versionadded:: 1.9
|
||||
|
||||
The :class:`GeoIP2` object is a wrapper for the `MaxMind geoip2 Python
|
||||
library`__. [#]_
|
||||
|
||||
|
|
|
@ -72,8 +72,6 @@ Features specification [#fnogc]_. There is no such standard for raster data.
|
|||
``RasterField``
|
||||
---------------
|
||||
|
||||
.. versionadded:: 1.9
|
||||
|
||||
.. class:: RasterField
|
||||
|
||||
``RasterField`` is currently only implemented for the PostGIS backend.
|
||||
|
@ -81,11 +79,6 @@ Features specification [#fnogc]_. There is no such standard for raster data.
|
|||
Spatial Field Options
|
||||
=====================
|
||||
|
||||
.. versionchanged:: 1.9
|
||||
|
||||
The geometry field options ``srid`` and ``spatial_index`` are now shared by
|
||||
``GeometryField`` and ``RasterField`` through the ``BaseSpatialField``.
|
||||
|
||||
In addition to the regular :ref:`common-model-field-options` available for
|
||||
Django model fields, spatial fields have the following additional options.
|
||||
All are optional.
|
||||
|
@ -267,31 +260,6 @@ The ``GeoManager`` is required in order to use the legacy
|
|||
as the legacy methods have been replaced in your code, you should be able
|
||||
to remove the special ``GeoManager`` from your GIS-enabled classes.
|
||||
|
||||
.. versionchanged:: 1.9
|
||||
|
||||
In older versions, the manager was required to conduct geographic queries.
|
||||
Without it, all geographic filters failed.
|
||||
|
||||
``GeoManager`` was required even if the model did not have a geographic
|
||||
field itself, e.g., in the case of a ``ForeignKey`` relation to a model
|
||||
with a geographic field. For example, if we had an ``Address`` model with
|
||||
a ``ForeignKey`` to our ``Zipcode`` model::
|
||||
|
||||
from django.contrib.gis.db import models
|
||||
|
||||
class Address(models.Model):
|
||||
num = models.IntegerField()
|
||||
street = models.CharField(max_length=100)
|
||||
city = models.CharField(max_length=100)
|
||||
state = models.CharField(max_length=2)
|
||||
zipcode = models.ForeignKey(Zipcode, on_delete=models.CASCADE)
|
||||
objects = models.GeoManager()
|
||||
|
||||
The geographic manager was needed to do spatial queries on related
|
||||
``Zipcode`` objects, for example::
|
||||
|
||||
qs = Address.objects.filter(zipcode__poly__contains='POINT(-104.590948 38.319914)')
|
||||
|
||||
.. rubric:: Footnotes
|
||||
.. [#fnogc] OpenGIS Consortium, Inc., `Simple Feature Specification For SQL <http://www.opengeospatial.org/standards/sfs>`_.
|
||||
.. [#fnogcsrid] *See id.* at Ch. 2.3.8, p. 39 (Geometry Values and Spatial Reference Systems).
|
||||
|
|
|
@ -12,11 +12,6 @@ The GDAL library is required if any of the serialized geometries need
|
|||
coordinate transformations (that is if the geometry's spatial reference system
|
||||
differs from the ``srid`` serializer option).
|
||||
|
||||
.. versionchanged:: 1.9
|
||||
|
||||
The GeoJSON serializer no longer needs GDAL if all geometries are in the
|
||||
same coordinate system as the ``srid`` serializer option.
|
||||
|
||||
__ http://geojson.org/
|
||||
|
||||
The ``geojson`` serializer is not meant for round-tripping data, as it has no
|
||||
|
|
|
@ -5,8 +5,6 @@ PostgreSQL specific aggregation functions
|
|||
.. module:: django.contrib.postgres.aggregates
|
||||
:synopsis: PostgreSQL specific aggregation functions
|
||||
|
||||
.. versionadded:: 1.9
|
||||
|
||||
These functions are described in more detail in the `PostgreSQL docs
|
||||
<http://www.postgresql.org/docs/current/static/functions-aggregate.html>`_.
|
||||
|
||||
|
|
|
@ -397,8 +397,6 @@ Returns objects where the given key is in the data. Uses the SQL operator
|
|||
``has_any_keys``
|
||||
~~~~~~~~~~~~~~~~
|
||||
|
||||
.. versionadded:: 1.9
|
||||
|
||||
Returns objects where any of the given keys are in the data. Uses the SQL
|
||||
operator ``?|``. For example::
|
||||
|
||||
|
@ -460,8 +458,6 @@ using in conjunction with lookups on
|
|||
``JSONField``
|
||||
=============
|
||||
|
||||
.. versionadded:: 1.9
|
||||
|
||||
.. class:: JSONField(**options)
|
||||
|
||||
A field for storing JSON encoded data. In Python the data is represented in
|
||||
|
|
|
@ -12,8 +12,6 @@ All of these functions are available from the
|
|||
|
||||
.. class:: TransactionNow()
|
||||
|
||||
.. versionadded:: 1.9
|
||||
|
||||
Returns the date and time on the database server that the current transaction
|
||||
started. If you are not in a transaction it will return the date and time of
|
||||
the current statement. This is a complement to
|
||||
|
|
|
@ -24,11 +24,6 @@ The sites framework is mainly based on a simple model:
|
|||
The fully qualified domain name associated with the website.
|
||||
For example, ``www.example.com``.
|
||||
|
||||
.. versionchanged:: 1.9
|
||||
|
||||
The ``domain`` field was set to be
|
||||
:attr:`~django.db.models.Field.unique`.
|
||||
|
||||
.. attribute:: name
|
||||
|
||||
A human-readable "verbose" name for the website.
|
||||
|
@ -508,7 +503,3 @@ Finally, to avoid repetitive fallback code, the framework provides a
|
|||
only. This does not apply to
|
||||
:class:`~django.contrib.sites.requests.RequestSite` which will always
|
||||
use the unmodified host.
|
||||
|
||||
.. versionchanged:: 1.9
|
||||
|
||||
Retrying the lookup with the port stripped was added.
|
||||
|
|
|
@ -92,10 +92,6 @@ Some commonly used options are:
|
|||
|
||||
Do NOT prompt the user for input of any kind.
|
||||
|
||||
.. versionchanged:: 1.9
|
||||
|
||||
The ``--no-input`` alias was added.
|
||||
|
||||
.. django-admin-option:: --ignore PATTERN, -i PATTERN
|
||||
|
||||
Ignore files or directories matching this glob-style pattern. Use multiple
|
||||
|
|
|
@ -303,11 +303,6 @@ enclosure per item, the ``item_enclosure_url``, ``item_enclosure_length``, and
|
|||
``item_enclosure_mime_type`` hooks. See the ``ExampleFeed`` class below for
|
||||
usage examples.
|
||||
|
||||
.. versionchanged:: 1.9
|
||||
|
||||
Support for multiple enclosures per feed item was added through the
|
||||
``item_enclosures`` hook.
|
||||
|
||||
Language
|
||||
--------
|
||||
|
||||
|
|
|
@ -289,10 +289,6 @@ the HOST header <host-headers-virtual-hosting>` and that there aren't any
|
|||
(because XSS vulnerabilities already let an attacker do anything a CSRF
|
||||
vulnerability allows and much worse).
|
||||
|
||||
.. versionchanged:: 1.9
|
||||
|
||||
Checking against the :setting:`CSRF_COOKIE_DOMAIN` setting was added.
|
||||
|
||||
.. versionchanged:: 1.10
|
||||
|
||||
Added salting to the token and started changing it with each request
|
||||
|
|
|
@ -34,10 +34,6 @@ The command-line examples throughout this document use ``django-admin`` to
|
|||
be consistent, but any example can use ``manage.py`` or ``python -m django``
|
||||
just as well.
|
||||
|
||||
.. versionadded:: 1.9
|
||||
|
||||
``python -m django`` was added.
|
||||
|
||||
Usage
|
||||
=====
|
||||
|
||||
|
@ -168,11 +164,6 @@ are excluded.
|
|||
|
||||
Includes fuzzy translations into compiled files.
|
||||
|
||||
.. versionchanged:: 1.9
|
||||
|
||||
``compilemessages`` now matches the operation of :djadmin:`makemessages`,
|
||||
scanning the project tree for ``.po`` files to compile.
|
||||
|
||||
Example usage::
|
||||
|
||||
django-admin compilemessages --locale=pt_BR
|
||||
|
@ -203,10 +194,6 @@ Specifies the database in which the cache table(s) will be created. Defaults to
|
|||
Prints the SQL that would be run without actually running it, so you can
|
||||
customize it or use the migrations framework.
|
||||
|
||||
.. versionchanged:: 1.9
|
||||
|
||||
The ``--dry-run`` option was added.
|
||||
|
||||
``dbshell``
|
||||
-----------
|
||||
|
||||
|
@ -324,10 +311,6 @@ standard output.
|
|||
When this option is set and ``--verbosity`` is greater than 0 (the default), a
|
||||
progress bar is shown in the terminal.
|
||||
|
||||
.. versionchanged:: 1.9
|
||||
|
||||
The progress bar in the terminal was added.
|
||||
|
||||
``flush``
|
||||
---------
|
||||
|
||||
|
@ -343,10 +326,6 @@ should drop and recreate the database and then run :djadmin:`migrate` instead.
|
|||
|
||||
Suppresses all user prompts.
|
||||
|
||||
.. versionchanged:: 1.9
|
||||
|
||||
The ``--no-input`` alias was added.
|
||||
|
||||
.. django-admin-option:: --database DATABASE
|
||||
|
||||
Specifies the database to flush. Defaults to ``default``.
|
||||
|
@ -684,10 +663,6 @@ of a ``ForeignKey``, for example).
|
|||
Suppresses all user prompts. If a suppressed prompt cannot be resolved
|
||||
automatically, the command will exit with error code 3.
|
||||
|
||||
.. versionchanged:: 1.9
|
||||
|
||||
The ``--no-input`` alias was added.
|
||||
|
||||
.. django-admin-option:: --empty
|
||||
|
||||
Outputs an empty migration for the specified apps, for manual editing. This is
|
||||
|
@ -774,8 +749,6 @@ schema matches what is recorded in your initial migration.
|
|||
|
||||
.. django-admin-option:: --run-syncdb
|
||||
|
||||
.. versionadded:: 1.9
|
||||
|
||||
Allows creating tables for apps without migrations. While this isn't
|
||||
recommended, the migrations framework is sometimes too slow on large projects
|
||||
with hundreds of models.
|
||||
|
@ -785,10 +758,6 @@ with hundreds of models.
|
|||
Suppresses all user prompts. An example prompt is asking about removing stale
|
||||
content types.
|
||||
|
||||
.. versionchanged:: 1.9
|
||||
|
||||
The ``--no-input`` alias was added.
|
||||
|
||||
``runserver``
|
||||
-------------
|
||||
|
||||
|
@ -925,8 +894,6 @@ you want to configure Django to serve static media, read
|
|||
|
||||
.. django-admin:: sendtestemail [email [email ...]]
|
||||
|
||||
.. versionadded:: 1.9
|
||||
|
||||
Sends a test email (to confirm email sending through Django is working) to the
|
||||
recipient(s) specified. For example::
|
||||
|
||||
|
@ -1053,12 +1020,6 @@ for running the migration in the forwards direction.
|
|||
|
||||
Specifies the database for which to generate the SQL. Defaults to ``default``.
|
||||
|
||||
.. versionchanged:: 1.9
|
||||
|
||||
To increase the readability of the overall SQL output the SQL code
|
||||
generated for each migration operation is preceded by the operation's
|
||||
description.
|
||||
|
||||
``sqlsequencereset``
|
||||
--------------------
|
||||
|
||||
|
@ -1086,8 +1047,6 @@ down into fewer migrations, if possible. The resulting squashed migrations
|
|||
can live alongside the unsquashed ones safely. For more information,
|
||||
please read :ref:`migration-squashing`.
|
||||
|
||||
.. versionadded:: 1.9
|
||||
|
||||
When ``start_migration_name`` is given, Django will only include migrations
|
||||
starting from and including this migration. This helps to mitigate the
|
||||
squashing limitation of :class:`~django.db.migrations.operations.RunPython` and
|
||||
|
@ -1105,10 +1064,6 @@ behavior, as optimization is meant to be safe.
|
|||
|
||||
Suppresses all user prompts.
|
||||
|
||||
.. versionchanged:: 1.9
|
||||
|
||||
The ``--no-input`` alias was added.
|
||||
|
||||
``startapp``
|
||||
------------
|
||||
|
||||
|
@ -1173,10 +1128,6 @@ files is:
|
|||
- ``camel_case_app_name`` -- the app name in camel case format
|
||||
- ``docs_version`` -- the version of the documentation: ``'dev'`` or ``'1.x'``
|
||||
|
||||
.. versionadded:: 1.9
|
||||
|
||||
``camel_case_app_name`` was added.
|
||||
|
||||
.. _render_warning:
|
||||
|
||||
.. warning::
|
||||
|
@ -1195,10 +1146,6 @@ files is:
|
|||
byte-compile invalid ``*.py`` files, template files ending with ``.py-tpl``
|
||||
will be renamed to ``.py``.
|
||||
|
||||
.. versionchanged:: 1.9.2
|
||||
|
||||
Renaming of ``.py-tpl`` to ``.py`` was added.
|
||||
|
||||
.. _source: https://github.com/django/django/tree/master/django/conf/app_template/
|
||||
|
||||
``startproject``
|
||||
|
@ -1278,19 +1225,11 @@ Overrides the default address where the live server (used with
|
|||
:class:`~django.test.LiveServerTestCase`) is expected to run from. The default
|
||||
value is ``localhost:8081-8179``.
|
||||
|
||||
.. versionchanged:: 1.9
|
||||
|
||||
In earlier versions, the default value was ``localhost:8081``.
|
||||
|
||||
.. django-admin-option:: --noinput, --no-input
|
||||
|
||||
Suppresses all user prompts. A typical prompt is a warning about deleting an
|
||||
existing test database.
|
||||
|
||||
.. versionchanged:: 1.9
|
||||
|
||||
The ``--no-input`` alias was added.
|
||||
|
||||
Test runner options
|
||||
~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
|
@ -1320,8 +1259,6 @@ Enables :ref:`SQL logging <django-db-logger>` for failing tests. If
|
|||
|
||||
.. django-admin-option:: --parallel [N]
|
||||
|
||||
.. versionadded:: 1.9
|
||||
|
||||
Runs tests in separate parallel processes. Since modern processors have
|
||||
multiple cores, this allows running tests significantly faster.
|
||||
|
||||
|
@ -1441,10 +1378,6 @@ To run on 1.2.3.4:7000 with a ``test`` fixture::
|
|||
Suppresses all user prompts. A typical prompt is a warning about deleting an
|
||||
existing test database.
|
||||
|
||||
.. versionchanged:: 1.9
|
||||
|
||||
The ``--no-input`` alias was added.
|
||||
|
||||
Commands provided by applications
|
||||
=================================
|
||||
|
||||
|
@ -1696,10 +1629,6 @@ number of roles in which color is used:
|
|||
* ``migrate_heading`` - A heading in a migrations management command.
|
||||
* ``migrate_label`` - A migration name.
|
||||
|
||||
.. versionchanged:: 1.9
|
||||
|
||||
``success`` was added.
|
||||
|
||||
Each of these roles can be assigned a specific foreground and
|
||||
background color, from the following list:
|
||||
|
||||
|
|
|
@ -95,10 +95,6 @@ The ``File`` class
|
|||
``truncate``, ``writelines``, ``xreadlines``. If you are using
|
||||
Python 3, the ``seekable`` method is also available.
|
||||
|
||||
.. versionchanged:: 1.9
|
||||
|
||||
The ``seekable`` method was added.
|
||||
|
||||
.. currentmodule:: django.core.files.base
|
||||
|
||||
The ``ContentFile`` class
|
||||
|
|
|
@ -716,8 +716,6 @@ There are several other ways to customize the order:
|
|||
|
||||
.. attribute:: Form.field_order
|
||||
|
||||
.. versionadded:: 1.9
|
||||
|
||||
By default ``Form.field_order=None``, which retains the order in which you
|
||||
define the fields in your form class. If ``field_order`` is a list of field
|
||||
names, the fields are ordered as specified by the list and remaining fields are
|
||||
|
@ -732,8 +730,6 @@ the ``Form``, then the latter ``field_order`` will have precedence.
|
|||
|
||||
.. method:: Form.order_fields(field_order)
|
||||
|
||||
.. versionadded:: 1.9
|
||||
|
||||
You may rearrange the fields any time using ``order_fields()`` with a list of
|
||||
field names as in :attr:`~django.forms.Form.field_order`.
|
||||
|
||||
|
@ -1013,8 +1009,6 @@ Methods of ``BoundField``
|
|||
Customizing ``BoundField``
|
||||
==========================
|
||||
|
||||
.. versionadded:: 1.9
|
||||
|
||||
If you need to access some additional information about a form field in a
|
||||
template and using a subclass of :class:`~django.forms.Field` isn't
|
||||
sufficient, consider also customizing :class:`~django.forms.BoundField`.
|
||||
|
@ -1201,7 +1195,3 @@ The prefix can also be specified on the form class::
|
|||
>>> class PersonForm(forms.Form):
|
||||
... ...
|
||||
... prefix = 'person'
|
||||
|
||||
.. versionadded:: 1.9
|
||||
|
||||
The ability to specify ``prefix`` on the form class was added.
|
||||
|
|
|
@ -305,8 +305,6 @@ more information.
|
|||
|
||||
.. attribute:: Field.disabled
|
||||
|
||||
.. versionadded:: 1.9
|
||||
|
||||
The ``disabled`` boolean argument, when set to ``True``, disables a form field
|
||||
using the ``disabled`` HTML attribute so that it won't be editable by users.
|
||||
Even if a user tampers with the field's value submitted to the server, it will
|
||||
|
@ -379,8 +377,6 @@ For each field, we describe the default widget used if you don't specify
|
|||
|
||||
.. attribute:: strip
|
||||
|
||||
.. versionadded:: 1.9
|
||||
|
||||
If ``True`` (default), the value will be stripped of leading and
|
||||
trailing whitespace.
|
||||
|
||||
|
@ -834,8 +830,6 @@ For each field, we describe the default widget used if you don't specify
|
|||
|
||||
.. attribute:: strip
|
||||
|
||||
.. versionadded:: 1.9
|
||||
|
||||
Defaults to ``False``. If enabled, stripping will be applied before the
|
||||
regex validation.
|
||||
|
||||
|
@ -858,8 +852,6 @@ For each field, we describe the default widget used if you don't specify
|
|||
|
||||
.. attribute:: allow_unicode
|
||||
|
||||
.. versionadded:: 1.9
|
||||
|
||||
A boolean instructing the field to accept Unicode letters in addition
|
||||
to ASCII letters. Defaults to ``False``.
|
||||
|
||||
|
|
|
@ -49,10 +49,6 @@ Model Form API reference. For introductory material about model forms, see the
|
|||
information. Omitting any definition of the fields to use will result in
|
||||
an :exc:`~django.core.exceptions.ImproperlyConfigured` exception.
|
||||
|
||||
.. versionadded:: 1.9
|
||||
|
||||
The ``field_classes`` keyword argument was added.
|
||||
|
||||
``modelformset_factory``
|
||||
========================
|
||||
|
||||
|
@ -72,10 +68,6 @@ Model Form API reference. For introductory material about model forms, see the
|
|||
|
||||
See :ref:`model-formsets` for example usage.
|
||||
|
||||
.. versionadded:: 1.9
|
||||
|
||||
The ``field_classes`` keyword argument was added.
|
||||
|
||||
``inlineformset_factory``
|
||||
=========================
|
||||
|
||||
|
@ -89,7 +81,3 @@ Model Form API reference. For introductory material about model forms, see the
|
|||
the ``parent_model``, you must specify a ``fk_name``.
|
||||
|
||||
See :ref:`inline-formsets` for example usage.
|
||||
|
||||
.. versionadded:: 1.9
|
||||
|
||||
The ``field_classes`` keyword argument was added.
|
||||
|
|
|
@ -223,11 +223,6 @@ foundation for custom widgets.
|
|||
microseconds part of :class:`~datetime.datetime` and
|
||||
:class:`~datetime.time` values will be set to ``0``.
|
||||
|
||||
.. versionadded:: 1.9
|
||||
|
||||
In older versions, this attribute was only defined on the date
|
||||
and time widgets (as ``False``).
|
||||
|
||||
.. method:: format_value(value)
|
||||
|
||||
Cleans and returns a value for use in the widget template. ``value``
|
||||
|
@ -843,9 +838,3 @@ Composite widgets
|
|||
empty_label=("Choose Year", "Choose Month", "Choose Day"),
|
||||
),
|
||||
)
|
||||
|
||||
.. versionchanged:: 1.9
|
||||
|
||||
This widget used to be located in the ``django.forms.extras.widgets``
|
||||
package. It is now defined in ``django.forms.widgets`` and like the
|
||||
other widgets it can be imported directly from ``django.forms``.
|
||||
|
|
|
@ -407,8 +407,6 @@ Middleware for utilizing Web server provided authentication. See
|
|||
|
||||
.. class:: PersistentRemoteUserMiddleware
|
||||
|
||||
.. versionadded:: 1.9
|
||||
|
||||
Middleware for utilizing Web server provided authentication when enabled only
|
||||
on the login page. See :ref:`persistent-remote-user-middleware-howto` for usage
|
||||
details.
|
||||
|
|
|
@ -114,8 +114,6 @@ Usage example::
|
|||
|
||||
.. class:: Greatest(*expressions, **extra)
|
||||
|
||||
.. versionadded:: 1.9
|
||||
|
||||
Accepts a list of at least two field names or expressions and returns the
|
||||
greatest value. Each argument must be of a similar type, so mixing text and
|
||||
numbers will result in a database error.
|
||||
|
@ -158,8 +156,6 @@ and ``comment.modified``.
|
|||
|
||||
.. class:: Least(*expressions, **extra)
|
||||
|
||||
.. versionadded:: 1.9
|
||||
|
||||
Accepts a list of at least two field names or expressions and returns the
|
||||
least value. Each argument must be of a similar type, so mixing text and numbers
|
||||
will result in a database error.
|
||||
|
@ -204,10 +200,6 @@ It can also be registered as a transform. For example::
|
|||
>>> # Get authors whose name is longer than 7 characters
|
||||
>>> authors = Author.objects.filter(name__length__gt=7)
|
||||
|
||||
.. versionchanged:: 1.9
|
||||
|
||||
The ability to register the function as a transform was added.
|
||||
|
||||
``Lower``
|
||||
=========
|
||||
|
||||
|
@ -226,17 +218,11 @@ Usage example::
|
|||
>>> print(author.name_lower)
|
||||
margaret smith
|
||||
|
||||
.. versionchanged:: 1.9
|
||||
|
||||
The ability to register the function as a transform was added.
|
||||
|
||||
``Now``
|
||||
=======
|
||||
|
||||
.. class:: Now()
|
||||
|
||||
.. versionadded:: 1.9
|
||||
|
||||
Returns the database server's current date and time when the query is executed,
|
||||
typically using the SQL ``CURRENT_TIMESTAMP``.
|
||||
|
||||
|
@ -290,10 +276,6 @@ Usage example::
|
|||
>>> print(author.name_upper)
|
||||
MARGARET SMITH
|
||||
|
||||
.. versionchanged:: 1.9
|
||||
|
||||
The ability to register the function as a transform was added.
|
||||
|
||||
Date Functions
|
||||
==============
|
||||
|
||||
|
|
|
@ -10,10 +10,6 @@ number of built-in expressions (documented below) that can be used to help you
|
|||
write queries. Expressions can be combined, or in some cases nested, to form
|
||||
more complex computations.
|
||||
|
||||
.. versionchanged:: 1.9
|
||||
|
||||
Support for using expressions when creating new model instances was added.
|
||||
|
||||
Supported arithmetic
|
||||
====================
|
||||
|
||||
|
|
|
@ -1064,8 +1064,6 @@ of some other value. You can do this automatically in the admin using
|
|||
|
||||
.. attribute:: SlugField.allow_unicode
|
||||
|
||||
.. versionadded:: 1.9
|
||||
|
||||
If ``True``, the field accepts Unicode letters in addition to ASCII
|
||||
letters. Defaults to ``False``.
|
||||
|
||||
|
@ -1165,12 +1163,6 @@ Django also defines a set of fields that represent relations.
|
|||
A many-to-one relationship. Requires a positional argument: the class to which
|
||||
the model is related.
|
||||
|
||||
.. versionchanged:: 1.9
|
||||
|
||||
``on_delete`` can now be used as the second positional argument (previously
|
||||
it was typically only passed as a keyword argument). It will be a required
|
||||
argument in Django 2.0.
|
||||
|
||||
.. _recursive-relationships:
|
||||
|
||||
To create a recursive relationship -- an object that has a many-to-one
|
||||
|
@ -1672,12 +1664,6 @@ A one-to-one relationship. Conceptually, this is similar to a
|
|||
:class:`ForeignKey` with :attr:`unique=True <Field.unique>`, but the
|
||||
"reverse" side of the relation will directly return a single object.
|
||||
|
||||
.. versionchanged:: 1.9
|
||||
|
||||
``on_delete`` can now be used as the second positional argument (previously
|
||||
it was typically only passed as a keyword argument). It will be a required
|
||||
argument in Django 2.0.
|
||||
|
||||
This is most useful as the primary key of a model which "extends"
|
||||
another model in some way; :ref:`multi-table-inheritance` is
|
||||
implemented by adding an implicit one-to-one relation from the child
|
||||
|
|
|
@ -564,14 +564,6 @@ Sometimes with :ref:`multi-table inheritance <multi-table-inheritance>` you may
|
|||
want to delete only a child model's data. Specifying ``keep_parents=True`` will
|
||||
keep the parent model's data.
|
||||
|
||||
.. versionchanged:: 1.9
|
||||
|
||||
The ``keep_parents`` parameter was added.
|
||||
|
||||
.. versionchanged:: 1.9
|
||||
|
||||
The return value describing the number of objects deleted was added.
|
||||
|
||||
Pickling objects
|
||||
================
|
||||
|
||||
|
|
|
@ -50,10 +50,6 @@ register lookups on itself. The two prominent examples are
|
|||
the same name. ``lookup_name`` will be used for this lookup if
|
||||
provided, otherwise ``lookup.lookup_name`` will be used.
|
||||
|
||||
.. versionchanged:: 1.9
|
||||
|
||||
The ``lookup_name`` parameter was added.
|
||||
|
||||
.. method:: get_lookup(lookup_name)
|
||||
|
||||
Returns the :class:`Lookup` named ``lookup_name`` registered in the class.
|
||||
|
@ -140,10 +136,6 @@ following methods:
|
|||
one argument. It can also be used on the right hand side of a filter or
|
||||
directly as an annotation.
|
||||
|
||||
.. versionchanged:: 1.9
|
||||
|
||||
``Transform`` is now a subclass of ``Func``.
|
||||
|
||||
.. attribute:: bilateral
|
||||
|
||||
A boolean indicating whether this transformation should apply to both
|
||||
|
|
|
@ -29,8 +29,6 @@ Available ``Meta`` options
|
|||
|
||||
app_label = 'myapp'
|
||||
|
||||
.. versionadded:: 1.9
|
||||
|
||||
If you want to represent a model with the format ``app_label.object_name``
|
||||
or ``app_label.model_name`` you can use ``model._meta.label``
|
||||
or ``model._meta.label_lower`` respectively.
|
||||
|
@ -352,8 +350,6 @@ The name of the manager to use for the model's
|
|||
|
||||
.. attribute:: Options.required_db_features
|
||||
|
||||
.. versionadded:: 1.9
|
||||
|
||||
List of database features that the current connection should have so that
|
||||
the model is considered during the migration phase. For example, if you set
|
||||
this list to ``['gis_enabled']``, the model will only be synchronized on
|
||||
|
@ -366,8 +362,6 @@ The name of the manager to use for the model's
|
|||
|
||||
.. attribute:: Options.required_db_vendor
|
||||
|
||||
.. versionadded:: 1.9
|
||||
|
||||
Name of a supported database vendor that this model is specific to. Current
|
||||
built-in vendor names are: ``sqlite``, ``postgresql``, ``mysql``,
|
||||
``oracle``. If this attribute is not empty and the current connection vendor
|
||||
|
@ -471,8 +465,6 @@ Read-only ``Meta`` attributes
|
|||
|
||||
.. attribute:: Options.label
|
||||
|
||||
.. versionadded:: 1.9
|
||||
|
||||
Representation of the object, returns ``app_label.object_name``, e.g.
|
||||
``'polls.Question'``.
|
||||
|
||||
|
@ -481,7 +473,5 @@ Read-only ``Meta`` attributes
|
|||
|
||||
.. attribute:: Options.label_lower
|
||||
|
||||
.. versionadded:: 1.9
|
||||
|
||||
Representation of the model, returns ``app_label.model_name``, e.g.
|
||||
``'polls.question'``.
|
||||
|
|
|
@ -1831,10 +1831,6 @@ This has a number of caveats though:
|
|||
unless the database backend supports it (currently PostgreSQL).
|
||||
* It does not work with many-to-many relationships.
|
||||
|
||||
.. versionchanged:: 1.9
|
||||
|
||||
Support for using ``bulk_create()`` with proxy models was added.
|
||||
|
||||
.. versionchanged:: 1.10
|
||||
|
||||
Support for setting primary keys on objects created using ``bulk_create()``
|
||||
|
@ -2169,10 +2165,6 @@ For example, to delete all the entries in a particular blog::
|
|||
>>> Entry.objects.filter(blog=b).delete()
|
||||
(4, {'weblog.Entry': 2, 'weblog.Entry_authors': 2})
|
||||
|
||||
.. versionchanged:: 1.9
|
||||
|
||||
The return value describing the number of objects deleted was added.
|
||||
|
||||
By default, Django's :class:`~django.db.models.ForeignKey` emulates the SQL
|
||||
constraint ``ON DELETE CASCADE`` — in other words, any objects with foreign
|
||||
keys pointing at the objects to be deleted will be deleted along with them.
|
||||
|
@ -2548,8 +2540,6 @@ numbers and even characters.
|
|||
``date``
|
||||
~~~~~~~~
|
||||
|
||||
.. versionadded:: 1.9
|
||||
|
||||
For datetime fields, casts the value as date. Allows chaining additional field
|
||||
lookups. Takes a date value.
|
||||
|
||||
|
@ -2587,10 +2577,6 @@ SQL equivalent::
|
|||
When :setting:`USE_TZ` is ``True``, datetime fields are converted to the
|
||||
current time zone before filtering.
|
||||
|
||||
.. versionchanged:: 1.9
|
||||
|
||||
Allowed chaining additional field lookups.
|
||||
|
||||
.. fieldlookup:: month
|
||||
|
||||
``month``
|
||||
|
@ -2615,10 +2601,6 @@ When :setting:`USE_TZ` is ``True``, datetime fields are converted to the
|
|||
current time zone before filtering. This requires :ref:`time zone definitions
|
||||
in the database <database-time-zone-definitions>`.
|
||||
|
||||
.. versionchanged:: 1.9
|
||||
|
||||
Allowed chaining additional field lookups.
|
||||
|
||||
.. fieldlookup:: day
|
||||
|
||||
``day``
|
||||
|
@ -2646,10 +2628,6 @@ When :setting:`USE_TZ` is ``True``, datetime fields are converted to the
|
|||
current time zone before filtering. This requires :ref:`time zone definitions
|
||||
in the database <database-time-zone-definitions>`.
|
||||
|
||||
.. versionchanged:: 1.9
|
||||
|
||||
Allowed chaining additional field lookups.
|
||||
|
||||
.. fieldlookup:: week_day
|
||||
|
||||
``week_day``
|
||||
|
@ -2677,10 +2655,6 @@ When :setting:`USE_TZ` is ``True``, datetime fields are converted to the
|
|||
current time zone before filtering. This requires :ref:`time zone definitions
|
||||
in the database <database-time-zone-definitions>`.
|
||||
|
||||
.. versionchanged:: 1.9
|
||||
|
||||
Allowed chaining additional field lookups.
|
||||
|
||||
.. fieldlookup:: hour
|
||||
|
||||
``hour``
|
||||
|
@ -2706,15 +2680,6 @@ SQL equivalent::
|
|||
For datetime fields, when :setting:`USE_TZ` is ``True``, values are converted
|
||||
to the current time zone before filtering.
|
||||
|
||||
.. versionchanged:: 1.9
|
||||
|
||||
Added support for :class:`~django.db.models.TimeField` on SQLite (other
|
||||
databases supported it as of 1.7).
|
||||
|
||||
.. versionchanged:: 1.9
|
||||
|
||||
Allowed chaining additional field lookups.
|
||||
|
||||
.. fieldlookup:: minute
|
||||
|
||||
``minute``
|
||||
|
@ -2740,15 +2705,6 @@ SQL equivalent::
|
|||
For datetime fields, When :setting:`USE_TZ` is ``True``, values are converted
|
||||
to the current time zone before filtering.
|
||||
|
||||
.. versionchanged:: 1.9
|
||||
|
||||
Added support for :class:`~django.db.models.TimeField` on SQLite (other
|
||||
databases supported it as of 1.7).
|
||||
|
||||
.. versionchanged:: 1.9
|
||||
|
||||
Allowed chaining additional field lookups.
|
||||
|
||||
.. fieldlookup:: second
|
||||
|
||||
``second``
|
||||
|
@ -2774,15 +2730,6 @@ SQL equivalent::
|
|||
For datetime fields, when :setting:`USE_TZ` is ``True``, values are converted
|
||||
to the current time zone before filtering.
|
||||
|
||||
.. versionchanged:: 1.9
|
||||
|
||||
Added support for :class:`~django.db.models.TimeField` on SQLite (other
|
||||
databases supported it as of 1.7).
|
||||
|
||||
.. versionchanged:: 1.9
|
||||
|
||||
Allowed chaining additional field lookups.
|
||||
|
||||
.. fieldlookup:: isnull
|
||||
|
||||
``isnull``
|
||||
|
@ -2942,11 +2889,6 @@ by the aggregate.
|
|||
* Return type: ``float`` (or the type of whatever ``output_field`` is
|
||||
specified)
|
||||
|
||||
.. versionchanged:: 1.9
|
||||
|
||||
The ``output_field`` parameter was added to allow aggregating over
|
||||
non-numeric columns, such as ``DurationField``.
|
||||
|
||||
``Count``
|
||||
~~~~~~~~~
|
||||
|
||||
|
|
|
@ -62,12 +62,6 @@ Related objects reference
|
|||
some custom logic when a relationship is created, listen to the
|
||||
:data:`~django.db.models.signals.m2m_changed` signal.
|
||||
|
||||
.. versionchanged:: 1.9
|
||||
|
||||
The ``bulk`` parameter was added. In older versions, foreign key
|
||||
updates were always done using ``save()``. Use ``bulk=False`` if
|
||||
you require the old behavior.
|
||||
|
||||
.. method:: create(**kwargs)
|
||||
|
||||
Creates a new object, saves it and puts it in the related object set.
|
||||
|
@ -147,8 +141,6 @@ Related objects reference
|
|||
|
||||
.. method:: set(objs, bulk=True, clear=False)
|
||||
|
||||
.. versionadded:: 1.9
|
||||
|
||||
Replace the set of related objects::
|
||||
|
||||
>>> new_list = [obj1, obj2, obj3]
|
||||
|
@ -191,12 +183,6 @@ will first disassociate any existing objects in the related set before adding
|
|||
the contents of ``new_list``. Otherwise the objects in ``new_list`` will be
|
||||
added to the existing related object set.
|
||||
|
||||
.. versionchanged:: 1.9
|
||||
|
||||
In earlier versions, direct assignment used to perform ``clear()`` followed
|
||||
by ``add()``. It now performs a ``set()`` with the keyword argument
|
||||
``clear=False``.
|
||||
|
||||
.. deprecated:: 1.10
|
||||
|
||||
Direct assignment is deprecated in favor of the
|
||||
|
|
|
@ -200,11 +200,6 @@ application.
|
|||
``urlconf`` can be set to ``None`` to revert any changes made by previous
|
||||
middleware and return to using the :setting:`ROOT_URLCONF`.
|
||||
|
||||
.. versionchanged:: 1.9
|
||||
|
||||
Setting ``urlconf=None`` raised
|
||||
:exc:`~django.core.exceptions.ImproperlyConfigured` in older versions.
|
||||
|
||||
Attributes set by middleware
|
||||
----------------------------
|
||||
|
||||
|
@ -284,8 +279,6 @@ Methods
|
|||
|
||||
.. method:: HttpRequest.get_port()
|
||||
|
||||
.. versionadded:: 1.9
|
||||
|
||||
Returns the originating port of the request using information from the
|
||||
``HTTP_X_FORWARDED_PORT`` (if :setting:`USE_X_FORWARDED_PORT` is enabled)
|
||||
and ``SERVER_PORT`` ``META`` variables, in that order.
|
||||
|
@ -689,24 +682,17 @@ Attributes
|
|||
|
||||
The :rfc:`HTTP status code <7231#section-6>` for the response.
|
||||
|
||||
.. versionchanged:: 1.9
|
||||
|
||||
Unless :attr:`reason_phrase` is explicitly set, modifying the value of
|
||||
``status_code`` outside the constructor will also modify the value of
|
||||
``reason_phrase``.
|
||||
|
||||
.. attribute:: HttpResponse.reason_phrase
|
||||
|
||||
The HTTP reason phrase for the response.
|
||||
The HTTP reason phrase for the response. It uses the :rfc:`HTTP standard's
|
||||
<7231#section-6.1>` default reason phrases.
|
||||
|
||||
.. versionchanged:: 1.9
|
||||
|
||||
``reason_phrase`` no longer defaults to all capital letters. It now
|
||||
uses the :rfc:`HTTP standard's <7231#section-6.1>` default reason
|
||||
phrases.
|
||||
|
||||
Unless explicitly set, ``reason_phrase`` is determined by the current
|
||||
value of :attr:`status_code`.
|
||||
Unless explicitly set, ``reason_phrase`` is determined by the value of
|
||||
:attr:`status_code`.
|
||||
|
||||
.. attribute:: HttpResponse.streaming
|
||||
|
||||
|
@ -962,10 +948,6 @@ types of HTTP responses. Like ``HttpResponse``, these subclasses live in
|
|||
The ``json_dumps_params`` parameter is a dictionary of keyword arguments
|
||||
to pass to the ``json.dumps()`` call used to generate the response.
|
||||
|
||||
.. versionchanged:: 1.9
|
||||
|
||||
The ``json_dumps_params`` argument was added.
|
||||
|
||||
Usage
|
||||
-----
|
||||
|
||||
|
@ -976,7 +958,6 @@ Typical usage could look like::
|
|||
>>> response.content
|
||||
b'{"foo": "bar"}'
|
||||
|
||||
|
||||
Serializing non-dictionary objects
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
|
@ -1058,24 +1039,17 @@ Attributes
|
|||
|
||||
The :rfc:`HTTP status code <7231#section-6>` for the response.
|
||||
|
||||
.. versionchanged:: 1.9
|
||||
|
||||
Unless :attr:`reason_phrase` is explicitly set, modifying the value of
|
||||
``status_code`` outside the constructor will also modify the value of
|
||||
``reason_phrase``.
|
||||
|
||||
.. attribute:: StreamingHttpResponse.reason_phrase
|
||||
|
||||
The HTTP reason phrase for the response.
|
||||
The HTTP reason phrase for the response. It uses the :rfc:`HTTP standard's
|
||||
<7231#section-6.1>` default reason phrases.
|
||||
|
||||
.. versionchanged:: 1.9
|
||||
|
||||
``reason_phrase`` no longer defaults to all capital letters. It now
|
||||
uses the :rfc:`HTTP standard's <7231#section-6.1>` default reason
|
||||
phrases.
|
||||
|
||||
Unless explicitly set, ``reason_phrase`` is determined by the current
|
||||
value of :attr:`status_code`.
|
||||
Unless explicitly set, ``reason_phrase`` is determined by the value of
|
||||
:attr:`status_code`.
|
||||
|
||||
.. attribute:: StreamingHttpResponse.streaming
|
||||
|
||||
|
|
|
@ -399,8 +399,6 @@ exists, it will be used to render the page.
|
|||
``CSRF_HEADER_NAME``
|
||||
--------------------
|
||||
|
||||
.. versionadded:: 1.9
|
||||
|
||||
Default: ``'HTTP_X_CSRFTOKEN'``
|
||||
|
||||
The name of the request header used for CSRF authentication.
|
||||
|
@ -416,8 +414,6 @@ should be ``'HTTP_X_XSRF_TOKEN'``.
|
|||
``CSRF_TRUSTED_ORIGINS``
|
||||
------------------------
|
||||
|
||||
.. versionadded:: 1.9
|
||||
|
||||
Default: ``[]`` (Empty list)
|
||||
|
||||
A list of hosts which are trusted origins for unsafe requests (e.g. ``POST``).
|
||||
|
@ -510,12 +506,6 @@ The database backend to use. The built-in database backends are:
|
|||
You can use a database backend that doesn't ship with Django by setting
|
||||
``ENGINE`` to a fully-qualified path (i.e. ``mypackage.backends.whatever``).
|
||||
|
||||
.. versionchanged:: 1.9
|
||||
|
||||
The ``django.db.backends.postgresql`` backend is named
|
||||
``django.db.backends.postgresql_psycopg2`` in older releases. For backwards
|
||||
compatibility, the old name still works in newer versions.
|
||||
|
||||
.. setting:: HOST
|
||||
|
||||
``HOST``
|
||||
|
@ -603,8 +593,6 @@ default port. Not used with SQLite.
|
|||
``TIME_ZONE``
|
||||
~~~~~~~~~~~~~
|
||||
|
||||
.. versionadded:: 1.9
|
||||
|
||||
Default: ``None``
|
||||
|
||||
A string representing the time zone for datetimes stored in this database
|
||||
|
@ -624,11 +612,6 @@ according to this option if it is set and in UTC if it isn't.
|
|||
When :setting:`USE_TZ` is ``True`` and the database supports time zones (e.g.
|
||||
PostgreSQL), it is an error to set this option.
|
||||
|
||||
.. versionchanged:: 1.9
|
||||
|
||||
Before Django 1.9, the PostgreSQL database backend accepted an
|
||||
undocumented ``TIME_ZONE`` option, which caused data corruption.
|
||||
|
||||
When :setting:`USE_TZ` is ``False``, it is an error to set this option.
|
||||
|
||||
.. _pytz: http://pytz.sourceforge.net/
|
||||
|
@ -1900,8 +1883,6 @@ the ``blog.db_migrations`` package.
|
|||
If you provide the ``app_label`` argument, :djadmin:`makemigrations` will
|
||||
automatically create the package if it doesn't already exist.
|
||||
|
||||
.. versionadded:: 1.9
|
||||
|
||||
When you supply ``None`` as a value for an app, Django will consider the app as
|
||||
an app without migrations regardless of an existing ``migrations`` submodule.
|
||||
This can be used, for example, in a test settings file to skip migrations while
|
||||
|
@ -2259,11 +2240,6 @@ A list of identifiers of messages generated by the system check framework
|
|||
(i.e. ``["models.W001"]``) that you wish to permanently acknowledge and ignore.
|
||||
Silenced checks will not be output to the console.
|
||||
|
||||
.. versionchanged:: 1.9
|
||||
|
||||
In older versions, silenced messages of ``ERROR`` level or higher were
|
||||
printed to the console.
|
||||
|
||||
See also the :doc:`/ref/checks` documentation.
|
||||
|
||||
.. setting:: TEMPLATES
|
||||
|
@ -2595,8 +2571,6 @@ number, in which case you shouldn't use :setting:`USE_X_FORWARDED_PORT`.
|
|||
``USE_X_FORWARDED_PORT``
|
||||
------------------------
|
||||
|
||||
.. versionadded:: 1.9
|
||||
|
||||
Default: ``False``
|
||||
|
||||
A boolean that specifies whether to use the ``X-Forwarded-Port`` header in
|
||||
|
@ -2789,8 +2763,6 @@ Default::
|
|||
``AUTH_PASSWORD_VALIDATORS``
|
||||
----------------------------
|
||||
|
||||
.. versionadded:: 1.9
|
||||
|
||||
Default: ``[]`` (Empty list)
|
||||
|
||||
The list of validators that are used to check the strength of user's passwords.
|
||||
|
|
|
@ -140,10 +140,6 @@ what's passed by :class:`~django.template.backends.django.DjangoTemplates`.
|
|||
Tags and filters from built-in libraries can be used without first calling
|
||||
the :ttag:`{% load %}<load>` tag.
|
||||
|
||||
.. versionadded:: 1.9
|
||||
|
||||
The ``libraries`` and ``builtins`` arguments were added.
|
||||
|
||||
.. staticmethod:: Engine.get_default()
|
||||
|
||||
When a Django project configures one and only one
|
||||
|
@ -449,8 +445,6 @@ dictionary syntax::
|
|||
|
||||
.. method:: Context.setdefault(key, default=None)
|
||||
|
||||
.. versionadded:: 1.9
|
||||
|
||||
If ``key`` is in the context, returns its value. Otherwise inserts ``key``
|
||||
with a value of ``default`` and returns ``default``.
|
||||
|
||||
|
@ -533,10 +527,6 @@ matching ``pop()`` is called.
|
|||
>>> c['foo']
|
||||
'first level'
|
||||
|
||||
.. versionadded:: 1.9
|
||||
|
||||
The ability to use ``update()`` as a context manager was added.
|
||||
|
||||
Using a ``Context`` as a stack comes in handy in :ref:`some custom template
|
||||
tags <howto-writing-custom-template-tags>`.
|
||||
|
||||
|
@ -974,11 +964,6 @@ loaders. Custom ``Loader`` classes should inherit from
|
|||
``django.template.loaders.base.Loader`` and define the ``get_contents()`` and
|
||||
``get_template_sources()`` methods.
|
||||
|
||||
.. versionchanged:: 1.9
|
||||
|
||||
In previous versions of Django, custom loaders defined a single method:
|
||||
``load_template_source()``.
|
||||
|
||||
Loader methods
|
||||
--------------
|
||||
|
||||
|
@ -1073,13 +1058,6 @@ Template origin
|
|||
Templates have an ``origin`` containing attributes depending on the source
|
||||
they are loaded from.
|
||||
|
||||
.. versionchanged:: 1.9
|
||||
|
||||
Django used to create an origin based on
|
||||
``django.template.loader.LoaderOrigin`` or
|
||||
``django.template.base.StringOrigin``. These have been replaced by
|
||||
``django.template.base.Origin``.
|
||||
|
||||
.. class:: Origin
|
||||
|
||||
.. attribute:: name
|
||||
|
|
|
@ -296,10 +296,6 @@ Or if only some variables should be escaped, you can use::
|
|||
You can use the syntax ``{% firstof var1 var2 var3 as value %}`` to store the
|
||||
output inside a variable.
|
||||
|
||||
.. versionadded:: 1.9
|
||||
|
||||
The "as" syntax was added.
|
||||
|
||||
.. templatetag:: for
|
||||
|
||||
``for``
|
||||
|
@ -732,10 +728,6 @@ is turned off, ``{% include %}`` logs a warning to the ``django.template``
|
|||
logger with the exception that happens while rendering the included template
|
||||
and returns an empty string.
|
||||
|
||||
.. versionchanged:: 1.9
|
||||
|
||||
Template logging now includes the warning logging mentioned above.
|
||||
|
||||
.. note::
|
||||
The :ttag:`include` tag should be considered as an implementation of
|
||||
"render this subtemplate and include the HTML", not as "parse this
|
||||
|
|
|
@ -144,8 +144,6 @@ If the URL does not resolve, the function raises a
|
|||
|
||||
.. attribute:: ResolverMatch.app_names
|
||||
|
||||
.. versionadded:: 1.9
|
||||
|
||||
The list of individual namespace components in the full
|
||||
application namespace for the URL pattern that matches the URL.
|
||||
For example, if the ``app_name`` is ``'foo:bar'``, then ``app_names``
|
||||
|
|
|
@ -161,12 +161,6 @@ The functions defined in this module share the following properties:
|
|||
See :ref:`decorating class based views <decorating-class-based-views>` for
|
||||
example usage.
|
||||
|
||||
.. versionchanged:: 1.9
|
||||
|
||||
The ability to decorate classes, the ``name`` parameter, and the ability
|
||||
for ``decorator`` to accept a list/tuple of decorator functions were
|
||||
added.
|
||||
|
||||
.. function:: decorator_from_middleware(middleware_class)
|
||||
|
||||
Given a middleware class, returns a view decorator. This lets you use
|
||||
|
@ -883,10 +877,6 @@ appropriate entities.
|
|||
|
||||
If ``value`` is ``"你好 World"``, the output will be ``"你好-world"``.
|
||||
|
||||
.. versionchanged:: 1.9
|
||||
|
||||
The ``allow_unicode`` parameter was added.
|
||||
|
||||
.. _time-zone-selection-functions:
|
||||
|
||||
``django.utils.timezone``
|
||||
|
@ -1012,10 +1002,6 @@ appropriate entities.
|
|||
|
||||
``is_dst`` has no effect when ``pytz`` is not installed.
|
||||
|
||||
.. versionchanged:: 1.9
|
||||
|
||||
The ``is_dst`` argument was added.
|
||||
|
||||
.. function:: make_naive(value, timezone=None)
|
||||
|
||||
Returns an naive :class:`~datetime.datetime` that represents in
|
||||
|
|
|
@ -187,8 +187,6 @@ to, or in lieu of custom ``field.clean()`` methods.
|
|||
|
||||
.. data:: validate_unicode_slug
|
||||
|
||||
.. versionadded:: 1.9
|
||||
|
||||
A :class:`RegexValidator` instance that ensures a value consists of only
|
||||
Unicode letters, numbers, underscores, or hyphens.
|
||||
|
||||
|
@ -228,8 +226,6 @@ to, or in lieu of custom ``field.clean()`` methods.
|
|||
|
||||
.. function:: int_list_validator(sep=',', message=None, code='invalid', allow_negative=False)
|
||||
|
||||
.. versionadded:: 1.9
|
||||
|
||||
Returns a :class:`RegexValidator` instance that ensures a string consists
|
||||
of integers separated by ``sep``. It allows negative integers when
|
||||
``allow_negative`` is ``True``.
|
||||
|
@ -275,8 +271,6 @@ to, or in lieu of custom ``field.clean()`` methods.
|
|||
|
||||
.. class:: DecimalValidator(max_digits, decimal_places)
|
||||
|
||||
.. versionadded:: 1.9
|
||||
|
||||
Raises :exc:`~django.core.exceptions.ValidationError` with the following
|
||||
codes:
|
||||
|
||||
|
|
|
@ -87,12 +87,6 @@ Three things to note about 404 views:
|
|||
your 404 view will never be used, and your URLconf will be displayed
|
||||
instead, with some debug information.
|
||||
|
||||
.. versionchanged:: 1.9
|
||||
|
||||
The signature of ``page_not_found()`` changed. The function now accepts a
|
||||
second parameter, the exception that triggered the error. A useful
|
||||
representation of the exception is also passed in the template context.
|
||||
|
||||
.. versionchanged:: 1.10
|
||||
|
||||
Passing a nonexistent ``template_name`` will raise ``TemplateDoesNotExist``.
|
||||
|
@ -149,13 +143,6 @@ view you can use code like this::
|
|||
raise PermissionDenied
|
||||
# ...
|
||||
|
||||
.. versionchanged:: 1.9
|
||||
|
||||
The signature of ``permission_denied()`` changed in Django 1.9. The function
|
||||
now accepts a second parameter, the exception that triggered the error. The
|
||||
unicode representation of the exception is also passed in the template
|
||||
context.
|
||||
|
||||
.. versionchanged:: 1.10
|
||||
|
||||
Passing a nonexistent ``template_name`` will raise ``TemplateDoesNotExist``.
|
||||
|
@ -181,11 +168,6 @@ filesystem paths.
|
|||
|
||||
``bad_request`` views are also only used when :setting:`DEBUG` is ``False``.
|
||||
|
||||
.. versionchanged:: 1.9
|
||||
|
||||
The signature of ``bad_request()`` changed in Django 1.9. The function
|
||||
now accepts a second parameter, the exception that triggered the error.
|
||||
|
||||
.. versionchanged:: 1.10
|
||||
|
||||
Passing a nonexistent ``template_name`` will raise ``TemplateDoesNotExist``.
|
||||
|
|
|
@ -595,13 +595,9 @@ password resets. You must then provide some key implementation details:
|
|||
|
||||
.. admonition:: Importing ``AbstractBaseUser``
|
||||
|
||||
.. versionadded:: 1.9
|
||||
|
||||
``AbstractBaseUser`` and ``BaseUserManager`` are importable from
|
||||
``django.contrib.auth.base_user`` so that they can be imported without
|
||||
including ``django.contrib.auth`` in :setting:`INSTALLED_APPS` (this
|
||||
raised a deprecation warning in older versions and is no longer
|
||||
supported in Django 1.9).
|
||||
including ``django.contrib.auth`` in :setting:`INSTALLED_APPS`.
|
||||
|
||||
The following attributes and methods are available on any subclass of
|
||||
:class:`~django.contrib.auth.models.AbstractBaseUser`:
|
||||
|
|
|
@ -532,8 +532,6 @@ inheritance list.
|
|||
|
||||
.. class:: LoginRequiredMixin
|
||||
|
||||
.. versionadded:: 1.9
|
||||
|
||||
If a view is using this mixin, all requests by non-authenticated users will
|
||||
be redirected to the login page or shown an HTTP 403 Forbidden error,
|
||||
depending on the
|
||||
|
@ -621,8 +619,6 @@ redirects to the login page::
|
|||
|
||||
.. class:: UserPassesTestMixin
|
||||
|
||||
.. versionadded:: 1.9
|
||||
|
||||
When using :doc:`class-based views </topics/class-based-views/index>`, you
|
||||
can use the ``UserPassesTestMixin`` to do this.
|
||||
|
||||
|
@ -718,11 +714,6 @@ The ``permission_required`` decorator
|
|||
def my_view(request):
|
||||
...
|
||||
|
||||
.. versionchanged:: 1.9
|
||||
|
||||
In older versions, the ``permission`` parameter only worked with
|
||||
strings, lists, and tuples instead of strings and any iterable.
|
||||
|
||||
.. currentmodule:: django.contrib.auth.mixins
|
||||
|
||||
The ``PermissionRequiredMixin`` mixin
|
||||
|
@ -733,8 +724,6 @@ To apply permission checks to :doc:`class-based views
|
|||
|
||||
.. class:: PermissionRequiredMixin
|
||||
|
||||
.. versionadded:: 1.9
|
||||
|
||||
This mixin, just like the ``permission_required``
|
||||
decorator, checks whether the user accessing a view has all given
|
||||
permissions. You should specify the permission (or an iterable of
|
||||
|
@ -775,8 +764,6 @@ user to the login page or issue an HTTP 403 Forbidden response.
|
|||
|
||||
.. class:: AccessMixin
|
||||
|
||||
.. versionadded:: 1.9
|
||||
|
||||
.. attribute:: login_url
|
||||
|
||||
Default return value for :meth:`get_login_url`. Defaults to ``None``
|
||||
|
@ -1313,10 +1300,6 @@ implementation details see :ref:`using-the-views`.
|
|||
The ``current_app`` parameter is deprecated and will be removed in
|
||||
Django 2.0. Callers should set ``request.current_app`` instead.
|
||||
|
||||
.. versionadded:: 1.9
|
||||
|
||||
The ``extra_email_context`` parameter was added.
|
||||
|
||||
**Template context:**
|
||||
|
||||
* ``form``: The form (see ``password_reset_form`` above) for resetting
|
||||
|
|
|
@ -258,10 +258,6 @@ request for a nonexistent user (which runs the default hasher). You may be able
|
|||
to mitigate this by :ref:`upgrading older password hashes
|
||||
<wrapping-password-hashers>`.
|
||||
|
||||
.. versionchanged:: 1.9
|
||||
|
||||
Passwords updates when changing the number of bcrypt rounds was added.
|
||||
|
||||
.. _wrapping-password-hashers:
|
||||
|
||||
Password upgrading without requiring a login
|
||||
|
@ -392,8 +388,6 @@ The corresponding algorithm names are:
|
|||
Writing your own hasher
|
||||
-----------------------
|
||||
|
||||
.. versionadded:: 1.9.3
|
||||
|
||||
If you write your own password hasher that contains a work factor such as a
|
||||
number of iterations, you should implement a
|
||||
``harden_runtime(self, password, encoded)`` method to bridge the runtime gap
|
||||
|
@ -450,8 +444,6 @@ Password validation
|
|||
|
||||
.. module:: django.contrib.auth.password_validation
|
||||
|
||||
.. versionadded:: 1.9
|
||||
|
||||
Users often choose poor passwords. To help mitigate this problem, Django
|
||||
offers pluggable password validation. You can configure multiple password
|
||||
validators at the same time. A few validators are included in Django, but it's
|
||||
|
|
|
@ -804,10 +804,6 @@ You can also pass any callable as a *default* value::
|
|||
>>> cache.get_or_set('some-timestamp-key', datetime.datetime.now)
|
||||
datetime.datetime(2014, 12, 11, 0, 15, 49, 457920)
|
||||
|
||||
.. versionchanged:: 1.9
|
||||
|
||||
The ``get_or_set()`` method was added.
|
||||
|
||||
There's also a ``get_many()`` interface that only hits the cache once.
|
||||
``get_many()`` returns a dictionary with all the keys you asked for that
|
||||
actually exist in the cache (and haven't expired)::
|
||||
|
|
|
@ -305,11 +305,6 @@ The decorators will process a request in the order they are passed to the
|
|||
decorator. In the example, ``never_cache()`` will process the request before
|
||||
``login_required()``.
|
||||
|
||||
.. versionchanged:: 1.9
|
||||
|
||||
The ability to use ``method_decorator()`` on a class and the ability for
|
||||
it to accept a list or tuple of decorators were added.
|
||||
|
||||
In this example, every instance of ``ProtectedView`` will have login protection.
|
||||
|
||||
.. note::
|
||||
|
|
|
@ -899,10 +899,6 @@ the number of deletions per object type. Example::
|
|||
>>> e.delete()
|
||||
(1, {'weblog.Entry': 1})
|
||||
|
||||
.. versionchanged:: 1.9
|
||||
|
||||
The return value describing the number of objects deleted was added.
|
||||
|
||||
You can also delete objects in bulk. Every
|
||||
:class:`~django.db.models.query.QuerySet` has a
|
||||
:meth:`~django.db.models.query.QuerySet.delete` method, which deletes all
|
||||
|
@ -924,10 +920,6 @@ object individually) rather than using the bulk
|
|||
:meth:`~django.db.models.query.QuerySet.delete` method of a
|
||||
:class:`~django.db.models.query.QuerySet`.
|
||||
|
||||
.. versionchanged:: 1.9
|
||||
|
||||
The return value describing the number of objects deleted was added.
|
||||
|
||||
When Django deletes an object, by default it emulates the behavior of the SQL
|
||||
constraint ``ON DELETE CASCADE`` -- in other words, any objects which had
|
||||
foreign keys pointing at the object to be deleted will be deleted along with
|
||||
|
|
|
@ -254,8 +254,6 @@ something really strange.
|
|||
Performing actions after commit
|
||||
===============================
|
||||
|
||||
.. versionadded:: 1.9
|
||||
|
||||
Sometimes you need to perform an action related to the current database
|
||||
transaction, but only if the transaction successfully commits. Examples might
|
||||
include a `Celery`_ task, an email notification, or a cache invalidation.
|
||||
|
|
|
@ -573,11 +573,6 @@ argument - the index of the form in the formset. The index is ``None`` for the
|
|||
... kwargs['custom_kwarg'] = index
|
||||
... return kwargs
|
||||
|
||||
|
||||
.. versionadded:: 1.9
|
||||
|
||||
The ``form_kwargs`` argument was added.
|
||||
|
||||
Using a formset in views and templates
|
||||
======================================
|
||||
|
||||
|
|
|
@ -560,10 +560,6 @@ the field declaratively and setting its ``validators`` parameter::
|
|||
model = Article
|
||||
fields = ['pub_date', 'headline', 'content', 'reporter', 'slug']
|
||||
|
||||
.. versionadded:: 1.9
|
||||
|
||||
The ``Meta.field_classes`` attribute was added.
|
||||
|
||||
.. note::
|
||||
|
||||
When you explicitly instantiate a form field like this, it is important to
|
||||
|
|
|
@ -111,8 +111,3 @@ client-side caching.
|
|||
This decorator adds a ``Cache-Control: max-age=0, no-cache, no-store,
|
||||
must-revalidate`` header to a response to indicate that a page should never
|
||||
be cached.
|
||||
|
||||
.. versionchanged:: 1.9
|
||||
|
||||
Before Django 1.9, ``Cache-Control: max-age=0`` was sent. This didn't
|
||||
reliably prevent caching in all browsers.
|
||||
|
|
|
@ -702,8 +702,6 @@ the next section for details).
|
|||
Extending database-backed session engines
|
||||
=========================================
|
||||
|
||||
.. versionadded:: 1.9
|
||||
|
||||
Creating a custom database-backed session engine built upon those included in
|
||||
Django (namely ``db`` and ``cached_db``) may be done by inheriting
|
||||
:class:`~base_session.AbstractBaseSession` and either ``SessionStore`` class.
|
||||
|
@ -714,7 +712,6 @@ including ``django.contrib.sessions`` in :setting:`INSTALLED_APPS`.
|
|||
|
||||
.. class:: base_session.AbstractBaseSession
|
||||
|
||||
.. versionadded:: 1.9
|
||||
|
||||
The abstract base session model.
|
||||
|
||||
|
@ -751,8 +748,6 @@ You can also customize the model manager by subclassing
|
|||
|
||||
.. class:: base_session.BaseSessionManager
|
||||
|
||||
.. versionadded:: 1.9
|
||||
|
||||
.. method:: encode(session_dict)
|
||||
|
||||
Returns the given session dictionary serialized and encoded as a string.
|
||||
|
@ -773,14 +768,10 @@ and properties described below:
|
|||
|
||||
.. classmethod:: get_model_class()
|
||||
|
||||
.. versionadded:: 1.9
|
||||
|
||||
Override this method to return a custom session model if you need one.
|
||||
|
||||
.. method:: create_model_instance(data)
|
||||
|
||||
.. versionadded:: 1.9
|
||||
|
||||
Returns a new instance of the session model object, which represents
|
||||
the current session state.
|
||||
|
||||
|
@ -793,8 +784,6 @@ and properties described below:
|
|||
|
||||
.. attribute:: cache_key_prefix
|
||||
|
||||
.. versionadded:: 1.9
|
||||
|
||||
A prefix added to a session key to build a cache key string.
|
||||
|
||||
Example
|
||||
|
|
|
@ -679,12 +679,6 @@ the fully qualified name into parts and then tries the following lookup:
|
|||
setting the current application on the :attr:`request.current_app
|
||||
<django.http.HttpRequest.current_app>` attribute.
|
||||
|
||||
.. versionchanged:: 1.9
|
||||
|
||||
Previously, the :ttag:`url` template tag did not use the namespace of the
|
||||
currently resolved view and you had to set the ``current_app`` attribute
|
||||
on the request.
|
||||
|
||||
3. If there is no current application. Django looks for a default
|
||||
application instance. The default application instance is the instance
|
||||
that has an :term:`instance namespace` matching the :term:`application
|
||||
|
@ -831,11 +825,3 @@ The instance namespace can be specified using the ``namespace`` argument to
|
|||
:func:`~django.conf.urls.include`. If the instance namespace is not specified,
|
||||
it will default to the included URLconf's application namespace. This means
|
||||
it will also be the default instance for that namespace.
|
||||
|
||||
.. versionchanged:: 1.9
|
||||
|
||||
In previous versions, you had to specify both the application namespace
|
||||
and the instance namespace in a single place, either by passing them as
|
||||
parameters to :func:`~django.conf.urls.include` or by including a 3-tuple
|
||||
containing
|
||||
``(<list of url() instances>, <application namespace>, <instance namespace>)``.
|
||||
|
|
|
@ -700,10 +700,6 @@ In practice you'll use this to get a string you can use in multiple places in a
|
|||
template or so you can use the output as an argument for other template tags or
|
||||
filters.
|
||||
|
||||
.. versionchanged:: 1.9
|
||||
|
||||
The ``asvar`` syntax was added.
|
||||
|
||||
``{% blocktrans %}`` also supports :ref:`contextual
|
||||
markers<contextual-markers>` using the ``context`` keyword:
|
||||
|
||||
|
@ -890,10 +886,6 @@ You can then access the information::
|
|||
Bi-directional: {{ lang.bidi }}
|
||||
Name in the active language: {{ lang.name_translated }}
|
||||
|
||||
.. versionadded:: 1.9
|
||||
|
||||
The ``name_translated`` attribute was added.
|
||||
|
||||
.. templatetag:: get_language_info_list
|
||||
|
||||
``get_language_info_list``
|
||||
|
@ -934,12 +926,6 @@ There are also simple filters available for convenience:
|
|||
* ``{{ LANGUAGE_CODE|language_bidi }}`` (False)
|
||||
* ``{{ LANGUAGE_CODE|language_name_translated }}`` ("německy", when active language is Czech)
|
||||
|
||||
.. versionadded:: 1.9
|
||||
|
||||
The ``language_name_translated`` filter was added.
|
||||
|
||||
.. _Django templates: ../templates_python/
|
||||
|
||||
Internationalization: in JavaScript code
|
||||
========================================
|
||||
|
||||
|
@ -1094,11 +1080,6 @@ If you use more than one ``javascript_catalog`` on a site and some of them
|
|||
define the same strings, the strings in the catalog that was loaded last take
|
||||
precedence.
|
||||
|
||||
.. versionchanged:: 1.9
|
||||
|
||||
Before Django 1.9, the catalogs completely overwrote each other and you
|
||||
could only use one at a time.
|
||||
|
||||
The JavaScript translations found in the paths listed in the
|
||||
:setting:`LOCALE_PATHS` setting are also always included. To keep consistency
|
||||
with the translations lookup order algorithm used for Python and templates, the
|
||||
|
@ -1304,8 +1285,6 @@ The ``JSONCatalog`` view
|
|||
The ``json_catalog`` view
|
||||
-------------------------
|
||||
|
||||
.. versionadded:: 1.9
|
||||
|
||||
.. function:: json_catalog(request, domain='djangojs', packages=None)
|
||||
|
||||
.. deprecated:: 1.10
|
||||
|
@ -1769,11 +1748,6 @@ which you ran :djadmin:`django-admin makemessages <makemessages>`, run
|
|||
|
||||
That's it. Your translations are ready for use.
|
||||
|
||||
.. versionchanged:: 1.9
|
||||
|
||||
``compilemessages`` now matches the operation of :djadmin:`makemessages`,
|
||||
scanning the project tree for ``.po`` files to compile.
|
||||
|
||||
.. admonition:: Working on Windows?
|
||||
|
||||
If you're using Windows and need to install the GNU gettext utilities so
|
||||
|
|
|
@ -292,11 +292,6 @@ verbose as it includes all database queries::
|
|||
},
|
||||
}
|
||||
|
||||
.. versionchanged:: 1.9
|
||||
|
||||
Django's default logging configuration changed. See :ref:`the release notes
|
||||
<default-logging-changes-19>` for a description of the changes.
|
||||
|
||||
Finally, here's an example of a fairly complex logging setup::
|
||||
|
||||
LOGGING = {
|
||||
|
@ -504,8 +499,6 @@ Messages to this logger have the following extra context:
|
|||
``django.template``
|
||||
~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
.. versionadded:: 1.9
|
||||
|
||||
Log messages related to the rendering of templates.
|
||||
|
||||
* Missing context variables are logged as ``DEBUG`` messages.
|
||||
|
@ -753,10 +746,5 @@ Independent of the value of :setting:`DEBUG`:
|
|||
* The :ref:`django-server-logger` logger sends all messages at the ``INFO``
|
||||
level or higher to the console.
|
||||
|
||||
.. versionchanged:: 1.9
|
||||
|
||||
Django's default logging configuration changed. See :ref:`the release notes
|
||||
<default-logging-changes-19>` for a description of the changes.
|
||||
|
||||
See also :ref:`Configuring logging <configuring-logging>` to learn how you can
|
||||
complement or replace this default logging configuration.
|
||||
|
|
|
@ -279,8 +279,6 @@ Initial migrations
|
|||
|
||||
.. attribute:: Migration.initial
|
||||
|
||||
.. versionadded:: 1.9
|
||||
|
||||
The "initial migrations" for an app are the migrations that create the first
|
||||
version of that app's tables. Usually an app will have just one initial
|
||||
migration, but in some cases of complex model interdependencies it may have two
|
||||
|
@ -656,11 +654,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.9
|
||||
|
||||
Serialization support for ``functools.partial`` and ``LazyObject``
|
||||
instances was added.
|
||||
|
||||
.. versionchanged:: 1.10
|
||||
|
||||
Serialization support for ``enum.Enum`` was added.
|
||||
|
|
|
@ -206,11 +206,6 @@ Attributes
|
|||
|
||||
A 1-based range iterator of page numbers, e.g. yielding ``[1, 2, 3, 4]``.
|
||||
|
||||
.. versionchanged:: 1.9
|
||||
|
||||
In older versions, ``page_range`` returned a list instead of an
|
||||
iterator.
|
||||
|
||||
``InvalidPage`` exceptions
|
||||
==========================
|
||||
|
||||
|
|
|
@ -216,8 +216,6 @@ This example links the given user with the permission models with PKs 46 and 47.
|
|||
|
||||
.. admonition:: Control characters
|
||||
|
||||
.. versionchanged:: 1.9
|
||||
|
||||
If the content to be serialized contains control characters that are not
|
||||
accepted in the XML 1.0 standard, the serialization will fail with a
|
||||
:exc:`ValueError` exception. Read also the W3C's explanation of `HTML,
|
||||
|
|
|
@ -142,10 +142,6 @@ If loading a template fails, the following two exceptions, defined in
|
|||
functions, such as :func:`~django.template.loader.get_template`, that
|
||||
try to load a given template from multiple engines.
|
||||
|
||||
.. versionadded:: 1.9
|
||||
|
||||
The ``backend``, ``tried``, and ``chain`` arguments were added.
|
||||
|
||||
.. exception:: TemplateSyntaxError(msg)
|
||||
|
||||
This exception is raised when a template was found but contains errors.
|
||||
|
@ -374,10 +370,6 @@ applications. This generic name was kept for backwards-compatibility.
|
|||
Tags and filters from built-in libraries can be used without first calling
|
||||
the :ttag:`{% load %} <load>` tag.
|
||||
|
||||
.. versionadded:: 1.9
|
||||
|
||||
The ``libraries`` and ``builtins`` arguments were added.
|
||||
|
||||
.. module:: django.template.backends.jinja2
|
||||
|
||||
.. class:: Jinja2
|
||||
|
@ -515,10 +507,6 @@ See `DEP 182`_ for more information.
|
|||
Debug integration for custom engines
|
||||
------------------------------------
|
||||
|
||||
.. versionadded:: 1.9
|
||||
|
||||
Debug page integration for non-Django template engines was added.
|
||||
|
||||
The Django debug page has hooks to provide detailed information when a template
|
||||
error arises. Custom template engines can use these hooks to enhance the
|
||||
traceback information that appears to users. The following hooks are available:
|
||||
|
|
|
@ -252,8 +252,6 @@ The initial serialization is usually very quick, but if you wish to exclude
|
|||
some apps from this process (and speed up test runs slightly), you may add
|
||||
those apps to :setting:`TEST_NON_SERIALIZED_APPS`.
|
||||
|
||||
.. versionchanged:: 1.9
|
||||
|
||||
To prevent serialized data from being loaded twice, setting
|
||||
``serialized_rollback=True`` disables the
|
||||
:data:`~django.db.models.signals.post_migrate` signal when flushing the test
|
||||
|
|
|
@ -379,8 +379,6 @@ Use the ``django.test.Client`` class to make requests.
|
|||
|
||||
.. method:: Client.force_login(user, backend=None)
|
||||
|
||||
.. versionadded:: 1.9
|
||||
|
||||
If your site uses Django's :doc:`authentication
|
||||
system</topics/auth/index>`, you can use the ``force_login()`` method
|
||||
to simulate the effect of a user logging into the site. Use this method
|
||||
|
@ -461,8 +459,6 @@ Specifically, a ``Response`` object has the following attributes:
|
|||
|
||||
.. method:: json(**kwargs)
|
||||
|
||||
.. versionadded:: 1.9
|
||||
|
||||
The body of the response, parsed as JSON. Extra keyword arguments are
|
||||
passed to :func:`json.loads`. For example::
|
||||
|
||||
|
@ -658,8 +654,6 @@ If your tests make any database queries, use subclasses
|
|||
|
||||
.. attribute:: SimpleTestCase.allow_database_queries
|
||||
|
||||
.. versionadded:: 1.9
|
||||
|
||||
:class:`~SimpleTestCase` disallows database queries by default. This
|
||||
helps to avoid executing write queries which will affect other tests
|
||||
since each ``SimpleTestCase`` test isn't run in a transaction. If you
|
||||
|
@ -824,11 +818,6 @@ By default the live server listens on ``localhost`` and picks the first
|
|||
available port in the ``8081-8179`` range. Its full URL can be accessed with
|
||||
``self.live_server_url`` during the tests.
|
||||
|
||||
.. versionchanged:: 1.9
|
||||
|
||||
In earlier versions, the live server's default address was always
|
||||
``'localhost:8081'``.
|
||||
|
||||
If you'd like to select another address, you may pass a different one using the
|
||||
:option:`test --liveserver` option, for example:
|
||||
|
||||
|
@ -836,12 +825,6 @@ If you'd like to select another address, you may pass a different one using the
|
|||
|
||||
$ ./manage.py test --liveserver=localhost:8082
|
||||
|
||||
.. versionchanged:: 1.9
|
||||
|
||||
In older versions ``live_server_url`` could only be accessed from an
|
||||
instance. It now is a class property and can be accessed from class methods
|
||||
like ``setUpClass()``.
|
||||
|
||||
Another way of changing the default server address is by setting the
|
||||
`DJANGO_LIVE_TEST_SERVER_ADDRESS` environment variable somewhere in your
|
||||
code (for example, in a :ref:`custom test runner<topics-testing-test_runner>`)::
|
||||
|
|
Loading…
Reference in New Issue