mirror of
https://github.com/django/django.git
synced 2024-11-18 07:26:04 +00:00
eb286aa22f
Applied the rule that string encoding should happen as late as possible. This is also a preparation for Python 3 compatibility.
156 lines
6.3 KiB
Plaintext
156 lines
6.3 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``.
|
|
|
|
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.
|