mirror of
https://github.com/django/django.git
synced 2025-08-04 02:48:35 +00:00
Removed versionadded/changed annotations for 1.9.
This commit is contained in:
Tim Graham
parent
1915a7e5c5
commit
46a38307c2
67 changed files with 15 additions and 731 deletions
|
|
@ -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``.
|
||||
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``.
|
||||
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``.
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue