mirrors/django
1
0
Fork 0
mirror of https://github.com/django/django.git synced 2025-10-24 22:26:08 +00:00
Code Issues 32 Releases Wiki Activity

Removed versionadded/changed notes for 1.7.

Browse Source
This commit is contained in:
Tim Graham
2015-01-26 15:39:52 -05:00
parent 0e60912492
commit c79faae761
64 changed files with 100 additions and 864 deletions
Download Patch File Download Diff File Expand all files Collapse all files

18
docs/topics/auth/customizing.txt
View File

@@ -436,18 +436,16 @@ different User model.
class Article(models.Model):
author = models.ForeignKey(settings.AUTH_USER_MODEL)
.. versionadded:: 1.7
When connecting to signals sent by the ``User`` model, you should specify
the custom model using the :setting:`AUTH_USER_MODEL` setting. For example::
When connecting to signals sent by the User model, you should specify the
custom model using the :setting:`AUTH_USER_MODEL` setting. For example::
from django.conf import settings
from django.db.models.signals import post_save
from django.conf import settings
from django.db.models.signals import post_save
def post_save_receiver(signal, sender, instance, **kwargs):
pass
def post_save_receiver(signal, sender, instance, **kwargs):
pass
post_save.connect(post_save_receiver, sender=settings.AUTH_USER_MODEL)
post_save.connect(post_save_receiver, sender=settings.AUTH_USER_MODEL)
Generally speaking, you should reference the User model with the
:setting:`AUTH_USER_MODEL` setting in code that is executed at import
@@ -637,8 +635,6 @@ The following methods are available on any subclass of
.. method:: models.AbstractBaseUser.get_session_auth_hash()
.. versionadded:: 1.7
Returns an HMAC of the password field. Used for
:ref:`session-invalidation-on-password-change`.

19
docs/topics/auth/default.txt
View File

@@ -108,8 +108,6 @@ Django also provides :ref:`views <built-in-auth-views>` and :ref:`forms
<built-in-auth-forms>` that may be used to allow users to change their own
passwords.
.. versionadded:: 1.7
Changing a user's password will log out all their sessions if the
:class:`~django.contrib.auth.middleware.SessionAuthenticationMiddleware` is
enabled. See :ref:`session-invalidation-on-password-change` for details.
@@ -560,11 +558,13 @@ The permission_required decorator
def my_view(request):
...
As for the :meth:`~django.contrib.auth.models.User.has_perm` method,
Just like the :meth:`~django.contrib.auth.models.User.has_perm` method,
permission names take the form ``"<app label>.<permission codename>"``
(i.e. ``polls.can_vote`` for a permission on a model in the ``polls``
application).
The decorator may also take a list of permissions.
Note that :func:`~django.contrib.auth.decorators.permission_required()`
also takes an optional ``login_url`` parameter. Example::
@@ -582,11 +582,6 @@ The permission_required decorator
(HTTP Forbidden) view<http_forbidden_view>` instead of redirecting to the
login page.
.. versionchanged:: 1.7
The :func:`~django.contrib.auth.decorators.permission_required`
decorator can take a list of permissions as well as a single permission.
.. _applying-permissions-to-generic-views:
Applying permissions to generic views
@@ -603,8 +598,6 @@ To apply a permission to a :doc:`class-based generic view
Session invalidation on password change
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
.. versionadded:: 1.7
.. warning::
This protection only applies if
@@ -986,10 +979,6 @@ patterns.
for generating a ``text/html`` multipart email with the password reset
link. By default, HTML email is not sent.
.. versionadded:: 1.7
``html_email_template_name`` was added.
.. deprecated:: 1.8
The ``is_admin_site`` argument is deprecated and will be removed in
@@ -1177,8 +1166,6 @@ provides several built-in forms located in :mod:`django.contrib.auth.forms`:
.. method:: confirm_login_allowed(user)
.. versionadded:: 1.7
By default, ``AuthenticationForm`` rejects users whose ``is_active`` flag
is set to ``False``. You may override this behavior with a custom policy to
determine which users can log in. Do this with a custom form that subclasses

27
docs/topics/cache.txt
View File

