1
0
mirror of https://github.com/django/django.git synced 2024-12-24 10:05:46 +00:00
django/docs/releases/1.6.txt
Aymeric Augustin 59a3520875 Refactored database exceptions wrapping.
Squashed commit of the following:

commit 2181d833ed1a2e422494738dcef311164c4e097e
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date:   Wed Feb 27 14:28:39 2013 +0100

    Fixed #15901 -- Wrapped all PEP-249 exceptions.

commit 5476a5d93c19aa2f928c497d39ce6e33f52694e2
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date:   Tue Feb 26 17:26:52 2013 +0100

    Added PEP 3134 exception chaining.

    Thanks Jacob Kaplan-Moss for the suggestion.

commit 9365fad0a650328002fb424457d675a273c95802
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date:   Tue Feb 26 17:13:49 2013 +0100

    Improved API for wrapping database errors.

    Thanks Alex Gaynor for the proposal.

commit 1b463b765f2826f73a8d9266795cd5da4f8d5e9e
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date:   Tue Feb 26 15:00:39 2013 +0100

    Removed redundant exception wrapping.

    This is now taken care of by the cursor wrapper.

commit 524bc7345a724bf526bdd2dd1bcf5ede67d6bb5c
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date:   Tue Feb 26 14:55:10 2013 +0100

    Wrapped database exceptions in the base backend.

    This covers the most common PEP-249 APIs:
    - Connection APIs: close(), commit(), rollback(), cursor()
    - Cursor APIs: callproc(), close(), execute(), executemany(),
      fetchone(), fetchmany(), fetchall(), nextset().

    Fixed #19920.

commit a66746bb5f0839f35543222787fce3b6a0d0a3ea
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date:   Tue Feb 26 14:53:34 2013 +0100

    Added a wrap_database_exception context manager and decorator.

    It re-throws backend-specific exceptions using Django's common wrappers.
2013-02-27 17:26:54 +01:00

256 lines
11 KiB
Plaintext

