mirrors/django
1
0
Fork 0
mirror of https://github.com/django/django.git synced 2024-12-25 02:26:12 +00:00
Code Issues 25 Releases Wiki Activity
93cffc3b37
django/docs/releases/1.6.txt
Andrew Gorcester f9ab543720 Fixed #20084 -- Provided option to validate formset max_num on server. 
This is provided as a new "validate_max" formset_factory option defaulting to
False, since the non-validating behavior of max_num is longstanding, and there
is certainly code relying on it. (In fact, even the Django admin relies on it
for the case where there are more existing inlines than the given max_num). It
may be that at some point we want to deprecate validate_max=False and
eventually remove the option, but this commit takes no steps in that direction.

This also fixes the DoS-prevention absolute_max enforcement so that it causes a
form validation error rather than an IndexError, and ensures that absolute_max
is always 1000 more than max_num, to prevent surprising changes in behavior
with max_num close to absolute_max.

Lastly, this commit fixes the previous inconsistency between a regular formset
and a model formset in the precedence of max_num and initial data. Previously
in a regular formset, if the provided initial data was longer than max_num, it
was truncated; in a model formset, all initial forms would be displayed
regardless of max_num. Now regular formsets are the same as model formsets; all
initial forms are displayed, even if more than max_num. (But if validate_max is
True, submitting these forms will result in a "too many forms" validation
error!) This combination of behaviors was chosen to keep the max_num validation
simple and consistent, and avoid silent data loss due to truncation of initial
data.

Thanks to Preston for discussion of the design choices.
2013-03-21 01:27:24 -07:00

472 lines
19 KiB
Plaintext
Raw Blame History