@@ -206,13 +206,6 @@ If you are using multiple databases, :djadmin:`createcachetable` observes the
Like :djadmin:`migrate`, :djadmin:`createcachetable` won't touch an existing
table. It will only create missing tables.
.. versionchanged:: 1.7
Before Django 1.7, :djadmin:`createcachetable` created one table at a time.
You had to pass the name of the table you wanted to create, and if you were
using multiple databases, you had to use the :djadminopt:`--database`
option. For backwards compatibility, this is still possible.
Multiple databases
~~~~~~~~~~~~~~~~~~
@@ -369,9 +362,6 @@ behavior. These arguments are provided as additional keys in the
* :setting:`TIMEOUT <CACHES-TIMEOUT>`: The default timeout, in
seconds, to use for the cache. This argument defaults to ``300`` seconds (5 minutes).
.. versionadded:: 1.7
You can set ``TIMEOUT`` to ``None`` so that, by default, cache keys never
expire.
@@ -662,12 +652,10 @@ equivalent:
This feature is useful in avoiding repetition in templates. You can set the
timeout in a variable, in one place, and just reuse that value.
.. versionadded:: 1.7
By default, the cache tag will try to use the cache called
"template_fragments". If no such cache exists, it will fall back to using
the default cache. You may select an alternate cache backend to use with
the ``using`` keyword argument, which must be the last argument to the tag.
By default, the cache tag will try to use the cache called "template_fragments".
If no such cache exists, it will fall back to using the default cache. You may
select an alternate cache backend to use with the ``using`` keyword argument,
which must be the last argument to the tag.
.. code-block:: html+django
@@ -719,8 +707,6 @@ Accessing the cache
.. data:: django.core.cache.caches
.. versionadded:: 1.7
You can access the caches configured in the :setting:`CACHES` setting
through a dict-like object: ``django.core.cache.caches``. Repeated
requests for the same alias in the same thread will return the same
@@ -1048,11 +1034,6 @@ produces different content based on some difference in request headers -- such
as a cookie, or a language, or a user-agent -- you'll need to use the ``Vary``
header to tell caching mechanisms that the page output depends on those things.
.. versionchanged:: 1.7
Cache keys use the request's fully-qualified URL rather than just the path
and query string.
To do this in Django, use the convenient
:func:`django.views.decorators.vary.vary_on_headers` view decorator, like so::

2
docs/topics/checks.txt
View File

@@ -2,8 +2,6 @@
System check framework
======================
.. versionadded:: 1.7
.. module:: django.core.checks
The system check framework is a set of static checks for validating Django

2
docs/topics/db/managers.txt
View File

@@ -242,8 +242,6 @@ the manager ``Person.people``.
Creating ``Manager`` with ``QuerySet`` methods
----------------------------------------------
.. versionadded:: 1.7
In lieu of the above approach which requires duplicating methods on both the
``QuerySet`` and the ``Manager``, :meth:`QuerySet.as_manager()
<django.db.models.query.QuerySet.as_manager>` can be used to create an instance

44
docs/topics/db/models.txt
View File

@@ -477,12 +477,6 @@ There are a few restrictions on the intermediate model:
:attr:`symmetrical=False <ManyToManyField.symmetrical>` (see
:ref:`the model field reference <manytomany-arguments>`).
.. versionchanged:: 1.7
In Django 1.6 and earlier, intermediate models containing more than one
foreign key to any of the models involved in the many-to-many relationship
used to be prohibited.
Now that you have set up your :class:`~django.db.models.ManyToManyField` to use
your intermediary model (``Membership``, in this case), you're ready to start
creating some many-to-many relationships. You do this by creating instances of
@@ -1303,41 +1297,9 @@ inheritance hierarchies as simple and straightforward as possible so that you
won't have to struggle to work out where a particular piece of information is
coming from.
.. versionchanged:: 1.7
Before Django 1.7, inheriting from multiple models that had an ``id`` primary
key field did not raise an error, but could result in data loss. For example,
consider these models (which no longer validate due to the clashing ``id``
fields)::
class Article(models.Model):
headline = models.CharField(max_length=50)
body = models.TextField()
class Book(models.Model):
title = models.CharField(max_length=50)
class BookReview(Book, Article):
pass
This snippet demonstrates how creating a child object overwrote the value of a
previously created parent object::
>>> article = Article.objects.create(headline='Some piece of news.')
>>> review = BookReview.objects.create(
... headline='Review of Little Red Riding Hood.',
... title='Little Red Riding Hood')
>>>
>>> assert Article.objects.get(pk=article.pk).headline == article.headline
Traceback (most recent call last):
File "<console>", line 1, in <module>
AssertionError
>>> # the "Some piece of news." headline has been overwritten.
>>> Article.objects.get(pk=article.pk).headline
'Review of Little Red Riding Hood.'
To properly use multiple inheritance, you can use an explicit
:class:`~django.db.models.AutoField` in the base models::
Note that inheriting from multiple models that have a common ``id`` primary
key field will raise an error. To properly use multiple inheritance, you can
use an explicit :class:`~django.db.models.AutoField` in the base models::
class Article(models.Model):
article_id = models.AutoField(primary_key=True)

