173 lines
7.2 KiB
Plaintext
173 lines
7.2 KiB
Plaintext
============================================
|
||
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 Jython, because Jython doesn't currently offer any
|
||
version compatible with Python 2.6.
|
||
|
||
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.
|
||
|
||
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.
|