django/docs/releases/1.5.txt

============================================
Django 1.5 release notes - UNDER DEVELOPMENT
============================================

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.4 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.5`_
.. _`backwards incompatible changes`: `Backwards incompatible changes in 1.5`_
.. _`begun the deprecation process for some features`: `Features deprecated in 1.5`_

Python compatibility
====================

Django 1.5 has dropped support for Python 2.5. Python 2.6 is now the minimum
required Python version. Django is tested and supported on Python 2.6 and
2.7.

This change should affect only a small number of Django users, as most
operating-system vendors today are shipping Python 2.6 or newer as their default
version. If you're still using Python 2.5, however, you'll need to stick to
Django 1.4 until you can upgrade your Python version. Per :doc:`our support policy
</internals/release-process>`, Django 1.4 will continue to receive security
support until the release of Django 1.6.

Django 1.5 does not run on a Jython final release, because Jython's latest release
doesn't currently support Python 2.6. However, Jython currently does offer an alpha
release featuring 2.7 support.

What's new in Django 1.5
========================

Support for saving a subset of model's fields
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

The method :meth:`Model.save() <django.db.models.Model.save()>` has a new
keyword argument ``update_fields``. By using this argument it is possible to
save only a select list of model's fields. This can be useful for performance
reasons or when trying to avoid overwriting concurrent changes.

See the :meth:`Model.save() <django.db.models.Model.save()>` documentation for
more details.

Caching of related model instances
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

When traversing relations, the ORM will avoid re-fetching objects that were
previously loaded. For example, with the tutorial's models::

    >>> first_poll = Poll.objects.all()[0]
    >>> first_choice = first_poll.choice_set.all()[0]
    >>> first_choice.poll is first_poll
    True

In Django 1.5, the third line no longer triggers a new SQL query to fetch
``first_choice.poll``; it was set by the second line.

For one-to-one relationships, both sides can be cached. For many-to-one
relationships, only the single side of the relationship can be cached. This
is particularly helpful in combination with ``prefetch_related``.

``{% verbatim %}`` template tag
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

To make it easier to deal with javascript templates which collide with Django's
syntax, you can now use the :ttag:`verbatim` block tag to avoid parsing the
tag's content.

Retreival of ``ContentType`` instances associated with proxy models
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

The methods :meth:`ContentTypeManager.get_for_model() <django.contrib.contenttypes.models.ContentTypeManager.get_for_model()>`
and :meth:`ContentTypeManager.get_for_models() <django.contrib.contenttypes.models.ContentTypeManager.get_for_models()>`
have a new keyword argument – respectively ``for_concrete_model`` and ``for_concrete_models``.
By passing ``False`` using this argument it is now possible to retreive the
:class:`ContentType <django.contrib.contenttypes.models.ContentType>`
associated with proxy models.

Minor features
~~~~~~~~~~~~~~

Django 1.5 also includes several smaller improvements worth noting:

* The template engine now interprets ``True``, ``False`` and ``None`` as the
  corresponding Python objects.

* :mod:`django.utils.timezone` provides a helper for converting aware
  datetimes between time zones. See :func:`~django.utils.timezone.localtime`.

* The generic views support OPTIONS requests.

* Management commands do not raise ``SystemExit`` any more when called by code
  from :ref:`call_command <call-command>`. Any exception raised by the command
  (mostly :ref:`CommandError <ref-command-exceptions>`) is propagated.

* The dumpdata management command outputs one row at a time, preventing
  out-of-memory errors when dumping large datasets.

* In the localflavor for Canada, "pq" was added to the acceptable codes for
  Quebec. It's an old abbreviation.

Backwards incompatible changes in 1.5
=====================================

.. 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.

Context in year archive class-based views
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

For consistency with the other date-based generic views,
:class:`~django.views.generic.dates.YearArchiveView` now passes ``year`` in
the context as a :class:`datetime.date` rather than a string.  If you are
using ``{{ year }}`` in your templates, you must replace it with ``{{
year|date:"Y" }}``.

``next_year`` and ``previous_year`` were also added in the context. They are
calculated according to ``allow_empty`` and ``allow_future``.

OPTIONS, PUT and DELETE requests in the test client
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Unlike GET and POST, these HTTP methods aren't implemented by web browsers.
Rather, they're used in APIs, which transfer data in various formats such as
JSON or XML. Since such requests may contain arbitrary data, Django doesn't
attempt to decode their body.

However, the test client used to build a query string for OPTIONS and DELETE
requests like for GET, and a request body for PUT requests like for POST. This
encoding was arbitrary and inconsistent with Django's behavior when it
receives the requests, so it was removed in Django 1.5.

If you were using the ``data`` parameter in an OPTIONS or a DELETE request,
you must convert it to a query string and append it to the ``path`` parameter.

If you were using the ``data`` parameter in a PUT request without a
``content_type``, you must encode your data before passing it to the test
client and set the ``content_type`` argument.

String types of hasher method parameters
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

If you have written a :ref:`custom password hasher <auth_password_storage>`,
your ``encode()``, ``verify()`` or ``safe_summary()`` methods should accept
Unicode parameters (``password``, ``salt`` or ``encoded``). If any of the
hashing methods need byte strings, you can use the
:func:`~django.utils.encoding.smart_str` utility to encode the strings.

Validation of previous_page_number and next_page_number
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

When using :doc:`object pagination </topics/pagination>`,
the ``previous_page_number()`` and ``next_page_number()`` methods of the
:class:`~django.core.paginator.Page` object did not check if the returned
number was inside the existing page range.
It does check it now and raises an :exc:`InvalidPage` exception when the number
is either too low or too high.

Features deprecated in 1.5
==========================

``django.utils.simplejson``
~~~~~~~~~~~~~~~~~~~~~~~~~~~

Since Django 1.5 drops support for Python 2.5, we can now rely on the
:mod:`json` module being in Python's standard library -- so we've removed
our own copy of ``simplejson``. You can safely change any use of
:mod:`django.utils.simplejson` to :mod:`json`.

``itercompat.product``
~~~~~~~~~~~~~~~~~~~~~~

The :func:`~django.utils.itercompat.product` function has been deprecated. Use
the built-in :func:`itertools.product` instead.