6
docs/topics/db/queries.txt
View File

@@ -618,10 +618,6 @@ and with other ``F()`` objects. To find all the blog entries with more than
>>> Entry.objects.filter(n_comments__gt=F('n_pingbacks') * 2)
.. versionadded:: 1.7
The power operator ``**`` was added.
To find all the entries where the rating of the entry is less than the
sum of the pingback count and comment count, we would issue the
query::
@@ -1149,8 +1145,6 @@ above example code would look like this::
Using a custom reverse manager
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
.. versionadded:: 1.7
By default the :class:`~django.db.models.fields.related.RelatedManager` used
for reverse relations is a subclass of the :ref:`default manager <manager-names>`
for that model. If you would like to specify a different manager for a given

10
docs/topics/db/sql.txt
View File

@@ -314,16 +314,6 @@ Also note that Django expects the ``"%s"`` placeholder, *not* the ``"?"``
placeholder, which is used by the SQLite Python bindings. This is for the sake
of consistency and sanity.
.. versionchanged:: 1.7
:pep:`249` does not state whether a cursor should be usable as a context
manager. Prior to Python 2.7, a cursor was usable as a context manager due
an unexpected behavior in magic method lookups (`Python ticket #9220`_).
Django 1.7 explicitly added support to allow using a cursor as context
manager.
.. _`Python ticket #9220`: https://bugs.python.org/issue9220
Using a cursor as a context manager::
with connection.cursor() as c:

28
docs/topics/email.txt
View File

@@ -74,10 +74,6 @@ are required.
The return value will be the number of successfully delivered messages (which
can be ``0`` or ``1`` since it can only send one message).
.. versionadded:: 1.7
The ``html_message`` parameter was added.
send_mass_mail()
================
@@ -333,17 +329,15 @@ The class has the following methods:
message.attach('design.png', img_data, 'image/png')
.. versionchanged:: 1.7
If you specify a ``mimetype`` of ``message/rfc822``, it will also accept
:class:`django.core.mail.EmailMessage` and :py:class:`email.message.Message`.
If you specify a ``mimetype`` of ``message/rfc822``, it will also accept
:class:`django.core.mail.EmailMessage` and :py:class:`email.message.Message`.
In addition, ``message/rfc822`` attachments will no longer be
base64-encoded in violation of :rfc:`2046#section-5.2.1`, which can cause
issues with displaying the attachments in `Evolution`__ and `Thunderbird`__.
In addition, ``message/rfc822`` attachments will no longer be
base64-encoded in violation of :rfc:`2046#section-5.2.1`, which can cause
issues with displaying the attachments in `Evolution`__ and `Thunderbird`__.
__ https://bugzilla.gnome.org/show_bug.cgi?id=651197
__ https://bugzilla.mozilla.org/show_bug.cgi?id=333880
__ https://bugzilla.gnome.org/show_bug.cgi?id=651197
__ https://bugzilla.mozilla.org/show_bug.cgi?id=333880
* ``attach_file()`` creates a new attachment using a file from your
filesystem. Call it with the path of the file to attach and, optionally,
@@ -468,12 +462,8 @@ SMTP backend
EMAIL_BACKEND = 'django.core.mail.backends.smtp.EmailBackend'
.. versionadded:: 1.7
The ``timeout`` parameter was added. If unspecified, the default
``timeout`` will be the one provided by
:func:`socket.getdefaulttimeout()`, which defaults to ``None`` (no
timeout).
If unspecified, the default ``timeout`` will be the one provided by
:func:`socket.getdefaulttimeout()`, which defaults to ``None`` (no timeout).
.. versionchanged:: 1.8

37
docs/topics/forms/formsets.txt
View File

