mirror of https://github.com/django/django.git
Removed versionadded/changed annotations for 1.8.
This commit is contained in:
Tim Graham
parent
48e7787db5
commit
54848a96dd
|
|
@ -52,10 +52,6 @@ Lookup registration can also be done using a decorator pattern::
|
|||
class NotEqualLookup(Lookup):
|
||||
# ...
|
||||
|
||||
.. versionchanged:: 1.8
|
||||
|
||||
The ability to use the decorator pattern was added.
|
||||
|
||||
We can now use ``foo__ne`` for any field ``foo``. You will need to ensure that
|
||||
this registration happens before you try to create any querysets using it. You
|
||||
could place the implementation in a ``models.py`` file, or register the lookup
|
||||
|
|
|
|||
|
|
@ -136,11 +136,6 @@ because some commands shipped with Django perform several tasks (for example,
|
|||
user-facing content rendering and database population) that require a
|
||||
project-neutral string language.
|
||||
|
||||
.. versionchanged:: 1.8
|
||||
|
||||
In previous versions, Django forced the "en-us" locale instead of
|
||||
deactivating translations.
|
||||
|
||||
If, for some reason, your custom management command needs to use a fixed locale,
|
||||
you should manually activate and deactivate it in your
|
||||
:meth:`~BaseCommand.handle` method using the functions provided by the I18N
|
||||
|
|
@ -226,8 +221,6 @@ All attributes can be set in your derived class and can be used in
|
|||
|
||||
.. attribute:: BaseCommand.missing_args_message
|
||||
|
||||
.. versionadded:: 1.8
|
||||
|
||||
If your command defines mandatory positional arguments, you can customize
|
||||
the message error returned in the case of missing arguments. The default is
|
||||
output by :py:mod:`argparse` ("too few arguments").
|
||||
|
|
@ -281,8 +274,6 @@ the :meth:`~BaseCommand.handle` method must be implemented.
|
|||
|
||||
.. method:: BaseCommand.add_arguments(parser)
|
||||
|
||||
.. versionadded:: 1.8
|
||||
|
||||
Entry point to add parser arguments to handle command line arguments passed
|
||||
to the command. Custom commands should override this method to add both
|
||||
positional and optional arguments accepted by the command. Calling
|
||||
|
|
|
|||
|
|
@ -340,8 +340,6 @@ Template filter code falls into one of two situations:
|
|||
|
||||
.. warning:: Avoiding XSS vulnerabilities when reusing built-in filters
|
||||
|
||||
.. versionchanged:: 1.8
|
||||
|
||||
Django's built-in filters have ``autoescape=True`` by default in order to
|
||||
get the proper autoescaping behavior and avoid a cross-site script
|
||||
vulnerability.
|
||||
|
|
@ -849,15 +847,6 @@ template yourself. For example::
|
|||
t = context.template.engine.get_template('small_fragment.html')
|
||||
return t.render(Context({'var': obj}, autoescape=context.autoescape))
|
||||
|
||||
.. versionchanged:: 1.8
|
||||
|
||||
The ``template`` attribute of ``Context`` objects was added in Django 1.8.
|
||||
:meth:`context.template.engine.get_template
|
||||
<django.template.Engine.get_template>` must be used instead of
|
||||
:func:`django.template.loader.get_template` because the latter now returns
|
||||
a wrapper whose ``render`` method doesn't accept a
|
||||
:class:`~django.template.Context`.
|
||||
|
||||
If we had neglected to pass in the current ``context.autoescape`` value to our
|
||||
new ``Context`` in this example, the results would have *always* been
|
||||
automatically escaped, which may not be the desired behavior if the template
|
||||
|
|
|
|||
|
|
@ -36,8 +36,6 @@ attribute::
|
|||
migrations.RunPython(forwards),
|
||||
]
|
||||
|
||||
.. versionadded:: 1.8
|
||||
|
||||
You can also provide hints that will be passed to the :meth:`allow_migrate()`
|
||||
method of database routers as ``**hints``:
|
||||
|
||||
|
|
|
|||
|
|
@ -207,12 +207,6 @@ level:
|
|||
class MyDeprecatedTests(unittest.TestCase):
|
||||
...
|
||||
|
||||
.. versionchanged:: 1.8
|
||||
|
||||
Previous versions of Django had some ``Ignore*DeprecationWarningsMixin``
|
||||
classes to prevent warnings from appearing. These have been replaced by the
|
||||
``ignore_warnings`` decorator.
|
||||
|
||||
You can also add a test for the deprecation warning. You'll have to disable the
|
||||
"warning as error" behavior in your test by doing::
|
||||
|
||||
|
|
|
|||
|
|
@ -282,10 +282,6 @@ combine this with ``--verbosity=2``, all SQL queries will be output::
|
|||
|
||||
$ ./runtests.py basic --debug-sql
|
||||
|
||||
.. versionadded:: 1.8
|
||||
|
||||
The ``--reverse`` and ``--debug-sql`` options were added.
|
||||
|
||||
By default tests are run in parallel with one process per core. You can adjust
|
||||
this behavior with the ``--parallel`` option::
|
||||
|
||||
|
|
|
|||
|
|
@ -114,11 +114,6 @@ ModelFormMixin
|
|||
:exc:`~django.core.exceptions.ImproperlyConfigured` exception will be
|
||||
raised.
|
||||
|
||||
.. versionchanged:: 1.8
|
||||
|
||||
Previously if both ``fields`` and ``form_class`` were specified,
|
||||
``fields`` was silently ignored.
|
||||
|
||||
**Mixins**
|
||||
|
||||
* :class:`django.views.generic.edit.FormMixin`
|
||||
|
|
@ -142,11 +137,6 @@ ModelFormMixin
|
|||
result in an :exc:`~django.core.exceptions.ImproperlyConfigured`
|
||||
exception.
|
||||
|
||||
.. versionchanged:: 1.8
|
||||
|
||||
Previously, omitting this attribute was allowed and resulted in
|
||||
a form with all fields of the model.
|
||||
|
||||
.. attribute:: success_url
|
||||
|
||||
The URL to redirect to when the form is successfully processed.
|
||||
|
|
|
|||
|
|
@ -74,8 +74,6 @@ MultipleObjectMixin
|
|||
|
||||
.. attribute:: ordering
|
||||
|
||||
.. versionadded:: 1.8
|
||||
|
||||
A string or list of strings specifying the ordering to apply to the ``queryset``.
|
||||
Valid values are the same as those for :meth:`~django.db.models.query.QuerySet.order_by`.
|
||||
|
||||
|
|
@ -120,8 +118,6 @@ MultipleObjectMixin
|
|||
|
||||
.. method:: get_ordering()
|
||||
|
||||
.. versionadded:: 1.8
|
||||
|
||||
Returns a string (or iterable of strings) that defines the ordering that
|
||||
will be applied to the ``queryset``.
|
||||
|
||||
|
|
|
|||
|
|
@ -51,8 +51,6 @@ TemplateResponseMixin
|
|||
|
||||
.. attribute:: template_engine
|
||||
|
||||
.. versionadded:: 1.8
|
||||
|
||||
The :setting:`NAME <TEMPLATES-NAME>` of a template engine to use for
|
||||
loading the template. ``template_engine`` is passed as the ``using``
|
||||
keyword argument to ``response_class``. Default is ``None``, which
|
||||
|
|
@ -61,25 +59,11 @@ TemplateResponseMixin
|
|||
.. attribute:: response_class
|
||||
|
||||
The response class to be returned by ``render_to_response`` method.
|
||||
Default is
|
||||
:class:`TemplateResponse <django.template.response.TemplateResponse>`.
|
||||
The template and context of ``TemplateResponse`` instances can be
|
||||
altered later (e.g. in
|
||||
Default is :class:`TemplateResponse
|
||||
<django.template.response.TemplateResponse>`. The template and context
|
||||
of ``TemplateResponse`` instances can be altered later (e.g. in
|
||||
:ref:`template response middleware <template-response-middleware>`).
|
||||
|
||||
.. versionchanged:: 1.8
|
||||
|
||||
In older versions of Django, ``TemplateResponse`` used
|
||||
:class:`~django.template.RequestContext` in such a way that values
|
||||
from template context processors would override template variables
|
||||
defined in your views. For example, if you subclassed
|
||||
:class:`DetailView <django.views.generic.detail.DetailView>` and
|
||||
set ``context_object_name`` to ``user``, the
|
||||
``django.contrib.auth.context_processors.auth`` context processor
|
||||
would overwrite your variable with the current user. Now, for
|
||||
consistency with the ``render()`` shortcut, values in the context
|
||||
provided by the class override values from context processors.
|
||||
|
||||
If you need custom template loading or custom context object
|
||||
instantiation, create a ``TemplateResponse`` subclass and assign it to
|
||||
``response_class``.
|
||||
|
|
|
|||
|
|
@ -53,8 +53,6 @@ SingleObjectMixin
|
|||
|
||||
.. attribute:: query_pk_and_slug
|
||||
|
||||
.. versionadded:: 1.8
|
||||
|
||||
If ``True``, causes :meth:`get_object()` to perform its lookup using
|
||||
both the primary key and the slug. Defaults to ``False``.
|
||||
|
||||
|
|
@ -81,8 +79,6 @@ SingleObjectMixin
|
|||
:attr:`slug_url_kwarg` argument, and performs a slug lookup using the
|
||||
:attr:`slug_field`.
|
||||
|
||||
.. versionchanged:: 1.8
|
||||
|
||||
When :attr:`query_pk_and_slug` is ``True``, ``get_object()`` will
|
||||
perform its lookup using both the primary key and the slug.
|
||||
|
||||
|
|
|
|||
|
|
@ -915,8 +915,6 @@ subclass::
|
|||
('is_staff', admin.BooleanFieldListFilter),
|
||||
)
|
||||
|
||||
.. versionadded:: 1.8
|
||||
|
||||
You can now limit the choices of a related model to the objects
|
||||
involved in that relation using ``RelatedOnlyFieldListFilter``::
|
||||
|
||||
|
|
@ -1200,8 +1198,6 @@ subclass::
|
|||
|
||||
.. attribute:: ModelAdmin.show_full_result_count
|
||||
|
||||
.. versionadded:: 1.8
|
||||
|
||||
Set ``show_full_result_count`` to control whether the full count of objects
|
||||
should be displayed on a filtered admin page (e.g. ``99 results (103 total)``).
|
||||
If this option is set to ``False``, a text like ``99 results (Show all)``
|
||||
|
|
@ -1711,8 +1707,6 @@ templates used by the :class:`ModelAdmin` views:
|
|||
|
||||
.. method:: ModelAdmin.has_module_permission(request)
|
||||
|
||||
.. versionadded:: 1.8
|
||||
|
||||
Should return ``True`` if displaying the module on the admin index page and
|
||||
accessing the module's index page is permitted, ``False`` otherwise.
|
||||
Uses :meth:`User.has_module_perms()
|
||||
|
|
@ -1788,10 +1782,6 @@ templates used by the :class:`ModelAdmin` views:
|
|||
``obj_id`` is the serialized identifier used to retrieve the object to be
|
||||
deleted.
|
||||
|
||||
.. versionadded:: 1.8
|
||||
|
||||
The ``obj_id`` parameter was added.
|
||||
|
||||
.. method:: ModelAdmin.get_changeform_initial_data(request)
|
||||
|
||||
A hook for the initial data on admin change forms. By default, fields are
|
||||
|
|
@ -1895,10 +1885,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.8
|
||||
|
||||
The embedded jQuery has been upgraded from 1.9.1 to 1.11.2.
|
||||
|
||||
.. versionchanged:: 1.9
|
||||
|
||||
The embedded jQuery has been upgraded from 1.11.2 to 2.1.4. This drops
|
||||
|
|
@ -2119,8 +2105,6 @@ The ``InlineModelAdmin`` class adds:
|
|||
|
||||
.. attribute:: InlineModelAdmin.show_change_link
|
||||
|
||||
.. versionadded:: 1.8
|
||||
|
||||
Specifies whether or not inline objects that can be changed in the
|
||||
admin have a link to the change form. Defaults to ``False``.
|
||||
|
||||
|
|
@ -2519,8 +2503,6 @@ Templates can override or extend base admin templates as described in
|
|||
|
||||
.. attribute:: AdminSite.site_url
|
||||
|
||||
.. versionadded:: 1.8
|
||||
|
||||
The URL for the "View site" link at the top of each admin page. By default,
|
||||
``site_url`` is ``/``. Set it to ``None`` to remove the link.
|
||||
|
||||
|
|
@ -2603,10 +2585,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.8
|
||||
|
||||
The ``request`` argument and the ``has_permission`` variable were added.
|
||||
|
||||
.. versionchanged:: 1.9
|
||||
|
||||
The ``available_apps`` variable was added.
|
||||
|
|
@ -2732,12 +2710,6 @@ a pattern for your new view.
|
|||
``AdminSite`` or ``self.admin_site.name`` if your view is on a
|
||||
``ModelAdmin``.
|
||||
|
||||
.. versionchanged:: 1.8
|
||||
|
||||
In previous versions of Django, you had to provide the ``current_app``
|
||||
argument to :class:`~django.template.RequestContext` or
|
||||
:class:`~django.template.Context` when rendering the template.
|
||||
|
||||
.. _auth_password_reset:
|
||||
|
||||
Adding a password-reset feature
|
||||
|
|
|
|||
|
|
@ -83,11 +83,6 @@ Fields
|
|||
|
||||
A datetime of the user's last login.
|
||||
|
||||
.. versionchanged:: 1.8
|
||||
|
||||
This field will be ``null`` if the user has never logged in.
|
||||
Previously it was set to the current date/time by default.
|
||||
|
||||
.. attribute:: date_joined
|
||||
|
||||
A datetime designating when the account was created. Is set to the
|
||||
|
|
@ -285,11 +280,6 @@ Anonymous users
|
|||
:meth:`~django.db.models.Model.save` and
|
||||
:meth:`~django.db.models.Model.delete()` raise :exc:`NotImplementedError`.
|
||||
|
||||
.. versionadded:: 1.8
|
||||
|
||||
``AnonymousUser.get_username()`` has been added to
|
||||
better mirror :class:`django.contrib.auth.models.User`.
|
||||
|
||||
In practice, you probably won't need to use
|
||||
:class:`~django.contrib.auth.models.AnonymousUser` objects on your own, but
|
||||
they're used by Web requests, as explained in the next section.
|
||||
|
|
@ -311,10 +301,6 @@ fields:
|
|||
|
||||
Required. 255 characters or fewer. Example: ``'Can vote'``.
|
||||
|
||||
.. versionchanged:: 1.8
|
||||
|
||||
The ``max_length`` increased from 50 to 255 characters.
|
||||
|
||||
.. attribute:: content_type
|
||||
|
||||
Required. A reference to the ``django_content_type`` database table,
|
||||
|
|
@ -460,8 +446,6 @@ The following backends are available in :mod:`django.contrib.auth.backends`:
|
|||
|
||||
.. method:: get_user_permissions(user_obj, obj=None)
|
||||
|
||||
.. versionadded:: 1.8
|
||||
|
||||
Returns the set of permission strings the ``user_obj`` has from their
|
||||
own user permissions. Returns an empty set if
|
||||
:meth:`~django.contrib.auth.models.AbstractBaseUser.is_anonymous` or
|
||||
|
|
|
|||
|
|
@ -345,11 +345,6 @@ Integrating with :mod:`django.contrib.sitemaps`
|
|||
:attr:`~django.contrib.sitemaps.Sitemap.changefreq` or
|
||||
:attr:`~django.contrib.sitemaps.Sitemap.priority`.
|
||||
|
||||
.. versionchanged:: 1.8
|
||||
|
||||
This class is available from ``django.contrib.sitemaps.FlatPageSitemap``
|
||||
in older version of Django.
|
||||
|
||||
Example
|
||||
-------
|
||||
|
||||
|
|
|
|||
|
|
@ -1090,8 +1090,6 @@ the same coordinate transformation repeatedly on different geometries::
|
|||
Raster Data Objects
|
||||
===================
|
||||
|
||||
.. versionadded:: 1.8
|
||||
|
||||
``GDALRaster``
|
||||
----------------
|
||||
|
||||
|
|
|
|||
|
|
@ -64,7 +64,8 @@ spatial functionality::
|
|||
> CREATE EXTENSION postgis;
|
||||
|
||||
The database user must be a superuser in order to run
|
||||
``CREATE EXTENSION postgis;``.
|
||||
``CREATE EXTENSION postgis;``. The command is run during the :djadmin:`migrate`
|
||||
process.
|
||||
|
||||
GeoDjango does not currently leverage any `PostGIS topology functionality`__.
|
||||
If you plan to use those features at some point, you can also install the
|
||||
|
|
@ -73,12 +74,6 @@ postgis_topology;``.
|
|||
|
||||
__ http://postgis.net/docs/Topology.html
|
||||
|
||||
.. versionchanged:: 1.8
|
||||
|
||||
The ``CREATE EXTENSION postgis`` command is now automatically run during
|
||||
the :djadmin:`migrate` process. You can still create it manually if you
|
||||
wish.
|
||||
|
||||
Managing the database
|
||||
---------------------
|
||||
|
||||
|
|
|
|||
|
|
@ -160,8 +160,3 @@ Creating a spatial database for SpatiaLite
|
|||
When running ``manage.py migrate`` with a SQLite or SpatiaLite database, the
|
||||
database file will be automatically created if it doesn't exist. Django will
|
||||
also ensure that the spatial metadata are initialized in the database.
|
||||
|
||||
.. versionchanged:: 1.8
|
||||
|
||||
Prior to Django 1.8, you had to initialize spatial metadata tables yourself
|
||||
by manually running the "SELECT InitSpatialMetaData();" query.
|
||||
|
|
|
|||
|
|
@ -2,8 +2,6 @@
|
|||
GeoJSON Serializer
|
||||
==================
|
||||
|
||||
.. versionadded:: 1.8
|
||||
|
||||
.. module:: django.contrib.gis.serializers.geojson
|
||||
:synopsis: Serialization of GeoDjango models in the GeoJSON format.
|
||||
|
||||
|
|
|
|||
|
|
@ -4,8 +4,6 @@
|
|||
.. module:: django.contrib.postgres
|
||||
:synopsis: PostgreSQL-specific fields and features
|
||||
|
||||
.. versionadded:: 1.8
|
||||
|
||||
PostgreSQL has a number of features which are not shared by the other databases
|
||||
Django supports. This optional module contains model fields and form fields for
|
||||
a number of PostgreSQL specific data types.
|
||||
|
|
|
|||
|
|
@ -243,8 +243,6 @@ Sitemap class reference
|
|||
|
||||
.. attribute:: Sitemap.i18n
|
||||
|
||||
.. versionadded:: 1.8
|
||||
|
||||
**Optional.**
|
||||
|
||||
A boolean attribute that defines if the URLs of this sitemap should
|
||||
|
|
|
|||
|
|
@ -509,10 +509,6 @@ Finally, to avoid repetitive fallback code, the framework provides a
|
|||
:class:`~django.contrib.sites.requests.RequestSite` which will always
|
||||
use the unmodified host.
|
||||
|
||||
.. versionchanged:: 1.8
|
||||
|
||||
Looking up the current site based on ``request.get_host()`` was added.
|
||||
|
||||
.. versionchanged:: 1.9
|
||||
|
||||
Retrying the lookup with the port stripped was added.
|
||||
|
|
|
|||
|
|
@ -544,15 +544,6 @@ executing a command like::
|
|||
or using a :class:`~django.db.migrations.operations.RunSQL` operation in a
|
||||
:ref:`data migration <data-migrations>`.
|
||||
|
||||
.. versionchanged:: 1.8
|
||||
|
||||
Previously, Django truncated fractional seconds from ``datetime`` and
|
||||
``time`` values when using the MySQL backend. Now it lets the database
|
||||
decide whether it should drop that part of the value or not. By default, new
|
||||
``DateTimeField`` or ``TimeField`` columns are now created with fractional
|
||||
seconds support on MySQL 5.6.4 or later with either mysqlclient or
|
||||
MySQLdb 1.2.5 or later.
|
||||
|
||||
``TIMESTAMP`` columns
|
||||
~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
|
|
@ -756,12 +747,6 @@ Some test suites also create views; to run these, the user also needs
|
|||
the CREATE VIEW WITH ADMIN OPTION privilege. In particular, this is needed
|
||||
for Django's own test suite.
|
||||
|
||||
.. versionchanged:: 1.8
|
||||
|
||||
Prior to Django 1.8, the test user was granted the CONNECT and RESOURCE
|
||||
roles, so the extra privileges required for running the test suite were
|
||||
different.
|
||||
|
||||
All of these privileges are included in the DBA role, which is appropriate
|
||||
for use on a private developer's database.
|
||||
|
||||
|
|
|
|||
|
|
@ -132,8 +132,6 @@ List all available tags.
|
|||
|
||||
.. django-admin-option:: --deploy
|
||||
|
||||
.. versionadded:: 1.8
|
||||
|
||||
The ``--deploy`` option activates some additional checks that are only relevant
|
||||
in a deployment setting.
|
||||
|
||||
|
|
@ -172,10 +170,6 @@ into compiled files.
|
|||
``compilemessages`` now matches the operation of :djadmin:`makemessages`,
|
||||
scanning the project tree for ``.po`` files to compile.
|
||||
|
||||
.. versionchanged:: 1.8
|
||||
|
||||
Added ``--exclude`` and ``--use-fuzzy`` options.
|
||||
|
||||
Example usage::
|
||||
|
||||
django-admin compilemessages --locale=pt_BR
|
||||
|
|
@ -312,8 +306,6 @@ one model.
|
|||
|
||||
.. django-admin-option:: --output
|
||||
|
||||
.. versionadded:: 1.8
|
||||
|
||||
By default ``dumpdata`` will output all the serialized data to standard output.
|
||||
This option allows you to specify the file to which the data is to be written.
|
||||
When this option is set and the verbosity is greater than 0 (the default), a
|
||||
|
|
@ -418,10 +410,6 @@ models that may have been removed since the fixture was originally generated.
|
|||
The :djadminopt:`--app` option can be used to specify a single app to look
|
||||
for fixtures in rather than looking through all apps.
|
||||
|
||||
.. versionchanged:: 1.8
|
||||
|
||||
``--ignorenonexistent`` also ignores non-existent models.
|
||||
|
||||
What's a "fixture"?
|
||||
~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
|
|
@ -587,8 +575,6 @@ Separate multiple extensions with commas or use -e or --extension multiple times
|
|||
Use the :djadminopt:`--locale` option (or its shorter version ``-l``) to
|
||||
specify the locale(s) to process.
|
||||
|
||||
.. versionadded:: 1.8
|
||||
|
||||
Use the :djadminopt:`--exclude` option (or its shorter version ``-x``) to
|
||||
specify the locale(s) to exclude from processing. If not provided, no locales
|
||||
are excluded.
|
||||
|
|
@ -698,15 +684,11 @@ The ``--merge`` option enables fixing of migration conflicts.
|
|||
|
||||
.. django-admin-option:: --name, -n
|
||||
|
||||
.. versionadded:: 1.8
|
||||
|
||||
The ``--name`` option allows you to give the migration(s) a custom name instead
|
||||
of a generated one.
|
||||
|
||||
.. django-admin-option:: --exit, -e
|
||||
|
||||
.. versionadded:: 1.8
|
||||
|
||||
The ``--exit`` option will cause ``makemigrations`` to exit with error code 1
|
||||
when no migrations are created (or would have been created, if combined with
|
||||
``--dry-run``).
|
||||
|
|
@ -749,8 +731,6 @@ run correctly.
|
|||
|
||||
.. django-admin-option:: --fake-initial
|
||||
|
||||
.. versionadded:: 1.8
|
||||
|
||||
The ``--fake-initial`` option can be used to allow Django to skip an app's
|
||||
initial migration if all database tables with the names of all models created
|
||||
by all :class:`~django.db.migrations.operations.CreateModel` operations in that
|
||||
|
|
@ -970,8 +950,6 @@ showmigrations [<app_label> [<app_label>]]
|
|||
|
||||
.. django-admin:: showmigrations
|
||||
|
||||
.. versionadded:: 1.8
|
||||
|
||||
Shows all migrations in a project.
|
||||
|
||||
.. django-admin-option:: --list, -l
|
||||
|
|
@ -1238,8 +1216,6 @@ expected to run from. The default value is ``localhost:8081-8179``.
|
|||
|
||||
.. django-admin-option:: --keepdb
|
||||
|
||||
.. versionadded:: 1.8
|
||||
|
||||
The ``--keepdb`` option can be used to preserve the test database between test
|
||||
runs. This has the advantage of skipping both the create and destroy actions
|
||||
which can greatly decrease the time to run tests, especially those in a large
|
||||
|
|
@ -1249,8 +1225,6 @@ be applied to the test database before running the test suite.
|
|||
|
||||
.. django-admin-option:: --reverse
|
||||
|
||||
.. versionadded:: 1.8
|
||||
|
||||
The ``--reverse`` option can be used to sort test cases in the opposite order.
|
||||
This may help in debugging the side effects of tests that aren't properly
|
||||
isolated. :ref:`Grouping by test class <order-of-tests>` is preserved when using
|
||||
|
|
@ -1258,8 +1232,6 @@ this option.
|
|||
|
||||
.. django-admin-option:: --debug-sql
|
||||
|
||||
.. versionadded:: 1.8
|
||||
|
||||
The ``--debug-sql`` option can be used to enable :ref:`SQL logging
|
||||
<django-db-logger>` for failing tests. If :djadminopt:`--verbosity` is ``2``,
|
||||
then queries in passing tests are also output.
|
||||
|
|
@ -1428,8 +1400,6 @@ it when running interactively.
|
|||
Use the ``--database`` option to specify the database into which the superuser
|
||||
object will be saved.
|
||||
|
||||
.. versionadded:: 1.8
|
||||
|
||||
You can subclass the management command and override ``get_input_data()`` if you
|
||||
want to customize data input and validation. Consult the source code for
|
||||
details on the existing implementation and the method's parameters. For example,
|
||||
|
|
@ -1767,13 +1737,6 @@ Named arguments can be passed by using either one of the following syntaxes::
|
|||
# `use_natural_foreign_keys` is the option destination variable
|
||||
management.call_command('dumpdata', use_natural_foreign_keys=True)
|
||||
|
||||
.. versionchanged:: 1.8
|
||||
|
||||
The first syntax is now supported thanks to management commands using the
|
||||
:py:mod:`argparse` module. For the second syntax, Django previously passed
|
||||
the option name as-is to the command, now it is always using the ``dest``
|
||||
variable name (which may or may not be the same as the option name).
|
||||
|
||||
Command options which take multiple options are passed a list::
|
||||
|
||||
management.call_command('dumpdata', exclude=['contenttypes', 'auth'])
|
||||
|
|
|
|||
|
|
@ -33,11 +33,6 @@ Django core exception classes are defined in ``django.core.exceptions``.
|
|||
``_meta.get_field()`` method when the requested field does not exist on the
|
||||
model or on the model's parents.
|
||||
|
||||
.. versionchanged:: 1.8
|
||||
|
||||
This exception was previously defined only in
|
||||
``django.db.models.fields`` and wasn't part of the public API.
|
||||
|
||||
``MultipleObjectsReturned``
|
||||
---------------------------
|
||||
|
||||
|
|
@ -250,8 +245,6 @@ Exceptions provided by the ``django.test`` package.
|
|||
|
||||
.. exception:: client.RedirectCycleError
|
||||
|
||||
.. versionadded:: 1.8
|
||||
|
||||
:exc:`~client.RedirectCycleError` is raised when the test client detects a
|
||||
loop or an overly long chain of redirects.
|
||||
|
||||
|
|
|
|||
|
|
@ -53,15 +53,6 @@ The ``File`` Class
|
|||
|
||||
Iterate over the file yielding one line at a time.
|
||||
|
||||
.. versionchanged:: 1.8
|
||||
|
||||
``File`` now uses `universal newlines`_. The following are
|
||||
recognized as ending a line: the Unix end-of-line convention
|
||||
``'\n'``, the Windows convention ``'\r\n'``, and the old Macintosh
|
||||
convention ``'\r'``.
|
||||
|
||||
.. _universal newlines: https://www.python.org/dev/peps/pep-0278
|
||||
|
||||
.. method:: chunks(chunk_size=None)
|
||||
|
||||
Iterate over the file yielding "chunks" of a given size. ``chunk_size``
|
||||
|
|
|
|||
|
|
@ -86,10 +86,6 @@ Here are some useful attributes of ``UploadedFile``:
|
|||
|
||||
.. _universal newlines: https://www.python.org/dev/peps/pep-0278
|
||||
|
||||
.. versionchanged:: 1.8
|
||||
|
||||
Previously lines were only split on the Unix end-of-line ``'\n'``.
|
||||
|
||||
Subclasses of ``UploadedFile`` include:
|
||||
|
||||
.. class:: TemporaryUploadedFile
|
||||
|
|
|
|||
|
|
@ -185,8 +185,6 @@ Note that ``Form.add_error()`` automatically removes the relevant field from
|
|||
|
||||
.. method:: Form.has_error(field, code=None)
|
||||
|
||||
.. versionadded:: 1.8
|
||||
|
||||
This method returns a boolean designating whether a field has an error with
|
||||
a specific error ``code``. If ``code`` is ``None``, it will return ``True``
|
||||
if the field contains any errors at all.
|
||||
|
|
@ -570,11 +568,6 @@ classes, as needed. The HTML will look something like::
|
|||
>>> f['subject'].label_tag(attrs={'class': 'foo'})
|
||||
<label for="id_subject" class="foo required">Subject:</label>
|
||||
|
||||
.. versionchanged:: 1.8
|
||||
|
||||
The ``required_css_class`` will also be added to the ``<label>`` tag as
|
||||
seen above.
|
||||
|
||||
.. _ref-forms-api-configuring-label:
|
||||
|
||||
Configuring form elements' HTML ``id`` attributes and ``<label>`` tags
|
||||
|
|
@ -693,8 +686,6 @@ Note that the label suffix is added only if the last character of the
|
|||
label isn't a punctuation character (in English, those are ``.``, ``!``, ``?``
|
||||
or ``:``).
|
||||
|
||||
.. versionadded:: 1.8
|
||||
|
||||
Fields can also define their own :attr:`~django.forms.Field.label_suffix`.
|
||||
This will take precedence over :attr:`Form.label_suffix
|
||||
<django.forms.Form.label_suffix>`. The suffix can also be overridden at runtime
|
||||
|
|
@ -990,10 +981,6 @@ Methods of ``BoundField``
|
|||
fields. If you need to do this in a template, you could write a custom
|
||||
filter to allow passing parameters to ``label_tag``.
|
||||
|
||||
.. versionchanged:: 1.8
|
||||
|
||||
The label includes :attr:`~Form.required_css_class` if applicable.
|
||||
|
||||
.. method:: BoundField.value()
|
||||
|
||||
Use this method to render the raw value of this field as it would be rendered
|
||||
|
|
|
|||
|
|
@ -124,8 +124,6 @@ We've specified ``auto_id=False`` to simplify the output::
|
|||
|
||||
.. attribute:: Field.label_suffix
|
||||
|
||||
.. versionadded:: 1.8
|
||||
|
||||
The ``label_suffix`` argument lets you override the form's
|
||||
:attr:`~django.forms.Form.label_suffix` on a per-field basis::
|
||||
|
||||
|
|
@ -319,10 +317,6 @@ Checking if the field data has changed
|
|||
|
||||
.. method:: Field.has_changed()
|
||||
|
||||
.. versionchanged:: 1.8
|
||||
|
||||
This method was renamed from ``_has_changed()``.
|
||||
|
||||
The ``has_changed()`` method is used to determine if the field value has changed
|
||||
from the initial value. Returns ``True`` or ``False``.
|
||||
|
||||
|
|
@ -412,10 +406,6 @@ For each field, we describe the default widget used if you don't specify
|
|||
choices <field-choices>` for more details. If the argument is a
|
||||
callable, it is evaluated each time the field's form is initialized.
|
||||
|
||||
.. versionchanged:: 1.8
|
||||
|
||||
The ability to pass a callable to ``choices`` was added.
|
||||
|
||||
``TypedChoiceField``
|
||||
~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
|
|
@ -561,8 +551,6 @@ For each field, we describe the default widget used if you don't specify
|
|||
``DurationField``
|
||||
~~~~~~~~~~~~~~~~~
|
||||
|
||||
.. versionadded:: 1.8
|
||||
|
||||
.. class:: DurationField(**kwargs)
|
||||
|
||||
* Default widget: :class:`TextInput`
|
||||
|
|
@ -708,11 +696,6 @@ For each field, we describe the default widget used if you don't specify
|
|||
``UploadedFile.content_type`` will be updated with the image's content type
|
||||
if Pillow can determine it, otherwise it will be set to ``None``.
|
||||
|
||||
.. versionchanged:: 1.8
|
||||
|
||||
The ``image`` and ``content_type`` attributes described in the last
|
||||
paragraph were added.
|
||||
|
||||
.. _Pillow: http://pillow.readthedocs.org/en/latest/
|
||||
.. _Image: https://pillow.readthedocs.org/en/latest/reference/Image.html
|
||||
|
||||
|
|
@ -922,8 +905,6 @@ For each field, we describe the default widget used if you don't specify
|
|||
``UUIDField``
|
||||
~~~~~~~~~~~~~
|
||||
|
||||
.. versionadded:: 1.8
|
||||
|
||||
.. class:: UUIDField(**kwargs)
|
||||
|
||||
* Default widget: :class:`TextInput`
|
||||
|
|
|
|||
|
|
@ -46,11 +46,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.
|
||||
|
||||
.. versionchanged:: 1.8
|
||||
|
||||
Previously, omitting the list of fields was allowed and resulted in
|
||||
a form with all fields of the model.
|
||||
|
||||
.. versionadded:: 1.9
|
||||
|
||||
The ``field_classes`` keyword argument was added.
|
||||
|
|
|
|||
|
|
@ -206,8 +206,6 @@ foundation for custom widgets.
|
|||
>>> name.render('name', 'A name')
|
||||
'<input title="Your name" type="text" name="name" value="A name" size="10" />'
|
||||
|
||||
.. versionchanged:: 1.8
|
||||
|
||||
If you assign a value of ``True`` or ``False`` to an attribute,
|
||||
it will be rendered as an HTML5 boolean attribute::
|
||||
|
||||
|
|
@ -809,8 +807,6 @@ Composite widgets
|
|||
|
||||
.. attribute:: SelectDateWidget.empty_label
|
||||
|
||||
.. versionadded:: 1.8
|
||||
|
||||
If the :class:`~django.forms.DateField` is not required,
|
||||
:class:`SelectDateWidget` will have an empty choice at the top of the
|
||||
list (which is ``---`` by default). You can change the text of this
|
||||
|
|
|
|||
|
|
@ -68,8 +68,6 @@ Adds a few conveniences for perfectionists:
|
|||
|
||||
.. attribute:: CommonMiddleware.response_redirect_class
|
||||
|
||||
.. versionadded:: 1.8
|
||||
|
||||
Defaults to :class:`~django.http.HttpResponsePermanentRedirect`. Subclass
|
||||
``CommonMiddleware`` and override the attribute to customize the redirects
|
||||
issued by the middleware.
|
||||
|
|
@ -180,8 +178,6 @@ Security middleware
|
|||
|
||||
.. class:: SecurityMiddleware
|
||||
|
||||
.. versionadded:: 1.8
|
||||
|
||||
The ``django.middleware.security.SecurityMiddleware`` provides several security
|
||||
enhancements to the request/response cycle. Each one can be independently
|
||||
enabled or disabled with a setting.
|
||||
|
|
|
|||
|
|
@ -60,10 +60,6 @@ inheriting from the standard ``models.Model``.
|
|||
The first manager in the list will be the default manager for this model during
|
||||
migrations.
|
||||
|
||||
.. versionchanged:: 1.8
|
||||
|
||||
The ``managers`` argument was added.
|
||||
|
||||
DeleteModel
|
||||
-----------
|
||||
|
||||
|
|
@ -132,8 +128,6 @@ should be a dictionary mapping option names to values.
|
|||
AlterModelManagers
|
||||
------------------
|
||||
|
||||
.. versionadded:: 1.8
|
||||
|
||||
.. class:: AlterModelManagers(name, managers)
|
||||
|
||||
Alters the managers that are available during migrations.
|
||||
|
|
@ -244,17 +238,8 @@ The optional ``hints`` argument will be passed as ``**hints`` to the
|
|||
routing decisions. See :ref:`topics-db-multi-db-hints` for more details on
|
||||
database hints.
|
||||
|
||||
.. versionchanged:: 1.8
|
||||
|
||||
The ability to pass parameters to the ``sql`` and ``reverse_sql`` queries
|
||||
was added.
|
||||
|
||||
The ``hints`` argument was added.
|
||||
|
||||
.. attribute:: RunSQL.noop
|
||||
|
||||
.. versionadded:: 1.8
|
||||
|
||||
Pass the ``RunSQL.noop`` attribute to ``sql`` or ``reverse_sql`` when you
|
||||
want the operation not to do anything in the given direction. This is
|
||||
especially useful in making the operation reversible.
|
||||
|
|
@ -282,10 +267,6 @@ The optional ``hints`` argument will be passed as ``**hints`` to the
|
|||
routing decision. See :ref:`topics-db-multi-db-hints` for more details on
|
||||
database hints.
|
||||
|
||||
.. versionadded:: 1.8
|
||||
|
||||
The ``hints`` argument was added.
|
||||
|
||||
You are advised to write the code as a separate function above the ``Migration``
|
||||
class in the migration file, and just pass it to ``RunPython``. Here's an
|
||||
example of using ``RunPython`` to create some initial objects on a ``Country``
|
||||
|
|
@ -370,8 +351,6 @@ attribute.
|
|||
|
||||
.. staticmethod:: RunPython.noop
|
||||
|
||||
.. versionadded:: 1.8
|
||||
|
||||
Pass the ``RunPython.noop`` method to ``code`` or ``reverse_code`` when
|
||||
you want the operation not to do anything in the given direction. This is
|
||||
especially useful in making the operation reversible.
|
||||
|
|
|
|||
|
|
@ -4,8 +4,6 @@ Conditional Expressions
|
|||
|
||||
.. currentmodule:: django.db.models.expressions
|
||||
|
||||
.. versionadded:: 1.8
|
||||
|
||||
Conditional expressions let you use :keyword:`if` ... :keyword:`elif` ...
|
||||
:keyword:`else` logic within filters, annotations, aggregations, and updates. A
|
||||
conditional expression evaluates a series of conditions for each row of a
|
||||
|
|
|
|||
|
|
@ -5,8 +5,6 @@ Database Functions
|
|||
.. module:: django.db.models.functions
|
||||
:synopsis: Database Functions
|
||||
|
||||
.. versionadded:: 1.8
|
||||
|
||||
The classes documented below provide a way for users to use functions provided
|
||||
by the underlying database as annotations, aggregations, or filters in Django.
|
||||
Functions are also :doc:`expressions <expressions>`, so they can be used and
|
||||
|
|
|
|||
|
|
@ -24,10 +24,6 @@ variables, and even other expressions.
|
|||
Some examples
|
||||
=============
|
||||
|
||||
.. versionchanged:: 1.8
|
||||
|
||||
Some of the examples rely on functionality that is new in Django 1.8.
|
||||
|
||||
.. code-block:: python
|
||||
|
||||
from django.db.models import F, Count
|
||||
|
|
@ -211,8 +207,6 @@ directly support ``output_field`` you will need to wrap the expression with
|
|||
``Func()`` expressions
|
||||
----------------------
|
||||
|
||||
.. versionadded:: 1.8
|
||||
|
||||
``Func()`` expressions are the base type of all expressions that involve
|
||||
database functions like ``COALESCE`` and ``LOWER``, or aggregates like ``SUM``.
|
||||
They can be used directly::
|
||||
|
|
@ -322,18 +316,9 @@ should define the desired ``output_field``. For example, adding an
|
|||
``IntegerField()`` and a ``FloatField()`` together should probably have
|
||||
``output_field=FloatField()`` defined.
|
||||
|
||||
.. versionchanged:: 1.8
|
||||
|
||||
``output_field`` is a new parameter.
|
||||
|
||||
The ``**extra`` kwargs are ``key=value`` pairs that can be interpolated
|
||||
into the ``template`` attribute.
|
||||
|
||||
.. versionadded:: 1.8
|
||||
|
||||
Aggregate functions can now use arithmetic and reference multiple
|
||||
model fields in a single function.
|
||||
|
||||
Creating your own Aggregate Functions
|
||||
-------------------------------------
|
||||
|
||||
|
|
@ -390,8 +375,6 @@ output value.
|
|||
|
||||
.. class:: ExpressionWrapper(expression, output_field)
|
||||
|
||||
.. versionadded:: 1.8
|
||||
|
||||
``ExpressionWrapper`` simply surrounds another expression and provides access
|
||||
to properties, such as ``output_field``, that may not be available on other
|
||||
expressions. ``ExpressionWrapper`` is necessary when using arithmetic on
|
||||
|
|
@ -401,8 +384,6 @@ expressions. ``ExpressionWrapper`` is necessary when using arithmetic on
|
|||
Conditional expressions
|
||||
-----------------------
|
||||
|
||||
.. versionadded:: 1.8
|
||||
|
||||
Conditional expressions allow you to use :keyword:`if` ... :keyword:`elif` ...
|
||||
:keyword:`else` logic in queries. Django natively supports SQL ``CASE``
|
||||
expressions. For more details see :doc:`conditional-expressions`.
|
||||
|
|
@ -410,8 +391,6 @@ expressions. For more details see :doc:`conditional-expressions`.
|
|||
Raw SQL expressions
|
||||
-------------------
|
||||
|
||||
.. versionadded:: 1.8
|
||||
|
||||
.. currentmodule:: django.db.models.expressions
|
||||
|
||||
.. class:: RawSQL(sql, params, output_field=None)
|
||||
|
|
|
|||
|
|
@ -228,11 +228,6 @@ The default value is used when new model instances are created and a value
|
|||
isn't provided for the field. When the field is a primary key, the default is
|
||||
also used when the field is set to ``None``.
|
||||
|
||||
.. versionchanged:: 1.8
|
||||
|
||||
The default wasn't used for ``None`` primary key values in previous
|
||||
versions.
|
||||
|
||||
``editable``
|
||||
------------
|
||||
|
||||
|
|
@ -574,8 +569,6 @@ when :attr:`~django.forms.Field.localize` is ``False`` or
|
|||
``DurationField``
|
||||
-----------------
|
||||
|
||||
.. versionadded:: 1.8
|
||||
|
||||
.. class:: DurationField(**options)
|
||||
|
||||
A field for storing periods of time - modeled in Python by
|
||||
|
|
@ -597,11 +590,6 @@ SECOND(6)``. Otherwise a ``bigint`` of microseconds is used.
|
|||
A :class:`CharField` that checks that the value is a valid email address. It
|
||||
uses :class:`~django.core.validators.EmailValidator` to validate the input.
|
||||
|
||||
.. versionchanged:: 1.8
|
||||
|
||||
The default ``max_length`` was increased from 75 to 254 in order to be
|
||||
compliant with RFC3696/5321.
|
||||
|
||||
``FileField``
|
||||
-------------
|
||||
|
||||
|
|
@ -1079,8 +1067,6 @@ Like all :class:`CharField` subclasses, :class:`URLField` takes the optional
|
|||
``UUIDField``
|
||||
-------------
|
||||
|
||||
.. versionadded:: 1.8
|
||||
|
||||
.. class:: UUIDField(**options)
|
||||
|
||||
A field for storing universally unique identifiers. Uses Python's
|
||||
|
|
@ -1757,8 +1743,6 @@ Field API reference
|
|||
|
||||
.. method:: from_db_value(value, expression, connection, context)
|
||||
|
||||
.. versionadded:: 1.8
|
||||
|
||||
Converts a value as returned by the database to a Python object. It is
|
||||
the reverse of :meth:`get_prep_value`.
|
||||
|
||||
|
|
@ -1878,8 +1862,6 @@ Field API reference
|
|||
Field attribute reference
|
||||
=========================
|
||||
|
||||
.. versionadded:: 1.8
|
||||
|
||||
Every ``Field`` instance contains several attributes that allow
|
||||
introspecting its behavior. Use these attributes instead of ``isinstance``
|
||||
checks when you need to write code that depends on a field's functionality.
|
||||
|
|
|
|||
|
|
@ -67,8 +67,6 @@ Customizing model loading
|
|||
|
||||
.. classmethod:: Model.from_db(db, field_names, values)
|
||||
|
||||
.. versionadded:: 1.8
|
||||
|
||||
The ``from_db()`` method can be used to customize model instance creation
|
||||
when loading from the database.
|
||||
|
||||
|
|
@ -121,8 +119,6 @@ Refreshing objects from database
|
|||
|
||||
.. method:: Model.refresh_from_db(using=None, fields=None, **kwargs)
|
||||
|
||||
.. versionadded:: 1.8
|
||||
|
||||
If you need to reload a model's values from the database, you can use the
|
||||
``refresh_from_db()`` method. When this method is called without arguments the
|
||||
following is done:
|
||||
|
|
@ -178,8 +174,6 @@ all of the instance's fields when a deferred field is reloaded::
|
|||
|
||||
.. method:: Model.get_deferred_fields()
|
||||
|
||||
.. versionadded:: 1.8
|
||||
|
||||
A helper method that returns a set containing the attribute names of all those
|
||||
fields that are currently deferred for this model.
|
||||
|
||||
|
|
@ -582,8 +576,6 @@ the data that's currently in the database.
|
|||
Django version N+1. Pickles should not be used as part of a long-term
|
||||
archival strategy.
|
||||
|
||||
.. versionadded:: 1.8
|
||||
|
||||
Since pickle compatibility errors can be difficult to diagnose, such as
|
||||
silently corrupted objects, a ``RuntimeWarning`` is raised when you try to
|
||||
unpickle a model in a Django version that is different than the one in
|
||||
|
|
|
|||
|
|
@ -141,8 +141,6 @@ Transform reference
|
|||
|
||||
.. attribute:: bilateral
|
||||
|
||||
.. versionadded:: 1.8
|
||||
|
||||
A boolean indicating whether this transformation should apply to both
|
||||
``lhs`` and ``rhs``. Bilateral transformations will be applied to ``rhs`` in
|
||||
the same order as they appear in the lookup expression. By default it is set
|
||||
|
|
|
|||
|
|
@ -18,15 +18,6 @@ Methods that it provides can be used to:
|
|||
* Retrieve all field instances of a model
|
||||
* Retrieve a single field instance of a model by name
|
||||
|
||||
.. versionchanged:: 1.8
|
||||
|
||||
The Model ``_meta`` API has always existed as a Django internal, but
|
||||
wasn't formally documented and supported. As part of the effort to
|
||||
make this API public, some of the already existing API entry points
|
||||
have changed slightly. A :ref:`migration guide <migrating-old-meta-api>`
|
||||
has been provided to assist in converting your code to use the new,
|
||||
official API.
|
||||
|
||||
.. _model-meta-field-api:
|
||||
|
||||
Field access API
|
||||
|
|
@ -75,8 +66,6 @@ Retrieving all field instances of a model
|
|||
|
||||
.. method:: Options.get_fields(include_parents=True, include_hidden=False)
|
||||
|
||||
.. versionadded:: 1.8
|
||||
|
||||
Returns a tuple of fields associated with a model. ``get_fields()`` accepts
|
||||
two parameters that can be used to control which fields are returned:
|
||||
|
||||
|
|
|
|||
|
|
@ -100,8 +100,6 @@ Django quotes column and table names behind the scenes.
|
|||
|
||||
.. attribute:: Options.default_related_name
|
||||
|
||||
.. versionadded:: 1.8
|
||||
|
||||
The name that will be used by default for the relation from a related object
|
||||
back to this one. The default is ``<model_name>_set``.
|
||||
|
||||
|
|
|
|||
|
|
@ -114,8 +114,6 @@ described here.
|
|||
Django version N+1. Pickles should not be used as part of a long-term
|
||||
archival strategy.
|
||||
|
||||
.. versionadded:: 1.8
|
||||
|
||||
Since pickle compatibility errors can be difficult to diagnose, such as
|
||||
silently corrupted objects, a ``RuntimeWarning`` is raised when you try to
|
||||
unpickle a queryset in a Django version that is different than the one in
|
||||
|
|
@ -230,12 +228,6 @@ reference to a field on the model (or any related models), or an aggregate
|
|||
expression (averages, sums, etc) that has been computed over the objects that
|
||||
are related to the objects in the ``QuerySet``.
|
||||
|
||||
.. versionadded:: 1.8
|
||||
|
||||
Previous versions of Django only allowed aggregate functions to be used as
|
||||
annotations. It is now possible to annotate a model with all kinds of
|
||||
expressions.
|
||||
|
||||
Each argument to ``annotate()`` is an annotation that will be added
|
||||
to each object in the ``QuerySet`` that is returned.
|
||||
|
||||
|
|
@ -334,10 +326,6 @@ calling ``asc()`` or ``desc()`` on the expression::
|
|||
|
||||
Entry.objects.order_by(Coalesce('summary', 'headline').desc())
|
||||
|
||||
.. versionadded:: 1.8
|
||||
|
||||
Ordering by query expressions was added.
|
||||
|
||||
Be cautious when ordering by fields in related models if you are also using
|
||||
:meth:`distinct()`. See the note in :meth:`distinct` for an explanation of how
|
||||
related model ordering can change the expected results.
|
||||
|
|
@ -381,10 +369,6 @@ ordering::
|
|||
|
||||
Entry.objects.order_by(Lower('headline').desc())
|
||||
|
||||
.. versionadded:: 1.8
|
||||
|
||||
The ability to order by expressions like ``Lower`` was added.
|
||||
|
||||
If you don't want any ordering to be applied to a query, not even the default
|
||||
ordering, call :meth:`order_by()` with no parameters.
|
||||
|
||||
|
|
@ -1224,10 +1208,6 @@ of the arguments is required, but you should use at least one of them.
|
|||
If you need to use a literal ``%s`` inside your select string, use
|
||||
the sequence ``%%s``.
|
||||
|
||||
.. versionchanged:: 1.8
|
||||
|
||||
Prior to 1.8, you were unable to escape a literal ``%s``.
|
||||
|
||||
* ``where`` / ``tables``
|
||||
|
||||
You can define explicit SQL ``WHERE`` clauses — perhaps to perform
|
||||
|
|
@ -2868,21 +2848,12 @@ All aggregates have the following parameters in common:
|
|||
A string that references a field on the model, or a :doc:`query expression
|
||||
</ref/models/expressions>`.
|
||||
|
||||
.. versionadded:: 1.8
|
||||
|
||||
Aggregate functions are now able to reference multiple fields in complex
|
||||
computations.
|
||||
|
||||
``output_field``
|
||||
~~~~~~~~~~~~~~~~
|
||||
|
||||
An optional argument that represents the :doc:`model field </ref/models/fields>`
|
||||
of the return value
|
||||
|
||||
.. versionadded:: 1.8
|
||||
|
||||
The ``output_field`` argument was added.
|
||||
|
||||
.. note::
|
||||
|
||||
When combining multiple field types, Django can only determine the
|
||||
|
|
|
|||
|
|
@ -208,8 +208,6 @@ All attributes should be considered read-only, unless stated otherwise below.
|
|||
|
||||
.. attribute:: HttpRequest.current_app
|
||||
|
||||
.. versionadded:: 1.8
|
||||
|
||||
Not defined by Django itself, but if set, the :ttag:`url` template tag
|
||||
will use its value as the ``current_app`` argument to
|
||||
:func:`~django.core.urlresolvers.reverse()`.
|
||||
|
|
@ -401,10 +399,6 @@ a subclass of dictionary. Exceptions are outlined here:
|
|||
Strings for setting both keys and values will be converted from ``encoding``
|
||||
to unicode. If encoding is not set, it defaults to :setting:`DEFAULT_CHARSET`.
|
||||
|
||||
.. versionchanged:: 1.8
|
||||
|
||||
In previous versions, ``query_string`` was a required positional argument.
|
||||
|
||||
.. method:: QueryDict.__getitem__(key)
|
||||
|
||||
Returns the value for the given key. If the key has more than one value,
|
||||
|
|
@ -650,8 +644,6 @@ Attributes
|
|||
|
||||
.. attribute:: HttpResponse.charset
|
||||
|
||||
.. versionadded:: 1.8
|
||||
|
||||
A string denoting the charset in which the response will be encoded. If not
|
||||
given at ``HttpResponse`` instantiation time, it will be extracted from
|
||||
``content_type`` and if that is unsuccessful, the
|
||||
|
|
@ -690,8 +682,6 @@ Attributes
|
|||
|
||||
.. attribute:: HttpResponse.closed
|
||||
|
||||
.. versionadded:: 1.8
|
||||
|
||||
``True`` if the response has been closed.
|
||||
|
||||
Methods
|
||||
|
|
@ -722,10 +712,6 @@ Methods
|
|||
given it will be extracted from ``content_type``, and if that
|
||||
is unsuccessful, the :setting:`DEFAULT_CHARSET` setting will be used.
|
||||
|
||||
.. versionadded:: 1.8
|
||||
|
||||
The ``charset`` parameter was added.
|
||||
|
||||
.. method:: HttpResponse.__setitem__(header, value)
|
||||
|
||||
Sets the given header name to the given value. Both ``header`` and
|
||||
|
|
@ -747,8 +733,6 @@ Methods
|
|||
|
||||
.. method:: HttpResponse.setdefault(header, value)
|
||||
|
||||
.. versionadded:: 1.8
|
||||
|
||||
Sets a header unless it has already been set.
|
||||
|
||||
.. method:: HttpResponse.set_cookie(key, value='', max_age=None, expires=None, path='/', domain=None, secure=None, httponly=False)
|
||||
|
|
@ -820,22 +804,16 @@ Methods
|
|||
|
||||
.. method:: HttpResponse.getvalue()
|
||||
|
||||
.. versionadded:: 1.8
|
||||
|
||||
Returns the value of :attr:`HttpResponse.content`. This method makes
|
||||
an :class:`HttpResponse` instance a stream-like object.
|
||||
|
||||
.. method:: HttpResponse.writable()
|
||||
|
||||
.. versionadded:: 1.8
|
||||
|
||||
Always ``True``. This method makes an :class:`HttpResponse` instance a
|
||||
stream-like object.
|
||||
|
||||
.. method:: HttpResponse.writelines(lines)
|
||||
|
||||
.. versionadded:: 1.8
|
||||
|
||||
Writes a list of lines to the response. Line separators are not added. This
|
||||
method makes an :class:`HttpResponse` instance a stream-like object.
|
||||
|
||||
|
|
|
|||
|
|
@ -802,10 +802,6 @@ This is an Oracle-specific setting.
|
|||
The name of the tablespace that will be used when running tests. If not
|
||||
provided, Django will use ``'test_' + USER``.
|
||||
|
||||
.. versionchanged:: 1.8
|
||||
|
||||
Previously Django used ``'test_' + NAME`` if not provided.
|
||||
|
||||
.. setting:: TEST_TBLSPACE_TMP
|
||||
|
||||
TBLSPACE_TMP
|
||||
|
|
@ -818,17 +814,11 @@ This is an Oracle-specific setting.
|
|||
The name of the temporary tablespace that will be used when running tests. If
|
||||
not provided, Django will use ``'test_' + USER + '_temp'``.
|
||||
|
||||
.. versionchanged:: 1.8
|
||||
|
||||
Previously Django used ``'test_' + NAME + '_temp'`` if not provided.
|
||||
|
||||
.. setting:: DATAFILE
|
||||
|
||||
DATAFILE
|
||||
^^^^^^^^
|
||||
|
||||
.. versionadded:: 1.8
|
||||
|
||||
Default: ``None``
|
||||
|
||||
This is an Oracle-specific setting.
|
||||
|
|
@ -841,8 +831,6 @@ use ``TBLSPACE + '.dbf'``.
|
|||
DATAFILE_TMP
|
||||
^^^^^^^^^^^^
|
||||
|
||||
.. versionadded:: 1.8
|
||||
|
||||
Default: ``None``
|
||||
|
||||
This is an Oracle-specific setting.
|
||||
|
|
@ -855,14 +843,8 @@ will use ``TBLSPACE_TMP + '.dbf'``.
|
|||
DATAFILE_MAXSIZE
|
||||
^^^^^^^^^^^^^^^^
|
||||
|
||||
.. versionadded:: 1.8
|
||||
|
||||
Default: ``'500M'``
|
||||
|
||||
.. versionchanged:: 1.8
|
||||
|
||||
The previous value was 200M and was not user customizable.
|
||||
|
||||
This is an Oracle-specific setting.
|
||||
|
||||
The maximum size that the DATAFILE is allowed to grow to.
|
||||
|
|
@ -872,14 +854,8 @@ The maximum size that the DATAFILE is allowed to grow to.
|
|||
DATAFILE_TMP_MAXSIZE
|
||||
^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
.. versionadded:: 1.8
|
||||
|
||||
Default: ``'500M'``
|
||||
|
||||
.. versionchanged:: 1.8
|
||||
|
||||
The previous value was 200M and was not user customizable.
|
||||
|
||||
This is an Oracle-specific setting.
|
||||
|
||||
The maximum size that the DATAFILE_TMP is allowed to grow to.
|
||||
|
|
@ -1261,8 +1237,6 @@ exclusive, so only set one of those settings to ``True``.
|
|||
EMAIL_SSL_CERTFILE
|
||||
------------------
|
||||
|
||||
.. versionadded:: 1.8
|
||||
|
||||
Default: ``None``
|
||||
|
||||
If :setting:`EMAIL_USE_SSL` or :setting:`EMAIL_USE_TLS` is ``True``, you can
|
||||
|
|
@ -1274,8 +1248,6 @@ for the SSL connection.
|
|||
EMAIL_SSL_KEYFILE
|
||||
-----------------
|
||||
|
||||
.. versionadded:: 1.8
|
||||
|
||||
Default: ``None``
|
||||
|
||||
If :setting:`EMAIL_USE_SSL` or :setting:`EMAIL_USE_TLS` is ``True``, you can
|
||||
|
|
@ -1293,8 +1265,6 @@ file and private key file are handled.
|
|||
EMAIL_TIMEOUT
|
||||
-------------
|
||||
|
||||
.. versionadded:: 1.8
|
||||
|
||||
Default: ``None``
|
||||
|
||||
Specifies a timeout in seconds for blocking operations like the connection
|
||||
|
|
@ -1463,19 +1433,17 @@ like::
|
|||
__init__.py
|
||||
formats.py
|
||||
|
||||
.. versionchanged:: 1.8
|
||||
|
||||
You can also set this setting to a list of Python paths, for example::
|
||||
You can also set this setting to a list of Python paths, for example::
|
||||
|
||||
FORMAT_MODULE_PATH = [
|
||||
'mysite.formats',
|
||||
'some_app.formats',
|
||||
]
|
||||
|
||||
When Django searches for a certain format, it will go through all given
|
||||
Python paths until it finds a module that actually defines the given
|
||||
format. This means that formats defined in packages farther up in the list
|
||||
will take precedence over the same formats in packages farther down.
|
||||
When Django searches for a certain format, it will go through all given Python
|
||||
paths until it finds a module that actually defines the given format. This
|
||||
means that formats defined in packages farther up in the list will take
|
||||
precedence over the same formats in packages farther down.
|
||||
|
||||
Available formats are :setting:`DATE_FORMAT`, :setting:`TIME_FORMAT`,
|
||||
:setting:`DATETIME_FORMAT`, :setting:`YEAR_MONTH_FORMAT`,
|
||||
|
|
@ -1580,10 +1548,6 @@ It serves two purposes:
|
|||
site. It also provides the fallback translation when a translation for a
|
||||
given literal doesn't exist for the user's preferred language.
|
||||
|
||||
.. versionchanged:: 1.8
|
||||
|
||||
The fallback for translation literals was added.
|
||||
|
||||
See :ref:`how-django-discovers-language-preference` for more details.
|
||||
|
||||
.. _list of language identifiers: http://www.i18nguy.com/unicode/language-identifiers.html
|
||||
|
|
@ -1967,8 +1931,6 @@ affect them.
|
|||
SECURE_BROWSER_XSS_FILTER
|
||||
-------------------------
|
||||
|
||||
.. versionadded:: 1.8
|
||||
|
||||
Default: ``False``
|
||||
|
||||
If ``True``, the :class:`~django.middleware.security.SecurityMiddleware` sets
|
||||
|
|
@ -1979,8 +1941,6 @@ the :ref:`x-xss-protection` header on all responses that do not already have it.
|
|||
SECURE_CONTENT_TYPE_NOSNIFF
|
||||
---------------------------
|
||||
|
||||
.. versionadded:: 1.8
|
||||
|
||||
Default: ``False``
|
||||
|
||||
If ``True``, the :class:`~django.middleware.security.SecurityMiddleware`
|
||||
|
|
@ -1992,8 +1952,6 @@ already have it.
|
|||
SECURE_HSTS_INCLUDE_SUBDOMAINS
|
||||
------------------------------
|
||||
|
||||
.. versionadded:: 1.8
|
||||
|
||||
Default: ``False``
|
||||
|
||||
If ``True``, the :class:`~django.middleware.security.SecurityMiddleware` adds
|
||||
|
|
@ -2011,8 +1969,6 @@ non-zero value.
|
|||
SECURE_HSTS_SECONDS
|
||||
-------------------
|
||||
|
||||
.. versionadded:: 1.8
|
||||
|
||||
Default: ``0``
|
||||
|
||||
If set to a non-zero integer value, the
|
||||
|
|
@ -2090,8 +2046,6 @@ available in ``request.META``.)
|
|||
SECURE_REDIRECT_EXEMPT
|
||||
----------------------
|
||||
|
||||
.. versionadded:: 1.8
|
||||
|
||||
Default: ``[]`` (Empty list)
|
||||
|
||||
If a URL path matches a regular expression in this list, the request will not be
|
||||
|
|
@ -2103,8 +2057,6 @@ setting has no effect.
|
|||
SECURE_SSL_HOST
|
||||
---------------
|
||||
|
||||
.. versionadded:: 1.8
|
||||
|
||||
Default: ``None``
|
||||
|
||||
If a string (e.g. ``secure.example.com``), all SSL redirects will be directed
|
||||
|
|
@ -2117,8 +2069,6 @@ setting has no effect.
|
|||
SECURE_SSL_REDIRECT
|
||||
-------------------
|
||||
|
||||
.. versionadded:: 1.8
|
||||
|
||||
Default: ``False``.
|
||||
|
||||
If ``True``, the :class:`~django.middleware.security.SecurityMiddleware`
|
||||
|
|
@ -2225,8 +2175,6 @@ See also the :doc:`/ref/checks` documentation.
|
|||
TEMPLATES
|
||||
---------
|
||||
|
||||
.. versionadded:: 1.8
|
||||
|
||||
Default: ``[]`` (Empty list)
|
||||
|
||||
A list containing the settings for all template engines to be used with
|
||||
|
|
|
|||
|
|
@ -496,10 +496,6 @@ Arguments sent with this signal:
|
|||
``environ``
|
||||
The ``environ`` dictionary provided to the request.
|
||||
|
||||
.. versionchanged:: 1.8
|
||||
|
||||
The ``environ`` argument was added.
|
||||
|
||||
request_finished
|
||||
----------------
|
||||
|
||||
|
|
@ -562,10 +558,6 @@ distinguish between the two.
|
|||
You can also import this signal from ``django.core.signals`` to avoid importing
|
||||
from ``django.test`` in non-test situations.
|
||||
|
||||
.. versionchanged:: 1.8
|
||||
|
||||
The signal was moved to ``django.core.signals`` as described above.
|
||||
|
||||
Arguments sent with this signal:
|
||||
|
||||
``sender``
|
||||
|
|
|
|||
|
|
@ -90,10 +90,6 @@ Methods
|
|||
The :setting:`NAME <TEMPLATES-NAME>` of a template engine to use for
|
||||
loading the template.
|
||||
|
||||
.. versionchanged:: 1.8
|
||||
|
||||
The ``charset`` and ``using`` parameters were added.
|
||||
|
||||
.. method:: SimpleTemplateResponse.resolve_context(context)
|
||||
|
||||
Preprocesses context data that will be used for rendering a template.
|
||||
|
|
@ -189,10 +185,6 @@ Methods
|
|||
The :setting:`NAME <TEMPLATES-NAME>` of a template engine to use for
|
||||
loading the template.
|
||||
|
||||
.. versionchanged:: 1.8
|
||||
|
||||
The ``charset`` and ``using`` parameters were added.
|
||||
|
||||
The rendering process
|
||||
=====================
|
||||
|
||||
|
|
|
|||
|
|
@ -50,8 +50,6 @@ what's passed by :class:`~django.template.backends.django.DjangoTemplates`.
|
|||
|
||||
.. class:: Engine(dirs=None, app_dirs=False, context_processors=None, debug=False, loaders=None, string_if_invalid='', file_charset='utf-8', libraries=None, builtins=None)
|
||||
|
||||
.. versionadded:: 1.8
|
||||
|
||||
When instantiating an ``Engine`` all arguments must be passed as keyword
|
||||
arguments:
|
||||
|
||||
|
|
@ -600,12 +598,6 @@ processors::
|
|||
'django.contrib.messages.context_processors.messages',
|
||||
]
|
||||
|
||||
.. versionchanged:: 1.8
|
||||
|
||||
Built-in template context processors were moved from
|
||||
``django.core.context_processors`` to
|
||||
``django.template.context_processors`` in Django 1.8.
|
||||
|
||||
In addition to these, :class:`RequestContext` always enables
|
||||
``'django.template.context_processors.csrf'``. This is a security related
|
||||
context processor required by the admin and other contrib apps, and, in case
|
||||
|
|
@ -774,10 +766,6 @@ way of specifying template directories is by using the :setting:`DIRS
|
|||
The :setting:`DIRS <TEMPLATES-DIRS>` option
|
||||
-------------------------------------------
|
||||
|
||||
.. versionchanged:: 1.8
|
||||
|
||||
This value used to be defined by the ``TEMPLATE_DIRS`` setting.
|
||||
|
||||
Tell Django what your template directories are by using the :setting:`DIRS
|
||||
<TEMPLATES-DIRS>` option in the :setting:`TEMPLATES` setting in your settings
|
||||
file — or the ``dirs`` argument of :class:`~django.template.Engine`. This
|
||||
|
|
@ -932,8 +920,6 @@ loaders that come with Django:
|
|||
|
||||
``django.template.loaders.locmem.Loader``
|
||||
|
||||
.. versionadded:: 1.8
|
||||
|
||||
.. class:: locmem.Loader
|
||||
|
||||
Loads templates from a Python dictionary. This is useful for testing.
|
||||
|
|
|
|||
|
|
@ -777,10 +777,6 @@ output (as a string) inside a variable. This is useful if you want to use
|
|||
{% now "Y" as current_year %}
|
||||
{% blocktrans %}Copyright {{ current_year }}{% endblocktrans %}
|
||||
|
||||
.. versionadded:: 1.8
|
||||
|
||||
The ability to use the "as" syntax was added.
|
||||
|
||||
.. templatetag:: regroup
|
||||
|
||||
regroup
|
||||
|
|
@ -1679,10 +1675,7 @@ For example::
|
|||
If ``value`` is ``['a', 'b', 'c', 'd']`` or ``"abcd"``, the output will be
|
||||
``4``.
|
||||
|
||||
.. versionchanged:: 1.8
|
||||
|
||||
The filter returns ``0`` for an undefined variable. Previously, it returned
|
||||
an empty string.
|
||||
The filter returns ``0`` for an undefined variable.
|
||||
|
||||
.. templatefilter:: length_is
|
||||
|
||||
|
|
@ -2239,12 +2232,6 @@ It also supports domain-only links ending in one of the original top level
|
|||
domains (``.com``, ``.edu``, ``.gov``, ``.int``, ``.mil``, ``.net``, and
|
||||
``.org``). For example, ``djangoproject.com`` gets converted.
|
||||
|
||||
.. versionchanged:: 1.8
|
||||
|
||||
Support for domain-only links that include characters after the top-level
|
||||
domain (e.g. ``djangoproject.com/`` and ``djangoproject.com/download/``)
|
||||
was added.
|
||||
|
||||
Links can have trailing punctuation (periods, commas, close-parens) and leading
|
||||
punctuation (opening parens), and ``urlize`` will still do the right thing.
|
||||
|
||||
|
|
|
|||
|
|
@ -18,11 +18,6 @@ Helper function to return a URL pattern for serving files in debug mode::
|
|||
# ... the rest of your URLconf goes here ...
|
||||
] + static(settings.MEDIA_URL, document_root=settings.MEDIA_ROOT)
|
||||
|
||||
.. versionchanged:: 1.8
|
||||
|
||||
The ``view`` argument changed from a string
|
||||
(``'django.views.static.serve'``) to the function.
|
||||
|
||||
url()
|
||||
-----
|
||||
|
||||
|
|
|
|||
|
|
@ -138,8 +138,6 @@ The functions defined in this module share the following properties:
|
|||
|
||||
.. function:: parse_duration(value)
|
||||
|
||||
.. versionadded:: 1.8
|
||||
|
||||
Parses a string and returns a :class:`datetime.timedelta`.
|
||||
|
||||
Expects data in the format ``"DD HH:MM:SS.uuuuuu"`` or as specified by ISO
|
||||
|
|
@ -277,8 +275,6 @@ The functions defined in this module share the following properties:
|
|||
|
||||
.. function:: uri_to_iri(uri)
|
||||
|
||||
.. versionadded:: 1.8
|
||||
|
||||
Converts a Uniform Resource Identifier into an Internationalized Resource
|
||||
Identifier.
|
||||
|
||||
|
|
@ -301,8 +297,6 @@ The functions defined in this module share the following properties:
|
|||
|
||||
.. function:: escape_uri_path(path)
|
||||
|
||||
.. versionadded:: 1.8
|
||||
|
||||
Escapes the unsafe characters from the path portion of a Uniform Resource
|
||||
Identifier (URI).
|
||||
|
||||
|
|
@ -510,8 +504,6 @@ Atom1Feed
|
|||
database by some other process in the brief interval between subsequent
|
||||
invocations of a method on the same instance.
|
||||
|
||||
.. versionadded:: 1.8
|
||||
|
||||
You can use the ``name`` argument to make cached properties of other
|
||||
methods. For example, if you had an expensive ``get_friends()`` method and
|
||||
wanted to allow calling it without retrieving the cached value, you could
|
||||
|
|
@ -657,8 +649,6 @@ escaping HTML.
|
|||
|
||||
.. function:: html_safe()
|
||||
|
||||
.. versionadded:: 1.8
|
||||
|
||||
The ``__html__()`` method on a class helps non-Django templates detect
|
||||
classes whose output doesn't require HTML escaping.
|
||||
|
||||
|
|
@ -916,9 +906,7 @@ appropriate entities.
|
|||
``None``, the :ref:`current time zone <default-current-time-zone>` is unset
|
||||
on entry with :func:`deactivate()` instead.
|
||||
|
||||
.. versionchanged:: 1.8
|
||||
|
||||
``override`` is now usable as a function decorator.
|
||||
``override`` is also usable as a function decorator.
|
||||
|
||||
.. function:: localtime(value, timezone=None)
|
||||
|
||||
|
|
@ -979,10 +967,6 @@ appropriate entities.
|
|||
|
||||
``is_dst`` has no effect when ``pytz`` is not installed.
|
||||
|
||||
.. versionchanged:: 1.8
|
||||
|
||||
In older versions of Django, ``timezone`` was a required argument.
|
||||
|
||||
.. versionchanged:: 1.9
|
||||
|
||||
The ``is_dst`` argument was added.
|
||||
|
|
@ -994,10 +978,6 @@ appropriate entities.
|
|||
aware :class:`~datetime.datetime`. If ``timezone`` is set to ``None``, it
|
||||
defaults to the :ref:`current time zone <default-current-time-zone>`.
|
||||
|
||||
.. versionchanged:: 1.8
|
||||
|
||||
In older versions of Django, ``timezone`` was a required argument.
|
||||
|
||||
.. _pytz: http://pytz.sourceforge.net/
|
||||
|
||||
``django.utils.translation``
|
||||
|
|
@ -1095,9 +1075,7 @@ For a complete discussion on the usage of the following see the
|
|||
is ``True``. If you pass ``None`` as the language argument, a
|
||||
``NullTranslations()`` instance is activated within the context.
|
||||
|
||||
.. versionchanged:: 1.8
|
||||
|
||||
``override`` is now usable as a function decorator.
|
||||
``override`` is also usable as a function decorator.
|
||||
|
||||
.. function:: get_language()
|
||||
|
||||
|
|
@ -1105,11 +1083,6 @@ For a complete discussion on the usage of the following see the
|
|||
translations are temporarily deactivated (by :func:`deactivate_all()` or
|
||||
when ``None`` is passed to :func:`override()`).
|
||||
|
||||
.. versionchanged:: 1.8
|
||||
|
||||
Before Django 1.8, ``get_language()`` always returned
|
||||
:setting:`LANGUAGE_CODE` when translations were deactivated.
|
||||
|
||||
.. function:: get_language_bidi()
|
||||
|
||||
Returns selected language's BiDi layout:
|
||||
|
|
|
|||
|
|
@ -163,11 +163,6 @@ to, or in lieu of custom ``field.clean()`` methods.
|
|||
|
||||
.. _valid URI schemes: https://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml
|
||||
|
||||
.. versionchanged:: 1.8
|
||||
|
||||
Support for IPv6 addresses, unicode domains, and URLs containing
|
||||
authentication data was added.
|
||||
|
||||
``validate_email``
|
||||
------------------
|
||||
|
||||
|
|
@ -242,10 +237,6 @@ to, or in lieu of custom ``field.clean()`` methods.
|
|||
Raises a :exc:`~django.core.exceptions.ValidationError` with a code of
|
||||
``'max_value'`` if ``value`` is greater than ``max_value``.
|
||||
|
||||
.. versionchanged:: 1.8
|
||||
|
||||
The ``message`` parameter was added.
|
||||
|
||||
``MinValueValidator``
|
||||
---------------------
|
||||
|
||||
|
|
@ -254,10 +245,6 @@ to, or in lieu of custom ``field.clean()`` methods.
|
|||
Raises a :exc:`~django.core.exceptions.ValidationError` with a code of
|
||||
``'min_value'`` if ``value`` is less than ``min_value``.
|
||||
|
||||
.. versionchanged:: 1.8
|
||||
|
||||
The ``message`` parameter was added.
|
||||
|
||||
``MaxLengthValidator``
|
||||
----------------------
|
||||
|
||||
|
|
@ -266,10 +253,6 @@ to, or in lieu of custom ``field.clean()`` methods.
|
|||
Raises a :exc:`~django.core.exceptions.ValidationError` with a code of
|
||||
``'max_length'`` if the length of ``value`` is greater than ``max_length``.
|
||||
|
||||
.. versionchanged:: 1.8
|
||||
|
||||
The ``message`` parameter was added.
|
||||
|
||||
``MinLengthValidator``
|
||||
----------------------
|
||||
|
||||
|
|
@ -278,10 +261,6 @@ to, or in lieu of custom ``field.clean()`` methods.
|
|||
Raises a :exc:`~django.core.exceptions.ValidationError` with a code of
|
||||
``'min_length'`` if the length of ``value`` is less than ``min_length``.
|
||||
|
||||
.. versionchanged:: 1.8
|
||||
|
||||
The ``message`` parameter was added.
|
||||
|
||||
``DecimalValidator``
|
||||
--------------------
|
||||
|
||||
|
|
|
|||
|
|
@ -77,11 +77,6 @@ but a few of the key features are:
|
|||
:ref:`ForeignKey <ref-foreignkey>` or :ref:`ManyToManyField <ref-manytomany>`
|
||||
to) apps with migrations.
|
||||
|
||||
* If you are upgrading from South, see our :ref:`upgrading-from-south`
|
||||
documentation, and third-party app authors should read the
|
||||
`South 1.0 release notes <http://south.readthedocs.org/en/latest/releasenotes/1.0.html#library-migration-path>`_
|
||||
for details on how to support South and Django migrations simultaneously.
|
||||
|
||||
.. _app-loading-refactor-17-release-note:
|
||||
|
||||
App-loading refactor
|
||||
|
|
|
|||
|
|
@ -180,13 +180,10 @@ The permissions given to the user will be the superset of all permissions
|
|||
returned by all backends. That is, Django grants a permission to a user that
|
||||
any one backend grants.
|
||||
|
||||
.. versionadded:: 1.8
|
||||
|
||||
If a backend raises a :class:`~django.core.exceptions.PermissionDenied`
|
||||
exception in :meth:`~django.contrib.auth.models.User.has_perm()` or
|
||||
:meth:`~django.contrib.auth.models.User.has_module_perms()`,
|
||||
the authorization will immediately fail and Django
|
||||
won't check the backends that follow.
|
||||
If a backend raises a :class:`~django.core.exceptions.PermissionDenied`
|
||||
exception in :meth:`~django.contrib.auth.models.User.has_perm()` or
|
||||
:meth:`~django.contrib.auth.models.User.has_module_perms()`, the authorization
|
||||
will immediately fail and Django won't check the backends that follow.
|
||||
|
||||
The simple backend above could implement permissions for the magic admin
|
||||
fairly simply::
|
||||
|
|
@ -494,11 +491,6 @@ Django expects your custom User model to meet some minimum requirements.
|
|||
what these two methods return - if you want, they can return exactly
|
||||
the same value.
|
||||
|
||||
.. versionchanged:: 1.8
|
||||
|
||||
Older versions of Django required your model to have an integer primary
|
||||
key as well.
|
||||
|
||||
The easiest way to construct a compliant custom User model is to inherit from
|
||||
:class:`~django.contrib.auth.models.AbstractBaseUser`.
|
||||
:class:`~django.contrib.auth.models.AbstractBaseUser` provides the core
|
||||
|
|
@ -526,8 +518,6 @@ password resets. You must then provide some key implementation details:
|
|||
...
|
||||
USERNAME_FIELD = 'identifier'
|
||||
|
||||
.. versionadded:: 1.8
|
||||
|
||||
:attr:`USERNAME_FIELD` now supports
|
||||
:class:`~django.db.models.ForeignKey`\s. Since there is no way to pass
|
||||
model instances during the :djadmin:`createsuperuser` prompt, expect the
|
||||
|
|
@ -562,8 +552,6 @@ password resets. You must then provide some key implementation details:
|
|||
``User`` model, but should *not* contain the ``USERNAME_FIELD`` or
|
||||
``password`` as these fields will always be prompted for.
|
||||
|
||||
.. versionadded:: 1.8
|
||||
|
||||
:attr:`REQUIRED_FIELDS` now supports
|
||||
:class:`~django.db.models.ForeignKey`\s. Since there is no way to pass
|
||||
model instances during the :djadmin:`createsuperuser` prompt, expect the
|
||||
|
|
|
|||
|
|
@ -1516,8 +1516,6 @@ provides several built-in forms located in :mod:`django.contrib.auth.forms`:
|
|||
|
||||
.. method:: send_email(subject_template_name, email_template_name, context, from_email, to_email, html_email_template_name=None)
|
||||
|
||||
.. versionadded:: 1.8
|
||||
|
||||
Uses the arguments to send an ``EmailMultiAlternatives``.
|
||||
Can be overridden to customize how the email is sent to the user.
|
||||
|
||||
|
|
|
|||
|
|
@ -99,8 +99,6 @@ make the following call::
|
|||
# ... perform compatibility checks and collect errors
|
||||
return errors
|
||||
|
||||
.. versionadded:: 1.8
|
||||
|
||||
You can register "deployment checks" that are only relevant to a production
|
||||
settings file like this::
|
||||
|
||||
|
|
@ -121,10 +119,6 @@ The code below is equivalent to the code above::
|
|||
...
|
||||
register(my_check, Tags.security, deploy=True)
|
||||
|
||||
.. versionchanged:: 1.8
|
||||
|
||||
The ability to use register as a function was added.
|
||||
|
||||
.. _field-checking:
|
||||
|
||||
Field, Model, and Manager checks
|
||||
|
|
|
|||
|
|
@ -143,16 +143,6 @@ If you specify both the :attr:`~django.views.generic.edit.ModelFormMixin.fields`
|
|||
and :attr:`~django.views.generic.edit.FormMixin.form_class` attributes, an
|
||||
:exc:`~django.core.exceptions.ImproperlyConfigured` exception will be raised.
|
||||
|
||||
.. versionchanged:: 1.8
|
||||
|
||||
Omitting the ``fields`` attribute was previously allowed and resulted in a
|
||||
form with all of the model's fields.
|
||||
|
||||
.. versionchanged:: 1.8
|
||||
|
||||
Previously if both ``fields`` and ``form_class`` were specified,
|
||||
``fields`` was silently ignored.
|
||||
|
||||
Finally, we hook these new views into the URLconf:
|
||||
|
||||
.. snippet::
|
||||
|
|
|
|||
|
|
@ -33,11 +33,6 @@ returned.
|
|||
When you need more fine-grained control you may use per-view conditional
|
||||
processing functions.
|
||||
|
||||
.. versionchanged:: 1.8
|
||||
|
||||
Support for the ``If-unmodified-since`` header was added to conditional
|
||||
view processing.
|
||||
|
||||
.. _conditional-decorators:
|
||||
|
||||
The ``condition`` decorator
|
||||
|
|
|
|||
|
|
@ -60,13 +60,6 @@ raises ``ValueError``::
|
|||
...
|
||||
ValueError: save() prohibited to prevent data loss due to unsaved related object 'reporter'.
|
||||
|
||||
.. versionchanged:: 1.8.4
|
||||
|
||||
Previously, saving an object with unsaved related objects did not raise an
|
||||
error and could result in silent data loss. In 1.8-1.8.3, unsaved model
|
||||
instances couldn't be assigned to related fields, but this restriction was
|
||||
removed to allow easier usage of in-memory models.
|
||||
|
||||
Article objects have access to their related Reporter objects::
|
||||
|
||||
>>> r = a.reporter
|
||||
|
|
|
|||
|
|
@ -101,13 +101,6 @@ raises ``ValueError``::
|
|||
...
|
||||
ValueError: save() prohibited to prevent data loss due to unsaved related object 'place'.
|
||||
|
||||
.. versionchanged:: 1.8.4
|
||||
|
||||
Previously, saving an object with unsaved related objects did not raise an
|
||||
error and could result in silent data loss. In 1.8-1.8.3, unsaved model
|
||||
instances couldn't be assigned to related fields, but this restriction was
|
||||
removed to allow easier usage of in-memory models.
|
||||
|
||||
Restaurant.objects.all() just returns the Restaurants, not the Places. Note
|
||||
that there are two restaurants - Ace Hardware the Restaurant was created in the
|
||||
call to r.place = p2::
|
||||
|
|
|
|||
|
|
@ -202,11 +202,6 @@ Django provides a single API to control database transactions.
|
|||
You may use ``atomic`` when autocommit is turned off. It will only use
|
||||
savepoints, even for the outermost block.
|
||||
|
||||
.. versionchanged:: 1.8.5
|
||||
|
||||
Previously the outermost atomic block couldn't be declared with
|
||||
``savepoint=False`` when autocommit was turned off.
|
||||
|
||||
.. admonition:: Performance considerations
|
||||
|
||||
Open transactions have a performance cost for your database server. To
|
||||
|
|
|
|||
|
|
@ -277,10 +277,6 @@ All parameters are optional and can be set at any time prior to calling the
|
|||
* ``reply_to``: A list or tuple of recipient addresses used in the "Reply-To"
|
||||
header when sending the email.
|
||||
|
||||
.. versionchanged:: 1.8
|
||||
|
||||
The ``reply_to`` parameter was added.
|
||||
|
||||
For example::
|
||||
|
||||
email = EmailMessage('Hello', 'Body goes here', 'from@example.com',
|
||||
|
|
@ -412,10 +408,6 @@ It can also be used as a context manager, which will automatically call
|
|||
mail.EmailMessage(subject2, body2, from2, [to2],
|
||||
connection=connection).send()
|
||||
|
||||
.. versionadded:: 1.8
|
||||
|
||||
The context manager protocol was added.
|
||||
|
||||
Obtaining an instance of an email backend
|
||||
-----------------------------------------
|
||||
|
||||
|
|
@ -472,12 +464,6 @@ SMTP backend
|
|||
If unspecified, the default ``timeout`` will be the one provided by
|
||||
:func:`socket.getdefaulttimeout()`, which defaults to ``None`` (no timeout).
|
||||
|
||||
.. versionchanged:: 1.8
|
||||
|
||||
The ``ssl_keyfile``, and ``ssl_certfile`` parameters and corresponding
|
||||
settings were added. The ability to customize ``timeout`` using
|
||||
a setting (:setting:`EMAIL_TIMEOUT`) was added.
|
||||
|
||||
.. _topic-email-console-backend:
|
||||
|
||||
Console backend
|
||||
|
|
|
|||
|
|
@ -615,10 +615,6 @@ errors. For example, ``{{ form.non_field_errors }}`` would look like:
|
|||
<li>Generic validation error</li>
|
||||
</ul>
|
||||
|
||||
.. versionchanged:: 1.8
|
||||
|
||||
The ``nonfield`` class as described in the example above was added.
|
||||
|
||||
See :doc:`/ref/forms/api` for more on errors, styling, and working with form
|
||||
attributes in templates.
|
||||
|
||||
|
|
|
|||
|
|
@ -436,12 +436,6 @@ In addition, Django applies the following rule: if you set ``editable=False`` on
|
|||
the model field, *any* form created from the model via ``ModelForm`` will not
|
||||
include that field.
|
||||
|
||||
.. versionchanged:: 1.8
|
||||
|
||||
In older versions, omitting both ``fields`` and ``exclude`` resulted in
|
||||
a form with all the model's fields. Doing this now raises an
|
||||
:exc:`~django.core.exceptions.ImproperlyConfigured` exception.
|
||||
|
||||
.. note::
|
||||
|
||||
Any fields not included in a form by the above logic
|
||||
|
|
@ -745,12 +739,6 @@ exclude::
|
|||
|
||||
>>> AuthorFormSet = modelformset_factory(Author, exclude=('birth_date',))
|
||||
|
||||
.. versionchanged:: 1.8
|
||||
|
||||
In older versions, omitting both ``fields`` and ``exclude`` resulted in
|
||||
a formset with all the model's fields. Doing this now raises an
|
||||
:exc:`~django.core.exceptions.ImproperlyConfigured` exception.
|
||||
|
||||
This will create a formset that is capable of working with the data associated
|
||||
with the ``Author`` model. It works just like a regular formset::
|
||||
|
||||
|
|
|
|||
|
|
@ -273,11 +273,6 @@ that piece of middleware from the middleware process and a debug message will
|
|||
be logged to the ``django.request`` logger when :setting:`DEBUG` is set to
|
||||
``True``.
|
||||
|
||||
.. versionchanged:: 1.8
|
||||
|
||||
Previously, :exc:`~django.core.exceptions.MiddlewareNotUsed` exceptions
|
||||
weren't logged.
|
||||
|
||||
Guidelines
|
||||
----------
|
||||
|
||||
|
|
|
|||
|
|
@ -226,12 +226,6 @@ You can edit it multiple times.
|
|||
can't be accessed again from the user's browser (for example, the
|
||||
:func:`django.contrib.auth.logout()` function calls it).
|
||||
|
||||
.. versionchanged:: 1.8
|
||||
|
||||
Deletion of the session cookie is a behavior new in Django 1.8.
|
||||
Previously, the behavior was to regenerate the session key value that
|
||||
was sent back to the user in the cookie.
|
||||
|
||||
.. method:: set_test_cookie()
|
||||
|
||||
Sets a test cookie to determine whether the user's browser supports
|
||||
|
|
|
|||
|
|
@ -56,10 +56,6 @@ Optional arguments
|
|||
The :setting:`NAME <TEMPLATES-NAME>` of a template engine to use for
|
||||
loading the template.
|
||||
|
||||
.. versionchanged:: 1.8
|
||||
|
||||
The ``using`` parameter was added.
|
||||
|
||||
Example
|
||||
-------
|
||||
|
||||
|
|
@ -121,10 +117,6 @@ Optional arguments
|
|||
The :setting:`NAME <TEMPLATES-NAME>` of a template engine to use for
|
||||
loading the template.
|
||||
|
||||
.. versionchanged:: 1.8
|
||||
|
||||
The ``status`` and ``using`` parameters were added.
|
||||
|
||||
Example
|
||||
-------
|
||||
|
||||
|
|
|
|||
|
|
@ -154,12 +154,6 @@ Django provides format definitions for many locales, but sometimes you might
|
|||
want to create your own, because a format files doesn't exist for your locale,
|
||||
or because you want to overwrite some of the values.
|
||||
|
||||
|
||||
.. versionchanged:: 1.8
|
||||
|
||||
The ability to specify :setting:`FORMAT_MODULE_PATH` as a list was added.
|
||||
Previously, only a single string value was supported.
|
||||
|
||||
To use custom formats, specify the path where you'll place format files
|
||||
first. To do that, just set your :setting:`FORMAT_MODULE_PATH` setting to
|
||||
the package where format files will exist, for instance::
|
||||
|
|
|
|||
|
|
@ -872,10 +872,6 @@ If you enable the ``django.template.context_processors.i18n`` context processor
|
|||
then each ``RequestContext`` will have access to ``LANGUAGES``,
|
||||
``LANGUAGE_CODE``, and ``LANGUAGE_BIDI`` as defined above.
|
||||
|
||||
.. versionchanged:: 1.8
|
||||
|
||||
The ``i18n`` context processor is not enabled by default for new projects.
|
||||
|
||||
.. templatetag:: get_language_info
|
||||
|
||||
``get_language_info``
|
||||
|
|
|
|||
|
|
@ -623,8 +623,6 @@ Python logging module.
|
|||
|
||||
.. method:: send_mail(subject, message, *args, **kwargs)
|
||||
|
||||
.. versionadded:: 1.8
|
||||
|
||||
Sends emails to admin users. To customize this behavior, you can
|
||||
subclass the :class:`~django.utils.log.AdminEmailHandler` class and
|
||||
override this method.
|
||||
|
|
|
|||
|
|
@ -140,8 +140,6 @@ developers (or your production servers) check out the code, they'll
|
|||
get both the changes to your models and the accompanying migration at the
|
||||
same time.
|
||||
|
||||
.. versionadded:: 1.8
|
||||
|
||||
If you want to give the migration(s) a meaningful name instead of a generated
|
||||
one, you can use the :djadminopt:`--name` option::
|
||||
|
||||
|
|
@ -251,8 +249,6 @@ argument, please create a keyword argument and add something like
|
|||
Model managers
|
||||
~~~~~~~~~~~~~~
|
||||
|
||||
.. versionadded:: 1.8
|
||||
|
||||
You can optionally serialize managers into migrations and have them available
|
||||
in :class:`~django.db.migrations.operations.RunPython` operations. This is done
|
||||
by defining a ``use_in_migrations`` attribute on the manager class::
|
||||
|
|
@ -333,12 +329,6 @@ Note that this only works given two things:
|
|||
that your database doesn't match your models, you'll just get errors when
|
||||
migrations try to modify those tables.
|
||||
|
||||
.. versionchanged:: 1.8
|
||||
|
||||
The ``--fake-initial`` flag to :djadmin:`migrate` was added. Previously,
|
||||
Django would always automatically fake-apply initial migrations if it
|
||||
detected that the tables exist.
|
||||
|
||||
.. _historical-models:
|
||||
|
||||
Historical models
|
||||
|
|
@ -380,8 +370,6 @@ can opt to move them into a superclass.
|
|||
Considerations when removing model fields
|
||||
-----------------------------------------
|
||||
|
||||
.. versionadded:: 1.8
|
||||
|
||||
Similar to the "references to historical functions" considerations described in
|
||||
the previous section, removing custom model fields from your project or
|
||||
third-party app will cause a problem if they are referenced in old migrations.
|
||||
|
|
@ -781,48 +769,6 @@ should run unchanged on Django X.Y+1. The migrations system does not promise
|
|||
forwards-compatibility, however. New features may be added, and migration files
|
||||
generated with newer versions of Django may not work on older versions.
|
||||
|
||||
.. _upgrading-from-south:
|
||||
|
||||
Upgrading from South
|
||||
--------------------
|
||||
|
||||
If you already have pre-existing migrations created with
|
||||
`South <http://south.aeracode.org>`_, then the upgrade process to use
|
||||
``django.db.migrations`` is quite simple:
|
||||
|
||||
* Ensure all installs are fully up-to-date with their migrations.
|
||||
* Remove ``'south'`` from :setting:`INSTALLED_APPS`.
|
||||
* Delete all your (numbered) migration files, but not the directory or
|
||||
``__init__.py`` - make sure you remove the ``.pyc`` files too.
|
||||
* Run ``python manage.py makemigrations``. Django should see the empty
|
||||
migration directories and make new initial migrations in the new format.
|
||||
* Run ``python manage.py migrate --fake-initial``. Django will see that the
|
||||
tables for the initial migrations already exist and mark them as applied
|
||||
without running them. (Django won't check that the table schema match your
|
||||
models, just that the right table names exist).
|
||||
|
||||
.. versionchanged:: 1.8
|
||||
|
||||
The :djadminopt:`--fake-initial` flag was added to :djadmin:`migrate`;
|
||||
previously, initial migrations were always automatically fake-applied if
|
||||
existing tables were detected.
|
||||
|
||||
Libraries/Third-party Apps
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
If you are a library or app maintainer, and wish to support both South migrations
|
||||
(for Django 1.6 and below) and Django migrations (for 1.7 and above) you should
|
||||
keep two parallel migration sets in your app, one in each format.
|
||||
|
||||
To aid in this, South 1.0 will automatically look for South-format migrations
|
||||
in a ``south_migrations`` directory first, before looking in ``migrations``,
|
||||
meaning that users' projects will transparently use the correct set as long
|
||||
as you put your South migrations in the ``south_migrations`` directory and
|
||||
your Django migrations in the ``migrations`` directory.
|
||||
|
||||
More information is available in the
|
||||
`South 1.0 release notes <http://south.readthedocs.org/en/latest/releasenotes/1.0.html#library-migration-path>`_.
|
||||
|
||||
.. seealso::
|
||||
|
||||
:doc:`The Migrations Operations Reference </ref/migration-operations>`
|
||||
|
|
|
|||
|
|
@ -261,10 +261,8 @@ be notified of a signal in the face of an error.
|
|||
and ensures all receivers are notified of the signal. If an error occurs, the
|
||||
error instance is returned in the tuple pair for the receiver that raised the error.
|
||||
|
||||
.. versionadded:: 1.8
|
||||
|
||||
The tracebacks are present on the ``__traceback__`` attribute
|
||||
of the errors returned when calling ``send_robust()``.
|
||||
The tracebacks are present on the ``__traceback__`` attribute of the errors
|
||||
returned when calling ``send_robust()``.
|
||||
|
||||
Disconnecting signals
|
||||
=====================
|
||||
|
|
@ -278,10 +276,6 @@ arguments are as described in :meth:`.Signal.connect`. The method returns
|
|||
The ``receiver`` argument indicates the registered receiver to disconnect. It
|
||||
may be ``None`` if ``dispatch_uid`` is used to identify the receiver.
|
||||
|
||||
.. versionchanged:: 1.8
|
||||
|
||||
The boolean return value was added.
|
||||
|
||||
.. deprecated:: 1.9
|
||||
|
||||
The ``weak`` argument is deprecated as it has no effect. It will be removed
|
||||
|
|
|
|||
|
|
@ -142,10 +142,6 @@ created within a specified period of time::
|
|||
otherwise raises ``SignatureExpired``. The ``max_age`` parameter can
|
||||
accept an integer or a :py:class:`datetime.timedelta` object.
|
||||
|
||||
.. versionchanged:: 1.8
|
||||
|
||||
Previously, the ``max_age`` parameter only accepted an integer.
|
||||
|
||||
Protecting complex data structures
|
||||
----------------------------------
|
||||
|
||||
|
|
|
|||
|
|
@ -41,11 +41,6 @@ namespace.
|
|||
Support for template engines
|
||||
============================
|
||||
|
||||
.. versionadded:: 1.8
|
||||
|
||||
Support for multiple template engines and the :setting:`TEMPLATES` setting
|
||||
were added in Django 1.8.
|
||||
|
||||
Configuration
|
||||
-------------
|
||||
|
||||
|
|
@ -115,30 +110,12 @@ The ``django.template.loader`` module defines two functions to load templates.
|
|||
If you want to restrict the search to a particular template engine, pass
|
||||
the engine's :setting:`NAME <TEMPLATES-NAME>` in the ``using`` argument.
|
||||
|
||||
.. versionchanged:: 1.8
|
||||
|
||||
The ``using`` parameter was added.
|
||||
|
||||
.. versionchanged:: 1.8
|
||||
|
||||
``get_template()`` returns a backend-dependent ``Template`` instead
|
||||
of a :class:`django.template.Template`.
|
||||
|
||||
.. function:: select_template(template_name_list, using=None)
|
||||
|
||||
``select_template()`` is just like ``get_template()``, except it takes a
|
||||
list of template names. It tries each name in order and returns the first
|
||||
template that exists.
|
||||
|
||||
.. versionchanged:: 1.8
|
||||
|
||||
The ``using`` parameter was added.
|
||||
|
||||
.. versionchanged:: 1.8
|
||||
|
||||
``select_template()`` returns a backend-dependent ``Template`` instead
|
||||
of a :class:`django.template.Template`.
|
||||
|
||||
.. currentmodule:: django.template
|
||||
|
||||
If loading a template fails, the following two exceptions, defined in
|
||||
|
|
@ -279,10 +256,6 @@ templates, Django provides a shortcut function which automates the process.
|
|||
An optional :class:`~django.http.HttpRequest` that will be available
|
||||
during the template's rendering process.
|
||||
|
||||
.. versionadded:: 1.8
|
||||
|
||||
The ``request`` argument was added.
|
||||
|
||||
See also the :func:`~django.shortcuts.render()` and
|
||||
:func:`~django.shortcuts.render_to_response()` shortcuts, which call
|
||||
:func:`render_to_string()` and feed the result into an
|
||||
|
|
|
|||
|
|
@ -415,10 +415,6 @@ execute and tear down the test suite.
|
|||
custom arguments by calling ``parser.add_argument()`` inside the method, so
|
||||
that the :djadmin:`test` command will be able to use those arguments.
|
||||
|
||||
.. versionchanged:: 1.8
|
||||
|
||||
The ``keepdb``, ``reverse``, and ``debug_sql`` arguments were added.
|
||||
|
||||
Attributes
|
||||
~~~~~~~~~~
|
||||
|
||||
|
|
@ -463,8 +459,6 @@ Methods
|
|||
|
||||
.. classmethod:: DiscoverRunner.add_arguments(parser)
|
||||
|
||||
.. versionadded:: 1.8
|
||||
|
||||
Override this class method to add custom arguments accepted by the
|
||||
:djadmin:`test` management command. See
|
||||
:py:meth:`argparse.ArgumentParser.add_argument()` for details about adding
|
||||
|
|
@ -604,10 +598,6 @@ can be useful during testing.
|
|||
:setting:`NAME` in :setting:`DATABASES` to match the name of the test
|
||||
database.
|
||||
|
||||
.. versionchanged:: 1.8
|
||||
|
||||
The ``keepdb`` argument was added.
|
||||
|
||||
.. function:: destroy_test_db(old_database_name, verbosity=1, keepdb=False)
|
||||
|
||||
Destroys the database whose name is the value of :setting:`NAME` in
|
||||
|
|
@ -620,10 +610,6 @@ can be useful during testing.
|
|||
If the ``keepdb`` argument is ``True``, then the connection to the
|
||||
database will be closed, but the database will not be destroyed.
|
||||
|
||||
.. versionchanged:: 1.8
|
||||
|
||||
The ``keepdb`` argument was added.
|
||||
|
||||
.. _topics-testing-code-coverage:
|
||||
|
||||
Integration with coverage.py
|
||||
|
|
|
|||
|
|
@ -135,13 +135,10 @@ Tests that require a database (namely, model tests) will not use your "real"
|
|||
Regardless of whether the tests pass or fail, the test databases are destroyed
|
||||
when all the tests have been executed.
|
||||
|
||||
.. versionadded:: 1.8
|
||||
|
||||
You can prevent the test databases from being destroyed by adding the
|
||||
:djadminopt:`--keepdb` flag to the test command. This will preserve the test
|
||||
database between runs. If the database does not exist, it will first
|
||||
be created. Any migrations will also be applied in order to keep it
|
||||
up to date.
|
||||
You can prevent the test databases from being destroyed by adding the
|
||||
:djadminopt:`--keepdb` flag to the test command. This will preserve the test
|
||||
database between runs. If the database does not exist, it will first be
|
||||
created. Any migrations will also be applied in order to keep it p to date.
|
||||
|
||||
By default the test databases get their names by prepending ``test_``
|
||||
to the value of the :setting:`NAME` settings for the databases
|
||||
|
|
@ -173,10 +170,6 @@ If using a SQLite in-memory database with Python 3.4+ and SQLite 3.7.13+,
|
|||
`shared cache <https://www.sqlite.org/sharedcache.html>`_ will be enabled, so
|
||||
you can write tests with ability to share the database between threads.
|
||||
|
||||
.. versionadded:: 1.8
|
||||
|
||||
The ability to use SQLite with a shared cache as described above was added.
|
||||
|
||||
.. admonition:: Finding data from your production database when running tests?
|
||||
|
||||
If your code attempts to access the database when its modules are compiled,
|
||||
|
|
@ -218,11 +211,9 @@ the Django test runner reorders tests in the following way:
|
|||
database by a given :class:`~django.test.TransactionTestCase` test, they
|
||||
must be updated to be able to run independently.
|
||||
|
||||
.. versionadded:: 1.8
|
||||
|
||||
You may reverse the execution order inside groups by passing
|
||||
:djadminopt:`--reverse` to the test command. This can help with ensuring
|
||||
your tests are independent from each other.
|
||||
You may reverse the execution order inside groups by passing
|
||||
:djadminopt:`--reverse` to the test command. This can help with ensuring your
|
||||
tests are independent from each other.
|
||||
|
||||
.. _test-case-serialized-rollback:
|
||||
|
||||
|
|
|
|||
|
|
@ -237,10 +237,6 @@ Use the ``django.test.Client`` class to make requests.
|
|||
You may also provide any file-like object (e.g., :class:`~io.StringIO` or
|
||||
:class:`~io.BytesIO`) as a file handle.
|
||||
|
||||
.. versionadded:: 1.8
|
||||
|
||||
The ability to use a file-like object was added.
|
||||
|
||||
Note that if you wish to use the same file handle for multiple
|
||||
``post()`` calls then you will need to manually reset the file
|
||||
pointer between posts. The easiest way to do this is to
|
||||
|
|
@ -321,8 +317,6 @@ Use the ``django.test.Client`` class to make requests.
|
|||
|
||||
.. method:: Client.trace(path, follow=False, secure=False, **extra)
|
||||
|
||||
.. versionadded:: 1.8
|
||||
|
||||
Makes a TRACE request on the provided ``path`` and returns a
|
||||
``Response`` object. Useful for simulating diagnostic probes.
|
||||
|
||||
|
|
@ -496,8 +490,6 @@ Specifically, a ``Response`` object has the following attributes:
|
|||
|
||||
.. attribute:: resolver_match
|
||||
|
||||
.. versionadded:: 1.8
|
||||
|
||||
An instance of :class:`~django.core.urlresolvers.ResolverMatch` for the
|
||||
response. You can use the
|
||||
:attr:`~django.core.urlresolvers.ResolverMatch.func` attribute, for
|
||||
|
|
@ -698,14 +690,6 @@ transaction, as is required when using
|
|||
:meth:`~django.db.models.query.QuerySet.select_for_update()`. In those cases,
|
||||
you should use ``TransactionTestCase``.
|
||||
|
||||
.. versionchanged:: 1.8
|
||||
|
||||
In older versions of Django, the effects of transaction commit and rollback
|
||||
could not be tested within a ``TestCase``. With the completion of the
|
||||
deprecation cycle of the old-style transaction management in Django 1.8,
|
||||
transaction management commands (e.g. ``transaction.commit()``) are no
|
||||
longer disabled within ``TestCase``.
|
||||
|
||||
``TransactionTestCase`` and ``TestCase`` are identical except for the manner
|
||||
in which the database is reset to a known state and the ability for test code
|
||||
to test the effects of commit and rollback:
|
||||
|
|
@ -759,8 +743,6 @@ additions, including:
|
|||
|
||||
.. classmethod:: TestCase.setUpTestData()
|
||||
|
||||
.. versionadded:: 1.8
|
||||
|
||||
The class-level ``atomic`` block described above allows the creation of
|
||||
initial data at the class level, once for the whole ``TestCase``. This
|
||||
technique allows for faster tests as compared to using ``setUp()``.
|
||||
|
|
@ -1433,11 +1415,9 @@ your test suite.
|
|||
|
||||
The name is a string such as ``'admin/index.html'``.
|
||||
|
||||
.. versionadded:: 1.8
|
||||
|
||||
The count argument is an integer indicating the number of times the
|
||||
template should be rendered. Default is ``None``, meaning that the
|
||||
template should be rendered one or more times.
|
||||
template should be rendered. Default is ``None``, meaning that the template
|
||||
should be rendered one or more times.
|
||||
|
||||
You can use this as a context manager, like this::
|
||||
|
||||
|
|
@ -1562,8 +1542,6 @@ your test suite.
|
|||
|
||||
.. method:: SimpleTestCase.assertJSONNotEqual(raw, expected_data, msg=None)
|
||||
|
||||
.. versionadded:: 1.8
|
||||
|
||||
Asserts that the JSON fragments ``raw`` and ``expected_data`` are *not* equal.
|
||||
See :meth:`~SimpleTestCase.assertJSONEqual` for further details.
|
||||
|
||||
|
|
@ -1724,10 +1702,6 @@ it would under MySQL with MyISAM tables)::
|
|||
# ... conditional test code
|
||||
pass
|
||||
|
||||
.. versionchanged:: 1.8
|
||||
|
||||
``skipIfDBFeature`` can accept multiple feature strings.
|
||||
|
||||
.. function:: skipUnlessDBFeature(*feature_name_strings)
|
||||
|
||||
Skip the decorated test or ``TestCase`` if any of the named database features
|
||||
|
|
@ -1742,7 +1716,3 @@ under MySQL with MyISAM tables)::
|
|||
def test_transaction_behavior(self):
|
||||
# ... conditional test code
|
||||
pass
|
||||
|
||||
.. versionchanged:: 1.8
|
||||
|
||||
``skipUnlessDBFeature`` can accept multiple feature strings.
|
||||
|
|
|
|||
Loading…
Reference in New Issue