============================================
Django 1.6 release notes - UNDER DEVELOPMENT
============================================
Welcome to Django 1.6!
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.5 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.6`_
.. _`backwards incompatible changes`: `Backwards incompatible changes in 1.6`_
.. _`begun the deprecation process for some features`: `Features deprecated in 1.6`_
What's new in Django 1.6
========================
Simplified default project and app templates
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The default templates used by :djadmin:`startproject` and :djadmin:`startapp`
have been simplified and modernized. The :doc:`admin
</ref/contrib/admin/index>` is now enabled by default in new projects; the
:doc:`sites </ref/contrib/sites>` framework no longer is. :ref:`Language
detection <how-django-discovers-language-preference>` and :ref:`clickjacking
prevention <clickjacking-prevention>` are turned on.
If the default templates don't suit your tastes, you can use :ref:`custom
project and app templates <custom-app-and-project-templates>`.
Time zone aware aggregation
~~~~~~~~~~~~~~~~~~~~~~~~~~~
The support for :doc:`time zones </topics/i18n/timezones>` introduced in
Django 1.4 didn't work well with :meth:`QuerySet.dates()
<django.db.models.query.QuerySet.dates>`: aggregation was always performed in
UTC. This limitation was lifted in Django 1.6. Use :meth:`QuerySet.datetimes()
<django.db.models.query.QuerySet.datetimes>` to perform time zone aware
aggregation on a :class:`~django.db.models.DateTimeField`.
Minor features
~~~~~~~~~~~~~~
* Authentication backends can raise ``PermissionDenied`` to immediately fail
the authentication chain.
* The HttpOnly flag can be set on the CSRF cookie with
:setting:`CSRF_COOKIE_HTTPONLY`.
* The ``assertQuerysetEqual()`` now checks for undefined order and raises
``ValueError`` if undefined order is spotted. The order is seen as
undefined if the given ``QuerySet`` isn't ordered and there are more than
one ordered values to compare against.
* Added :meth:`~django.db.models.query.QuerySet.earliest` for symmetry with
:meth:`~django.db.models.query.QuerySet.latest`.
* In addition to :lookup:`year`, :lookup:`month` and :lookup:`day`, the ORM
now supports :lookup:`hour`, :lookup:`minute` and :lookup:`second` lookups.
* Django now wraps all PEP-249 exceptions.
* The default widgets for :class:`~django.forms.EmailField`,
:class:`~django.forms.URLField`, :class:`~django.forms.IntegerField`,
:class:`~django.forms.FloatField` and :class:`~django.forms.DecimalField` use
the new type attributes available in HTML5 (type='email', type='url',
type='number'). Note that due to erratic support of the ``number`` input type
with localized numbers in current browsers, Django only uses it when numeric
fields are not localized.
* The ``number`` argument for :ref:`lazy plural translations
<lazy-plural-translations>` can be provided at translation time rather than
at definition time.
* For custom management commands: Verification of the presence of valid
settings in commands that ask for it by using the
:attr:`~django.core.management.BaseCommand.can_import_settings` internal
option is now performed independently from handling of the locale that
should be active during the execution of the command. The latter can now be
influenced by the new
:attr:`~django.core.management.BaseCommand.leave_locale_alone` internal
option. See :ref:`management-commands-and-locales` for more details.
* The :attr:`~django.views.generic.edit.DeletionMixin.success_url` of
:class:`~django.views.generic.edit.DeletionMixin` is now interpolated with
its ``object``\'s ``__dict__``.
* :class:`~django.http.HttpResponseRedirect` and
:class:`~django.http.HttpResponsePermanentRedirect` now provide an ``url``
attribute (equivalent to the URL the response will redirect to).
* The ``MemcachedCache`` cache backend now uses the latest :mod:`pickle`
protocol available.
* Added the :attr:`django.db.models.ForeignKey.db_constraint`
option.
* The jQuery library embedded in the admin has been upgraded to version 1.9.1.
* Syndication feeds (:mod:`django.contrib.syndication`) can now pass extra
context through to feed templates using a new `Feed.get_context_data()`
callback.
* The admin list columns have a ``column-<field_name>`` class in the HTML
so the columns header can be styled with CSS, e.g. to set a column width.
Backwards incompatible changes in 1.6
=====================================
* The ``django.db.models.query.EmptyQuerySet`` can't be instantiated any more -
it is only usable as a marker class for checking if
:meth:`~django.db.models.query.QuerySet.none` has been called:
``isinstance(qs.none(), EmptyQuerySet)``
* :meth:`QuerySet.dates() <django.db.models.query.QuerySet.dates>` raises an
error if it's used on :class:`~django.db.models.DateTimeField` when time
zone support is active. Use :meth:`QuerySet.datetimes()
<django.db.models.query.QuerySet.datetimes>` instead.
* :meth:`QuerySet.dates() <django.db.models.query.QuerySet.dates>` returns a
list of :class:`~datetime.date`. It used to return a list of
:class:`~datetime.datetime`.
* The :attr:`~django.contrib.admin.ModelAdmin.date_hierarchy` feature of the
admin on a :class:`~django.db.models.DateTimeField` requires time zone
definitions in the database when :setting:`USE_TZ` is ``True``.
:ref:`Learn more <database-time-zone-definitions>`.
* Accessing ``date_list`` in the context of a date-based generic view requires
time zone definitions in the database when the view is based on a
:class:`~django.db.models.DateTimeField` and :setting:`USE_TZ` is ``True``.
:ref:`Learn more <database-time-zone-definitions>`.
* Model fields named ``hour``, ``minute`` or ``second`` may clash with the new
lookups. Append an explicit :lookup:`exact` lookup if this is an issue.
* If your CSS/Javascript code used to access HTML input widgets by type, you
should review it as ``type='text'`` widgets might be now output as
``type='email'``, ``type='url'`` or ``type='number'`` depending on their
corresponding field type.
* Extraction of translatable literals from templates with the
:djadmin:`makemessages` command now correctly detects i18n constructs when
they are located after a ``{#`` / ``#}``-type comment on the same line. E.g.:
.. code-block:: html+django
{# A comment #}{% trans "This literal was incorrectly ignored. Not anymore" %}
* (Related to the above item.) Validation of the placement of
:ref:`translator-comments-in-templates` specified using ``{#`` / ``#}`` is now
stricter. All translator comments not located at the end of their respective
lines in a template are ignored and a warning is generated by
:djadmin:`makemessages` when it finds them. E.g.:
.. code-block:: html+django
{# Translators: This is ignored #}{% trans "Translate me" %}
{{ title }}{# Translators: Extracted and associated with 'Welcome' below #}
<h1>{% trans "Welcome" %}</h1>
* The :doc:`comments </ref/contrib/comments/index>` app now uses a ``GenericIPAddressField``
for storing commenters' IP addresses, to support comments submitted from IPv6 addresses.
Until now, it stored them in an ``IPAddressField``, which is only meant to support IPv4.
When saving a comment made from an IPv6 address, the address would be silently truncated
on MySQL databases, and raise an exception on Oracle.
You will need to change the column type in your database to benefit from this change.
For MySQL, execute this query on your project's database:
.. code-block:: sql
ALTER TABLE django_comments MODIFY ip_address VARCHAR(39);
For Oracle, execute this query:
.. code-block:: sql
ALTER TABLE DJANGO_COMMENTS MODIFY (ip_address VARCHAR2(39));
If you do not apply this change, the behaviour is unchanged: on MySQL, IPv6 addresses
are silently truncated; on Oracle, an exception is generated. No database
change is needed for SQLite or PostgreSQL databases.
.. 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.
Features deprecated in 1.6
==========================
Changes to :ttag:`cycle` and :ttag:`firstof`
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The template system generally escapes all variables to avoid XSS attacks.
However, due to an accident of history, the :ttag:`cycle` and :ttag:`firstof`
tags render their arguments as-is.
Django 1.6 starts a process to correct this inconsistency. The ``future``
template library provides alternate implementations of :ttag:`cycle` and
:ttag:`firstof` that autoescape their inputs. If you're using these tags,
you're encourage to include the following line at the top of your templates to
enable the new behavior::
{% load cycle from future %}
or::
{% load firstof from future %}
The tags implementing the old behavior have been deprecated, and in Django
1.8, the old behavior will be replaced with the new behavior. To ensure
compatibility with future versions of Django, existing templates should be
modified to use the ``future`` versions.
If necessary, you can temporarily disable auto-escaping with
:func:`~django.utils.safestring.mark_safe` or :ttag:`{% autoescape off %}
<autoescape>`.
``SEND_BROKEN_LINK_EMAILS`` setting
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
:class:`~django.middleware.common.CommonMiddleware` used to provide basic
reporting of broken links by email when ``SEND_BROKEN_LINK_EMAILS`` is set to
``True``.
Because of intractable ordering problems between
:class:`~django.middleware.common.CommonMiddleware` and
:class:`~django.middleware.locale.LocaleMiddleware`, this feature was split
out into a new middleware:
:class:`~django.middleware.common.BrokenLinkEmailsMiddleware`.
If you're relying on this feature, you should add
``'django.middleware.common.BrokenLinkEmailsMiddleware'`` to your
:setting:`MIDDLEWARE_CLASSES` setting and remove ``SEND_BROKEN_LINK_EMAILS``
from your settings.
``_has_changed`` method on widgets
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
If you defined your own form widgets and defined the ``_has_changed`` method
on a widget, you should now define this method on the form field itself.
``module_name`` model meta attribute
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
``Model._meta.module_name`` was renamed to ``model_name``. Despite being a
private API, it will go through a regular deprecation path.