============================================
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>`.
Improved transaction management
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Django's transaction management was overhauled. Database-level autocommit is
now turned on by default. This makes transaction handling more explicit and
should improve performance. The existing APIs were deprecated, and new APIs
were introduced, as described in the :doc:`transaction management docs
</topics/db/transactions>`.
Please review carefully the list of :ref:`known backwards-incompatibilities
<transactions-upgrading-from-1.5>` to determine if you need to make changes in
your code.
Persistent database connections
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Django now supports reusing the same database connection for several requests.
This avoids the overhead of re-establishing a connection at the beginning of
each request.
By default, database connections will kept open for 10 minutes. This behavior
is controlled by the :setting:`CONN_MAX_AGE` setting. To restore the previous
behavior of closing the connection at the end of each request, set
:setting:`CONN_MAX_AGE` to ``0``. See :ref:`persistent-database-connections`
for details.
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`.
``BinaryField`` model field
~~~~~~~~~~~~~~~~~~~~~~~~~~~
A new :class:`django.db.models.BinaryField` model field allows to store raw
binary data in the database.
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 :class:`~django.contrib.messages.views.SuccessMessageMixin` which
provides a ``success_message`` attribute for
:class:`~django.view.generic.edit.FormView` based classes.
* Added the :attr:`django.db.models.ForeignKey.db_constraint` and
:attr:`django.db.models.ManyToManyField.db_constraint` options.
* 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.
* The isolation level can be customized under PostgreSQL.
* The :ttag:`blocktrans` template tag now respects
:setting:`TEMPLATE_STRING_IF_INVALID` for variables not present in the
context, just like other template constructs.
* SimpleLazyObjects will now present more helpful representations in shell
debugging situations.
* Generic :class:`~django.contrib.gis.db.models.GeometryField` is now editable
with the OpenLayers widget in the admin.
* The :meth:`Model.save() <django.db.models.Model.save()>` will do
``UPDATE`` - if not updated - ``INSERT`` instead of ``SELECT`` - if not
found ``INSERT`` else ``UPDATE`` in case the model's primary key is set.
* The documentation contains a :doc:`deployment checklist
</howto/deployment/checklist>`.
* The :djadmin:`diffsettings` comand gained a ``--all`` option.
* :func:`django.forms.fields.Field.__init__` now calls ``super()``, allowing
field mixins to implement ``__init__()`` methods that will reliably be
called.
* The ``validate_max`` parameter was added to ``BaseFormSet`` and
:func:`~django.forms.formsets.formset_factory`, and ``ModelForm`` and inline
versions of the same. The behavior of validation for formsets with
``max_num`` was clarified. The previously undocumented behavior that
hardened formsets against memory exhaustion attacks was documented,
and the undocumented limit of the higher of 1000 or ``max_num`` forms
was changed so it is always 1000 more than ``max_num``.
Backwards incompatible changes in 1.6
=====================================
.. 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.
New transaction management model
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Database-level autocommit is enabled by default in Django 1.6. While this
doesn't change the general spirit of Django's transaction management, there
are a few known backwards-incompatibities, described in the :ref:`transaction
management docs <transactions-upgrading-from-1.5>`. You should review your
code to determine if you're affected.
In previous versions, database-level autocommit was only an option for
PostgreSQL, and it was disabled by default. This option is now :ref:`ignored
<postgresql-autocommit-mode>` and can be removed.
Addition of ``QuerySet.datetimes()``
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
When the :doc:`time zone support </topics/i18n/timezones>` added in Django 1.4
was active, :meth:`QuerySet.dates() <django.db.models.query.QuerySet.dates>`
lookups returned unexpected results, because the aggregation was performed in
UTC. To fix this, Django 1.6 introduces a new API, :meth:`QuerySet.datetimes()
<django.db.models.query.QuerySet.datetimes>`. This requires a few changes in
your code.
``QuerySet.dates()`` returns ``date`` objects
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
:meth:`QuerySet.dates() <django.db.models.query.QuerySet.dates>` now returns a
list of :class:`~datetime.date`. It used to return a list of
:class:`~datetime.datetime`.
:meth:`QuerySet.datetimes() <django.db.models.query.QuerySet.datetimes>`
returns a list of :class:`~datetime.datetime`.
``QuerySet.dates()`` no longer usable on ``DateTimeField``
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
: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.
``date_hierarchy`` requires time zone definitions
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
The :attr:`~django.contrib.admin.ModelAdmin.date_hierarchy` feature of the
admin now relies on :meth:`QuerySet.datetimes()
<django.db.models.query.QuerySet.datetimes>` when it's used on a
:class:`~django.db.models.DateTimeField`.
This requires time zone definitions in the database when :setting:`USE_TZ` is
``True``. :ref:`Learn more <database-time-zone-definitions>`.
``date_list`` in generic views requires time zone definitions
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
For the same reason, 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>`.
New lookups may clash with model fields
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Django 1.6 introduces ``hour``, ``minute``, and ``second`` lookups on
:class:`~django.db.models.DateTimeField`. If you had model fields called
``hour``, ``minute``, or ``second``, the new lookups will clash with you field
names. Append an explicit :lookup:`exact` lookup if this is an issue.
Persistent database connections
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Connection setup not repeated for each request
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
When Django establishes a connection to the database, it sets up appropriate
parameters, depending on the backend being used. Since `persistent database
connections <persistent-database-connections>`_ are enabled by default in
Django 1.6, this setup isn't repeated at every request any more. If you
modifiy parameters such as the connection's isolation level or time zone, you
should either restore Django's defaults at the end of each request, force an
appropriate value at the beginning of each request, or disable persistent
connections.
Translations and comments in templates
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Extraction of translations after comments
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
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" %}
Location of translator comments
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
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>
Quoting in :func:`~django.core.urlresolvers.reverse`
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
When reversing URLs, Django didn't apply :func:`~django.utils.http.urlquote`
to arguments before interpolating them in URL patterns. This bug is fixed in
Django 1.6. If you worked around this bug by applying URL quoting before
passing arguments to :func:`~django.core.urlresolvers.reverse`, this may
result in double-quoting. If this happens, simply remove the URL quoting from
your code.
Storage of IP addresses in the comments app
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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.
Miscellaneous
~~~~~~~~~~~~~
* 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)``
* 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.
Features deprecated in 1.6
==========================
Transaction management APIs
~~~~~~~~~~~~~~~~~~~~~~~~~~~
Transaction management was completely overhauled in Django 1.6, and the
current APIs are deprecated:
- ``django.middleware.transaction.TransactionMiddleware``
- ``django.db.transaction.autocommit``
- ``django.db.transaction.commit_on_success``
- ``django.db.transaction.commit_manually``
- the ``TRANSACTIONS_MANAGED`` setting
The reasons for this change and the upgrade path are described in the
:ref:`transactions documentation <transactions-upgrading-from-1.5>`.
``django.contrib.comments``
~~~~~~~~~~~~~~~~~~~~~~~~~~~
Django's comment framework has been deprecated and is no longer supported. It
will be available in Django 1.6 and 1.7, and removed in Django 1.8. Most users
will be better served with a custom solution, or a hosted product like Disqus__.
The code formerly known as ``django.contrib.comments`` is `still available
in an external repository`__.
__ https://disqus.com/
__ https://github.com/django/django-contrib-comments
Support for PostgreSQL versions older than 8.4
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The end of upstream support periods was reached in December 2011 for
PostgreSQL 8.2 and in February 2013 for 8.3. As a consequence, Django 1.6 sets
8.4 as the minimum PostgreSQL version it officially supports.
You're strongly encouraged to use the most recent version of PostgreSQL
available, because of performance improvements and to take advantage of the
native streaming replication available in PostgreSQL 9.x.
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.
``get_query_set`` and similar methods renamed to ``get_queryset``
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Methods that return a ``QuerySet`` such as ``Manager.get_query_set`` or
``ModelAdmin.queryset`` have been renamed to ``get_queryset``.
``shortcut`` view and URLconf
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The ``shortcut`` view was moved from ``django.views.defaults`` to
``django.contrib.contenttypes.views`` shortly after the 1.0 release, but the
old location was never deprecated. This oversight was corrected in Django 1.6
and you should now use the new location.
The URLconf ``django.conf.urls.shortcut`` was also deprecated. If you're
including it in an URLconf, simply replace::
(r'^prefix/', include('django.conf.urls.shortcut')),
with::
(r'^prefix/(?P<content_type_id>\d+)/(?P<object_id>.*)/$', 'django.contrib.contenttypes.views.shortcut'),
Reference in New Issue View Git Blame Copy Permalink