mirror of
https://github.com/django/django.git
synced 2024-12-23 09:36:06 +00:00
4fdd51b732
Requests made with django.test.Client.login() and logout() respect defaults defined in django.test.Client instantiation and are processed through middleware. Thanks to Loic for the reviews.
778 lines
33 KiB
Plaintext
778 lines
33 KiB
Plaintext
============================================
|
||
Django 1.7 release notes - UNDER DEVELOPMENT
|
||
============================================
|
||
|
||
Welcome to Django 1.7!
|
||
|
||
These release notes cover the `new features`_, as well as some `backwards
|
||
incompatible changes`_ you'll want to be aware of when upgrading from Django
|
||
1.6 or older versions. We've also dropped some features, which are detailed in
|
||
:doc:`our deprecation plan </internals/deprecation>`, and we've `begun the
|
||
deprecation process for some features`_.
|
||
|
||
.. _`new features`: `What's new in Django 1.7`_
|
||
.. _`backwards incompatible changes`: `Backwards incompatible changes in 1.7`_
|
||
.. _`begun the deprecation process for some features`: `Features deprecated in 1.7`_
|
||
|
||
Python compatibility
|
||
====================
|
||
|
||
Django 1.7 requires Python 2.7 or above, though we **highly recommend**
|
||
the latest minor release. Support for Python 2.6 has been dropped.
|
||
|
||
This change should affect only a small number of Django users, as most
|
||
operating-system vendors today are shipping Python 2.7 or newer as their default
|
||
version. If you're still using Python 2.6, however, you'll need to stick to
|
||
Django 1.6 until you can upgrade your Python version. Per :doc:`our support
|
||
policy </internals/release-process>`, Django 1.6 will continue to receive
|
||
security support until the release of Django 1.8.
|
||
|
||
What's new in Django 1.7
|
||
========================
|
||
|
||
Schema migrations
|
||
~~~~~~~~~~~~~~~~~
|
||
|
||
Django now has built-in support for schema migrations. It allows models
|
||
to be updated, changed, and deleted by creating migration files that represent
|
||
the model changes and which can be run on any development, staging or production
|
||
database.
|
||
|
||
Migrations are covered in :doc:`their own documentation</topics/migrations>`,
|
||
but a few of the key features are:
|
||
|
||
* ``syncdb`` has been deprecated and replaced by ``migrate``. Don't worry -
|
||
calls to ``syncdb`` will still work as before.
|
||
|
||
* A new ``makemigrations`` command provides an easy way to autodetect changes
|
||
to your models and make migrations for them.
|
||
|
||
* :data:`~django.db.models.signals.pre_syncdb` and
|
||
:data:`~django.db.models.signals.post_syncdb` have been renamed to
|
||
:data:`~django.db.models.signals.pre_migrate` and
|
||
:data:`~django.db.models.signals.post_migrate` respectively. The
|
||
``create_models``/``created_models`` argument has also been deprecated.
|
||
|
||
* The ``allow_syncdb`` method on database routers is now called ``allow_migrate``,
|
||
but still performs the same function. Routers with ``allow_syncdb`` methods
|
||
will still work, but that method name is deprecated and you should change
|
||
it as soon as possible (nothing more than renaming is required).
|
||
|
||
New method on Field subclasses
|
||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||
|
||
To help power both schema migrations and composite keys, the :class:`~django.db.models.Field` API now
|
||
has a new required method: ``deconstruct()``.
|
||
|
||
This method takes no arguments, and returns a tuple of four items:
|
||
|
||
* ``name``: The field's attribute name on its parent model, or None if it is not part of a model
|
||
* ``path``: A dotted, Python path to the class of this field, including the class name.
|
||
* ``args``: Positional arguments, as a list
|
||
* ``kwargs``: Keyword arguments, as a dict
|
||
|
||
These four values allow any field to be serialized into a file, as well as
|
||
allowing the field to be copied safely, both essential parts of these new features.
|
||
|
||
This change should not affect you unless you write custom Field subclasses;
|
||
if you do, you may need to reimplement the ``deconstruct()`` method if your
|
||
subclass changes the method signature of ``__init__`` in any way. If your
|
||
field just inherits from a built-in Django field and doesn't override ``__init__``,
|
||
no changes are necessary.
|
||
|
||
If you do need to override ``deconstruct()``, a good place to start is the
|
||
built-in Django fields (``django/db/models/fields/__init__.py``) as several
|
||
fields, including ``DecimalField`` and ``DateField``, override it and show how
|
||
to call the method on the superclass and simply add or remove extra arguments.
|
||
|
||
Calling custom ``QuerySet`` methods from the ``Manager``
|
||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||
|
||
The :meth:`QuerySet.as_manager() <django.db.models.query.QuerySet.as_manager>`
|
||
class method has been added to :ref:`create Manager with QuerySet methods
|
||
<create-manager-with-queryset-methods>`.
|
||
|
||
Using a custom manager when traversing reverse relations
|
||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||
|
||
It is now possible to :ref:`specify a custom manager
|
||
<using-custom-reverse-manager>` when traversing a reverse relationship.
|
||
|
||
New ``Prefetch`` object for advanced ``prefetch_related`` operations.
|
||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||
|
||
The new :class:`~django.db.models.Prefetch` object allows customizing
|
||
prefetch operations.
|
||
|
||
You can specify the ``QuerySet`` used to traverse a given relation
|
||
or customize the storage location of prefetch results.
|
||
|
||
This enables things like filtering prefetched relations, calling
|
||
:meth:`~django.db.models.query.QuerySet.select_related()` from a prefetched
|
||
relation, or prefetching the same relation multiple times with different
|
||
querysets. See :meth:`~django.db.models.query.QuerySet.prefetch_related()`
|
||
for more details.
|
||
|
||
Admin shortcuts support time zones
|
||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||
|
||
The "today" and "now" shortcuts next to date and time input widgets in the
|
||
admin are now operating in the :ref:`current time zone
|
||
<default-current-time-zone>`. Previously, they used the browser time zone,
|
||
which could result in saving the wrong value when it didn't match the current
|
||
time zone on the server.
|
||
|
||
In addition, the widgets now display a help message when the browser and
|
||
server time zone are different, to clarify how the value inserted in the field
|
||
will be interpreted.
|
||
|
||
Using database cursors as context managers
|
||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||
|
||
Prior to Python 2.7, database cursors could be used as a context manager. The
|
||
specific backend's cursor defined the behavior of the context manager. The
|
||
behavior of magic method lookups was changed with Python 2.7 and cursors were
|
||
no longer usable as context managers.
|
||
|
||
Django 1.7 allows a cursor to be used as a context manager that is a shortcut
|
||
for the following, instead of backend specific behavior.
|
||
|
||
.. code-block:: python
|
||
|
||
c = connection.cursor()
|
||
try:
|
||
c.execute(...)
|
||
finally:
|
||
c.close()
|
||
|
||
Minor features
|
||
~~~~~~~~~~~~~~
|
||
|
||
:mod:`django.contrib.admin`
|
||
^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||
|
||
* You can now implement :attr:`~django.contrib.admin.AdminSite.site_header`,
|
||
:attr:`~django.contrib.admin.AdminSite.site_title`, and
|
||
:attr:`~django.contrib.admin.AdminSite.index_title` attributes on a custom
|
||
:class:`~django.contrib.admin.AdminSite` in order to easily change the admin
|
||
site's page title and header text. No more needing to override templates!
|
||
|
||
* Buttons in :mod:`django.contrib.admin` now use the ``border-radius`` CSS
|
||
property for rounded corners rather than GIF background images.
|
||
|
||
* Some admin templates now have ``app-<app_name>`` and ``model-<model_name>``
|
||
classes in their ``<body>`` tag to allow customizing the CSS per app or per
|
||
model.
|
||
|
||
* The admin changelist cells now have a ``field-<field_name>`` class in the
|
||
HTML to enable style customizations.
|
||
|
||
* The admin's search fields can now be customized per-request thanks to the new
|
||
:meth:`django.contrib.admin.ModelAdmin.get_search_fields` method.
|
||
|
||
* The :meth:`ModelAdmin.get_fields()
|
||
<django.contrib.admin.ModelAdmin.get_fields>` method may be overridden to
|
||
customize the value of :attr:`ModelAdmin.fields
|
||
<django.contrib.admin.ModelAdmin.fields>`.
|
||
|
||
* In addition to the existing ``admin.site.register`` syntax, you can use the
|
||
new :func:`~django.contrib.admin.register` decorator to register a
|
||
:class:`~django.contrib.admin.ModelAdmin`.
|
||
|
||
* You may specify :meth:`ModelAdmin.list_display_links
|
||
<django.contrib.admin.ModelAdmin.list_display_links>` ``= None`` to disable
|
||
links on the change list page grid.
|
||
|
||
* You may now specify :attr:`ModelAdmin.view_on_site
|
||
<django.contrib.admin.ModelAdmin.view_on_site>` to control whether or not to
|
||
display the "View on site" link.
|
||
|
||
:mod:`django.contrib.auth`
|
||
^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||
|
||
* Any ``**kwargs`` passed to
|
||
:meth:`~django.contrib.auth.models.User.email_user()` are passed to the
|
||
underlying :meth:`~django.core.mail.send_mail()` call.
|
||
|
||
* The :func:`~django.contrib.auth.decorators.permission_required` decorator can
|
||
take a list of permissions as well as a single permission.
|
||
|
||
* You can override the new :meth:`AuthenticationForm.confirm_login_allowed()
|
||
<django.contrib.auth.forms.AuthenticationForm.confirm_login_allowed>` method
|
||
to more easily customize the login policy.
|
||
|
||
* :func:`django.contrib.auth.views.password_reset` takes an optional
|
||
``html_email_template_name`` parameter used to send a multipart HTML email
|
||
for password resets.
|
||
|
||
:mod:`django.contrib.gis`
|
||
^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||
|
||
* The default OpenLayers library version included in widgets has been updated
|
||
from 2.11 to 2.13.
|
||
|
||
:mod:`django.contrib.messages`
|
||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||
|
||
* The backends for :mod:`django.contrib.messages` that use cookies, will now
|
||
follow the :setting:`SESSION_COOKIE_SECURE` and
|
||
:setting:`SESSION_COOKIE_HTTPONLY` settings.
|
||
|
||
* The :ref:`messages context processor <message-displaying>` now adds a
|
||
dictionary of default levels under the name ``DEFAULT_MESSAGE_LEVELS``.
|
||
|
||
* :class:`~django.contrib.messages.storage.base.Message` objects now have a
|
||
``level_tag`` attribute that contains the string representation of the
|
||
message level.
|
||
|
||
:mod:`django.contrib.redirects`
|
||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||
|
||
* :class:`~django.contrib.redirects.middleware.RedirectFallbackMiddleware`
|
||
has two new attributes
|
||
(:attr:`~django.contrib.redirects.middleware.RedirectFallbackMiddleware.response_gone_class`
|
||
and
|
||
:attr:`~django.contrib.redirects.middleware.RedirectFallbackMiddleware.response_redirect_class`)
|
||
that specify the types of :class:`~django.http.HttpResponse` instances the
|
||
middleware returns.
|
||
|
||
:mod:`django.contrib.sessions`
|
||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||
|
||
* The ``"django.contrib.sessions.backends.cached_db"`` session backend now
|
||
respects :setting:`SESSION_CACHE_ALIAS`. In previous versions, it always used
|
||
the `default` cache.
|
||
|
||
:mod:`django.contrib.sitemaps`
|
||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||
|
||
* The :mod:`sitemap framework<django.contrib.sitemaps>` now makes use of
|
||
:attr:`~django.contrib.sitemaps.Sitemap.lastmod` to set a ``Last-Modified``
|
||
header in the response. This makes it possible for the
|
||
:class:`~django.middleware.http.ConditionalGetMiddleware` to handle
|
||
conditional ``GET`` requests for sitemaps which set ``lastmod``.
|
||
|
||
:mod:`django.contrib.staticfiles`
|
||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||
|
||
* The :ref:`static files storage classes <staticfiles-storages>` may be
|
||
subclassed to override the permissions that collected static files receive by
|
||
setting the
|
||
:attr:`~django.core.files.storage.FileSystemStorage.file_permissions_mode`
|
||
parameter. See :djadmin:`collectstatic` for example usage.
|
||
|
||
:mod:`django.contrib.syndication`
|
||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||
|
||
* The :class:`~django.utils.feedgenerator.Atom1Feed` syndication feed's
|
||
``updated`` element now utilizes ``updateddate`` instead of ``pubdate``,
|
||
allowing the ``published`` element to be included in the feed (which
|
||
relies on ``pubdate``).
|
||
|
||
Email
|
||
^^^^^
|
||
|
||
* :func:`~django.core.mail.send_mail` now accepts an ``html_message``
|
||
parameter for sending a multipart ``text/plain`` and ``text/html`` email.
|
||
* The SMTP :class:`~django.core.mail.backends.smtp.EmailBackend` now accepts a
|
||
:attr:`~django.core.mail.backends.smtp.EmailBackend.timeout` parameter.
|
||
|
||
File Uploads
|
||
^^^^^^^^^^^^
|
||
|
||
* The new :attr:`UploadedFile.content_type_extra
|
||
<django.core.files.uploadedfile.UploadedFile.content_type_extra>` attribute
|
||
contains extra parameters passed to the ``content-type`` header on a file
|
||
upload.
|
||
|
||
* The new :setting:`FILE_UPLOAD_DIRECTORY_PERMISSIONS` setting controls
|
||
the file system permissions of directories created during file upload, like
|
||
:setting:`FILE_UPLOAD_PERMISSIONS` does for the files themselves.
|
||
|
||
* The :attr:`FileField.upload_to <django.db.models.FileField.upload_to>`
|
||
attribute is now optional. If it is omitted or given ``None`` or an empty
|
||
string, a subdirectory won't be used for storing the uploaded files.
|
||
|
||
Forms
|
||
^^^^^
|
||
|
||
* The ``<label>`` and ``<input>`` tags rendered by
|
||
:class:`~django.forms.RadioSelect` and
|
||
:class:`~django.forms.CheckboxSelectMultiple` when looping over the radio
|
||
buttons or checkboxes now include ``for`` and ``id`` attributes, respectively.
|
||
Each radio button or checkbox includes an ``id_for_label`` attribute to
|
||
output the element's ID.
|
||
|
||
* :attr:`Field.choices<django.db.models.Field.choices>` now allows you to
|
||
customize the "empty choice" label by including a tuple with an empty string
|
||
or ``None`` for the key and the custom label as the value. The default blank
|
||
option ``"----------"`` will be omitted in this case.
|
||
|
||
* :class:`~django.forms.MultiValueField` allows optional subfields by setting
|
||
the ``require_all_fields`` argument to ``False``. The ``required`` attribute
|
||
for each individual field will be respected, and a new ``incomplete``
|
||
validation error will be raised when any required fields are empty.
|
||
|
||
* The :meth:`~django.forms.Form.clean` method on a form no longer needs to
|
||
return ``self.cleaned_data``. If it does return a changed dictionary then
|
||
that will still be used.
|
||
|
||
* After a temporary regression in Django 1.6, it's now possible again to make
|
||
:class:`~django.forms.TypedChoiceField` ``coerce`` method return an arbitrary
|
||
value.
|
||
|
||
* :attr:`SelectDateWidget.months
|
||
<django.forms.extras.widgets.SelectDateWidget.months>` can be used to
|
||
customize the wording of the months displayed in the select widget.
|
||
|
||
* The ``min_num`` and ``validate_min`` parameters were added to
|
||
:func:`~django.forms.formsets.formset_factory` to allow validating
|
||
a minimum number of submitted forms.
|
||
|
||
* The metaclasses used by ``Form`` and ``ModelForm`` have been reworked to
|
||
support more inheritance scenarios. The previous limitation that prevented
|
||
inheriting from both ``Form`` and ``ModelForm`` simultaneously have been
|
||
removed as long as ``ModelForm`` appears first in the MRO.
|
||
|
||
* It's now possible to opt-out from a ``Form`` field declared in a parent class
|
||
by shadowing it with a non-``Field`` value.
|
||
|
||
Internationalization
|
||
^^^^^^^^^^^^^^^^^^^^
|
||
|
||
* The :attr:`django.middleware.locale.LocaleMiddleware.response_redirect_class`
|
||
attribute allows you to customize the redirects issued by the middleware.
|
||
|
||
* The :class:`~django.middleware.locale.LocaleMiddleware` now stores the user's
|
||
selected language with the session key ``_language``. Previously it was
|
||
stored with the key ``django_language``, but keys reserved for Django should
|
||
start with an underscore. For backwards compatibility ``django_language`` is
|
||
still read from in 1.7. Sessions will be migrated to the new ``_language``
|
||
key as they are written.
|
||
|
||
* The :ttag:`blocktrans` now supports a ``trimmed`` option. This
|
||
option will remove newline characters from the beginning and the end of the
|
||
content of the ``{% blocktrans %}`` tag, replace any whitespace at the
|
||
beginning and end of a line and merge all lines into one using a space
|
||
character to separate them. This is quite useful for indenting the content of
|
||
a ``{% blocktrans %}`` tag without having the indentation characters end up
|
||
in the corresponding entry in the PO file, which makes the translation
|
||
process easier.
|
||
|
||
Management Commands
|
||
^^^^^^^^^^^^^^^^^^^
|
||
|
||
* The :djadminopt:`--no-color` option for ``django-admin.py`` allows you to
|
||
disable the colorization of management command output.
|
||
|
||
* The new :djadminopt:`--natural-foreign` and :djadminopt:`--natural-primary`
|
||
options for :djadmin:`dumpdata`, and the new ``use_natural_foreign_keys`` and
|
||
``use_natural_primary_keys`` arguments for ``serializers.serialize()``, allow
|
||
the use of natural primary keys when serializing.
|
||
|
||
* It is no longer necessary to provide the cache table name or the
|
||
:djadminopt:`--database` option for the :djadmin:`createcachetable` command.
|
||
Django takes this information from your settings file. If you have configured
|
||
multiple caches or multiple databases, all cache tables are created.
|
||
|
||
* The :djadmin:`runserver` command received several improvements:
|
||
|
||
# On BSD systems, including OS X, the development server will reload
|
||
immediately when a file is changed. Previously, it polled the filesystem
|
||
for changes every second. That caused a small delay before reloads and
|
||
reduced battery life on laptops.
|
||
|
||
* On Linux, the same improvements are available when pyinotify_ is
|
||
installed.
|
||
|
||
.. _pyinotify: https://pypi.python.org/pypi/pyinotify
|
||
|
||
* In addition, the development server automatically reloads when a
|
||
translation file is updated, i.e. after running
|
||
:djadmin:`compilemessages`.
|
||
|
||
* All HTTP requests are logged to the console, including requests for static
|
||
files or ``favicon.ico`` that used to be filtered out.
|
||
|
||
Models
|
||
^^^^^^
|
||
|
||
* The :meth:`QuerySet.update_or_create()
|
||
<django.db.models.query.QuerySet.update_or_create>` method was added.
|
||
|
||
* The new :attr:`~django.db.models.Options.default_permissions` model
|
||
``Meta`` option allows you to customize (or disable) creation of the default
|
||
add, change, and delete permissions.
|
||
|
||
* :attr:`~django.db.models.Options.app_label` is no longer required for models
|
||
that are defined in a ``models`` package within an app.
|
||
|
||
* Explicit :class:`~django.db.models.OneToOneField` for
|
||
:ref:`multi-table-inheritance` are now discovered in abstract classes.
|
||
|
||
* Is it now possible to avoid creating a backward relation for
|
||
:class:`~django.db.models.OneToOneField` by setting its
|
||
:attr:`~django.db.models.ForeignKey.related_name` to
|
||
`'+'` or ending it with `'+'`.
|
||
|
||
* :class:`F expressions <django.db.models.F>` support the power operator
|
||
(``**``).
|
||
|
||
Signals
|
||
^^^^^^^
|
||
|
||
* The ``enter`` argument was added to the
|
||
:data:`~django.test.signals.setting_changed` signal.
|
||
|
||
Templates
|
||
^^^^^^^^^
|
||
|
||
* The :meth:`Context.push() <django.template.Context.push>` method now returns
|
||
a context manager which automatically calls :meth:`pop()
|
||
<django.template.Context.pop>` upon exiting the ``with`` statement.
|
||
Additionally, :meth:`push() <django.template.Context.push>` now accepts
|
||
parameters that are passed to the ``dict`` constructor used to build the new
|
||
context level.
|
||
|
||
* The :ttag:`widthratio` template tag now accepts an "as" parameter to capture
|
||
the result in a variable.
|
||
|
||
* The :ttag:`include` template tag will now also accept anything with a
|
||
``render()`` method (such as a ``Template``) as an argument. String
|
||
arguments will be looked up using
|
||
:func:`~django.template.loader.get_template` as always.
|
||
|
||
* It is now possible to :ttag:`include` templates recursively.
|
||
|
||
* Template objects now have an origin attribute set when
|
||
:setting:`TEMPLATE_DEBUG` is ``True``. This allows template origins to be
|
||
inspected and logged outside of the ``django.template`` infrastructure.
|
||
|
||
* ``TypeError`` exceptions are no longer silenced when raised during the
|
||
rendering of a template.
|
||
|
||
* The following functions now accept a ``dirs`` parameter which is a list or
|
||
tuple to override :setting:`TEMPLATE_DIRS`:
|
||
|
||
* :func:`django.template.loader.get_template()`
|
||
* :func:`django.template.loader.select_template()`
|
||
* :func:`django.shortcuts.render()`
|
||
* :func:`django.shortcuts.render_to_response()`
|
||
|
||
* The :tfilter:`time` filter now accepts timzone-related :ref:`format
|
||
specifiers <date-and-time-formatting-specifiers>` ``'e'``, ``'O'`` , ``'T'``
|
||
and ``'Z'`` and is able to digest :ref:`time-zone-aware
|
||
<naive_vs_aware_datetimes>` ``datetime`` instances performing the expected
|
||
rendering.
|
||
|
||
* The :ttag:`cache` tag will now try to use the cache called
|
||
"template_fragments" if it exists and fall back to using the default cache
|
||
otherwise. It also now accepts an optional ``using`` keyword argument to
|
||
control which cache it uses.
|
||
|
||
Requests
|
||
^^^^^^^^
|
||
|
||
* The new :attr:`HttpRequest.scheme <django.http.HttpRequest.scheme>` attribute
|
||
specifies the scheme of the request (``http`` or ``https`` normally).
|
||
|
||
Tests
|
||
^^^^^
|
||
|
||
* :class:`~django.test.runner.DiscoverRunner` has two new attributes,
|
||
:attr:`~django.test.runner.DiscoverRunner.test_suite` and
|
||
:attr:`~django.test.runner.DiscoverRunner.test_runner`, which facilitate
|
||
overriding the way tests are collected and run.
|
||
|
||
* The ``fetch_redirect_response`` argument was added to
|
||
:meth:`~django.test.SimpleTestCase.assertRedirects`. Since the test
|
||
client can't fetch externals URLs, this allows you to use ``assertRedirects``
|
||
with redirects that aren't part of your Django app.
|
||
|
||
* Correct handling of scheme when making comparisons in
|
||
:meth:`~django.test.SimpleTestCase.assertRedirects`.
|
||
|
||
* The ``secure`` argument was added to all the request methods of
|
||
:class:`~django.test.Client`. If ``True``, the request will be made
|
||
through HTTPS.
|
||
|
||
* Requests made with :meth:`Client.login() <django.test.Client.login>` and
|
||
:meth:`Client.logout() <django.test.Client.logout>` respect defaults defined
|
||
in :class:`~django.test.Client` instantiation and are processed through
|
||
middleware.
|
||
|
||
Backwards incompatible changes in 1.7
|
||
=====================================
|
||
|
||
.. warning::
|
||
|
||
In addition to the changes outlined in this section, be sure to review the
|
||
:doc:`deprecation plan </internals/deprecation>` for any features that
|
||
have been removed. If you haven't updated your code within the
|
||
deprecation timeline for a given feature, its removal may appear as a
|
||
backwards incompatible change.
|
||
|
||
allow_syncdb/allow_migrate
|
||
~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||
|
||
While Django will still look at ``allow_syncdb`` methods even though they
|
||
should be renamed to ``allow_migrate``, there is a subtle difference in which
|
||
models get passed to these methods.
|
||
|
||
For apps with migrations, ``allow_migrate`` will now get passed
|
||
:ref:`historical models <historical-models>`, which are special versioned models
|
||
without custom attributes, methods or managers. Make sure your ``allow_migrate``
|
||
methods are only referring to fields or other items in ``model._meta``.
|
||
|
||
Passing ``None`` to ``Manager.db_manager()``
|
||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||
|
||
In previous versions of Django, it was possible to use
|
||
``db_manager(using=None)`` on a model manager instance to obtain a manager
|
||
instance using default routing behavior, overriding any manually specified
|
||
database routing. In Django 1.7, a value of ``None`` passed to db_manager will
|
||
produce a router that *retains* any manually assigned database routing -- the
|
||
manager will *not* be reset. This was necessary to resolve an inconsistency in
|
||
the way routing information cascaded over joins. See `Ticket #13724`_ for more
|
||
details.
|
||
|
||
.. _Ticket #13724: https://code.djangoproject.com/ticket/13724
|
||
|
||
pytz may be required
|
||
~~~~~~~~~~~~~~~~~~~~
|
||
|
||
If your project handles datetimes before 1970 or after 2037 and Django raises
|
||
a :exc:`~exceptions.ValueError` when encountering them, you will have to
|
||
install pytz_. You may be affected by this problem if you use Django's time
|
||
zone-related date formats or :mod:`django.contrib.syndication`.
|
||
|
||
.. _pytz: https://pypi.python.org/pypi/pytz/
|
||
|
||
Miscellaneous
|
||
~~~~~~~~~~~~~
|
||
|
||
* The :meth:`django.core.files.uploadhandler.FileUploadHandler.new_file()`
|
||
method is now passed an additional ``content_type_extra`` parameter. If you
|
||
have a custom :class:`~django.core.files.uploadhandler.FileUploadHandler`
|
||
that implements ``new_file()``, be sure it accepts this new parameter.
|
||
|
||
* :class:`ModelFormSet<django.forms.models.BaseModelFormSet>`’s no longer
|
||
delete instances when ``save(commit=False)`` is called. See
|
||
:attr:`~django.forms.formsets.BaseFormSet.can_delete` for instructions on how
|
||
to manually delete objects from deleted forms.
|
||
|
||
* Loading empty fixtures emits a ``RuntimeWarning`` rather than raising
|
||
:class:`~django.core.management.CommandError`.
|
||
|
||
* :func:`django.contrib.staticfiles.views.serve` will now raise an
|
||
:exc:`~django.http.Http404` exception instead of
|
||
:exc:`~django.core.exceptions.ImproperlyConfigured` when :setting:`DEBUG`
|
||
is ``False``. This change removes the need to conditionally add the view to
|
||
your root URLconf, which in turn makes it safe to reverse by name. It also
|
||
removes the ability for visitors to generate spurious HTTP 500 errors by
|
||
requesting static files that don't exist or haven't been collected yet.
|
||
|
||
* The :meth:`django.db.models.Model.__eq__` method is now defined in a
|
||
way where instances of a proxy model and its base model are considered
|
||
equal when primary keys match. Previously only instances of exact same
|
||
class were considered equal on primary key match.
|
||
|
||
* The :meth:`django.db.models.Model.__eq__` method has changed such that
|
||
two ``Model`` instances without primary key values won't be considered
|
||
equal (unless they are the same instance).
|
||
|
||
* The :meth:`django.db.models.Model.__hash__` will now raise ``TypeError``
|
||
when called on an instance without a primary key value. This is done to
|
||
avoid mutable ``__hash__`` values in containers.
|
||
|
||
* :class:`~django.db.models.AutoField` columns in SQLite databases will now be
|
||
created using the ``AUTOINCREMENT`` option, which guarantees monotonic
|
||
increments. This will cause primary key numbering behavior to change on
|
||
SQLite, becoming consistent with most other SQL databases. This will only
|
||
apply to newly created tables. If you have a database created with an older
|
||
version of Django, you will need to migrate it to take advantage of this
|
||
feature. For example, you could do the following:
|
||
|
||
#) Use :djadmin:`dumpdata` to save your data.
|
||
#) Rename the existing database file (keep it as a backup).
|
||
#) Run :djadmin:`migrate` to create the updated schema.
|
||
#) Use :djadmin:`loaddata` to import the fixtures you exported in (1).
|
||
|
||
* ``django.contrib.auth.models.AbstractUser`` no longer defines a
|
||
:meth:`~django.db.models.Model.get_absolute_url()` method. The old definition
|
||
returned ``"/users/%s/" % urlquote(self.username)`` which was arbitrary
|
||
since applications may or may not define such a url in ``urlpatterns``.
|
||
Define a ``get_absolute_url()`` method on your own custom user object or use
|
||
:setting:`ABSOLUTE_URL_OVERRIDES` if you want a URL for your user.
|
||
|
||
* The static asset-serving functionality of the
|
||
:class:`django.test.LiveServerTestCase` class has been simplified: Now it's
|
||
only able to serve content already present in :setting:`STATIC_ROOT` when
|
||
tests are run. The ability to transparently serve all the static assets
|
||
(similarly to what one gets with :setting:`DEBUG = True <DEBUG>` at
|
||
development-time) has been moved to a new class that lives in the
|
||
``staticfiles`` application (the one actually in charge of such feature):
|
||
:class:`django.contrib.staticfiles.testing.StaticLiveServerCase`. In other
|
||
words, ``LiveServerTestCase`` itself is less powerful but at the same time
|
||
has less magic.
|
||
|
||
Rationale behind this is removal of dependency of non-contrib code on
|
||
contrib applications.
|
||
|
||
* The old cache URI syntax (e.g. ``"locmem://"``) is no longer supported. It
|
||
still worked, even though it was not documented or officially supported. If
|
||
you're still using it, please update to the current :setting:`CACHES` syntax.
|
||
|
||
* The default ordering of ``Form`` fields in case of inheritance has changed to
|
||
follow normal Python MRO. Fields are now discovered by iterating through the
|
||
MRO in reverse with the topmost class coming last. This only affects you if
|
||
you relied on the default field ordering while having fields defined on both
|
||
the current class *and* on a parent ``Form``.
|
||
|
||
* The ``required`` argument of
|
||
:class:`~django.forms.extras.widgets.SelectDateWidget` has been removed.
|
||
This widget now respects the form field's ``is_required`` attribute like
|
||
other widgets.
|
||
|
||
* :meth:`~django.db.models.query.QuerySet.select_related` now chains in the
|
||
same way as other similar calls like ``prefetch_related``. That is,
|
||
``select_related('foo', 'bar')`` is equivalent to
|
||
``select_related('foo').select_related('bar')``. Previously the latter would
|
||
have been equivalent to ``select_related('bar')``.
|
||
|
||
Features deprecated in 1.7
|
||
==========================
|
||
|
||
``django.utils.dictconfig``/``django.utils.importlib``
|
||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||
|
||
``django.utils.dictconfig`` and ``django.utils.importlib`` were copies of
|
||
respectively :mod:`logging.config` and :mod:`importlib` provided for Python
|
||
versions prior to 2.7. They have been deprecated.
|
||
|
||
``django.utils.tzinfo``
|
||
~~~~~~~~~~~~~~~~~~~~~~~
|
||
|
||
``django.utils.tzinfo`` provided two :class:`~datetime.tzinfo` subclasses,
|
||
``LocalTimezone`` and ``FixedOffset``. They've been deprecated in favor of
|
||
more correct alternatives provided by :mod:`django.utils.timezone`,
|
||
:func:`django.utils.timezone.get_default_timezone` and
|
||
:func:`django.utils.timezone.get_fixed_timezone`.
|
||
|
||
``django.utils.unittest``
|
||
~~~~~~~~~~~~~~~~~~~~~~~~~
|
||
|
||
``django.utils.unittest`` provided uniform access to the ``unittest2`` library
|
||
on all Python versions. Since ``unittest2`` became the standard library's
|
||
:mod:`unittest` module in Python 2.7, and Django 1.7 drops support for older
|
||
Python versions, this module isn't useful anymore. It has been deprecated. Use
|
||
:mod:`unittest` instead.
|
||
|
||
``django.utils.datastructures.SortedDict``
|
||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||
|
||
As :class:`~collections.OrderedDict` was added to the standard library in
|
||
Python 2.7, :class:`~django.utils.datastructures.SortedDict` is no longer
|
||
needed and has been deprecated.
|
||
|
||
Custom SQL location for models package
|
||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||
|
||
Previously, if models were organized in a package (``myapp/models/``) rather
|
||
than simply ``myapp/models.py``, Django would look for :ref:`initial SQL data
|
||
<initial-sql>` in ``myapp/models/sql/``. This bug has been fixed so that Django
|
||
will search ``myapp/sql/`` as documented. The old location will continue to
|
||
work until Django 1.9.
|
||
|
||
``declared_fieldsets`` attribute on ``ModelAdmin``
|
||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||
|
||
``ModelAdmin.declared_fieldsets`` has been deprecated. Despite being a private
|
||
API, it will go through a regular deprecation path. This attribute was mostly
|
||
used by methods that bypassed ``ModelAdmin.get_fieldsets()`` but this was
|
||
considered a bug and has been addressed.
|
||
|
||
``syncdb``
|
||
~~~~~~~~~~
|
||
|
||
The ``syncdb`` command has been deprecated in favour of the new ``migrate``
|
||
command. ``migrate`` takes the same arguments as ``syncdb`` used to plus a few
|
||
more, so it's safe to just change the name you're calling and nothing else.
|
||
|
||
``util`` modules renamed to ``utils``
|
||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||
|
||
The following instances of ``util.py`` in the Django codebase have been renamed
|
||
to ``utils.py`` in an effort to unify all util and utils references:
|
||
|
||
* ``django.contrib.admin.util``
|
||
* ``django.contrib.gis.db.backends.util``
|
||
* ``django.db.backends.util``
|
||
* ``django.forms.util``
|
||
|
||
``get_formsets`` method on ``ModelAdmin``
|
||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||
|
||
``ModelAdmin.get_formsets`` has been deprecated in favor of the new
|
||
:meth:`~django.contrib.admin.ModelAdmin.get_formsets_with_inlines`, in order to
|
||
better handle the case of selecting showing inlines on a ``ModelAdmin``.
|
||
|
||
``IPAddressField``
|
||
~~~~~~~~~~~~~~~~~~
|
||
|
||
The :class:`django.db.models.IPAddressField` and
|
||
:class:`django.forms.IPAddressField` fields have been deprecated in favor of
|
||
:class:`django.db.models.GenericIPAddressField` and
|
||
:class:`django.forms.GenericIPAddressField`.
|
||
|
||
``BaseMemcachedCache._get_memcache_timeout`` method
|
||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||
|
||
The ``BaseMemcachedCache._get_memcache_timeout()`` method has been renamed to
|
||
``get_backend_timeout()``. Despite being a private API, it will go through the
|
||
normal deprecation.
|
||
|
||
Natural key serialization options
|
||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||
|
||
The ``--natural`` and ``-n`` options for :djadmin:`dumpdata` have been
|
||
deprecated. Use :djadminopt:`--natural-foreign` instead.
|
||
|
||
Similarly, the ``use_natural_keys`` argument for ``serializers.serialize()``
|
||
has been deprecated. Use ``use_natural_foreign_keys`` instead.
|
||
|
||
Merging of ``POST`` and ``GET`` arguments into ``WSGIRequest.REQUEST``
|
||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||
|
||
It was already strongly suggested that you use ``GET`` and ``POST`` instead of
|
||
``REQUEST``, because the former are more explicit. The property ``REQUEST`` is
|
||
deprecated and will be removed in Django 1.9.
|
||
|
||
``django.utils.datastructures.MergeDict`` class
|
||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||
|
||
``MergeDict`` exists primarily to support merging ``POST`` and ``GET``
|
||
arguments into a ``REQUEST`` property on ``WSGIRequest``. To merge
|
||
dictionaries, use ``dict.update()`` instead. The class ``MergeDict`` is
|
||
deprecated and will be removed in Django 1.9.
|
||
|
||
Language codes ``zh-cn``, ``zh-tw`` and ``fy-nl``
|
||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||
|
||
The currently used language codes for Simplified Chinese ``zh-cn``,
|
||
Traditional Chinese ``zh-tw`` and (Western) Frysian ``fy-nl`` are deprecated
|
||
and should be replaced by the language codes ``zh-hans``, ``zh-hant`` and
|
||
``fy`` respectively. If you use these language codes, you should rename the
|
||
locale directories and update your settings to reflect these changes. The
|
||
deprecated language codes will be removed in Django 1.9.
|
||
|
||
``django.utils.functional.memoize`` function
|
||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||
|
||
The function ``memoize`` is deprecated and should be replaced by the
|
||
``functools.lru_cache`` decorator (available from Python 3.2 onwards).
|
||
|
||
Django ships a backport of this decorator for older Python versions and it's
|
||
available at ``django.utils.lru_cache.lru_cache``. The deprecated function will
|
||
be removed in Django 1.9.
|