@@ -343,8 +343,6 @@ excessive.
``validate_min``
~~~~~~~~~~~~~~~~
.. versionadded:: 1.7
If ``validate_min=True`` is passed to
:func:`~django.forms.formsets.formset_factory`, validation will also check
that the number of forms in the data set, minus those marked for
@@ -371,11 +369,6 @@ deletion, is greater than or equal to ``min_num``.
>>> formset.non_form_errors()
['Please submit 3 or more forms.']
.. versionchanged:: 1.7
The ``min_num`` and ``validate_min`` parameters were added to
:func:`~django.forms.formsets.formset_factory`.
Dealing with ordering and deletion of forms
-------------------------------------------
@@ -502,29 +495,15 @@ If you are using a :class:`ModelFormSet<django.forms.models.BaseModelFormSet>`,
model instances for deleted forms will be deleted when you call
``formset.save()``.
.. versionchanged:: 1.7
If you call ``formset.save(commit=False)``, objects will not be deleted
automatically. You'll need to call ``delete()`` on each of the
:attr:`formset.deleted_objects
<django.forms.models.BaseModelFormSet.deleted_objects>` to actually delete
them::
If you call ``formset.save(commit=False)``, objects will not be deleted
automatically. You'll need to call ``delete()`` on each of the
:attr:`formset.deleted_objects
<django.forms.models.BaseModelFormSet.deleted_objects>` to actually delete
them::
>>> instances = formset.save(commit=False)
>>> for obj in formset.deleted_objects:
... obj.delete()
If you want to maintain backwards compatibility with Django 1.6 and earlier,
you can do something like this::
>>> try:
>>> # For Django 1.7+
>>> for obj in formset.deleted_objects:
>>> obj.delete()
>>> except AssertionError:
>>> # Django 1.6 and earlier already deletes the objects, trying to
>>> # delete them a second time raises an AssertionError.
>>> pass
>>> instances = formset.save(commit=False)
>>> for obj in formset.deleted_objects:
... obj.delete()
On the other hand, if you are using a plain ``FormSet``, it's up to you to
handle ``formset.deleted_forms``, perhaps in your formset's ``save()`` method,

6
docs/topics/forms/modelforms.txt
View File

@@ -275,8 +275,6 @@ Error messages defined on :attr:`model fields
<validating-objects>` step and no corresponding error messages are defined at
the form level.
.. versionadded:: 1.7
You can override the error messages from ``NON_FIELD_ERRORS`` raised by model
validation by adding the :data:`~django.core.exceptions.NON_FIELD_ERRORS` key
to the ``error_messages`` dictionary of the ``ModelForm``’s inner ``Meta`` class::
@@ -656,15 +654,11 @@ There are a couple of things to note, however.
used. This means the child's ``Meta``, if it exists, otherwise the
``Meta`` of the first parent, etc.
.. versionchanged:: 1.7
* It's possible to inherit from both ``Form`` and ``ModelForm`` simultaneously,
however, you must ensure that ``ModelForm`` appears first in the MRO. This is
because these classes rely on different metaclasses and a class can only have
one metaclass.
.. versionadded:: 1.7
* It's possible to declaratively remove a ``Field`` inherited from a parent class by
setting the name to be ``None`` on the subclass.

5
docs/topics/http/sessions.txt
View File

@@ -95,11 +95,6 @@ session data be expunged from time to time, the ``cache`` backend is for you.
If you use the ``cached_db`` session backend, you also need to follow the
configuration instructions for the `using database-backed sessions`_.
.. versionchanged:: 1.7
Before version 1.7, the ``cached_db`` backend always used the ``default``
cache rather than the :setting:`SESSION_CACHE_ALIAS`.
Using file-based sessions
-------------------------

12
docs/topics/http/shortcuts.txt
View File

@@ -77,10 +77,6 @@ Optional arguments
The ``current_app`` argument is deprecated. Instead you should set
``request.current_app``.
.. versionchanged:: 1.7
The ``dirs`` parameter was added.
.. deprecated:: 1.8
The ``dirs`` parameter was deprecated.
@@ -167,10 +163,6 @@ Optional arguments
The ``status`` parameter was added.
.. versionchanged:: 1.7
The ``dirs`` parameter was added.
.. deprecated:: 1.8
The ``dirs`` parameter was deprecated.
@@ -223,10 +215,6 @@ This example is equivalent to::
By default issues a temporary redirect; pass ``permanent=True`` to issue a
permanent redirect.
.. versionchanged:: 1.7
The ability to use relative URLs was added.
Examples
--------

31
docs/topics/i18n/translation.txt
View File

