Removed versionadded/changed annotations for 1.5
This commit is contained in:
parent
58c6d0209d
commit
7b69c3e775
|
@ -104,12 +104,6 @@ TemplateView
|
|||
Renders a given template, with the context containing parameters captured
|
||||
in the URL.
|
||||
|
||||
.. versionchanged:: 1.5
|
||||
|
||||
The context used to be populated with a ``{{ params }}`` dictionary of
|
||||
the parameters captured in the URL. Now those parameters are first-level
|
||||
context variables.
|
||||
|
||||
**Ancestors (MRO)**
|
||||
|
||||
This view inherits methods and attributes from the following views:
|
||||
|
|
|
@ -138,24 +138,16 @@ YearArchiveView
|
|||
* ``year``: A :class:`~datetime.date` object
|
||||
representing the given year.
|
||||
|
||||
.. versionchanged:: 1.5
|
||||
|
||||
Previously, this returned a string.
|
||||
|
||||
* ``next_year``: A :class:`~datetime.date` object
|
||||
representing the first day of the next year, according to
|
||||
:attr:`~BaseDateListView.allow_empty` and
|
||||
:attr:`~DateMixin.allow_future`.
|
||||
|
||||
.. versionadded:: 1.5
|
||||
|
||||
* ``previous_year``: A :class:`~datetime.date` object
|
||||
representing the first day of the previous year, according to
|
||||
:attr:`~BaseDateListView.allow_empty` and
|
||||
:attr:`~DateMixin.allow_future`.
|
||||
|
||||
.. versionadded:: 1.5
|
||||
|
||||
**Notes**
|
||||
|
||||
* Uses a default ``template_name_suffix`` of ``_archive_year``.
|
||||
|
|
|
@ -328,8 +328,3 @@ BaseDateListView
|
|||
:meth:`~BaseDateListView.get_date_list_period` is used. ``date_type``
|
||||
and ``ordering`` are simply passed to
|
||||
:meth:`QuerySet.dates()<django.db.models.query.QuerySet.dates>`.
|
||||
|
||||
.. versionchanged:: 1.5
|
||||
|
||||
The ``ordering`` parameter was added, and the default order was
|
||||
changed to ascending.
|
||||
|
|
|
@ -90,8 +90,6 @@ MultipleObjectMixin
|
|||
|
||||
.. attribute:: page_kwarg
|
||||
|
||||
.. versionadded:: 1.5
|
||||
|
||||
A string specifying the name to use for the page parameter.
|
||||
The view will expect this prameter to be available either as a query
|
||||
string parameter (via ``request.GET``) or as a kwarg variable specified
|
||||
|
|
|
@ -7,8 +7,6 @@ ContextMixin
|
|||
|
||||
.. class:: django.views.generic.base.ContextMixin
|
||||
|
||||
.. versionadded:: 1.5
|
||||
|
||||
**Methods**
|
||||
|
||||
.. method:: get_context_data(**kwargs)
|
||||
|
@ -77,8 +75,6 @@ TemplateResponseMixin
|
|||
|
||||
.. attribute:: content_type
|
||||
|
||||
.. versionadded:: 1.5
|
||||
|
||||
The content type to use for the response. ``content_type`` is passed
|
||||
as a keyword argument to ``response_class``. Default is ``None`` --
|
||||
meaning that Django uses :setting:`DEFAULT_CONTENT_TYPE`.
|
||||
|
|
|
@ -1235,8 +1235,6 @@ templates used by the :class:`ModelAdmin` views:
|
|||
|
||||
.. method:: ModelAdmin.get_list_filter(self, request)
|
||||
|
||||
.. versionadded:: 1.5
|
||||
|
||||
The ``get_list_filter`` method is given the ``HttpRequest`` and is expected
|
||||
to return the same kind of sequence type as for the
|
||||
:attr:`~ModelAdmin.list_filter` attribute.
|
||||
|
@ -1251,8 +1249,6 @@ templates used by the :class:`ModelAdmin` views:
|
|||
|
||||
.. method:: ModelAdmin.get_inline_instances(self, request, obj=None)
|
||||
|
||||
.. versionadded:: 1.5
|
||||
|
||||
The ``get_inline_instances`` method is given the ``HttpRequest`` and the
|
||||
``obj`` being edited (or ``None`` on an add form) and is expected to return
|
||||
a ``list`` or ``tuple`` of :class:`~django.contrib.admin.InlineModelAdmin`
|
||||
|
@ -1506,10 +1502,6 @@ templates used by the :class:`ModelAdmin` views:
|
|||
Sends a message to the user using the :mod:`django.contrib.messages`
|
||||
backend. See the :ref:`custom ModelAdmin example <custom-admin-action>`.
|
||||
|
||||
.. versionchanged:: 1.5
|
||||
|
||||
Keyword arguments were added in Django 1.5.
|
||||
|
||||
Keyword arguments allow you to change the message level, add extra CSS
|
||||
tags, or fail silently if the ``contrib.messages`` framework is not
|
||||
installed. These keyword arguments match those for
|
||||
|
|
|
@ -389,8 +389,6 @@ can be used for notification when a user logs in or out.
|
|||
|
||||
.. function:: user_login_failed
|
||||
|
||||
.. versionadded:: 1.5
|
||||
|
||||
Sent when the user failed to login successfully
|
||||
|
||||
``sender``
|
||||
|
|
|
@ -199,14 +199,18 @@ The ``ContentTypeManager``
|
|||
|
||||
Takes either a model class or an instance of a model, and returns the
|
||||
:class:`~django.contrib.contenttypes.models.ContentType` instance
|
||||
representing that model.
|
||||
representing that model. ``for_concrete_model=False`` allows fetching
|
||||
the :class:`~django.contrib.contenttypes.models.ContentType` of a proxy
|
||||
model.
|
||||
|
||||
.. method:: get_for_models(*models[, for_concrete_models=True])
|
||||
|
||||
Takes a variadic number of model classes, and returns a dictionary
|
||||
mapping the model classes to the
|
||||
:class:`~django.contrib.contenttypes.models.ContentType` instances
|
||||
representing them.
|
||||
representing them. ``for_concrete_models=False`` allows fetching the
|
||||
:class:`~django.contrib.contenttypes.models.ContentType` of proxy
|
||||
models.
|
||||
|
||||
.. method:: get_by_natural_key(app_label, model)
|
||||
|
||||
|
@ -232,21 +236,6 @@ lookup::
|
|||
|
||||
.. _generic-relations:
|
||||
|
||||
.. versionadded:: 1.5
|
||||
|
||||
Prior to Django 1.5,
|
||||
:meth:`~django.contrib.contenttypes.models.ContentTypeManager.get_for_model` and
|
||||
:meth:`~django.contrib.contenttypes.models.ContentTypeManager.get_for_models`
|
||||
always returned the :class:`~django.contrib.contenttypes.models.ContentType`
|
||||
associated with the concrete model of the specified one(s). That means there
|
||||
was no way to retrieve the
|
||||
:class:`~django.contrib.contenttypes.models.ContentType` of a proxy model
|
||||
using those methods. As of Django 1.5 you can now pass a boolean flag –
|
||||
``for_concrete_model`` and ``for_concrete_models`` respectively – to specify
|
||||
wether or not you want to retrieve the
|
||||
:class:`~django.contrib.contenttypes.models.ContentType` for the concrete or
|
||||
direct model.
|
||||
|
||||
Generic relations
|
||||
=================
|
||||
|
||||
|
|
|
@ -949,10 +949,6 @@ __ http://geohash.org/
|
|||
|
||||
*Availability*: PostGIS, SpatiaLite
|
||||
|
||||
.. versionchanged:: 1.5
|
||||
|
||||
``geojson`` support for Spatialite > 3.0 has been added.
|
||||
|
||||
Attaches a ``geojson`` attribute to every model in the queryset that contains the
|
||||
`GeoJSON`__ representation of the geometry.
|
||||
|
||||
|
|
|
@ -276,10 +276,6 @@ that the SRID value is not included in this representation
|
|||
because it is not a part of the OGC specification (use the
|
||||
:attr:`GEOSGeometry.hexewkb` property instead).
|
||||
|
||||
.. versionchanged:: 1.5
|
||||
|
||||
Prior to Django 1.5, the Z value of the geometry was dropped.
|
||||
|
||||
.. attribute:: GEOSGeometry.hexewkb
|
||||
|
||||
Returns the EWKB of this Geometry in hexadecimal form. This is an
|
||||
|
@ -325,10 +321,6 @@ Returns the WKB (Well-Known Binary) representation of this Geometry
|
|||
as a Python buffer. SRID value is not included, use the
|
||||
:attr:`GEOSGeometry.ewkb` property instead.
|
||||
|
||||
.. versionchanged:: 1.5
|
||||
|
||||
Prior to Django 1.5, the Z value of the geometry was dropped.
|
||||
|
||||
.. _ewkb:
|
||||
|
||||
.. attribute:: GEOSGeometry.ewkb
|
||||
|
@ -426,8 +418,6 @@ geometry that do not make up other.
|
|||
.. method:: GEOSGeometry.interpolate(distance)
|
||||
.. method:: GEOSGeometry.interpolate_normalized(distance)
|
||||
|
||||
.. versionadded:: 1.5
|
||||
|
||||
Given a distance (float), returns the point (or closest point) within the
|
||||
geometry (:class:`LineString` or :class:`MultiLineString`) at that distance.
|
||||
The normalized version takes the distance as a float between 0 (origin) and 1
|
||||
|
@ -443,8 +433,6 @@ geometry and other.
|
|||
.. method:: GEOSGeometry.project(point)
|
||||
.. method:: GEOSGeometry.project_normalized(point)
|
||||
|
||||
.. versionadded:: 1.5
|
||||
|
||||
Returns the distance (float) from the origin of the geometry
|
||||
(:class:`LineString` or :class:`MultiLineString`) to the point projected on the
|
||||
geometry (that is to a point of the line the closest to the given point).
|
||||
|
|
|
@ -255,8 +255,6 @@ CachedStaticFilesStorage
|
|||
|
||||
.. method:: file_hash(name, content=None)
|
||||
|
||||
.. versionadded:: 1.5
|
||||
|
||||
The method that is used when creating the hashed name of a file.
|
||||
Needs to return a hash for the given file name and content.
|
||||
By default it calculates a MD5 hash from the content's chunks as
|
||||
|
@ -290,8 +288,6 @@ The previous example is equal to calling the ``url`` method of an instance of
|
|||
useful when using a non-local storage backend to deploy files as documented
|
||||
in :ref:`staticfiles-from-cdn`.
|
||||
|
||||
.. versionadded:: 1.5
|
||||
|
||||
If you'd like to retrieve a static URL without displaying it, you can use a
|
||||
slightly different call:
|
||||
|
||||
|
|
|
@ -191,10 +191,6 @@ Django supports MySQL 5.0.3 and higher.
|
|||
`MySQL 5.0`_ adds the ``information_schema`` database, which contains detailed
|
||||
data on all database schema. Django's ``inspectdb`` feature uses it.
|
||||
|
||||
.. versionchanged:: 1.5
|
||||
|
||||
The minimum version requirement of MySQL 5.0.3 was set in Django 1.5.
|
||||
|
||||
Django expects the database to support Unicode (UTF-8 encoding) and delegates to
|
||||
it the task of enforcing transactions and referential integrity. It is important
|
||||
to be aware of the fact that the two latter ones aren't actually enforced by
|
||||
|
|
|
@ -256,8 +256,6 @@ to flush.
|
|||
``--no-initial-data``
|
||||
~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
.. versionadded:: 1.5
|
||||
|
||||
Use ``--no-initial-data`` to avoid loading the initial_data fixture.
|
||||
|
||||
|
||||
|
@ -334,8 +332,6 @@ onto which the data will be loaded.
|
|||
|
||||
.. django-admin-option:: --ignorenonexistent
|
||||
|
||||
.. versionadded:: 1.5
|
||||
|
||||
The :djadminopt:`--ignorenonexistent` option can be used to ignore fields that
|
||||
may have been removed from models since the fixture was originally generated.
|
||||
|
||||
|
@ -859,10 +855,6 @@ behavior you can use the ``--no-startup`` option. e.g.::
|
|||
|
||||
django-admin.py shell --plain --no-startup
|
||||
|
||||
.. versionadded:: 1.5
|
||||
|
||||
The ``--interface`` option was added in Django 1.5.
|
||||
|
||||
.. versionadded:: 1.6
|
||||
|
||||
The ``--no-startup`` option was added in Django 1.6.
|
||||
|
@ -1148,8 +1140,6 @@ synchronize.
|
|||
``--no-initial-data``
|
||||
~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
.. versionadded:: 1.5
|
||||
|
||||
Use ``--no-initial-data`` to avoid loading the initial_data fixture.
|
||||
|
||||
test <app or test identifier>
|
||||
|
@ -1327,8 +1317,6 @@ clearsessions
|
|||
|
||||
.. django-admin:: clearsessions
|
||||
|
||||
.. versionadded:: 1.5
|
||||
|
||||
Can be run as a cron job or directly to clean out expired sessions.
|
||||
|
||||
``django.contrib.sitemaps``
|
||||
|
|
|
@ -100,10 +100,6 @@ The ``ContentFile`` Class
|
|||
f1 = ContentFile("esta sentencia está en español")
|
||||
f2 = ContentFile(b"these are bytes")
|
||||
|
||||
.. versionchanged:: 1.5
|
||||
|
||||
ContentFile also accepts Unicode strings.
|
||||
|
||||
.. currentmodule:: django.core.files.images
|
||||
|
||||
The ``ImageFile`` Class
|
||||
|
|
|
@ -211,11 +211,6 @@ only the valid fields::
|
|||
>>> f.cleaned_data
|
||||
{'cc_myself': True, 'message': u'Hi there'}
|
||||
|
||||
.. versionchanged:: 1.5
|
||||
|
||||
Until Django 1.5, the ``cleaned_data`` attribute wasn't defined at all when
|
||||
the ``Form`` didn't validate.
|
||||
|
||||
``cleaned_data`` will always *only* contain a key for fields defined in the
|
||||
``Form``, even if you pass extra data when you define the ``Form``. In this
|
||||
example, we pass a bunch of extra fields to the ``ContactForm`` constructor,
|
||||
|
|
|
@ -573,16 +573,12 @@ For each field, we describe the default widget used if you don't specify
|
|||
|
||||
.. attribute:: allow_files
|
||||
|
||||
.. versionadded:: 1.5
|
||||
|
||||
Optional. Either ``True`` or ``False``. Default is ``True``. Specifies
|
||||
whether files in the specified location should be included. Either this or
|
||||
:attr:`allow_folders` must be ``True``.
|
||||
|
||||
.. attribute:: allow_folders
|
||||
|
||||
.. versionadded:: 1.5
|
||||
|
||||
Optional. Either ``True`` or ``False``. Default is ``False``. Specifies
|
||||
whether folders in the specified location should be included. Either this or
|
||||
:attr:`allow_files` must be ``True``.
|
||||
|
@ -1065,11 +1061,6 @@ objects (in the case of ``ModelMultipleChoiceField``) into the
|
|||
* Error message keys: ``required``, ``list``, ``invalid_choice``,
|
||||
``invalid_pk_value``
|
||||
|
||||
.. versionchanged:: 1.5
|
||||
|
||||
The empty and normalized values were changed to be consistently
|
||||
``QuerySets`` instead of ``[]`` and ``QuerySet`` respectively.
|
||||
|
||||
.. versionchanged:: 1.6
|
||||
|
||||
The ``invalid_choice`` message may contain ``%(value)s`` and the
|
||||
|
|
|
@ -450,11 +450,5 @@ entries in ``_errors``.
|
|||
|
||||
Secondly, once we have decided that the combined data in the two fields we are
|
||||
considering aren't valid, we must remember to remove them from the
|
||||
``cleaned_data``.
|
||||
|
||||
.. versionchanged:: 1.5
|
||||
|
||||
Django used to remove the ``cleaned_data`` attribute entirely if there were
|
||||
any errors in the form. Since version 1.5, ``cleaned_data`` is present even if
|
||||
the form doesn't validate, but it contains only field values that did
|
||||
validate.
|
||||
``cleaned_data``. `cleaned_data`` is present even if the form doesn't
|
||||
validate, but it contains only field values that did validate.
|
||||
|
|
|
@ -525,11 +525,6 @@ Selector and checkbox widgets
|
|||
A callable that takes the value of the CheckBoxInput and returns
|
||||
``True`` if the checkbox should be checked for that value.
|
||||
|
||||
.. versionchanged:: 1.5
|
||||
|
||||
Exceptions from ``check_test`` used to be silenced by its caller,
|
||||
this is no longer the case, they will propagate upwards.
|
||||
|
||||
``Select``
|
||||
~~~~~~~~~~
|
||||
|
||||
|
|
|
@ -757,21 +757,16 @@ directory on the filesystem. Has three special arguments, of which the first is
|
|||
|
||||
.. attribute:: FilePathField.allow_files
|
||||
|
||||
.. versionadded:: 1.5
|
||||
|
||||
Optional. Either ``True`` or ``False``. Default is ``True``. Specifies
|
||||
whether files in the specified location should be included. Either this or
|
||||
:attr:`~FilePathField.allow_folders` must be ``True``.
|
||||
|
||||
.. attribute:: FilePathField.allow_folders
|
||||
|
||||
.. versionadded:: 1.5
|
||||
|
||||
Optional. Either ``True`` or ``False``. Default is ``False``. Specifies
|
||||
whether folders in the specified location should be included. Either this
|
||||
or :attr:`~FilePathField.allow_files` must be ``True``.
|
||||
|
||||
|
||||
Of course, these arguments can be used together.
|
||||
|
||||
The one potential gotcha is that :attr:`~FilePathField.match` applies to the
|
||||
|
@ -980,12 +975,6 @@ Like all :class:`CharField` subclasses, :class:`URLField` takes the optional
|
|||
:attr:`~CharField.max_length` argument. If you don't specify
|
||||
:attr:`~CharField.max_length`, a default of 200 is used.
|
||||
|
||||
.. versionadded:: 1.5
|
||||
|
||||
The current value of the field will be displayed as a clickable link above the
|
||||
input widget.
|
||||
|
||||
|
||||
Relationship fields
|
||||
===================
|
||||
|
||||
|
|
|
@ -388,8 +388,6 @@ For more details, see the documentation on :ref:`F() expressions
|
|||
Specifying which fields to save
|
||||
-------------------------------
|
||||
|
||||
.. versionadded:: 1.5
|
||||
|
||||
If ``save()`` is passed a list of field names in keyword argument
|
||||
``update_fields``, only the fields named in that list will be updated.
|
||||
This may be desirable if you want to update just one or a few fields on
|
||||
|
|
|
@ -286,8 +286,6 @@ Django quotes column and table names behind the scenes.
|
|||
|
||||
.. attribute:: Options.index_together
|
||||
|
||||
.. versionadded:: 1.5
|
||||
|
||||
Sets of field names that, taken together, are indexed::
|
||||
|
||||
index_together = [
|
||||
|
|
|
@ -1149,13 +1149,11 @@ to ``defer()``::
|
|||
# Load all fields immediately.
|
||||
my_queryset.defer(None)
|
||||
|
||||
.. versionchanged:: 1.5
|
||||
|
||||
Some fields in a model won't be deferred, even if you ask for them. You can
|
||||
never defer the loading of the primary key. If you are using
|
||||
:meth:`select_related()` to retrieve related models, you shouldn't defer the
|
||||
loading of the field that connects from the primary model to the related
|
||||
one, doing so will result in an error.
|
||||
Some fields in a model won't be deferred, even if you ask for them. You can
|
||||
never defer the loading of the primary key. If you are using
|
||||
:meth:`select_related()` to retrieve related models, you shouldn't defer the
|
||||
loading of the field that connects from the primary model to the related
|
||||
one, doing so will result in an error.
|
||||
|
||||
.. note::
|
||||
|
||||
|
@ -1178,8 +1176,6 @@ to ``defer()``::
|
|||
reader, is slightly faster and consumes a little less memory in the Python
|
||||
process.
|
||||
|
||||
.. versionchanged:: 1.5
|
||||
|
||||
.. note::
|
||||
|
||||
When calling :meth:`~django.db.models.Model.save()` for instances with
|
||||
|
@ -1227,16 +1223,14 @@ All of the cautions in the note for the :meth:`defer` documentation apply to
|
|||
``only()`` as well. Use it cautiously and only after exhausting your other
|
||||
options.
|
||||
|
||||
.. versionchanged:: 1.5
|
||||
Using :meth:`only` and omitting a field requested using :meth:`select_related`
|
||||
is an error as well.
|
||||
|
||||
Using :meth:`only` and omitting a field requested using
|
||||
:meth:`select_related` is an error as well.
|
||||
.. note::
|
||||
|
||||
.. note::
|
||||
|
||||
When calling :meth:`~django.db.models.Model.save()` for instances with
|
||||
deferred fields, only the loaded fields will be saved. See
|
||||
:meth:`~django.db.models.Model.save()` for more details.
|
||||
When calling :meth:`~django.db.models.Model.save()` for instances with
|
||||
deferred fields, only the loaded fields will be saved. See
|
||||
:meth:`~django.db.models.Model.save()` for more details.
|
||||
|
||||
using
|
||||
~~~~~
|
||||
|
@ -1567,10 +1561,6 @@ The ``batch_size`` parameter controls how many objects are created in single
|
|||
query. The default is to create all objects in one batch, except for SQLite
|
||||
where the default is such that at maximum 999 variables per query is used.
|
||||
|
||||
.. versionadded:: 1.5
|
||||
|
||||
The ``batch_size`` parameter was added in version 1.5.
|
||||
|
||||
count
|
||||
~~~~~
|
||||
|
||||
|
@ -1900,10 +1890,6 @@ methods on your models. It does, however, emit the
|
|||
:data:`~django.db.models.signals.post_delete` signals for all deleted objects
|
||||
(including cascaded deletions).
|
||||
|
||||
.. versionadded:: 1.5
|
||||
|
||||
Allow fast-path deletion of objects.
|
||||
|
||||
Django needs to fetch objects into memory to send signals and handle cascades.
|
||||
However, if there are no cascades and no signals, then Django may take a
|
||||
fast-path and delete objects without fetching into memory. For large
|
||||
|
@ -1911,7 +1897,7 @@ deletes this can result in significantly reduced memory usage. The amount of
|
|||
executed queries can be reduced, too.
|
||||
|
||||
ForeignKeys which are set to :attr:`~django.db.models.ForeignKey.on_delete`
|
||||
DO_NOTHING do not prevent taking the fast-path in deletion.
|
||||
``DO_NOTHING`` do not prevent taking the fast-path in deletion.
|
||||
|
||||
Note that the queries generated in object deletion is an implementation
|
||||
detail subject to change.
|
||||
|
|
|
@ -93,10 +93,6 @@ All attributes should be considered read-only, unless stated otherwise below.
|
|||
non-form data posted in the request, access this through the
|
||||
:attr:`HttpRequest.body` attribute instead.
|
||||
|
||||
.. versionchanged:: 1.5
|
||||
|
||||
Before Django 1.5, HttpRequest.POST contained non-form data.
|
||||
|
||||
It's possible that a request can come in via POST with an empty ``POST``
|
||||
dictionary -- if, say, a form is requested via the POST HTTP method but
|
||||
does not include form data. Therefore, you shouldn't use ``if request.POST``
|
||||
|
@ -196,8 +192,6 @@ All attributes should be considered read-only, unless stated otherwise below.
|
|||
|
||||
.. attribute:: HttpRequest.resolver_match
|
||||
|
||||
.. versionadded:: 1.5
|
||||
|
||||
An instance of :class:`~django.core.urlresolvers.ResolverMatch` representing
|
||||
the resolved url. This attribute is only set after url resolving took place,
|
||||
which means it's available in all views but not in middleware methods which
|
||||
|
@ -824,8 +818,6 @@ types of HTTP responses. Like ``HttpResponse``, these subclasses live in
|
|||
StreamingHttpResponse objects
|
||||
=============================
|
||||
|
||||
.. versionadded:: 1.5
|
||||
|
||||
.. class:: StreamingHttpResponse
|
||||
|
||||
The :class:`StreamingHttpResponse` class is used to stream a response from
|
||||
|
|
|
@ -1542,6 +1542,8 @@ unpredictable value.
|
|||
:djadmin:`django-admin.py startproject <startproject>` automatically adds a
|
||||
randomly-generated ``SECRET_KEY`` to each new project.
|
||||
|
||||
Django will refuse to start if :setting:`SECRET_KEY` is not set.
|
||||
|
||||
.. warning::
|
||||
|
||||
**Keep this value secret.**
|
||||
|
@ -1550,10 +1552,6 @@ randomly-generated ``SECRET_KEY`` to each new project.
|
|||
security protections, and can lead to privilege escalation and remote code
|
||||
execution vulnerabilities.
|
||||
|
||||
.. versionchanged:: 1.5
|
||||
|
||||
Django will now refuse to start if :setting:`SECRET_KEY` is not set.
|
||||
|
||||
.. setting:: SECURE_PROXY_SSL_HEADER
|
||||
|
||||
SECURE_PROXY_SSL_HEADER
|
||||
|
@ -2108,13 +2106,9 @@ The URL where requests are redirected after login when the
|
|||
This is used by the :func:`~django.contrib.auth.decorators.login_required`
|
||||
decorator, for example.
|
||||
|
||||
.. versionchanged:: 1.5
|
||||
|
||||
This setting now also accepts view function names and
|
||||
:ref:`named URL patterns <naming-url-patterns>` which can be used to reduce
|
||||
configuration duplication since you no longer have to define the URL in two
|
||||
places (``settings`` and URLconf).
|
||||
For backward compatibility reasons the default remains unchanged.
|
||||
This setting also accepts view function names and :ref:`named URL patterns
|
||||
<naming-url-patterns>` which can be used to reduce configuration duplication
|
||||
since you don't have to define the URL in two places (``settings`` and URLconf).
|
||||
|
||||
.. setting:: LOGIN_URL
|
||||
|
||||
|
@ -2126,13 +2120,9 @@ Default: ``'/accounts/login/'``
|
|||
The URL where requests are redirected for login, especially when using the
|
||||
:func:`~django.contrib.auth.decorators.login_required` decorator.
|
||||
|
||||
.. versionchanged:: 1.5
|
||||
|
||||
This setting now also accepts view function names and
|
||||
:ref:`named URL patterns <naming-url-patterns>` which can be used to reduce
|
||||
configuration duplication since you no longer have to define the URL in two
|
||||
places (``settings`` and URLconf).
|
||||
For backward compatibility reasons the default remains unchanged.
|
||||
This setting also accepts view function names and :ref:`named URL patterns
|
||||
<naming-url-patterns>` which can be used to reduce configuration duplication
|
||||
since you don't have to define the URL in two places (``settings`` and URLconf).
|
||||
|
||||
.. setting:: LOGOUT_URL
|
||||
|
||||
|
|
|
@ -118,8 +118,6 @@ Arguments sent with this signal:
|
|||
``using``
|
||||
The database alias being used.
|
||||
|
||||
.. versionadded:: 1.5
|
||||
|
||||
``update_fields``
|
||||
The set of fields to update explicitly specified in the ``save()`` method.
|
||||
``None`` if this argument was not used in the ``save()`` call.
|
||||
|
@ -153,8 +151,6 @@ Arguments sent with this signal:
|
|||
``using``
|
||||
The database alias being used.
|
||||
|
||||
.. versionadded:: 1.5
|
||||
|
||||
``update_fields``
|
||||
The set of fields to update explicitly specified in the ``save()`` method.
|
||||
``None`` if this argument was not used in the ``save()`` call.
|
||||
|
@ -496,14 +492,7 @@ request_finished
|
|||
.. data:: django.core.signals.request_finished
|
||||
:module:
|
||||
|
||||
Sent when Django finishes processing an HTTP request.
|
||||
|
||||
.. versionchanged:: 1.5
|
||||
|
||||
Before Django 1.5, this signal was sent before delivering content to the
|
||||
client. In order to accommodate :ref:`streaming responses
|
||||
<httpresponse-streaming>`, it is now sent after the response has been fully
|
||||
delivered to the client.
|
||||
Sent when Django finishes delvering an HTTP response to the client.
|
||||
|
||||
.. note::
|
||||
|
||||
|
|
|
@ -75,16 +75,10 @@ Methods
|
|||
The HTTP Status code for the response.
|
||||
|
||||
``content_type``
|
||||
|
||||
.. versionchanged:: 1.5
|
||||
|
||||
Historically, this parameter was only called ``mimetype`` (now
|
||||
deprecated), but since this is actually the value included in the HTTP
|
||||
``Content-Type`` header, it can also include the character set
|
||||
encoding, which makes it more than just a MIME type specification. If
|
||||
``content_type`` is specified, then its value is used. Otherwise,
|
||||
:setting:`DEFAULT_CONTENT_TYPE` is used.
|
||||
|
||||
The value included in the HTTP ``Content-Type`` header, including the
|
||||
MIME type specification and the character set encoding. If
|
||||
``content_type`` is specified, then its value is used. Otherwise,
|
||||
:setting:`DEFAULT_CONTENT_TYPE` is used.
|
||||
|
||||
.. method:: SimpleTemplateResponse.resolve_context(context)
|
||||
|
||||
|
@ -167,13 +161,8 @@ Methods
|
|||
The HTTP Status code for the response.
|
||||
|
||||
``content_type``
|
||||
|
||||
.. versionchanged:: 1.5
|
||||
|
||||
Historically, this parameter was only called ``mimetype`` (now
|
||||
deprecated), but since this is actually the value included in the HTTP
|
||||
``Content-Type`` header, it can also include the character set
|
||||
encoding, which makes it more than just a MIME type specification. If
|
||||
The value included in the HTTP ``Content-Type`` header, including the
|
||||
MIME type specification and the character set encoding. If
|
||||
``content_type`` is specified, then its value is used. Otherwise,
|
||||
:setting:`DEFAULT_CONTENT_TYPE` is used.
|
||||
|
||||
|
|
|
@ -274,11 +274,6 @@ Builtin variables
|
|||
Every context contains ``True``, ``False`` and ``None``. As you would expect,
|
||||
these variables resolve to the corresponding Python objects.
|
||||
|
||||
.. versionadded:: 1.5
|
||||
|
||||
Before Django 1.5, these variables weren't a special case, and they
|
||||
resolved to ``None`` unless you defined them in the context.
|
||||
|
||||
Playing with Context objects
|
||||
----------------------------
|
||||
|
||||
|
|
|
@ -1059,22 +1059,14 @@ by the context as to the current application.
|
|||
|
||||
.. warning::
|
||||
|
||||
Don't forget to put quotes around the function path or pattern name!
|
||||
|
||||
.. versionchanged:: 1.5
|
||||
|
||||
The first parameter used not to be quoted, which was inconsistent with
|
||||
other template tags. Since Django 1.5, it is evaluated according to
|
||||
the usual rules: it can be a quoted string or a variable that will be
|
||||
looked up in the context.
|
||||
Don't forget to put quotes around the function path or pattern name,
|
||||
otherwise the value will be interpreted as a context variable!
|
||||
|
||||
.. templatetag:: verbatim
|
||||
|
||||
verbatim
|
||||
^^^^^^^^
|
||||
|
||||
.. versionadded:: 1.5
|
||||
|
||||
Stops the template engine from rendering the contents of this block tag.
|
||||
|
||||
A common use is to allow a Javascript template layer that collides with
|
||||
|
@ -2411,8 +2403,6 @@ It is also able to consume standard context variables, e.g. assuming a
|
|||
If you'd like to retrieve a static URL without displaying it, you can use a
|
||||
slightly different call:
|
||||
|
||||
.. versionadded:: 1.5
|
||||
|
||||
.. code-block:: html+django
|
||||
|
||||
{% load static %}
|
||||
|
|
|
@ -45,28 +45,26 @@ rendering or anywhere else -- you have two choices for encoding those strings.
|
|||
You can use Unicode strings, or you can use normal strings (sometimes called
|
||||
"bytestrings") that are encoded using UTF-8.
|
||||
|
||||
.. versionchanged:: 1.5
|
||||
In Python 3, the logic is reversed, that is normal strings are Unicode, and
|
||||
when you want to specifically create a bytestring, you have to prefix the
|
||||
string with a 'b'. As we are doing in Django code from version 1.5,
|
||||
we recommend that you import ``unicode_literals`` from the __future__ library
|
||||
in your code. Then, when you specifically want to create a bytestring literal,
|
||||
prefix the string with 'b'.
|
||||
|
||||
In Python 3, the logic is reversed, that is normal strings are Unicode, and
|
||||
when you want to specifically create a bytestring, you have to prefix the
|
||||
string with a 'b'. As we are doing in Django code from version 1.5,
|
||||
we recommend that you import ``unicode_literals`` from the __future__ library
|
||||
in your code. Then, when you specifically want to create a bytestring literal,
|
||||
prefix the string with 'b'.
|
||||
Python 2 legacy::
|
||||
|
||||
Python 2 legacy::
|
||||
my_string = "This is a bytestring"
|
||||
my_unicode = u"This is an Unicode string"
|
||||
|
||||
my_string = "This is a bytestring"
|
||||
my_unicode = u"This is an Unicode string"
|
||||
Python 2 with unicode literals or Python 3::
|
||||
|
||||
Python 2 with unicode literals or Python 3::
|
||||
from __future__ import unicode_literals
|
||||
|
||||
from __future__ import unicode_literals
|
||||
my_string = b"This is a bytestring"
|
||||
my_unicode = "This is an Unicode string"
|
||||
|
||||
my_string = b"This is a bytestring"
|
||||
my_unicode = "This is an Unicode string"
|
||||
|
||||
See also :doc:`Python 3 compatibility </topics/python3>`.
|
||||
See also :doc:`Python 3 compatibility </topics/python3>`.
|
||||
|
||||
.. warning::
|
||||
|
||||
|
|
|
@ -204,8 +204,6 @@ The functions defined in this module share the following properties:
|
|||
|
||||
.. function:: smart_text(s, encoding='utf-8', strings_only=False, errors='strict')
|
||||
|
||||
.. versionadded:: 1.5
|
||||
|
||||
Returns a text object representing ``s`` -- ``unicode`` on Python 2 and
|
||||
``str`` on Python 3. Treats bytestrings using the ``encoding`` codec.
|
||||
|
||||
|
@ -225,8 +223,6 @@ The functions defined in this module share the following properties:
|
|||
|
||||
.. function:: force_text(s, encoding='utf-8', strings_only=False, errors='strict')
|
||||
|
||||
.. versionadded:: 1.5
|
||||
|
||||
Similar to ``smart_text``, except that lazy instances are resolved to
|
||||
strings, rather than kept as lazy objects.
|
||||
|
||||
|
@ -239,8 +235,6 @@ The functions defined in this module share the following properties:
|
|||
|
||||
.. function:: smart_bytes(s, encoding='utf-8', strings_only=False, errors='strict')
|
||||
|
||||
.. versionadded:: 1.5
|
||||
|
||||
Returns a bytestring version of ``s``, encoded as specified in
|
||||
``encoding``.
|
||||
|
||||
|
@ -249,8 +243,6 @@ The functions defined in this module share the following properties:
|
|||
|
||||
.. function:: force_bytes(s, encoding='utf-8', strings_only=False, errors='strict')
|
||||
|
||||
.. versionadded:: 1.5
|
||||
|
||||
Similar to ``smart_bytes``, except that lazy instances are resolved to
|
||||
bytestrings, rather than kept as lazy objects.
|
||||
|
||||
|
@ -745,8 +737,6 @@ appropriate entities.
|
|||
|
||||
.. class:: SafeBytes
|
||||
|
||||
.. versionadded:: 1.5
|
||||
|
||||
A ``bytes`` subclass that has been specifically marked as "safe"
|
||||
(requires no further escaping) for HTML output purposes.
|
||||
|
||||
|
@ -758,8 +748,6 @@ appropriate entities.
|
|||
|
||||
.. class:: SafeText
|
||||
|
||||
.. versionadded:: 1.5
|
||||
|
||||
A ``str`` (in Python 3) or ``unicode`` (in Python 2) subclass
|
||||
that has been specifically marked as "safe" for HTML output purposes.
|
||||
|
||||
|
@ -977,8 +965,6 @@ For a complete discussion on the usage of the following see the
|
|||
``None``, the :ref:`current time zone <default-current-time-zone>` is unset
|
||||
on entry with :func:`deactivate()` instead.
|
||||
|
||||
.. versionadded:: 1.5
|
||||
|
||||
.. function:: localtime(value, timezone=None)
|
||||
|
||||
Converts an aware :class:`~datetime.datetime` to a different time zone,
|
||||
|
|
|
@ -359,8 +359,6 @@ the extra database load.
|
|||
Substituting a custom User model
|
||||
================================
|
||||
|
||||
.. versionadded:: 1.5
|
||||
|
||||
Some kinds of projects may have authentication requirements for which Django's
|
||||
built-in :class:`~django.contrib.auth.models.User` model is not always
|
||||
appropriate. For instance, on some sites it makes more sense to use an email
|
||||
|
|
|
@ -434,12 +434,10 @@ The login_required decorator
|
|||
|
||||
(r'^accounts/login/$', 'django.contrib.auth.views.login'),
|
||||
|
||||
.. versionchanged:: 1.5
|
||||
|
||||
The :setting:`settings.LOGIN_URL <LOGIN_URL>` also accepts
|
||||
view function names and :ref:`named URL patterns <naming-url-patterns>`.
|
||||
This allows you to freely remap your login view within your URLconf
|
||||
without having to update the setting.
|
||||
The :setting:`settings.LOGIN_URL <LOGIN_URL>` also accepts view function
|
||||
names and :ref:`named URL patterns <naming-url-patterns>`. This allows you
|
||||
to freely remap your login view within your URLconf without having to
|
||||
update the setting.
|
||||
|
||||
.. note::
|
||||
|
||||
|
@ -1187,10 +1185,6 @@ Thus, you can check permissions in template ``{% if %}`` statements:
|
|||
<p>You don't have permission to do anything in the foo app.</p>
|
||||
{% endif %}
|
||||
|
||||
.. versionadded:: 1.5
|
||||
|
||||
Permission lookup by "if in".
|
||||
|
||||
It is possible to also look permissions up by ``{% if in %}`` statements.
|
||||
For example:
|
||||
|
||||
|
|
|
@ -55,8 +55,6 @@ interface to working with templates in class-based views.
|
|||
override this to provide more flexible defaults when dealing with actual
|
||||
objects.
|
||||
|
||||
.. versionadded:: 1.5
|
||||
|
||||
:class:`~django.views.generic.base.ContextMixin`
|
||||
Every built in view which needs context data, such as for rendering a
|
||||
template (including ``TemplateResponseMixin`` above), should call
|
||||
|
|
|
@ -680,11 +680,6 @@ In addition, some objects are automatically created just after
|
|||
- three ``Permission`` for each model (including those not stored in that
|
||||
database).
|
||||
|
||||
.. versionchanged:: 1.5
|
||||
|
||||
Previously, ``ContentType`` and ``Permission`` instances were created only
|
||||
in the default database.
|
||||
|
||||
For common setups with multiple databases, it isn't useful to have these
|
||||
objects in more than one database. Common setups include master / slave and
|
||||
connecting to external databases. Therefore, it's recommended:
|
||||
|
|
|
@ -639,20 +639,11 @@ that were modified more than 3 days after they were published::
|
|||
>>> from datetime import timedelta
|
||||
>>> Entry.objects.filter(mod_date__gt=F('pub_date') + timedelta(days=3))
|
||||
|
||||
.. versionadded:: 1.5
|
||||
|
||||
``.bitand()`` and ``.bitor()``
|
||||
|
||||
The ``F()`` objects now support bitwise operations by ``.bitand()`` and
|
||||
The ``F()`` objects support bitwise operations by ``.bitand()`` and
|
||||
``.bitor()``, for example::
|
||||
|
||||
>>> F('somefield').bitand(16)
|
||||
|
||||
.. versionchanged:: 1.5
|
||||
|
||||
The previously undocumented operators ``&`` and ``|`` no longer produce
|
||||
bitwise operations, use ``.bitand()`` and ``.bitor()`` instead.
|
||||
|
||||
The pk lookup shortcut
|
||||
----------------------
|
||||
|
||||
|
|
|
@ -204,11 +204,6 @@ reverse order, from the bottom up. This means classes defined at the end of
|
|||
Dealing with streaming responses
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
.. versionchanged:: 1.5
|
||||
|
||||
``response`` may also be an :class:`~django.http.StreamingHttpResponse`
|
||||
object.
|
||||
|
||||
Unlike :class:`~django.http.HttpResponse`,
|
||||
:class:`~django.http.StreamingHttpResponse` does not have a ``content``
|
||||
attribute. As a result, middleware can no longer assume that all responses
|
||||
|
|
|
@ -70,10 +70,6 @@ If you have multiple caches defined in :setting:`CACHES`, Django will use the
|
|||
default cache. To use another cache, set :setting:`SESSION_CACHE_ALIAS` to the
|
||||
name of that cache.
|
||||
|
||||
.. versionchanged:: 1.5
|
||||
|
||||
The :setting:`SESSION_CACHE_ALIAS` setting was added.
|
||||
|
||||
Once your cache is configured, you've got two choices for how to store data in
|
||||
the cache:
|
||||
|
||||
|
@ -302,8 +298,6 @@ You can edit it multiple times.
|
|||
|
||||
.. method:: SessionBase.clear_expired
|
||||
|
||||
.. versionadded:: 1.5
|
||||
|
||||
Removes expired sessions from the session store. This class method is
|
||||
called by :djadmin:`clearsessions`.
|
||||
|
||||
|
@ -469,9 +463,7 @@ cookie will be sent on every request.
|
|||
Similarly, the ``expires`` part of a session cookie is updated each time the
|
||||
session cookie is sent.
|
||||
|
||||
.. versionchanged:: 1.5
|
||||
|
||||
The session is not saved if the response's status code is 500.
|
||||
The session is not saved if the response's status code is 500.
|
||||
|
||||
.. _browser-length-vs-persistent-sessions:
|
||||
|
||||
|
|
|
@ -50,10 +50,6 @@ Optional arguments
|
|||
The MIME type to use for the resulting document. Defaults to the value of
|
||||
the :setting:`DEFAULT_CONTENT_TYPE` setting.
|
||||
|
||||
.. versionchanged:: 1.5
|
||||
|
||||
This parameter used to be called ``mimetype``.
|
||||
|
||||
``status``
|
||||
The status code for the response. Defaults to ``200``.
|
||||
|
||||
|
@ -129,11 +125,6 @@ Optional arguments
|
|||
The MIME type to use for the resulting document. Defaults to the value of
|
||||
the :setting:`DEFAULT_CONTENT_TYPE` setting.
|
||||
|
||||
.. versionchanged:: 1.5
|
||||
|
||||
This parameter used to be called ``mimetype``.
|
||||
|
||||
|
||||
Example
|
||||
-------
|
||||
|
||||
|
|
|
@ -1031,8 +1031,6 @@ in django-statici18n_.
|
|||
Internationalization: in URL patterns
|
||||
=====================================
|
||||
|
||||
.. versionadded:: 1.4
|
||||
|
||||
.. module:: django.conf.urls.i18n
|
||||
|
||||
Django provides two mechanisms to internationalize URL patterns:
|
||||
|
|
|
@ -581,8 +581,6 @@ logging module.
|
|||
|
||||
.. class:: RequireDebugTrue()
|
||||
|
||||
.. versionadded:: 1.5
|
||||
|
||||
This filter is similar to :class:`RequireDebugFalse`, except that records are
|
||||
passed only when :setting:`DEBUG` is ``True``.
|
||||
|
||||
|
@ -599,10 +597,5 @@ All messages reaching the ``django`` catch-all logger when :setting:`DEBUG` is
|
|||
``True`` are sent to the console. They are simply discarded (sent to
|
||||
``NullHandler``) when :setting:`DEBUG` is ``False``.
|
||||
|
||||
.. versionchanged:: 1.5
|
||||
|
||||
Before Django 1.5, all messages reaching the ``django`` logger were
|
||||
discarded, regardless of :setting:`DEBUG`.
|
||||
|
||||
See also :ref:`Configuring logging <configuring-logging>` to learn how you can
|
||||
complement or replace this default logging configuration.
|
||||
|
|
|
@ -248,19 +248,13 @@ Methods
|
|||
|
||||
.. method:: Page.next_page_number()
|
||||
|
||||
Returns the next page number.
|
||||
|
||||
.. versionchanged:: 1.5
|
||||
|
||||
Raises :exc:`InvalidPage` if next page doesn't exist.
|
||||
Returns the next page number. Raises :exc:`InvalidPage` if next page
|
||||
doesn't exist.
|
||||
|
||||
.. method:: Page.previous_page_number()
|
||||
|
||||
Returns the previous page number.
|
||||
|
||||
.. versionchanged:: 1.5
|
||||
|
||||
Raises :exc:`InvalidPage` if previous page doesn't exist.
|
||||
Returns the previous page number. Raises :exc:`InvalidPage` if previous
|
||||
page doesn't exist.
|
||||
|
||||
.. method:: Page.start_index()
|
||||
|
||||
|
|
|
@ -141,14 +141,11 @@ sure that they are "appropriate" for saving before doing so. Of course, if you
|
|||
trust your data source you could just save the object and move on.
|
||||
|
||||
The Django object itself can be inspected as ``deserialized_object.object``.
|
||||
If fields in the serialized data do not exist on a model, a
|
||||
``DeserializationError`` will be raised unless the ``ignorenonexistent``
|
||||
argument is passed in as ``True``::
|
||||
|
||||
.. versionadded:: 1.5
|
||||
|
||||
If fields in the serialized data do not exist on a model,
|
||||
a ``DeserializationError`` will be raised unless the ``ignorenonexistent``
|
||||
argument is passed in as True::
|
||||
|
||||
serializers.deserialize("xml", data, ignorenonexistent=True)
|
||||
serializers.deserialize("xml", data, ignorenonexistent=True)
|
||||
|
||||
.. _serialization-formats:
|
||||
|
||||
|
|
|
@ -132,10 +132,6 @@ Now, our ``my_callback`` function will be called each time a request finishes.
|
|||
Note that ``receiver`` can also take a list of signals to connect a function
|
||||
to.
|
||||
|
||||
.. versionchanged:: 1.5
|
||||
|
||||
The ability to pass a list of signals was added.
|
||||
|
||||
.. admonition:: Where should this code live?
|
||||
|
||||
You can put signal handling and registration code anywhere you like.
|
||||
|
|
|
@ -217,8 +217,6 @@ Advanced features of ``TransactionTestCase``
|
|||
|
||||
.. attribute:: TransactionTestCase.reset_sequences
|
||||
|
||||
.. versionadded:: 1.5
|
||||
|
||||
Setting ``reset_sequences = True`` on a ``TransactionTestCase`` will make
|
||||
sure sequences are always reset before the test run::
|
||||
|
||||
|
|
|
@ -219,12 +219,6 @@ the Django test runner reorders tests in the following way:
|
|||
* Then any other tests (e.g. doctests) that may alter the database without
|
||||
restoring it to its original state are run.
|
||||
|
||||
.. versionchanged:: 1.5
|
||||
|
||||
Before Django 1.5, the only guarantee was that
|
||||
:class:`~django.test.TestCase` tests were always ran first, before any other
|
||||
tests.
|
||||
|
||||
.. note::
|
||||
|
||||
The new ordering of tests may reveal unexpected dependencies on test case
|
||||
|
@ -587,11 +581,6 @@ Use the ``django.test.client.Client`` class to make requests.
|
|||
When ``data`` is provided, it is used as the request body, and
|
||||
a ``Content-Type`` header is set to ``content_type``.
|
||||
|
||||
.. versionchanged:: 1.5
|
||||
|
||||
:meth:`Client.options` used to process ``data`` like
|
||||
:meth:`Client.get`.
|
||||
|
||||
The ``follow`` and ``extra`` arguments act the same as for
|
||||
:meth:`Client.get`.
|
||||
|
||||
|
@ -603,11 +592,6 @@ Use the ``django.test.client.Client`` class to make requests.
|
|||
When ``data`` is provided, it is used as the request body, and
|
||||
a ``Content-Type`` header is set to ``content_type``.
|
||||
|
||||
.. versionchanged:: 1.5
|
||||
|
||||
:meth:`Client.put` used to process ``data`` like
|
||||
:meth:`Client.post`.
|
||||
|
||||
The ``follow`` and ``extra`` arguments act the same as for
|
||||
:meth:`Client.get`.
|
||||
|
||||
|
@ -627,15 +611,9 @@ Use the ``django.test.client.Client`` class to make requests.
|
|||
When ``data`` is provided, it is used as the request body, and
|
||||
a ``Content-Type`` header is set to ``content_type``.
|
||||
|
||||
.. versionchanged:: 1.5
|
||||
|
||||
:meth:`Client.delete` used to process ``data`` like
|
||||
:meth:`Client.get`.
|
||||
|
||||
The ``follow`` and ``extra`` arguments act the same as for
|
||||
:meth:`Client.get`.
|
||||
|
||||
|
||||
.. method:: Client.login(**credentials)
|
||||
|
||||
If your site uses Django's :doc:`authentication system</topics/auth/index>`
|
||||
|
@ -931,25 +909,6 @@ to test the effects of commit and rollback:
|
|||
database. This can cause your tests to pass or fail unexpectedly. Always
|
||||
use ``TransactionTestCase`` when testing transactional behavior.
|
||||
|
||||
.. versionchanged:: 1.5
|
||||
|
||||
Prior to 1.5, :class:`~django.test.TransactionTestCase` flushed the
|
||||
database tables *before* each test. In Django 1.5, this is instead done
|
||||
*after* the test has been run.
|
||||
|
||||
When the flush took place before the test, it was guaranteed that primary
|
||||
key values started at one in :class:`~django.test.TransactionTestCase`
|
||||
tests.
|
||||
|
||||
Tests should not depend on this behavior, but for legacy tests that do,
|
||||
the :attr:`~TransactionTestCase.reset_sequences` attribute can be used
|
||||
until the test has been properly updated.
|
||||
|
||||
.. versionchanged:: 1.5
|
||||
|
||||
The order in which tests are run has changed. See `Order in which tests are
|
||||
executed`_.
|
||||
|
||||
``TransactionTestCase`` inherits from :class:`~django.test.SimpleTestCase`.
|
||||
|
||||
TestCase
|
||||
|
@ -975,11 +934,6 @@ additions, including:
|
|||
* Django-specific assertions for testing for things like redirection and form
|
||||
errors.
|
||||
|
||||
.. versionchanged:: 1.5
|
||||
|
||||
The order in which tests are run has changed. See `Order in which tests are
|
||||
executed`_.
|
||||
|
||||
``TestCase`` inherits from :class:`~django.test.TransactionTestCase`.
|
||||
|
||||
.. _live-test-server:
|
||||
|
@ -1636,8 +1590,6 @@ your test suite.
|
|||
|
||||
.. method:: SimpleTestCase.assertXMLEqual(xml1, xml2, msg=None)
|
||||
|
||||
.. versionadded:: 1.5
|
||||
|
||||
Asserts that the strings ``xml1`` and ``xml2`` are equal. The
|
||||
comparison is based on XML semantics. Similarly to
|
||||
:meth:`~SimpleTestCase.assertHTMLEqual`, the comparison is
|
||||
|
@ -1649,8 +1601,6 @@ your test suite.
|
|||
|
||||
.. method:: SimpleTestCase.assertXMLNotEqual(xml1, xml2, msg=None)
|
||||
|
||||
.. versionadded:: 1.5
|
||||
|
||||
Asserts that the strings ``xml1`` and ``xml2`` are *not* equal. The
|
||||
comparison is based on XML semantics. See
|
||||
:meth:`~SimpleTestCase.assertXMLEqual` for details.
|
||||
|
@ -1659,8 +1609,6 @@ your test suite.
|
|||
|
||||
.. method:: SimpleTestCase.assertInHTML(needle, haystack, count=None, msg_prefix='')
|
||||
|
||||
.. versionadded:: 1.5
|
||||
|
||||
Asserts that the HTML fragment ``needle`` is contained in the ``haystack`` one.
|
||||
|
||||
If the ``count`` integer argument is specified, then additionally the number
|
||||
|
@ -1671,8 +1619,6 @@ your test suite.
|
|||
|
||||
.. method:: SimpleTestCase.assertJSONEqual(raw, expected_data, msg=None)
|
||||
|
||||
.. versionadded:: 1.5
|
||||
|
||||
Asserts that the JSON fragments ``raw`` and ``expected_data`` are equal.
|
||||
Usual JSON non-significant whitespace rules apply as the heavyweight is
|
||||
delegated to the :mod:`json` library.
|
||||
|
|
Loading…
Reference in New Issue