@@ -699,11 +699,6 @@ will result in the entry ``"First sentence. Second paragraph."`` in the PO file,
compared to ``"\n First sentence.\n Second sentence.\n"``, if the ``trimmed``
option had not been specified.
.. versionchanged:: 1.7
The ``trimmed`` option was added.
String literals passed to tags and filters
------------------------------------------
@@ -1275,16 +1270,13 @@ is configured correctly). It creates (or updates) a message file in the
directory ``locale/LANG/LC_MESSAGES``. In the ``de`` example, the file will be
``locale/de/LC_MESSAGES/django.po``.
.. versionchanged:: 1.7
When you run ``makemessages`` from the root directory of your project, the
extracted strings will be automatically distributed to the proper message
files. That is, a string extracted from a file of an app containing a
``locale`` directory will go in a message file under that directory.
A string extracted from a file of an app without any ``locale`` directory
will either go in a message file under the directory listed first in
:setting:`LOCALE_PATHS` or will generate an error if :setting:`LOCALE_PATHS`
is empty.
When you run ``makemessages`` from the root directory of your project, the
extracted strings will be automatically distributed to the proper message files.
That is, a string extracted from a file of an app containing a ``locale``
directory will go in a message file under that directory. A string extracted
from a file of an app without any ``locale`` directory will either go in a
message file under the directory listed first in :setting:`LOCALE_PATHS` or
will generate an error if :setting:`LOCALE_PATHS` is empty.
By default :djadmin:`django-admin makemessages <makemessages>` examines every
file that has the ``.html`` or ``.txt`` file extension. In case you want to
@@ -1627,14 +1619,10 @@ Language cookie
A number of settings can be used to adjust language cookie options:
* :setting:`LANGUAGE_COOKIE_NAME`
.. versionadded:: 1.7
* :setting:`LANGUAGE_COOKIE_AGE`
* :setting:`LANGUAGE_COOKIE_DOMAIN`
* :setting:`LANGUAGE_COOKIE_PATH`
Implementation notes
====================
@@ -1716,11 +1704,6 @@ following this algorithm:
* Failing that, it looks for the :data:`~django.utils.translation.LANGUAGE_SESSION_KEY`
key in the current user's session.
.. versionchanged:: 1.7
In previous versions, the key was named ``django_language``, and the
``LANGUAGE_SESSION_KEY`` constant did not exist.
* Failing that, it looks for a cookie.
The name of the cookie used is set by the :setting:`LANGUAGE_COOKIE_NAME`

2
docs/topics/logging.txt
View File

@@ -498,8 +498,6 @@ specific logger following this example:
``django.db.backends.schema``
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
.. versionadded:: 1.7
Logs the SQL queries that are executed during schema changes to the database by
the :doc:`migrations framework </topics/migrations>`. Note that it won't log the
queries executed by :class:`~django.db.migrations.operations.RunPython`.

6
docs/topics/migrations.txt
View File

@@ -5,8 +5,6 @@ Migrations
.. module:: django.db.migrations
:synopsis: Schema migration support for Django models
.. versionadded:: 1.7
Migrations are Django's way of propagating changes you make to your models
(adding a field, deleting a model, etc.) into your database schema. They're
designed to be mostly automatic, but you'll need to know when to make
@@ -663,10 +661,6 @@ Django can serialize the following:
- Any class reference (must be in module's top-level scope)
- Anything with a custom ``deconstruct()`` method (:ref:`see below <custom-deconstruct-method>`)
.. versionchanged:: 1.7.1
Support for serializing timezone-aware datetimes was added.
Django can serialize the following on Python 3 only:
- Unbound methods used from within the class body (see below)

2
docs/topics/serialization.txt
View File

@@ -405,8 +405,6 @@ into the primary key of an actual ``Person`` object.
fields will be effectively unique, you can still use those fields
as a natural key.
.. versionadded:: 1.7
Deserialization of objects with no primary key will always check whether the
model's manager has a ``get_by_natural_key()`` method and if so, use it to
populate the deserialized object's primary key.

6
docs/topics/signals.txt
View File

@@ -140,12 +140,6 @@ Now, our ``my_callback`` function will be called each time a request finishes.
decorator, simply import the ``signals`` submodule inside
:meth:`~django.apps.AppConfig.ready`.
.. versionchanged:: 1.7
Since :meth:`~django.apps.AppConfig.ready` didn't exist in previous
versions of Django, signal registration usually happened in the
``models`` module.
.. note::
The :meth:`~django.apps.AppConfig.ready` method may be executed more than

8
docs/topics/templates.txt
View File

@@ -115,10 +115,6 @@ The ``django.template.loader`` module defines two functions to load templates.
If you want to restrict the search to a particular template engine, pass
the engine's :setting:`NAME <TEMPLATES-NAME>` in the ``using`` argument.
.. versionchanged:: 1.7
The ``dirs`` parameter was added.
.. deprecated:: 1.8
The ``dirs`` parameter was deprecated.
@@ -138,10 +134,6 @@ The ``django.template.loader`` module defines two functions to load templates.
list of template names. It tries each name in order and returns the first
template that exists.
.. versionchanged:: 1.7
The ``dirs`` parameter was added.
.. deprecated:: 1.8
The ``dirs`` parameter was deprecated.

16
docs/topics/testing/advanced.txt
View File

@@ -414,16 +414,12 @@ Attributes
.. attribute:: DiscoverRunner.test_suite
.. versionadded:: 1.7
The class used to build the test suite. By default it is set to
``unittest.TestSuite``. This can be overridden if you wish to implement
different logic for collecting tests.
.. attribute:: DiscoverRunner.test_runner
.. versionadded:: 1.7
This is the class of the low-level test runner which is used to execute
the individual tests and format the results. By default it is set to
``unittest.TextTestRunner``. Despite the unfortunate similarity in
@@ -594,11 +590,9 @@ can be useful during testing.
``False`` to speed up creation time if you don't have any test classes
with :ref:`serialized_rollback=True <test-case-serialized-rollback>`.
.. versionadded:: 1.7.1
If you are using the default test runner, you can control this with the
the :setting:`SERIALIZE <TEST_SERIALIZE>` entry in the
:setting:`TEST <DATABASE-TEST>` dictionary
If you are using the default test runner, you can control this with the
the :setting:`SERIALIZE <TEST_SERIALIZE>` entry in the :setting:`TEST
<DATABASE-TEST>` dictionary.
``keepdb`` determines if the test run should use an existing
database, or create a new one. If ``True``, the existing
@@ -612,10 +606,6 @@ can be useful during testing.
:setting:`NAME` in :setting:`DATABASES` to match the name of the test
database.
.. versionchanged:: 1.7
The ``serialize`` argument was added.
.. versionchanged:: 1.8
The ``keepdb`` argument was added.

18
docs/topics/testing/overview.txt
View File

@@ -152,10 +152,8 @@ entirely!). If you want to use a different database name, specify
:setting:`NAME <TEST_NAME>` in the :setting:`TEST <DATABASE-TEST>`
dictionary for any given database in :setting:`DATABASES`.
.. versionchanged:: 1.7
On PostgreSQL, :setting:`USER` will also need read access to the built-in
``postgres`` database.
On PostgreSQL, :setting:`USER` will also need read access to the built-in
``postgres`` database.
Aside from using a separate database, the test runner will otherwise
use all of the same database settings you have in your settings file:
@@ -175,12 +173,6 @@ If using a SQLite in-memory database with Python 3.4+ and SQLite 3.7.13+,
`shared cache <https://www.sqlite.org/sharedcache.html>`_ will be enabled, so
you can write tests with ability to share the database between threads.
.. versionchanged:: 1.7
The different options in the :setting:`TEST <DATABASE-TEST>` database
setting used to be separate options in the database settings dictionary,
prefixed with ``TEST_``.
.. versionadded:: 1.8
The ability to use SQLite with a shared cache as described above was added.
@@ -194,10 +186,8 @@ you can write tests with ability to share the database between threads.
your tests. *It is a bad idea to have such import-time database queries in
your code* anyway - rewrite your code so that it doesn't do this.
.. versionadded:: 1.7
This also applies to customized implementations of
:meth:`~django.apps.AppConfig.ready()`.
This also applies to customized implementations of
:meth:`~django.apps.AppConfig.ready()`.
.. seealso::

60
docs/topics/testing/tools.txt
View File

@@ -130,10 +130,6 @@ Use the ``django.test.Client`` class to make requests.
.. method:: Client.get(path, data=None, follow=False, secure=False, **extra)
.. versionadded:: 1.7
The ``secure`` argument was added.
Makes a GET request on the provided ``path`` and returns a ``Response``
object, which is documented below.
@@ -435,8 +431,6 @@ Specifically, a ``Response`` object has the following attributes:
.. attribute:: wsgi_request
.. versionadded:: 1.7
The ``WSGIRequest`` instance generated by the test handler that
generated the response.
@@ -845,25 +839,15 @@ out the `full reference`_ for more details.
.. _full reference: http://selenium-python.readthedocs.org/en/latest/api.html
.. _Firefox: http://www.mozilla.com/firefox/
.. versionchanged:: 1.7
.. tip::
Before Django 1.7 ``LiveServerTestCase`` used to rely on the
:doc:`staticfiles contrib app </howto/static-files/index>` to get the
static assets of the application(s) under test transparently served at their
expected locations during the execution of these tests.
In Django 1.7 this dependency of core functionality on a ``contrib``
application has been removed, because of which ``LiveServerTestCase``
ability in this respect has been retrofitted to simply publish the contents
of the file system under :setting:`STATIC_ROOT` at the :setting:`STATIC_URL`
URL.
If you use the ``staticfiles`` app in your project and need to perform live
testing then you might want to consider using the
If you use the :mod:`~django.contrib.staticfiles` app in your project and
need to perform live testing, then you might want to use the
:class:`~django.contrib.staticfiles.testing.StaticLiveServerTestCase`
subclass shipped with it instead because it's the one that implements the
original behavior now. See :ref:`the relevant documentation
<staticfiles-testing-support>` for more details.
subclass which transparently serves all the assets during execution of
its tests in a way very similar to what we get at development time with
``DEBUG=True``, i.e. without having to collect them using
:djadmin:`collectstatic`.
.. note::
@@ -1135,8 +1119,6 @@ in the ``with`` block and reset its value to the previous state afterwards.
.. method:: SimpleTestCase.modify_settings()
.. versionadded:: 1.7
It can prove unwieldy to redefine settings that contain a list of values. In
practice, adding or removing values is often sufficient. The
:meth:`~django.test.SimpleTestCase.modify_settings` context manager makes it
@@ -1189,14 +1171,8 @@ The decorator can also be applied to :class:`~django.test.TestCase` classes::
response = self.client.get('/sekrit/')
self.assertRedirects(response, '/other/login/?next=/sekrit/')
.. versionchanged:: 1.7
Previously, ``override_settings`` was imported from ``django.test.utils``.
.. function:: modify_settings
.. versionadded:: 1.7
Likewise, Django provides the :func:`~django.test.modify_settings`
decorator::
@@ -1265,11 +1241,6 @@ have been overridden, like this::
del settings.LOGIN_URL
...
.. versionchanged:: 1.7
Previously, you could only simulate the deletion of a setting which was
explicitly overridden.
When overriding settings, make sure to handle the cases in which your app's
code uses a cache or similar feature that retains state even if the setting is
changed. Django provides the :data:`django.test.signals.setting_changed`
@@ -1445,14 +1416,10 @@ your test suite.
host (for example, initializing the test client with
``Client(HTTP_HOST="testhost")``.
.. versionadded:: 1.7
If ``fetch_redirect_response`` is ``False``, the final page won't be
loaded. Since the test client can't fetch externals URLs, this is
particularly useful if ``expected_url`` isn't part of your Django app.
.. versionadded:: 1.7
Scheme is handled correctly when making comparisons between two URLs. If
there isn't any scheme specified in the location where we are redirected to,
the original request's scheme is used. If present, the scheme in
@@ -1564,11 +1531,6 @@ your test suite.
Output in case of error can be customized with the ``msg`` argument.
.. versionchanged:: 1.7
The method now accepts a ``msg`` parameter to allow customization of
error message
.. method:: TransactionTestCase.assertNumQueries(num, func, *args, **kwargs)
Asserts that when ``func`` is called with ``*args`` and ``**kwargs`` that
@@ -1705,10 +1667,6 @@ it would under MySQL with MyISAM tables)::
def test_transaction_behavior(self):
# ... conditional test code
.. versionchanged:: 1.7
``skipIfDBFeature`` can now be used to decorate a ``TestCase`` class.
.. versionchanged:: 1.8
``skipIfDBFeature`` can accept multiple feature strings.
@@ -1727,10 +1685,6 @@ under MySQL with MyISAM tables)::
def test_transaction_behavior(self):
# ... conditional test code
.. versionchanged:: 1.7
``skipUnlessDBFeature`` can now be used to decorate a ``TestCase`` class.
.. versionchanged:: 1.8
``skipUnlessDBFeature`` can accept multiple feature strings.