<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" lang="">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<title>Django 1.6 release notes — Django 1.8.19 documentation</title>
<link rel="stylesheet" href="../_static/default.css" type="text/css" />
<link rel="stylesheet" href="../_static/pygments.css" type="text/css" />
<script type="text/javascript">
var DOCUMENTATION_OPTIONS = {
URL_ROOT: '../',
VERSION: '1.8.19',
COLLAPSE_INDEX: false,
FILE_SUFFIX: '.html',
HAS_SOURCE: true
};
</script>
<script type="text/javascript" src="../_static/jquery.js"></script>
<script type="text/javascript" src="../_static/underscore.js"></script>
<script type="text/javascript" src="../_static/doctools.js"></script>
<link rel="index" title="Index" href="../genindex.html" />
<link rel="search" title="Search" href="../search.html" />
<link rel="top" title="Django 1.8.19 documentation" href="../contents.html" />
<link rel="up" title="Release notes" href="index.html" />
<link rel="next" title="Django 1.5.12 release notes" href="1.5.12.html" />
<link rel="prev" title="Django 1.6.1 release notes" href="1.6.1.html" />
<script type="text/javascript" src="../templatebuiltins.js"></script>
<script type="text/javascript">
(function($) {
if (!django_template_builtins) {
// templatebuiltins.js missing, do nothing.
return;
}
$(document).ready(function() {
// Hyperlink Django template tags and filters
var base = "../ref/templates/builtins.html";
if (base == "#") {
// Special case for builtins.html itself
base = "";
}
// Tags are keywords, class '.k'
$("div.highlight\\-html\\+django span.k").each(function(i, elem) {
var tagname = $(elem).text();
if ($.inArray(tagname, django_template_builtins.ttags) != -1) {
var fragment = tagname.replace(/_/, '-');
$(elem).html("<a href='" + base + "#" + fragment + "'>" + tagname + "</a>");
}
});
// Filters are functions, class '.nf'
$("div.highlight\\-html\\+django span.nf").each(function(i, elem) {
var filtername = $(elem).text();
if ($.inArray(filtername, django_template_builtins.tfilters) != -1) {
var fragment = filtername.replace(/_/, '-');
$(elem).html("<a href='" + base + "#" + fragment + "'>" + filtername + "</a>");
}
});
});
})(jQuery);
</script>
</head>
<body role="document">
<div class="document">
<div id="custom-doc" class="yui-t6">
<div id="hd">
<h1><a href="../index.html">Django 1.8.19 documentation</a></h1>
<div id="global-nav">
<a title="Home page" href="../index.html">Home</a> |
<a title="Table of contents" href="../contents.html">Table of contents</a> |
<a title="Global index" href="../genindex.html">Index</a> |
<a title="Module index" href="../py-modindex.html">Modules</a>
</div>
<div class="nav">
« <a href="1.6.1.html" title="Django 1.6.1 release notes">previous</a>
|
<a href="index.html" title="Release notes" accesskey="U">up</a>
|
<a href="1.5.12.html" title="Django 1.5.12 release notes">next</a> »</div>
</div>
<div id="bd">
<div id="yui-main">
<div class="yui-b">
<div class="yui-g" id="releases-1.6">
<div class="section" id="s-django-1-6-release-notes">
<span id="django-1-6-release-notes"></span><h1>Django 1.6 release notes<a class="headerlink" href="#django-1-6-release-notes" title="Permalink to this headline">¶</a></h1>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p>Dedicated to Malcolm Tredinnick</p>
<p>On March 17, 2013, the Django project and the free software community lost
a very dear friend and developer.</p>
<p>Malcolm was a long-time contributor to Django, a model community member, a
brilliant mind, and a friend. His contributions to Django — and to many other
open source projects — are nearly impossible to enumerate. Many on the core
Django team had their first patches reviewed by him; his mentorship enriched
us. His consideration, patience, and dedication will always be an inspiration
to us.</p>
<p>This release of Django is for Malcolm.</p>
<p class="last">– The Django Developers</p>
</div>
<p><em>November 6, 2013</em></p>
<p>Welcome to Django 1.6!</p>
<p>These release notes cover the <a class="reference internal" href="#whats-new-1-6"><span class="std std-ref">new features</span></a>, as well as
some <a class="reference internal" href="#backwards-incompatible-1-6"><span class="std std-ref">backwards incompatible changes</span></a> 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 <a class="reference internal" href="../internals/deprecation.html#deprecation-removed-in-1-6"><span class="std std-ref">our deprecation plan</span></a>, and we’ve <a class="reference internal" href="#deprecated-features-1-6"><span class="std std-ref">begun the deprecation process
for some features</span></a>.</p>
<div class="section" id="s-python-compatibility">
<span id="python-compatibility"></span><h2>Python compatibility<a class="headerlink" href="#python-compatibility" title="Permalink to this headline">¶</a></h2>
<p>Django 1.6, like Django 1.5, requires Python 2.6.5 or above. Python 3 is also
officially supported. We <strong>highly recommend</strong> the latest minor release for each
supported Python series (2.6.X, 2.7.X, 3.2.X, and 3.3.X).</p>
<p>Django 1.6 will be the final release series to support Python 2.6; beginning
with Django 1.7, the minimum supported Python version will be 2.7.</p>
<p>Python 3.4 is not supported, but support will be added in Django 1.7.</p>
</div>
<div class="section" id="s-what-s-new-in-django-1-6">
<span id="s-whats-new-1-6"></span><span id="what-s-new-in-django-1-6"></span><span id="whats-new-1-6"></span><h2>What’s new in Django 1.6<a class="headerlink" href="#what-s-new-in-django-1-6" title="Permalink to this headline">¶</a></h2>
<div class="section" id="s-simplified-default-project-and-app-templates">
<span id="simplified-default-project-and-app-templates"></span><h3>Simplified default project and app templates<a class="headerlink" href="#simplified-default-project-and-app-templates" title="Permalink to this headline">¶</a></h3>
<p>The default templates used by <a class="reference internal" href="../ref/django-admin.html#django-admin-startproject"><code class="xref std std-djadmin docutils literal"><span class="pre">startproject</span></code></a> and <a class="reference internal" href="../ref/django-admin.html#django-admin-startapp"><code class="xref std std-djadmin docutils literal"><span class="pre">startapp</span></code></a>
have been simplified and modernized. The <a class="reference internal" href="../ref/contrib/admin/index.html"><span class="doc">admin</span></a> is now enabled by default in new projects; the
<a class="reference internal" href="../ref/contrib/sites.html"><span class="doc">sites</span></a> framework no longer is. <a class="reference internal" href="../ref/clickjacking.html#clickjacking-prevention"><span class="std std-ref">clickjacking
prevention</span></a> is now on and the database defaults to
SQLite.</p>
<p>If the default templates don’t suit your tastes, you can use <a class="reference internal" href="../ref/django-admin.html#custom-app-and-project-templates"><span class="std std-ref">custom
project and app templates</span></a>.</p>
</div>
<div class="section" id="s-improved-transaction-management">
<span id="improved-transaction-management"></span><h3>Improved transaction management<a class="headerlink" href="#improved-transaction-management" title="Permalink to this headline">¶</a></h3>
<p>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 <a class="reference internal" href="../topics/db/transactions.html"><span class="doc">transaction management docs</span></a>.</p>
</div>
<div class="section" id="s-persistent-database-connections">
<span id="persistent-database-connections"></span><h3>Persistent database connections<a class="headerlink" href="#persistent-database-connections" title="Permalink to this headline">¶</a></h3>
<p>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. For backwards compatibility, this feature is disabled by
default. See <a class="reference internal" href="../ref/databases.html#persistent-database-connections"><span class="std std-ref">Persistent connections</span></a> for details.</p>
</div>
<div class="section" id="s-discovery-of-tests-in-any-test-module">
<span id="discovery-of-tests-in-any-test-module"></span><h3>Discovery of tests in any test module<a class="headerlink" href="#discovery-of-tests-in-any-test-module" title="Permalink to this headline">¶</a></h3>
<p>Django 1.6 ships with a new test runner that allows more flexibility in the
location of tests. The previous runner
(<code class="docutils literal"><span class="pre">django.test.simple.DjangoTestSuiteRunner</span></code>) found tests only in the
<code class="docutils literal"><span class="pre">models.py</span></code> and <code class="docutils literal"><span class="pre">tests.py</span></code> modules of a Python package in
<a class="reference internal" href="../ref/settings.html#std:setting-INSTALLED_APPS"><code class="xref std std-setting docutils literal"><span class="pre">INSTALLED_APPS</span></code></a>.</p>
<p>The new runner (<code class="docutils literal"><span class="pre">django.test.runner.DiscoverRunner</span></code>) uses the test discovery
features built into <code class="docutils literal"><span class="pre">unittest2</span></code> (the version of <code class="docutils literal"><span class="pre">unittest</span></code> in the
Python 2.7+ standard library, and bundled with Django). With test discovery,
tests can be located in any module whose name matches the pattern <code class="docutils literal"><span class="pre">test*.py</span></code>.</p>
<p>In addition, the test labels provided to <code class="docutils literal"><span class="pre">./manage.py</span> <span class="pre">test</span></code> to nominate
specific tests to run must now be full Python dotted paths (or directory
paths), rather than <code class="docutils literal"><span class="pre">applabel.TestCase.test_method_name</span></code> pseudo-paths. This
allows running tests located anywhere in your codebase, rather than only in
<a class="reference internal" href="../ref/settings.html#std:setting-INSTALLED_APPS"><code class="xref std std-setting docutils literal"><span class="pre">INSTALLED_APPS</span></code></a>. For more details, see <a class="reference internal" href="../topics/testing/index.html"><span class="doc">Testing in Django</span></a>.</p>
<p>This change is backwards-incompatible; see the <a class="reference internal" href="#new-test-runner"><span class="std std-ref">backwards-incompatibility
notes</span></a>.</p>
</div>
<div class="section" id="s-time-zone-aware-aggregation">
<span id="time-zone-aware-aggregation"></span><h3>Time zone aware aggregation<a class="headerlink" href="#time-zone-aware-aggregation" title="Permalink to this headline">¶</a></h3>
<p>The support for <a class="reference internal" href="../topics/i18n/timezones.html"><span class="doc">time zones</span></a> introduced in
Django 1.4 didn’t work well with <a class="reference internal" href="../ref/models/querysets.html#django.db.models.query.QuerySet.dates" title="django.db.models.query.QuerySet.dates"><code class="xref py py-meth docutils literal"><span class="pre">QuerySet.dates()</span></code></a>: aggregation was always performed in
UTC. This limitation was lifted in Django 1.6. Use <a class="reference internal" href="../ref/models/querysets.html#django.db.models.query.QuerySet.datetimes" title="django.db.models.query.QuerySet.datetimes"><code class="xref py py-meth docutils literal"><span class="pre">QuerySet.datetimes()</span></code></a> to perform time zone aware
aggregation on a <a class="reference internal" href="../ref/models/fields.html#django.db.models.DateTimeField" title="django.db.models.DateTimeField"><code class="xref py py-class docutils literal"><span class="pre">DateTimeField</span></code></a>.</p>
</div>
<div class="section" id="s-support-for-savepoints-in-sqlite">
<span id="support-for-savepoints-in-sqlite"></span><h3>Support for savepoints in SQLite<a class="headerlink" href="#support-for-savepoints-in-sqlite" title="Permalink to this headline">¶</a></h3>
<p>Django 1.6 adds support for savepoints in SQLite, with some <a class="reference internal" href="../topics/db/transactions.html#savepoints-in-sqlite"><span class="std std-ref">limitations</span></a>.</p>
</div>
<div class="section" id="s-binaryfield-model-field">
<span id="binaryfield-model-field"></span><h3><code class="docutils literal"><span class="pre">BinaryField</span></code> model field<a class="headerlink" href="#binaryfield-model-field" title="Permalink to this headline">¶</a></h3>
<p>A new <a class="reference internal" href="../ref/models/fields.html#django.db.models.BinaryField" title="django.db.models.BinaryField"><code class="xref py py-class docutils literal"><span class="pre">django.db.models.BinaryField</span></code></a> model field allows storage of raw
binary data in the database.</p>
</div>
<div class="section" id="s-geodjango-form-widgets">
<span id="geodjango-form-widgets"></span><h3>GeoDjango form widgets<a class="headerlink" href="#geodjango-form-widgets" title="Permalink to this headline">¶</a></h3>
<p>GeoDjango now provides <a class="reference internal" href="../ref/contrib/gis/forms-api.html"><span class="doc">form fields and widgets</span></a>
for its geo-specialized fields. They are OpenLayers-based by default, but they
can be customized to use any other JS framework.</p>
</div>
<div class="section" id="s-check-management-command-added-for-verifying-compatibility">
<span id="check-management-command-added-for-verifying-compatibility"></span><h3><code class="docutils literal"><span class="pre">check</span></code> management command added for verifying compatibility<a class="headerlink" href="#check-management-command-added-for-verifying-compatibility" title="Permalink to this headline">¶</a></h3>
<p>A <a class="reference internal" href="../ref/django-admin.html#django-admin-check"><code class="xref std std-djadmin docutils literal"><span class="pre">check</span></code></a> management command was added, enabling you to verify if your
current configuration (currently oriented at settings) is compatible with the
current version of Django.</p>
</div>
<div class="section" id="s-model-save-algorithm-changed">
<span id="model-save-algorithm-changed"></span><h3><a class="reference internal" href="../ref/models/instances.html#django.db.models.Model.save" title="django.db.models.Model.save"><code class="xref py py-meth docutils literal"><span class="pre">Model.save()</span></code></a> algorithm changed<a class="headerlink" href="#model-save-algorithm-changed" title="Permalink to this headline">¶</a></h3>
<p>The <a class="reference internal" href="../ref/models/instances.html#django.db.models.Model.save" title="django.db.models.Model.save"><code class="xref py py-meth docutils literal"><span class="pre">Model.save()</span></code></a> method now
tries to directly <code class="docutils literal"><span class="pre">UPDATE</span></code> the database if the instance has a primary
key value. Previously <code class="docutils literal"><span class="pre">SELECT</span></code> was performed to determine if <code class="docutils literal"><span class="pre">UPDATE</span></code>
or <code class="docutils literal"><span class="pre">INSERT</span></code> were needed. The new algorithm needs only one query for
updating an existing row while the old algorithm needed two. See
<a class="reference internal" href="../ref/models/instances.html#django.db.models.Model.save" title="django.db.models.Model.save"><code class="xref py py-meth docutils literal"><span class="pre">Model.save()</span></code></a> for more details.</p>
<p>In some rare cases the database doesn’t report that a matching row was
found when doing an <code class="docutils literal"><span class="pre">UPDATE</span></code>. An example is the PostgreSQL <code class="docutils literal"><span class="pre">ON</span> <span class="pre">UPDATE</span></code>
trigger which returns <code class="docutils literal"><span class="pre">NULL</span></code>. In such cases it is possible to set
<a class="reference internal" href="../ref/models/options.html#django.db.models.Options.select_on_save" title="django.db.models.Options.select_on_save"><code class="xref py py-attr docutils literal"><span class="pre">django.db.models.Options.select_on_save</span></code></a> flag to force saving to
use the old algorithm.</p>
</div>
<div class="section" id="s-minor-features">
<span id="minor-features"></span><h3>Minor features<a class="headerlink" href="#minor-features" title="Permalink to this headline">¶</a></h3>
<ul class="simple">
<li>Authentication backends can raise <code class="docutils literal"><span class="pre">PermissionDenied</span></code> to immediately fail
the authentication chain.</li>
<li>The <code class="docutils literal"><span class="pre">HttpOnly</span></code> flag can be set on the CSRF cookie with
<a class="reference internal" href="../ref/settings.html#std:setting-CSRF_COOKIE_HTTPONLY"><code class="xref std std-setting docutils literal"><span class="pre">CSRF_COOKIE_HTTPONLY</span></code></a>.</li>
<li>The <a class="reference internal" href="../topics/testing/tools.html#django.test.TransactionTestCase.assertQuerysetEqual" title="django.test.TransactionTestCase.assertQuerysetEqual"><code class="xref py py-meth docutils literal"><span class="pre">assertQuerysetEqual()</span></code></a> now checks
for undefined order and raises <code class="xref py py-exc docutils literal"><span class="pre">ValueError</span></code> if undefined
order is spotted. The order is seen as undefined if the given <code class="docutils literal"><span class="pre">QuerySet</span></code>
isn’t ordered and there are more than one ordered values to compare against.</li>
<li>Added <a class="reference internal" href="../ref/models/querysets.html#django.db.models.query.QuerySet.earliest" title="django.db.models.query.QuerySet.earliest"><code class="xref py py-meth docutils literal"><span class="pre">earliest()</span></code></a> for symmetry with
<a class="reference internal" href="../ref/models/querysets.html#django.db.models.query.QuerySet.latest" title="django.db.models.query.QuerySet.latest"><code class="xref py py-meth docutils literal"><span class="pre">latest()</span></code></a>.</li>
<li>In addition to <a class="reference internal" href="../ref/models/querysets.html#std:fieldlookup-year"><code class="xref std std-lookup docutils literal"><span class="pre">year</span></code></a>, <a class="reference internal" href="../ref/models/querysets.html#std:fieldlookup-month"><code class="xref std std-lookup docutils literal"><span class="pre">month</span></code></a> and <a class="reference internal" href="../ref/models/querysets.html#std:fieldlookup-day"><code class="xref std std-lookup docutils literal"><span class="pre">day</span></code></a>, the ORM
now supports <a class="reference internal" href="../ref/models/querysets.html#std:fieldlookup-hour"><code class="xref std std-lookup docutils literal"><span class="pre">hour</span></code></a>, <a class="reference internal" href="../ref/models/querysets.html#std:fieldlookup-minute"><code class="xref std std-lookup docutils literal"><span class="pre">minute</span></code></a> and <a class="reference internal" href="../ref/models/querysets.html#std:fieldlookup-second"><code class="xref std std-lookup docutils literal"><span class="pre">second</span></code></a> lookups.</li>
<li>Django now wraps all PEP-249 exceptions.</li>
<li>The default widgets for <a class="reference internal" href="../ref/forms/fields.html#django.forms.EmailField" title="django.forms.EmailField"><code class="xref py py-class docutils literal"><span class="pre">EmailField</span></code></a>,
<a class="reference internal" href="../ref/forms/fields.html#django.forms.URLField" title="django.forms.URLField"><code class="xref py py-class docutils literal"><span class="pre">URLField</span></code></a>, <a class="reference internal" href="../ref/forms/fields.html#django.forms.IntegerField" title="django.forms.IntegerField"><code class="xref py py-class docutils literal"><span class="pre">IntegerField</span></code></a>,
<a class="reference internal" href="../ref/forms/fields.html#django.forms.FloatField" title="django.forms.FloatField"><code class="xref py py-class docutils literal"><span class="pre">FloatField</span></code></a> and <a class="reference internal" href="../ref/forms/fields.html#django.forms.DecimalField" title="django.forms.DecimalField"><code class="xref py py-class docutils literal"><span class="pre">DecimalField</span></code></a> use
the new type attributes available in HTML5 (<code class="docutils literal"><span class="pre">type='email'</span></code>, <code class="docutils literal"><span class="pre">type='url'</span></code>,
<code class="docutils literal"><span class="pre">type='number'</span></code>). Note that due to erratic support of the <code class="docutils literal"><span class="pre">number</span></code>
input type with localized numbers in current browsers, Django only uses it
when numeric fields are not localized.</li>
<li>The <code class="docutils literal"><span class="pre">number</span></code> argument for <a class="reference internal" href="../topics/i18n/translation.html#lazy-plural-translations"><span class="std std-ref">lazy plural translations</span></a> can be provided at translation time rather than
at definition time.</li>
<li>For custom management commands: Verification of the presence of valid
settings in commands that ask for it by using the
<a class="reference internal" href="../howto/custom-management-commands.html#django.core.management.BaseCommand.can_import_settings" title="django.core.management.BaseCommand.can_import_settings"><code class="xref py py-attr docutils literal"><span class="pre">can_import_settings</span></code></a> 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
<a class="reference internal" href="../howto/custom-management-commands.html#django.core.management.BaseCommand.leave_locale_alone" title="django.core.management.BaseCommand.leave_locale_alone"><code class="xref py py-attr docutils literal"><span class="pre">leave_locale_alone</span></code></a> internal
option. See <a class="reference internal" href="../howto/custom-management-commands.html#management-commands-and-locales"><span class="std std-ref">Management commands and locales</span></a> for more details.</li>
<li>The <a class="reference internal" href="../ref/class-based-views/mixins-editing.html#django.views.generic.edit.DeletionMixin.success_url" title="django.views.generic.edit.DeletionMixin.success_url"><code class="xref py py-attr docutils literal"><span class="pre">success_url</span></code></a> of
<a class="reference internal" href="../ref/class-based-views/mixins-editing.html#django.views.generic.edit.DeletionMixin" title="django.views.generic.edit.DeletionMixin"><code class="xref py py-class docutils literal"><span class="pre">DeletionMixin</span></code></a> is now interpolated with
its <code class="docutils literal"><span class="pre">object</span></code>’s <code class="docutils literal"><span class="pre">__dict__</span></code>.</li>
<li><a class="reference internal" href="../ref/request-response.html#django.http.HttpResponseRedirect" title="django.http.HttpResponseRedirect"><code class="xref py py-class docutils literal"><span class="pre">HttpResponseRedirect</span></code></a> and
<a class="reference internal" href="../ref/request-response.html#django.http.HttpResponsePermanentRedirect" title="django.http.HttpResponsePermanentRedirect"><code class="xref py py-class docutils literal"><span class="pre">HttpResponsePermanentRedirect</span></code></a> now provide an <code class="docutils literal"><span class="pre">url</span></code>
attribute (equivalent to the URL the response will redirect to).</li>
<li>The <code class="docutils literal"><span class="pre">MemcachedCache</span></code> cache backend now uses the latest <code class="xref py py-mod docutils literal"><span class="pre">pickle</span></code>
protocol available.</li>
<li>Added <a class="reference internal" href="../ref/contrib/messages.html#django.contrib.messages.views.SuccessMessageMixin" title="django.contrib.messages.views.SuccessMessageMixin"><code class="xref py py-class docutils literal"><span class="pre">SuccessMessageMixin</span></code></a> which
provides a <code class="docutils literal"><span class="pre">success_message</span></code> attribute for
<a class="reference internal" href="../ref/class-based-views/generic-editing.html#django.views.generic.edit.FormView" title="django.views.generic.edit.FormView"><code class="xref py py-class docutils literal"><span class="pre">FormView</span></code></a> based classes.</li>
<li>Added the <a class="reference internal" href="../ref/models/fields.html#django.db.models.ForeignKey.db_constraint" title="django.db.models.ForeignKey.db_constraint"><code class="xref py py-attr docutils literal"><span class="pre">django.db.models.ForeignKey.db_constraint</span></code></a> and
<a class="reference internal" href="../ref/models/fields.html#django.db.models.ManyToManyField.db_constraint" title="django.db.models.ManyToManyField.db_constraint"><code class="xref py py-attr docutils literal"><span class="pre">django.db.models.ManyToManyField.db_constraint</span></code></a> options.</li>
<li>The jQuery library embedded in the admin has been upgraded to version 1.9.1.</li>
<li>Syndication feeds (<a class="reference internal" href="../ref/contrib/syndication.html#module-django.contrib.syndication" title="django.contrib.syndication: A framework for generating syndication feeds, in RSS and Atom, quite easily."><code class="xref py py-mod docutils literal"><span class="pre">django.contrib.syndication</span></code></a>) can now pass extra
context through to feed templates using a new
<a class="reference internal" href="../ref/contrib/syndication.html#django.contrib.syndication.Feed.get_context_data" title="django.contrib.syndication.Feed.get_context_data"><code class="xref py py-meth docutils literal"><span class="pre">Feed.get_context_data()</span></code></a> callback.</li>
<li>The admin list columns have a <code class="docutils literal"><span class="pre">column-<field_name></span></code> class in the HTML
so the columns header can be styled with CSS, e.g. to set a column width.</li>
<li>The <a class="reference internal" href="../ref/databases.html#database-isolation-level"><span class="std std-ref">isolation level</span></a> can be customized under
PostgreSQL.</li>
<li>The <a class="reference internal" href="../topics/i18n/translation.html#std:templatetag-blocktrans"><code class="xref std std-ttag docutils literal"><span class="pre">blocktrans</span></code></a> template tag now respects
<code class="docutils literal"><span class="pre">TEMPLATE_STRING_IF_INVALID</span></code> for variables not present in the
context, just like other template constructs.</li>
<li><code class="docutils literal"><span class="pre">SimpleLazyObject</span></code>s will now present more helpful representations in shell
debugging situations.</li>
<li>Generic <a class="reference internal" href="../ref/contrib/gis/model-api.html#django.contrib.gis.db.models.GeometryField" title="django.contrib.gis.db.models.GeometryField"><code class="xref py py-class docutils literal"><span class="pre">GeometryField</span></code></a> is now editable
with the OpenLayers widget in the admin.</li>
<li>The documentation contains a <a class="reference internal" href="../howto/deployment/checklist.html"><span class="doc">deployment checklist</span></a>.</li>
<li>The <a class="reference internal" href="../ref/django-admin.html#django-admin-diffsettings"><code class="xref std std-djadmin docutils literal"><span class="pre">diffsettings</span></code></a> command gained a <code class="docutils literal"><span class="pre">--all</span></code> option.</li>
<li><code class="docutils literal"><span class="pre">django.forms.fields.Field.__init__</span></code> now calls <code class="docutils literal"><span class="pre">super()</span></code>, allowing
field mixins to implement <code class="docutils literal"><span class="pre">__init__()</span></code> methods that will reliably be
called.</li>
<li>The <code class="docutils literal"><span class="pre">validate_max</span></code> parameter was added to <code class="docutils literal"><span class="pre">BaseFormSet</span></code> and
<a class="reference internal" href="../ref/forms/formsets.html#django.forms.formsets.formset_factory" title="django.forms.formsets.formset_factory"><code class="xref py py-func docutils literal"><span class="pre">formset_factory()</span></code></a>, and <code class="docutils literal"><span class="pre">ModelForm</span></code> and inline
versions of the same. The behavior of validation for formsets with
<code class="docutils literal"><span class="pre">max_num</span></code> 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 <code class="docutils literal"><span class="pre">max_num</span></code> forms
was changed so it is always 1000 more than <code class="docutils literal"><span class="pre">max_num</span></code>.</li>
<li>Added <code class="docutils literal"><span class="pre">BCryptSHA256PasswordHasher</span></code> to resolve the password truncation issue
with bcrypt.</li>
<li><a class="reference external" href="https://pypi.python.org/pypi/Pillow">Pillow</a> is now the preferred image manipulation library to use with Django.
<a class="reference external" href="https://pypi.python.org/pypi/PIL">PIL</a> is pending deprecation (support to be removed in Django 1.8).
To upgrade, you should <strong>first</strong> uninstall PIL, <strong>then</strong> install Pillow.</li>
</ul>
<ul class="simple">
<li><a class="reference internal" href="../topics/forms/modelforms.html#django.forms.ModelForm" title="django.forms.ModelForm"><code class="xref py py-class docutils literal"><span class="pre">ModelForm</span></code></a> accepts several new <code class="docutils literal"><span class="pre">Meta</span></code>
options.<ul>
<li>Fields included in the <code class="docutils literal"><span class="pre">localized_fields</span></code> list will be localized
(by setting <code class="docutils literal"><span class="pre">localize</span></code> on the form field).</li>
<li>The <code class="docutils literal"><span class="pre">labels</span></code>, <code class="docutils literal"><span class="pre">help_texts</span></code> and <code class="docutils literal"><span class="pre">error_messages</span></code> options may be used
to customize the default fields, see
<a class="reference internal" href="../topics/forms/modelforms.html#modelforms-overriding-default-fields"><span class="std std-ref">Overriding the default fields</span></a> for details.</li>
</ul>
</li>
<li>The <code class="docutils literal"><span class="pre">choices</span></code> argument to model fields now accepts an iterable of iterables
instead of requiring an iterable of lists or tuples.</li>
<li>The reason phrase can be customized in HTTP responses using
<a class="reference internal" href="../ref/request-response.html#django.http.HttpResponse.reason_phrase" title="django.http.HttpResponse.reason_phrase"><code class="xref py py-attr docutils literal"><span class="pre">reason_phrase</span></code></a>.</li>
<li>When giving the URL of the next page for
<a class="reference internal" href="../topics/auth/default.html#django.contrib.auth.views.logout" title="django.contrib.auth.views.logout"><code class="xref py py-func docutils literal"><span class="pre">logout()</span></code></a>,
<a class="reference internal" href="../topics/auth/default.html#django.contrib.auth.views.password_reset" title="django.contrib.auth.views.password_reset"><code class="xref py py-func docutils literal"><span class="pre">password_reset()</span></code></a>,
<a class="reference internal" href="../topics/auth/default.html#django.contrib.auth.views.password_reset_confirm" title="django.contrib.auth.views.password_reset_confirm"><code class="xref py py-func docutils literal"><span class="pre">password_reset_confirm()</span></code></a>,
and <a class="reference internal" href="../topics/auth/default.html#django.contrib.auth.views.password_change" title="django.contrib.auth.views.password_change"><code class="xref py py-func docutils literal"><span class="pre">password_change()</span></code></a>, you can now pass
URL names and they will be resolved.</li>
<li>The <a class="reference internal" href="../ref/django-admin.html#django-admin-dumpdata"><code class="xref std std-djadmin docutils literal"><span class="pre">dumpdata</span></code></a> <code class="docutils literal"><span class="pre">manage.py</span></code> command now has a <a class="reference internal" href="../ref/django-admin.html#django-admin-option---pks"><code class="xref std std-djadminopt docutils literal"><span class="pre">--pks</span></code></a>
option which will allow users to specify the primary keys of objects they
want to dump. This option can only be used with one model.</li>
<li>Added <code class="docutils literal"><span class="pre">QuerySet</span></code> methods <a class="reference internal" href="../ref/models/querysets.html#django.db.models.query.QuerySet.first" title="django.db.models.query.QuerySet.first"><code class="xref py py-meth docutils literal"><span class="pre">first()</span></code></a>
and <a class="reference internal" href="../ref/models/querysets.html#django.db.models.query.QuerySet.last" title="django.db.models.query.QuerySet.last"><code class="xref py py-meth docutils literal"><span class="pre">last()</span></code></a> which are convenience
methods returning the first or last object matching the filters. Returns
<code class="docutils literal"><span class="pre">None</span></code> if there are no objects matching.</li>
<li><a class="reference internal" href="../ref/class-based-views/base.html#django.views.generic.base.View" title="django.views.generic.base.View"><code class="xref py py-class docutils literal"><span class="pre">View</span></code></a> and
<a class="reference internal" href="../ref/class-based-views/base.html#django.views.generic.base.RedirectView" title="django.views.generic.base.RedirectView"><code class="xref py py-class docutils literal"><span class="pre">RedirectView</span></code></a> now support HTTP <code class="docutils literal"><span class="pre">PATCH</span></code>
method.</li>
<li><code class="docutils literal"><span class="pre">GenericForeignKey</span></code> now takes an optional <code class="docutils literal"><span class="pre">for_concrete_model</span></code> argument,
which when set to <code class="docutils literal"><span class="pre">False</span></code> allows the field to reference proxy models. The
default is <code class="docutils literal"><span class="pre">True</span></code> to retain the old behavior.</li>
<li>The <a class="reference internal" href="../ref/middleware.html#django.middleware.locale.LocaleMiddleware" title="django.middleware.locale.LocaleMiddleware"><code class="xref py py-class docutils literal"><span class="pre">LocaleMiddleware</span></code></a> now stores the active
language in session if it is not present there. This prevents loss of
language settings after session flush, e.g. logout.</li>
<li><a class="reference internal" href="../ref/exceptions.html#django.core.exceptions.SuspiciousOperation" title="django.core.exceptions.SuspiciousOperation"><code class="xref py py-exc docutils literal"><span class="pre">SuspiciousOperation</span></code></a> has been differentiated
into a number of subclasses, and each will log to a matching named logger
under the <code class="docutils literal"><span class="pre">django.security</span></code> logging hierarchy. Along with this change,
a <code class="docutils literal"><span class="pre">handler400</span></code> mechanism and default view are used whenever
a <code class="docutils literal"><span class="pre">SuspiciousOperation</span></code> reaches the WSGI handler to return an
<code class="docutils literal"><span class="pre">HttpResponseBadRequest</span></code>.</li>
<li>The <a class="reference internal" href="../ref/models/instances.html#django.db.models.Model.DoesNotExist" title="django.db.models.Model.DoesNotExist"><code class="xref py py-exc docutils literal"><span class="pre">DoesNotExist</span></code></a> exception now includes a
message indicating the name of the attribute used for the lookup.</li>
<li>The <a class="reference internal" href="../ref/models/querysets.html#django.db.models.query.QuerySet.get_or_create" title="django.db.models.query.QuerySet.get_or_create"><code class="xref py py-meth docutils literal"><span class="pre">get_or_create()</span></code></a> method no longer
requires at least one keyword argument.</li>
<li>The <a class="reference internal" href="../topics/testing/tools.html#django.test.SimpleTestCase" title="django.test.SimpleTestCase"><code class="xref py py-class docutils literal"><span class="pre">SimpleTestCase</span></code></a> class includes a new assertion
helper for testing formset errors:
<a class="reference internal" href="../topics/testing/tools.html#django.test.SimpleTestCase.assertFormsetError" title="django.test.SimpleTestCase.assertFormsetError"><code class="xref py py-meth docutils literal"><span class="pre">assertFormsetError()</span></code></a>.</li>
<li>The list of related fields added to a
<a class="reference internal" href="../ref/models/querysets.html#django.db.models.query.QuerySet" title="django.db.models.query.QuerySet"><code class="xref py py-class docutils literal"><span class="pre">QuerySet</span></code></a> by
<a class="reference internal" href="../ref/models/querysets.html#django.db.models.query.QuerySet.select_related" title="django.db.models.query.QuerySet.select_related"><code class="xref py py-meth docutils literal"><span class="pre">select_related()</span></code></a> can be cleared using
<code class="docutils literal"><span class="pre">select_related(None)</span></code>.</li>
<li>The <a class="reference internal" href="../ref/contrib/admin/index.html#django.contrib.admin.InlineModelAdmin.get_extra" title="django.contrib.admin.InlineModelAdmin.get_extra"><code class="xref py py-meth docutils literal"><span class="pre">get_extra()</span></code></a> and
<a class="reference internal" href="../ref/contrib/admin/index.html#django.contrib.admin.InlineModelAdmin.get_max_num" title="django.contrib.admin.InlineModelAdmin.get_max_num"><code class="xref py py-meth docutils literal"><span class="pre">get_max_num()</span></code></a> methods on
<a class="reference internal" href="../ref/contrib/admin/index.html#django.contrib.admin.InlineModelAdmin" title="django.contrib.admin.InlineModelAdmin"><code class="xref py py-class docutils literal"><span class="pre">InlineModelAdmin</span></code></a> may be overridden to
customize the extra and maximum number of inline forms.</li>
<li>Formsets now have a
<a class="reference internal" href="../topics/forms/formsets.html#django.forms.formsets.BaseFormSet.total_error_count" title="django.forms.formsets.BaseFormSet.total_error_count"><code class="xref py py-meth docutils literal"><span class="pre">total_error_count()</span></code></a> method.</li>
<li><a class="reference internal" href="../topics/forms/modelforms.html#django.forms.ModelForm" title="django.forms.ModelForm"><code class="xref py py-class docutils literal"><span class="pre">ModelForm</span></code></a> fields can now override error messages
defined in model fields by using the
<a class="reference internal" href="../ref/forms/fields.html#django.forms.Field.error_messages" title="django.forms.Field.error_messages"><code class="xref py py-attr docutils literal"><span class="pre">error_messages</span></code></a> argument of a <code class="docutils literal"><span class="pre">Field</span></code>’s
constructor. To take advantage of this new feature with your custom fields,
<a class="reference internal" href="../ref/forms/validation.html#raising-validation-error"><span class="std std-ref">see the updated recommendation</span></a> for raising
a <code class="docutils literal"><span class="pre">ValidationError</span></code>.</li>
<li><a class="reference internal" href="../ref/contrib/admin/index.html#django.contrib.admin.ModelAdmin" title="django.contrib.admin.ModelAdmin"><code class="xref py py-class docutils literal"><span class="pre">ModelAdmin</span></code></a> now preserves filters on the list view
after creating, editing or deleting an object. It’s possible to restore the previous
behavior of clearing filters by setting the
<a class="reference internal" href="../ref/contrib/admin/index.html#django.contrib.admin.ModelAdmin.preserve_filters" title="django.contrib.admin.ModelAdmin.preserve_filters"><code class="xref py py-attr docutils literal"><span class="pre">preserve_filters</span></code></a> attribute to <code class="docutils literal"><span class="pre">False</span></code>.</li>
<li>Added
<a class="reference internal" href="../ref/class-based-views/mixins-editing.html#django.views.generic.edit.FormMixin.get_prefix" title="django.views.generic.edit.FormMixin.get_prefix"><code class="xref py py-meth docutils literal"><span class="pre">FormMixin.get_prefix</span></code></a>
(which returns
<a class="reference internal" href="../ref/class-based-views/mixins-editing.html#django.views.generic.edit.FormMixin.prefix" title="django.views.generic.edit.FormMixin.prefix"><code class="xref py py-attr docutils literal"><span class="pre">FormMixin.prefix</span></code></a> by
default) to allow customizing the <a class="reference internal" href="../ref/forms/api.html#django.forms.Form.prefix" title="django.forms.Form.prefix"><code class="xref py py-attr docutils literal"><span class="pre">prefix</span></code></a> of the
form.</li>
<li>Raw queries (<code class="docutils literal"><span class="pre">Manager.raw()</span></code> or <code class="docutils literal"><span class="pre">cursor.execute()</span></code>) can now use the
“pyformat” parameter style, where placeholders in the query are given as
<code class="docutils literal"><span class="pre">'%(name)s'</span></code> and the parameters are passed as a dictionary rather than
a list (except on SQLite). This has long been possible (but not officially
supported) on MySQL and PostgreSQL, and is now also available on Oracle.</li>
<li>The default iteration count for the PBKDF2 password hasher has been
increased by 20%. This backwards compatible change will not affect
existing passwords or users who have subclassed
<code class="docutils literal"><span class="pre">django.contrib.auth.hashers.PBKDF2PasswordHasher</span></code> to change the
default value. Passwords <a class="reference internal" href="../topics/auth/passwords.html#password-upgrades"><span class="std std-ref">will be upgraded</span></a> to use
the new iteration count as necessary.</li>
</ul>
</div>
</div>
<div class="section" id="s-backwards-incompatible-changes-in-1-6">
<span id="s-backwards-incompatible-1-6"></span><span id="backwards-incompatible-changes-in-1-6"></span><span id="backwards-incompatible-1-6"></span><h2>Backwards incompatible changes in 1.6<a class="headerlink" href="#backwards-incompatible-changes-in-1-6" title="Permalink to this headline">¶</a></h2>
<div class="admonition warning">
<p class="first admonition-title">Warning</p>
<p class="last">In addition to the changes outlined in this section, be sure to review the
<a class="reference internal" href="../internals/deprecation.html#deprecation-removed-in-1-6"><span class="std std-ref">deprecation plan</span></a> 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.</p>
</div>
<div class="section" id="s-new-transaction-management-model">
<span id="new-transaction-management-model"></span><h3>New transaction management model<a class="headerlink" href="#new-transaction-management-model" title="Permalink to this headline">¶</a></h3>
<div class="section" id="s-behavior-changes">
<span id="behavior-changes"></span><h4>Behavior changes<a class="headerlink" href="#behavior-changes" title="Permalink to this headline">¶</a></h4>
<p>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 backwards-incompatibilities.</p>
</div>
<div class="section" id="s-savepoints-and-assertnumqueries">
<span id="savepoints-and-assertnumqueries"></span><h4>Savepoints and <code class="docutils literal"><span class="pre">assertNumQueries</span></code><a class="headerlink" href="#savepoints-and-assertnumqueries" title="Permalink to this headline">¶</a></h4>
<p>The changes in transaction management may result in additional statements to
create, release or rollback savepoints. This is more likely to happen with
SQLite, since it didn’t support savepoints until this release.</p>
<p>If tests using <a class="reference internal" href="../topics/testing/tools.html#django.test.TransactionTestCase.assertNumQueries" title="django.test.TransactionTestCase.assertNumQueries"><code class="xref py py-meth docutils literal"><span class="pre">assertNumQueries()</span></code></a> fail
because of a higher number of queries than expected, check that the extra
queries are related to savepoints, and adjust the expected number of queries
accordingly.</p>
</div>
<div class="section" id="s-autocommit-option-for-postgresql">
<span id="autocommit-option-for-postgresql"></span><h4>Autocommit option for PostgreSQL<a class="headerlink" href="#autocommit-option-for-postgresql" title="Permalink to this headline">¶</a></h4>
<p>In previous versions, database-level autocommit was only an option for
PostgreSQL, and it was disabled by default. This option is now ignored and can
be removed.</p>
</div>
</div>
<div class="section" id="s-new-test-runner">
<span id="s-id1"></span><span id="new-test-runner"></span><span id="id1"></span><h3>New test runner<a class="headerlink" href="#new-test-runner" title="Permalink to this headline">¶</a></h3>
<p>In order to maintain greater consistency with Python’s unittest module, the new
test runner (<code class="docutils literal"><span class="pre">django.test.runner.DiscoverRunner</span></code>) does not automatically
support some types of tests that were supported by the previous runner:</p>
<ul class="simple">
<li>Tests in <code class="docutils literal"><span class="pre">models.py</span></code> and <code class="docutils literal"><span class="pre">tests/__init__.py</span></code> files will no longer be
found and run. Move them to a file whose name begins with <code class="docutils literal"><span class="pre">test</span></code>.</li>
<li>Doctests will no longer be automatically discovered. To integrate doctests in
your test suite, follow the <a class="reference external" href="https://docs.python.org/library/doctest.html#unittest-api">recommendations in the Python documentation</a>.</li>
</ul>
<p>Django bundles a modified version of the <code class="xref py py-mod docutils literal"><span class="pre">doctest</span></code> module from the Python
standard library (in <code class="docutils literal"><span class="pre">django.test._doctest</span></code>) and includes some additional
doctest utilities. These utilities are deprecated and will be removed in Django
1.8; doctest suites should be updated to work with the standard library’s
doctest module (or converted to unittest-compatible tests).</p>
<p>If you wish to delay updates to your test suite, you can set your
<a class="reference internal" href="../ref/settings.html#std:setting-TEST_RUNNER"><code class="xref std std-setting docutils literal"><span class="pre">TEST_RUNNER</span></code></a> setting to <code class="docutils literal"><span class="pre">django.test.simple.DjangoTestSuiteRunner</span></code>
to fully restore the old test behavior. <code class="docutils literal"><span class="pre">DjangoTestSuiteRunner</span></code> is deprecated
but will not be removed from Django until version 1.8.</p>
</div>
<div class="section" id="s-removal-of-django-contrib-gis-tests-geodjangotestsuiterunner-geodjango-custom-test-runner">
<span id="removal-of-django-contrib-gis-tests-geodjangotestsuiterunner-geodjango-custom-test-runner"></span><h3>Removal of <code class="docutils literal"><span class="pre">django.contrib.gis.tests.GeoDjangoTestSuiteRunner</span></code> GeoDjango custom test runner<a class="headerlink" href="#removal-of-django-contrib-gis-tests-geodjangotestsuiterunner-geodjango-custom-test-runner" title="Permalink to this headline">¶</a></h3>
<p>This is for developers working on the GeoDjango application itself and related
to the item above about changes in the test runners:</p>
<p>The <code class="docutils literal"><span class="pre">django.contrib.gis.tests.GeoDjangoTestSuiteRunner</span></code> test runner has been
removed and the standalone GeoDjango tests execution setup it implemented isn’t
supported anymore. To run the GeoDjango tests simply use the new
<code class="docutils literal"><span class="pre">DiscoverRunner</span></code> and specify the <code class="docutils literal"><span class="pre">django.contrib.gis</span></code> app.</p>
</div>
<div class="section" id="s-custom-user-models-in-tests">
<span id="custom-user-models-in-tests"></span><h3>Custom User models in tests<a class="headerlink" href="#custom-user-models-in-tests" title="Permalink to this headline">¶</a></h3>
<p>The introduction of the new test runner has also slightly changed the way that
test models are imported. As a result, any test that overrides <code class="docutils literal"><span class="pre">AUTH_USER_MODEL</span></code>
to test behavior with one of Django’s test user models (
<code class="docutils literal"><span class="pre">django.contrib.auth.tests.custom_user.CustomUser</span></code> and
<code class="docutils literal"><span class="pre">django.contrib.auth.tests.custom_user.ExtensionUser</span></code>) must now
explicitly import the User model in your test module:</p>
<div class="highlight-default"><div class="highlight"><pre><span></span><span class="kn">from</span> <span class="nn">django.contrib.auth.tests.custom_user</span> <span class="k">import</span> <span class="n">CustomUser</span>
<span class="nd">@override_settings</span><span class="p">(</span><span class="n">AUTH_USER_MODEL</span><span class="o">=</span><span class="s1">'auth.CustomUser'</span><span class="p">)</span>
<span class="k">class</span> <span class="nc">CustomUserFeatureTests</span><span class="p">(</span><span class="n">TestCase</span><span class="p">):</span>
<span class="k">def</span> <span class="nf">test_something</span><span class="p">(</span><span class="bp">self</span><span class="p">):</span>
<span class="c1"># Test code here ...</span>
</pre></div>
</div>
<p>This import forces the custom user model to be registered. Without this import,
the test will be unable to swap in the custom user model, and you will get an
error reporting:</p>
<div class="highlight-default"><div class="highlight"><pre><span></span><span class="n">ImproperlyConfigured</span><span class="p">:</span> <span class="n">AUTH_USER_MODEL</span> <span class="n">refers</span> <span class="n">to</span> <span class="n">model</span> <span class="s1">'auth.CustomUser'</span> <span class="n">that</span> <span class="n">has</span> <span class="ow">not</span> <span class="n">been</span> <span class="n">installed</span>
</pre></div>
</div>
</div>
<div class="section" id="s-time-zone-aware-day-month-and-week-day-lookups">
<span id="time-zone-aware-day-month-and-week-day-lookups"></span><h3>Time zone-aware <code class="docutils literal"><span class="pre">day</span></code>, <code class="docutils literal"><span class="pre">month</span></code>, and <code class="docutils literal"><span class="pre">week_day</span></code> lookups<a class="headerlink" href="#time-zone-aware-day-month-and-week-day-lookups" title="Permalink to this headline">¶</a></h3>
<p>Django 1.6 introduces time zone support for <a class="reference internal" href="../ref/models/querysets.html#std:fieldlookup-day"><code class="xref std std-lookup docutils literal"><span class="pre">day</span></code></a>, <a class="reference internal" href="../ref/models/querysets.html#std:fieldlookup-month"><code class="xref std std-lookup docutils literal"><span class="pre">month</span></code></a>,
and <a class="reference internal" href="../ref/models/querysets.html#std:fieldlookup-week_day"><code class="xref std std-lookup docutils literal"><span class="pre">week_day</span></code></a> lookups when <a class="reference internal" href="../ref/settings.html#std:setting-USE_TZ"><code class="xref std std-setting docutils literal"><span class="pre">USE_TZ</span></code></a> is <code class="docutils literal"><span class="pre">True</span></code>. These
lookups were previously performed in UTC regardless of the current time zone.</p>
<p>This requires <a class="reference internal" href="../ref/models/querysets.html#database-time-zone-definitions"><span class="std std-ref">time zone definitions in the database</span></a>. If you’re using SQLite, you must install
<a class="reference external" href="http://pytz.sourceforge.net/">pytz</a>. If you’re using MySQL, you must install <a class="reference external" href="http://pytz.sourceforge.net/">pytz</a> and load the time zone
tables with <a class="reference external" href="http://dev.mysql.com/doc/refman/5.6/en/mysql-tzinfo-to-sql.html">mysql_tzinfo_to_sql</a>.</p>
</div>
<div class="section" id="s-addition-of-queryset-datetimes">
<span id="addition-of-queryset-datetimes"></span><h3>Addition of <code class="docutils literal"><span class="pre">QuerySet.datetimes()</span></code><a class="headerlink" href="#addition-of-queryset-datetimes" title="Permalink to this headline">¶</a></h3>
<p>When the <a class="reference internal" href="../topics/i18n/timezones.html"><span class="doc">time zone support</span></a> added in Django 1.4
was active, <a class="reference internal" href="../ref/models/querysets.html#django.db.models.query.QuerySet.dates" title="django.db.models.query.QuerySet.dates"><code class="xref py py-meth docutils literal"><span class="pre">QuerySet.dates()</span></code></a>
lookups returned unexpected results, because the aggregation was performed in
UTC. To fix this, Django 1.6 introduces a new API, <a class="reference internal" href="../ref/models/querysets.html#django.db.models.query.QuerySet.datetimes" title="django.db.models.query.QuerySet.datetimes"><code class="xref py py-meth docutils literal"><span class="pre">QuerySet.datetimes()</span></code></a>. This requires a few changes in
your code.</p>
<div class="section" id="s-queryset-dates-returns-date-objects">
<span id="queryset-dates-returns-date-objects"></span><h4><code class="docutils literal"><span class="pre">QuerySet.dates()</span></code> returns <code class="docutils literal"><span class="pre">date</span></code> objects<a class="headerlink" href="#queryset-dates-returns-date-objects" title="Permalink to this headline">¶</a></h4>
<p><a class="reference internal" href="../ref/models/querysets.html#django.db.models.query.QuerySet.dates" title="django.db.models.query.QuerySet.dates"><code class="xref py py-meth docutils literal"><span class="pre">QuerySet.dates()</span></code></a> now returns a
list of <code class="xref py py-class docutils literal"><span class="pre">date</span></code>. It used to return a list of
<code class="xref py py-class docutils literal"><span class="pre">datetime</span></code>.</p>
<p><a class="reference internal" href="../ref/models/querysets.html#django.db.models.query.QuerySet.datetimes" title="django.db.models.query.QuerySet.datetimes"><code class="xref py py-meth docutils literal"><span class="pre">QuerySet.datetimes()</span></code></a>
returns a list of <code class="xref py py-class docutils literal"><span class="pre">datetime</span></code>.</p>
</div>
<div class="section" id="s-queryset-dates-no-longer-usable-on-datetimefield">
<span id="queryset-dates-no-longer-usable-on-datetimefield"></span><h4><code class="docutils literal"><span class="pre">QuerySet.dates()</span></code> no longer usable on <code class="docutils literal"><span class="pre">DateTimeField</span></code><a class="headerlink" href="#queryset-dates-no-longer-usable-on-datetimefield" title="Permalink to this headline">¶</a></h4>
<p><a class="reference internal" href="../ref/models/querysets.html#django.db.models.query.QuerySet.dates" title="django.db.models.query.QuerySet.dates"><code class="xref py py-meth docutils literal"><span class="pre">QuerySet.dates()</span></code></a> raises an
error if it’s used on <a class="reference internal" href="../ref/models/fields.html#django.db.models.DateTimeField" title="django.db.models.DateTimeField"><code class="xref py py-class docutils literal"><span class="pre">DateTimeField</span></code></a> when time
zone support is active. Use <a class="reference internal" href="../ref/models/querysets.html#django.db.models.query.QuerySet.datetimes" title="django.db.models.query.QuerySet.datetimes"><code class="xref py py-meth docutils literal"><span class="pre">QuerySet.datetimes()</span></code></a> instead.</p>
</div>
<div class="section" id="s-date-hierarchy-requires-time-zone-definitions">
<span id="date-hierarchy-requires-time-zone-definitions"></span><h4><code class="docutils literal"><span class="pre">date_hierarchy</span></code> requires time zone definitions<a class="headerlink" href="#date-hierarchy-requires-time-zone-definitions" title="Permalink to this headline">¶</a></h4>
<p>The <a class="reference internal" href="../ref/contrib/admin/index.html#django.contrib.admin.ModelAdmin.date_hierarchy" title="django.contrib.admin.ModelAdmin.date_hierarchy"><code class="xref py py-attr docutils literal"><span class="pre">date_hierarchy</span></code></a> feature of the
admin now relies on <a class="reference internal" href="../ref/models/querysets.html#django.db.models.query.QuerySet.datetimes" title="django.db.models.query.QuerySet.datetimes"><code class="xref py py-meth docutils literal"><span class="pre">QuerySet.datetimes()</span></code></a> when it’s used on a
<a class="reference internal" href="../ref/models/fields.html#django.db.models.DateTimeField" title="django.db.models.DateTimeField"><code class="xref py py-class docutils literal"><span class="pre">DateTimeField</span></code></a>.</p>
<p>This requires time zone definitions in the database when <a class="reference internal" href="../ref/settings.html#std:setting-USE_TZ"><code class="xref std std-setting docutils literal"><span class="pre">USE_TZ</span></code></a> is
<code class="docutils literal"><span class="pre">True</span></code>. <a class="reference internal" href="../ref/models/querysets.html#database-time-zone-definitions"><span class="std std-ref">Learn more</span></a>.</p>
</div>
<div class="section" id="s-date-list-in-generic-views-requires-time-zone-definitions">
<span id="date-list-in-generic-views-requires-time-zone-definitions"></span><h4><code class="docutils literal"><span class="pre">date_list</span></code> in generic views requires time zone definitions<a class="headerlink" href="#date-list-in-generic-views-requires-time-zone-definitions" title="Permalink to this headline">¶</a></h4>
<p>For the same reason, accessing <code class="docutils literal"><span class="pre">date_list</span></code> in the context of a date-based
generic view requires time zone definitions in the database when the view is
based on a <a class="reference internal" href="../ref/models/fields.html#django.db.models.DateTimeField" title="django.db.models.DateTimeField"><code class="xref py py-class docutils literal"><span class="pre">DateTimeField</span></code></a> and <a class="reference internal" href="../ref/settings.html#std:setting-USE_TZ"><code class="xref std std-setting docutils literal"><span class="pre">USE_TZ</span></code></a> is
<code class="docutils literal"><span class="pre">True</span></code>. <a class="reference internal" href="../ref/models/querysets.html#database-time-zone-definitions"><span class="std std-ref">Learn more</span></a>.</p>
</div>
</div>
<div class="section" id="s-new-lookups-may-clash-with-model-fields">
<span id="new-lookups-may-clash-with-model-fields"></span><h3>New lookups may clash with model fields<a class="headerlink" href="#new-lookups-may-clash-with-model-fields" title="Permalink to this headline">¶</a></h3>
<p>Django 1.6 introduces <code class="docutils literal"><span class="pre">hour</span></code>, <code class="docutils literal"><span class="pre">minute</span></code>, and <code class="docutils literal"><span class="pre">second</span></code> lookups on
<a class="reference internal" href="../ref/models/fields.html#django.db.models.DateTimeField" title="django.db.models.DateTimeField"><code class="xref py py-class docutils literal"><span class="pre">DateTimeField</span></code></a>. If you had model fields called
<code class="docutils literal"><span class="pre">hour</span></code>, <code class="docutils literal"><span class="pre">minute</span></code>, or <code class="docutils literal"><span class="pre">second</span></code>, the new lookups will clash with you field
names. Append an explicit <a class="reference internal" href="../ref/models/querysets.html#std:fieldlookup-exact"><code class="xref std std-lookup docutils literal"><span class="pre">exact</span></code></a> lookup if this is an issue.</p>
</div>
<div class="section" id="s-booleanfield-no-longer-defaults-to-false">
<span id="booleanfield-no-longer-defaults-to-false"></span><h3><code class="docutils literal"><span class="pre">BooleanField</span></code> no longer defaults to <code class="docutils literal"><span class="pre">False</span></code><a class="headerlink" href="#booleanfield-no-longer-defaults-to-false" title="Permalink to this headline">¶</a></h3>
<p>When a <a class="reference internal" href="../ref/models/fields.html#django.db.models.BooleanField" title="django.db.models.BooleanField"><code class="xref py py-class docutils literal"><span class="pre">BooleanField</span></code></a> doesn’t have an explicit
<a class="reference internal" href="../ref/models/fields.html#django.db.models.Field.default" title="django.db.models.Field.default"><code class="xref py py-attr docutils literal"><span class="pre">default</span></code></a>, the implicit default value is
<code class="docutils literal"><span class="pre">None</span></code>. In previous version of Django, it was <code class="docutils literal"><span class="pre">False</span></code>, but that didn’t
represent accurately the lack of a value.</p>
<p>Code that relies on the default value being <code class="docutils literal"><span class="pre">False</span></code> may raise an exception
when saving new model instances to the database, because <code class="docutils literal"><span class="pre">None</span></code> isn’t an
acceptable value for a <a class="reference internal" href="../ref/models/fields.html#django.db.models.BooleanField" title="django.db.models.BooleanField"><code class="xref py py-class docutils literal"><span class="pre">BooleanField</span></code></a>. You should
either specify <code class="docutils literal"><span class="pre">default=False</span></code> in the field definition, or ensure the field
is set to <code class="docutils literal"><span class="pre">True</span></code> or <code class="docutils literal"><span class="pre">False</span></code> before saving the object.</p>
</div>
<div class="section" id="s-translations-and-comments-in-templates">
<span id="translations-and-comments-in-templates"></span><h3>Translations and comments in templates<a class="headerlink" href="#translations-and-comments-in-templates" title="Permalink to this headline">¶</a></h3>
<div class="section" id="s-extraction-of-translations-after-comments">
<span id="extraction-of-translations-after-comments"></span><h4>Extraction of translations after comments<a class="headerlink" href="#extraction-of-translations-after-comments" title="Permalink to this headline">¶</a></h4>
<p>Extraction of translatable literals from templates with the
<a class="reference internal" href="../ref/django-admin.html#django-admin-makemessages"><code class="xref std std-djadmin docutils literal"><span class="pre">makemessages</span></code></a> command now correctly detects i18n constructs when
they are located after a <code class="docutils literal"><span class="pre">{#</span></code> / <code class="docutils literal"><span class="pre">#}</span></code>-type comment on the same line. E.g.:</p>
<div class="highlight-html+django"><div class="highlight"><pre><span></span><span class="c">{# A comment #}</span><span class="cp">{%</span> <span class="k">trans</span> <span class="s2">"This literal was incorrectly ignored. Not anymore"</span> <span class="cp">%}</span>
</pre></div>
</div>
</div>
<div class="section" id="s-location-of-translator-comments">
<span id="location-of-translator-comments"></span><h4>Location of translator comments<a class="headerlink" href="#location-of-translator-comments" title="Permalink to this headline">¶</a></h4>
<p><a class="reference internal" href="../topics/i18n/translation.html#translator-comments-in-templates"><span class="std std-ref">Comments for translators in templates</span></a> specified using <code class="docutils literal"><span class="pre">{#</span></code> / <code class="docutils literal"><span class="pre">#}</span></code> need to
be at the end of a line. If they are not, the comments are ignored and
<a class="reference internal" href="../ref/django-admin.html#django-admin-makemessages"><code class="xref std std-djadmin docutils literal"><span class="pre">makemessages</span></code></a> will generate a warning. For example:</p>
<div class="highlight-html+django"><div class="highlight"><pre><span></span><span class="c">{# Translators: This is ignored #}</span><span class="cp">{%</span> <span class="k">trans</span> <span class="s2">"Translate me"</span> <span class="cp">%}</span>
<span class="cp">{{</span> <span class="nv">title</span> <span class="cp">}}</span><span class="c">{# Translators: Extracted and associated with 'Welcome' below #}</span>
<span class="p"><</span><span class="nt">h1</span><span class="p">></span><span class="cp">{%</span> <span class="k">trans</span> <span class="s2">"Welcome"</span> <span class="cp">%}</span><span class="p"></</span><span class="nt">h1</span><span class="p">></span>
</pre></div>
</div>
</div>
</div>
<div class="section" id="s-quoting-in-reverse">
<span id="quoting-in-reverse"></span><h3>Quoting in <a class="reference internal" href="../ref/urlresolvers.html#django.core.urlresolvers.reverse" title="django.core.urlresolvers.reverse"><code class="xref py py-func docutils literal"><span class="pre">reverse()</span></code></a><a class="headerlink" href="#quoting-in-reverse" title="Permalink to this headline">¶</a></h3>
<p>When reversing URLs, Django didn’t apply <a class="reference internal" href="../ref/utils.html#django.utils.http.urlquote" title="django.utils.http.urlquote"><code class="xref py py-func docutils literal"><span class="pre">urlquote()</span></code></a>
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 <a class="reference internal" href="../ref/urlresolvers.html#django.core.urlresolvers.reverse" title="django.core.urlresolvers.reverse"><code class="xref py py-func docutils literal"><span class="pre">reverse()</span></code></a>, this may
result in double-quoting. If this happens, simply remove the URL quoting from
your code. You will also have to replace special characters in URLs used in
<a class="reference internal" href="../topics/testing/tools.html#django.test.SimpleTestCase.assertRedirects" title="django.test.SimpleTestCase.assertRedirects"><code class="xref py py-func docutils literal"><span class="pre">assertRedirects()</span></code></a> with their encoded versions.</p>
</div>
<div class="section" id="s-storage-of-ip-addresses-in-the-comments-app">
<span id="storage-of-ip-addresses-in-the-comments-app"></span><h3>Storage of IP addresses in the comments app<a class="headerlink" href="#storage-of-ip-addresses-in-the-comments-app" title="Permalink to this headline">¶</a></h3>
<p>The comments app now uses a
<code class="docutils literal"><span class="pre">GenericIPAddressField</span></code> for storing commenters’ IP addresses, to support
comments submitted from IPv6 addresses. Until now, it stored them in an
<code class="docutils literal"><span class="pre">IPAddressField</span></code>, 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.</p>
<p>For MySQL, execute this query on your project’s database:</p>
<div class="highlight-sql"><div class="highlight"><pre><span></span><span class="k">ALTER</span> <span class="k">TABLE</span> <span class="n">django_comments</span> <span class="k">MODIFY</span> <span class="n">ip_address</span> <span class="nb">VARCHAR</span><span class="p">(</span><span class="mi">39</span><span class="p">);</span>
</pre></div>
</div>
<p>For Oracle, execute this query:</p>
<div class="highlight-sql"><div class="highlight"><pre><span></span><span class="k">ALTER</span> <span class="k">TABLE</span> <span class="n">DJANGO_COMMENTS</span> <span class="k">MODIFY</span> <span class="p">(</span><span class="n">ip_address</span> <span class="n">VARCHAR2</span><span class="p">(</span><span class="mi">39</span><span class="p">));</span>
</pre></div>
</div>
<p>If you do not apply this change, the behavior 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.</p>
</div>
<div class="section" id="s-percent-literals-in-cursor-execute-queries">
<span id="percent-literals-in-cursor-execute-queries"></span><h3>Percent literals in <code class="docutils literal"><span class="pre">cursor.execute</span></code> queries<a class="headerlink" href="#percent-literals-in-cursor-execute-queries" title="Permalink to this headline">¶</a></h3>
<p>When you are running raw SQL queries through the
<a class="reference internal" href="../topics/db/sql.html#executing-custom-sql"><span class="std std-ref">cursor.execute</span></a> method, the rule about doubling
percent literals (<code class="docutils literal"><span class="pre">%</span></code>) inside the query has been unified. Past behavior
depended on the database backend. Now, across all backends, you only need to
double literal percent characters if you are also providing replacement
parameters. For example:</p>
<div class="highlight-default"><div class="highlight"><pre><span></span><span class="c1"># No parameters, no percent doubling</span>
<span class="n">cursor</span><span class="o">.</span><span class="n">execute</span><span class="p">(</span><span class="s2">"SELECT foo FROM bar WHERE baz = '30%'"</span><span class="p">)</span>
<span class="c1"># Parameters passed, non-placeholders have to be doubled</span>
<span class="n">cursor</span><span class="o">.</span><span class="n">execute</span><span class="p">(</span><span class="s2">"SELECT foo FROM bar WHERE baz = '30</span><span class="si">%%</span><span class="s2">' and id = </span><span class="si">%s</span><span class="s2">"</span><span class="p">,</span> <span class="p">[</span><span class="bp">self</span><span class="o">.</span><span class="n">id</span><span class="p">])</span>
</pre></div>
</div>
<p><code class="docutils literal"><span class="pre">SQLite</span></code> users need to check and update such queries.</p>
</div>
<div class="section" id="s-help-text-of-model-form-fields-for-manytomanyfield-fields">
<span id="s-m2m-help-text"></span><span id="help-text-of-model-form-fields-for-manytomanyfield-fields"></span><span id="m2m-help-text"></span><h3>Help text of model form fields for ManyToManyField fields<a class="headerlink" href="#help-text-of-model-form-fields-for-manytomanyfield-fields" title="Permalink to this headline">¶</a></h3>
<p>HTML rendering of model form fields corresponding to
<a class="reference internal" href="../ref/models/fields.html#django.db.models.ManyToManyField" title="django.db.models.ManyToManyField"><code class="xref py py-class docutils literal"><span class="pre">ManyToManyField</span></code></a> model fields used to get the
hard-coded sentence:</p>
<blockquote>
<div><em>Hold down “Control”, or “Command” on a Mac, to select more than one.</em></div></blockquote>
<p>(or its translation to the active locale) imposed as the help legend shown along
them if neither <a class="reference internal" href="../ref/models/fields.html#django.db.models.Field.help_text" title="django.db.models.Field.help_text"><code class="xref py py-attr docutils literal"><span class="pre">model</span></code></a> nor <a class="reference internal" href="../ref/forms/fields.html#django.forms.Field.help_text" title="django.forms.Field.help_text"><code class="xref py py-attr docutils literal"><span class="pre">form</span></code></a> <code class="docutils literal"><span class="pre">help_text</span></code> attributes were specified by the
user (or this string was appended to any <code class="docutils literal"><span class="pre">help_text</span></code> that was provided).</p>
<p>Since this happened at the model layer, there was no way to prevent the text
from appearing in cases where it wasn’t applicable such as form fields that
implement user interactions that don’t involve a keyboard and/or a mouse.</p>
<p>Starting with Django 1.6, as an ad-hoc temporary backward-compatibility
provision, the logic to add the “Hold down...” sentence has been moved to the
model form field layer and modified to add the text only when the associated
widget is <a class="reference internal" href="../ref/forms/widgets.html#django.forms.SelectMultiple" title="django.forms.SelectMultiple"><code class="xref py py-class docutils literal"><span class="pre">SelectMultiple</span></code></a> or selected subclasses.</p>
<p>The change can affect you in a backward incompatible way if you employ custom
model form fields and/or widgets for <code class="docutils literal"><span class="pre">ManyToManyField</span></code> model fields whose UIs
do rely on the automatic provision of the mentioned hard-coded sentence. These
form field implementations need to adapt to the new scenario by providing their
own handling of the <code class="docutils literal"><span class="pre">help_text</span></code> attribute.</p>
<p>Applications that use Django <a class="reference internal" href="../topics/forms/modelforms.html"><span class="doc">model form</span></a>
facilities together with Django built-in form <a class="reference internal" href="../ref/forms/fields.html"><span class="doc">fields</span></a>
and <a class="reference internal" href="../ref/forms/widgets.html"><span class="doc">widgets</span></a> aren’t affected but need to be aware of
what’s described in <a class="reference internal" href="#m2m-help-text-deprecation"><span class="std std-ref">Munging of help text of model form fields for ManyToManyField fields</span></a> below.</p>
</div>
<div class="section" id="s-queryset-iteration">
<span id="queryset-iteration"></span><h3>QuerySet iteration<a class="headerlink" href="#queryset-iteration" title="Permalink to this headline">¶</a></h3>
<p>The <code class="docutils literal"><span class="pre">QuerySet</span></code> iteration was changed to immediately convert all fetched
rows to <code class="docutils literal"><span class="pre">Model</span></code> objects. In Django 1.5 and earlier the fetched rows were
converted to <code class="docutils literal"><span class="pre">Model</span></code> objects in chunks of 100.</p>
<p>Existing code will work, but the amount of rows converted to objects
might change in certain use cases. Such usages include partially looping
over a queryset or any usage which ends up doing <code class="docutils literal"><span class="pre">__bool__</span></code> or
<code class="docutils literal"><span class="pre">__contains__</span></code>.</p>
<p>Notably most database backends did fetch all the rows in one go already in
1.5.</p>
<p>It is still possible to convert the fetched rows to <code class="docutils literal"><span class="pre">Model</span></code> objects
lazily by using the <a class="reference internal" href="../ref/models/querysets.html#django.db.models.query.QuerySet.iterator" title="django.db.models.query.QuerySet.iterator"><code class="xref py py-meth docutils literal"><span class="pre">iterator()</span></code></a>
method.</p>
</div>
<div class="section" id="s-boundfield-label-tag-now-includes-the-form-s-label-suffix">
<span id="boundfield-label-tag-now-includes-the-form-s-label-suffix"></span><h3><a class="reference internal" href="../ref/forms/api.html#django.forms.BoundField.label_tag" title="django.forms.BoundField.label_tag"><code class="xref py py-meth docutils literal"><span class="pre">BoundField.label_tag</span></code></a> now includes the form’s <a class="reference internal" href="../ref/forms/api.html#django.forms.Form.label_suffix" title="django.forms.Form.label_suffix"><code class="xref py py-attr docutils literal"><span class="pre">label_suffix</span></code></a><a class="headerlink" href="#boundfield-label-tag-now-includes-the-form-s-label-suffix" title="Permalink to this headline">¶</a></h3>
<p>This is consistent with how methods like
<a class="reference internal" href="../ref/forms/api.html#django.forms.Form.as_p" title="django.forms.Form.as_p"><code class="xref py py-meth docutils literal"><span class="pre">Form.as_p</span></code></a> and
<a class="reference internal" href="../ref/forms/api.html#django.forms.Form.as_ul" title="django.forms.Form.as_ul"><code class="xref py py-meth docutils literal"><span class="pre">Form.as_ul</span></code></a> render labels.</p>
<p>If you manually render <code class="docutils literal"><span class="pre">label_tag</span></code> in your templates:</p>
<div class="highlight-html+django"><div class="highlight"><pre><span></span><span class="cp">{{</span> <span class="nv">form.my_field.label_tag</span> <span class="cp">}}</span>: <span class="cp">{{</span> <span class="nv">form.my_field</span> <span class="cp">}}</span>
</pre></div>
</div>
<p>you’ll want to remove the colon (or whatever other separator you may be
using) to avoid duplicating it when upgrading to Django 1.6. The following
template in Django 1.6 will render identically to the above template in Django
1.5, except that the colon will appear inside the <code class="docutils literal"><span class="pre"><label></span></code> element.</p>
<div class="highlight-html+django"><div class="highlight"><pre><span></span><span class="cp">{{</span> <span class="nv">form.my_field.label_tag</span> <span class="cp">}}</span> <span class="cp">{{</span> <span class="nv">form.my_field</span> <span class="cp">}}</span>
</pre></div>
</div>
<p>will render something like:</p>
<div class="highlight-html"><div class="highlight"><pre><span></span><span class="p"><</span><span class="nt">label</span> <span class="na">for</span><span class="o">=</span><span class="s">"id_my_field"</span><span class="p">></span>My Field:<span class="p"></</span><span class="nt">label</span><span class="p">></span> <span class="p"><</span><span class="nt">input</span> <span class="na">id</span><span class="o">=</span><span class="s">"id_my_field"</span> <span class="na">type</span><span class="o">=</span><span class="s">"text"</span> <span class="na">name</span><span class="o">=</span><span class="s">"my_field"</span> <span class="p">/></span>
</pre></div>
</div>
<p>If you want to keep the current behavior of rendering <code class="docutils literal"><span class="pre">label_tag</span></code> without
the <code class="docutils literal"><span class="pre">label_suffix</span></code>, instantiate the form <code class="docutils literal"><span class="pre">label_suffix=''</span></code>. You can also
customize the <code class="docutils literal"><span class="pre">label_suffix</span></code> on a per-field basis using the new
<code class="docutils literal"><span class="pre">label_suffix</span></code> parameter on <a class="reference internal" href="../ref/forms/api.html#django.forms.BoundField.label_tag" title="django.forms.BoundField.label_tag"><code class="xref py py-meth docutils literal"><span class="pre">label_tag()</span></code></a>.</p>
</div>
<div class="section" id="s-admin-views-changelist-filters-get-parameter">
<span id="admin-views-changelist-filters-get-parameter"></span><h3>Admin views <code class="docutils literal"><span class="pre">_changelist_filters</span></code> GET parameter<a class="headerlink" href="#admin-views-changelist-filters-get-parameter" title="Permalink to this headline">¶</a></h3>
<p>To achieve preserving and restoring list view filters, admin views now
pass around the <cite>_changelist_filters</cite> GET parameter. It’s important that you
account for that change if you have custom admin templates or if your tests
rely on the previous URLs. If you want to revert to the original behavior you
can set the
<a class="reference internal" href="../ref/contrib/admin/index.html#django.contrib.admin.ModelAdmin.preserve_filters" title="django.contrib.admin.ModelAdmin.preserve_filters"><code class="xref py py-attr docutils literal"><span class="pre">preserve_filters</span></code></a> attribute to <code class="docutils literal"><span class="pre">False</span></code>.</p>
</div>
<div class="section" id="s-django-contrib-auth-password-reset-uses-base-64-encoding-of-user-pk">
<span id="django-contrib-auth-password-reset-uses-base-64-encoding-of-user-pk"></span><h3><code class="docutils literal"><span class="pre">django.contrib.auth</span></code> password reset uses base 64 encoding of <code class="docutils literal"><span class="pre">User</span></code> PK<a class="headerlink" href="#django-contrib-auth-password-reset-uses-base-64-encoding-of-user-pk" title="Permalink to this headline">¶</a></h3>
<p>Past versions of Django used base 36 encoding of the <code class="docutils literal"><span class="pre">User</span></code> primary key in
the password reset views and URLs
(<a class="reference internal" href="../topics/auth/default.html#django.contrib.auth.views.password_reset_confirm" title="django.contrib.auth.views.password_reset_confirm"><code class="xref py py-func docutils literal"><span class="pre">django.contrib.auth.views.password_reset_confirm()</span></code></a>). Base 36 encoding is
sufficient if the user primary key is an integer, however, with the
introduction of custom user models in Django 1.5, that assumption may no longer
be true.</p>
<p><a class="reference internal" href="../topics/auth/default.html#django.contrib.auth.views.password_reset_confirm" title="django.contrib.auth.views.password_reset_confirm"><code class="xref py py-func docutils literal"><span class="pre">django.contrib.auth.views.password_reset_confirm()</span></code></a> has been modified to
take a <code class="docutils literal"><span class="pre">uidb64</span></code> parameter instead of <code class="docutils literal"><span class="pre">uidb36</span></code>. If you are reversing this
view, for example in a custom <code class="docutils literal"><span class="pre">password_reset_email.html</span></code> template, be sure
to update your code.</p>
<p>A temporary shim for <a class="reference internal" href="../topics/auth/default.html#django.contrib.auth.views.password_reset_confirm" title="django.contrib.auth.views.password_reset_confirm"><code class="xref py py-func docutils literal"><span class="pre">django.contrib.auth.views.password_reset_confirm()</span></code></a>
that will allow password reset links generated prior to Django 1.6 to continue
to work has been added to provide backwards compatibility; this will be removed
in Django 1.7. Thus, as long as your site has been running Django 1.6 for more
than <a class="reference internal" href="../ref/settings.html#std:setting-PASSWORD_RESET_TIMEOUT_DAYS"><code class="xref std std-setting docutils literal"><span class="pre">PASSWORD_RESET_TIMEOUT_DAYS</span></code></a>, this change will have no effect.
If not (for example, if you upgrade directly from Django 1.5 to Django 1.7),
then any password reset links generated before you upgrade to Django 1.7 or
later won’t work after the upgrade.</p>
<p>In addition, if you have any custom password reset URLs, you will need to
update them by replacing <code class="docutils literal"><span class="pre">uidb36</span></code> with <code class="docutils literal"><span class="pre">uidb64</span></code> and the dash that follows
that pattern with a slash. Also add <code class="docutils literal"><span class="pre">_\-</span></code> to the list of characters that may
match the <code class="docutils literal"><span class="pre">uidb64</span></code> pattern.</p>
<p>For example:</p>
<div class="highlight-default"><div class="highlight"><pre><span></span><span class="n">url</span><span class="p">(</span><span class="s1">r'^reset/(?P<uidb36>[0-9A-Za-z]+)-(?P<token>.+)/$'</span><span class="p">,</span>
<span class="s1">'django.contrib.auth.views.password_reset_confirm'</span><span class="p">,</span>
<span class="n">name</span><span class="o">=</span><span class="s1">'password_reset_confirm'</span><span class="p">),</span>
</pre></div>
</div>
<p>becomes:</p>
<div class="highlight-default"><div class="highlight"><pre><span></span><span class="n">url</span><span class="p">(</span><span class="s1">r'^reset/(?P<uidb64>[0-9A-Za-z_\-]+)/(?P<token>.+)/$'</span><span class="p">,</span>
<span class="s1">'django.contrib.auth.views.password_reset_confirm'</span><span class="p">,</span>
<span class="n">name</span><span class="o">=</span><span class="s1">'password_reset_confirm'</span><span class="p">),</span>
</pre></div>
</div>
<p>You may also want to add the shim to support the old style reset links. Using
the example above, you would modify the existing url by replacing
<code class="docutils literal"><span class="pre">django.contrib.auth.views.password_reset_confirm</span></code> with
<code class="docutils literal"><span class="pre">django.contrib.auth.views.password_reset_confirm_uidb36</span></code> and also remove
the <code class="docutils literal"><span class="pre">name</span></code> argument so it doesn’t conflict with the new url:</p>
<div class="highlight-default"><div class="highlight"><pre><span></span><span class="n">url</span><span class="p">(</span><span class="s1">r'^reset/(?P<uidb36>[0-9A-Za-z]+)-(?P<token>.+)/$'</span><span class="p">,</span>
<span class="s1">'django.contrib.auth.views.password_reset_confirm_uidb36'</span><span class="p">),</span>
</pre></div>
</div>
<p>You can remove this url pattern after your app has been deployed with Django
1.6 for <a class="reference internal" href="../ref/settings.html#std:setting-PASSWORD_RESET_TIMEOUT_DAYS"><code class="xref std std-setting docutils literal"><span class="pre">PASSWORD_RESET_TIMEOUT_DAYS</span></code></a>.</p>
</div>
<div class="section" id="s-default-session-serialization-switched-to-json">
<span id="default-session-serialization-switched-to-json"></span><h3>Default session serialization switched to JSON<a class="headerlink" href="#default-session-serialization-switched-to-json" title="Permalink to this headline">¶</a></h3>
<p>Historically, <a class="reference internal" href="../topics/http/sessions.html#module-django.contrib.sessions" title="django.contrib.sessions: Provides session management for Django projects."><code class="xref py py-mod docutils literal"><span class="pre">django.contrib.sessions</span></code></a> used <code class="xref py py-mod docutils literal"><span class="pre">pickle</span></code> to serialize
session data before storing it in the backend. If you’re using the <a class="reference internal" href="../topics/http/sessions.html#cookie-session-backend"><span class="std std-ref">signed
cookie session backend</span></a> and <a class="reference internal" href="../ref/settings.html#std:setting-SECRET_KEY"><code class="xref std std-setting docutils literal"><span class="pre">SECRET_KEY</span></code></a> is
known by an attacker (there isn’t an inherent vulnerability in Django that
would cause it to leak), the attacker could insert a string into his session
which, when unpickled, executes arbitrary code on the server. The technique for
doing so is simple and easily available on the internet. Although the cookie
session storage signs the cookie-stored data to prevent tampering, a
<a class="reference internal" href="../ref/settings.html#std:setting-SECRET_KEY"><code class="xref std std-setting docutils literal"><span class="pre">SECRET_KEY</span></code></a> leak immediately escalates to a remote code execution
vulnerability.</p>
<p>This attack can be mitigated by serializing session data using JSON rather
than <code class="xref py py-mod docutils literal"><span class="pre">pickle</span></code>. To facilitate this, Django 1.5.3 introduced a new setting,
<a class="reference internal" href="../ref/settings.html#std:setting-SESSION_SERIALIZER"><code class="xref std std-setting docutils literal"><span class="pre">SESSION_SERIALIZER</span></code></a>, to customize the session serialization format.
For backwards compatibility, this setting defaulted to using <code class="xref py py-mod docutils literal"><span class="pre">pickle</span></code>
in Django 1.5.3, but we’ve changed the default to JSON in 1.6. If you upgrade
and switch from pickle to JSON, sessions created before the upgrade will be
lost. While JSON serialization does not support all Python objects like
<code class="xref py py-mod docutils literal"><span class="pre">pickle</span></code> does, we highly recommend using JSON-serialized sessions. Be
aware of the following when checking your code to determine if JSON
serialization will work for your application:</p>
<ul class="simple">
<li>JSON requires string keys, so you will likely run into problems if you are
using non-string keys in <code class="docutils literal"><span class="pre">request.session</span></code>.</li>
<li>Setting session expiration by passing <code class="docutils literal"><span class="pre">datetime</span></code> values to
<a class="reference internal" href="../topics/http/sessions.html#django.contrib.sessions.backends.base.SessionBase.set_expiry" title="django.contrib.sessions.backends.base.SessionBase.set_expiry"><code class="xref py py-meth docutils literal"><span class="pre">set_expiry()</span></code></a> will
not work as <code class="docutils literal"><span class="pre">datetime</span></code> values are not serializable in JSON. You can use
integer values instead.</li>
</ul>
<p>See the <a class="reference internal" href="../topics/http/sessions.html#session-serialization"><span class="std std-ref">Session serialization</span></a> documentation for more details.</p>
</div>
<div class="section" id="s-object-relational-mapper-changes">
<span id="object-relational-mapper-changes"></span><h3>Object Relational Mapper changes<a class="headerlink" href="#object-relational-mapper-changes" title="Permalink to this headline">¶</a></h3>
<p>Django 1.6 contains many changes to the ORM. These changes fall mostly in
three categories:</p>
<ol class="arabic simple">
<li>Bug fixes (e.g. proper join clauses for generic relations, query combining,
join promotion, and join trimming fixes)</li>
<li>Preparation for new features. For example the ORM is now internally ready
for multicolumn foreign keys.</li>
<li>General cleanup.</li>
</ol>
<p>These changes can result in some compatibility problems. For example, some
queries will now generate different table aliases. This can affect
<a class="reference internal" href="../ref/models/querysets.html#django.db.models.query.QuerySet.extra" title="django.db.models.query.QuerySet.extra"><code class="xref py py-meth docutils literal"><span class="pre">QuerySet.extra()</span></code></a>. In addition
some queries will now produce different results. An example is
<a class="reference internal" href="../ref/models/querysets.html#django.db.models.query.QuerySet.exclude" title="django.db.models.query.QuerySet.exclude"><code class="xref py py-meth docutils literal"><span class="pre">exclude(condition)</span></code></a>
where the condition is a complex one (referencing multijoins inside
<a class="reference internal" href="../ref/models/querysets.html#django.db.models.Q" title="django.db.models.Q"><code class="xref py py-class docutils literal"><span class="pre">Q</span> <span class="pre">objects</span></code></a>). In many cases the affected
queries didn’t produce correct results in Django 1.5 but do now.
Unfortunately there are also cases that produce different results, but
neither Django 1.5 nor 1.6 produce correct results.</p>
<p>Finally, there have been many changes to the ORM internal APIs.</p>
</div>
<div class="section" id="s-miscellaneous">
<span id="miscellaneous"></span><h3>Miscellaneous<a class="headerlink" href="#miscellaneous" title="Permalink to this headline">¶</a></h3>
<ul>
<li><p class="first">The <code class="docutils literal"><span class="pre">django.db.models.query.EmptyQuerySet</span></code> can’t be instantiated any more -
it is only usable as a marker class for checking if
<a class="reference internal" href="../ref/models/querysets.html#django.db.models.query.QuerySet.none" title="django.db.models.query.QuerySet.none"><code class="xref py py-meth docutils literal"><span class="pre">none()</span></code></a> has been called:
<code class="docutils literal"><span class="pre">isinstance(qs.none(),</span> <span class="pre">EmptyQuerySet)</span></code></p>
</li>
<li><p class="first">If your CSS/JavaScript code used to access HTML input widgets by type, you
should review it as <code class="docutils literal"><span class="pre">type='text'</span></code> widgets might be now output as
<code class="docutils literal"><span class="pre">type='email'</span></code>, <code class="docutils literal"><span class="pre">type='url'</span></code> or <code class="docutils literal"><span class="pre">type='number'</span></code> depending on their
corresponding field type.</p>
</li>
<li><p class="first">Form field’s <a class="reference internal" href="../ref/forms/fields.html#django.forms.Field.error_messages" title="django.forms.Field.error_messages"><code class="xref py py-attr docutils literal"><span class="pre">error_messages</span></code></a> that contain a
placeholder should now always use a named placeholder (<code class="docutils literal"><span class="pre">"Value</span> <span class="pre">'%(value)s'</span> <span class="pre">is</span>
<span class="pre">too</span> <span class="pre">big"</span></code> instead of <code class="docutils literal"><span class="pre">"Value</span> <span class="pre">'%s'</span> <span class="pre">is</span> <span class="pre">too</span> <span class="pre">big"</span></code>). See the corresponding
field documentation for details about the names of the placeholders. The
changes in 1.6 particularly affect <a class="reference internal" href="../ref/forms/fields.html#django.forms.DecimalField" title="django.forms.DecimalField"><code class="xref py py-class docutils literal"><span class="pre">DecimalField</span></code></a> and
<a class="reference internal" href="../ref/forms/fields.html#django.forms.ModelMultipleChoiceField" title="django.forms.ModelMultipleChoiceField"><code class="xref py py-class docutils literal"><span class="pre">ModelMultipleChoiceField</span></code></a>.</p>
</li>
<li><p class="first">Some <a class="reference internal" href="../ref/forms/fields.html#django.forms.Field.error_messages" title="django.forms.Field.error_messages"><code class="xref py py-attr docutils literal"><span class="pre">error_messages</span></code></a> for
<a class="reference internal" href="../ref/forms/fields.html#django.forms.IntegerField" title="django.forms.IntegerField"><code class="xref py py-class docutils literal"><span class="pre">IntegerField</span></code></a>,
<a class="reference internal" href="../ref/forms/fields.html#django.forms.EmailField" title="django.forms.EmailField"><code class="xref py py-class docutils literal"><span class="pre">EmailField</span></code></a>,
<a class="reference internal" href="../ref/forms/fields.html#django.forms.IPAddressField" title="django.forms.IPAddressField"><code class="xref py py-class docutils literal"><span class="pre">IPAddressField</span></code></a>,
<a class="reference internal" href="../ref/forms/fields.html#django.forms.GenericIPAddressField" title="django.forms.GenericIPAddressField"><code class="xref py py-class docutils literal"><span class="pre">GenericIPAddressField</span></code></a>, and
<a class="reference internal" href="../ref/forms/fields.html#django.forms.SlugField" title="django.forms.SlugField"><code class="xref py py-class docutils literal"><span class="pre">SlugField</span></code></a> have been suppressed because they
duplicated error messages already provided by validators tied to the fields.</p>
</li>
<li><p class="first">Due to a change in the form validation workflow,
<a class="reference internal" href="../ref/forms/fields.html#django.forms.TypedChoiceField" title="django.forms.TypedChoiceField"><code class="xref py py-class docutils literal"><span class="pre">TypedChoiceField</span></code></a> <code class="docutils literal"><span class="pre">coerce</span></code> method should always
return a value present in the <code class="docutils literal"><span class="pre">choices</span></code> field attribute. That limitation
should be lift again in Django 1.7.</p>
</li>
<li><p class="first">There have been changes in the way timeouts are handled in cache backends.
Explicitly passing in <code class="docutils literal"><span class="pre">timeout=None</span></code> no longer results in using the
default timeout. It will now set a non-expiring timeout. Passing 0 into the
memcache backend no longer uses the default timeout, and now will
set-and-expire-immediately the value.</p>
</li>
<li><p class="first">The <code class="docutils literal"><span class="pre">django.contrib.flatpages</span></code> app used to set custom HTTP headers for
debugging purposes. This functionality was not documented and made caching
ineffective so it has been removed, along with its generic implementation,
previously available in <code class="docutils literal"><span class="pre">django.core.xheaders</span></code>.</p>
</li>
<li><p class="first">The <code class="docutils literal"><span class="pre">XViewMiddleware</span></code> has been moved from <code class="docutils literal"><span class="pre">django.middleware.doc</span></code> to
<code class="docutils literal"><span class="pre">django.contrib.admindocs.middleware</span></code> because it is an implementation
detail of admindocs, proven not to be reusable in general.</p>
</li>
<li><p class="first"><a class="reference internal" href="../ref/models/fields.html#django.db.models.GenericIPAddressField" title="django.db.models.GenericIPAddressField"><code class="xref py py-class docutils literal"><span class="pre">GenericIPAddressField</span></code></a> will now only allow
<code class="docutils literal"><span class="pre">blank</span></code> values if <code class="docutils literal"><span class="pre">null</span></code> values are also allowed. Creating a
<code class="docutils literal"><span class="pre">GenericIPAddressField</span></code> where <code class="docutils literal"><span class="pre">blank</span></code> is allowed but <code class="docutils literal"><span class="pre">null</span></code> is not
will trigger a model validation error because <code class="docutils literal"><span class="pre">blank</span></code> values are always
stored as <code class="docutils literal"><span class="pre">null</span></code>. Previously, storing a <code class="docutils literal"><span class="pre">blank</span></code> value in a field which
did not allow <code class="docutils literal"><span class="pre">null</span></code> would cause a database exception at runtime.</p>
</li>
<li><p class="first">If a <a class="reference internal" href="../ref/exceptions.html#django.core.urlresolvers.NoReverseMatch" title="django.core.urlresolvers.NoReverseMatch"><code class="xref py py-class docutils literal"><span class="pre">NoReverseMatch</span></code></a> exception is raised
from a method when rendering a template, it is not silenced. For example,
<code class="docutils literal"><span class="pre">{{</span> <span class="pre">obj.view_href</span> <span class="pre">}}</span></code> will cause template rendering to fail if
<code class="docutils literal"><span class="pre">view_href()</span></code> raises <code class="docutils literal"><span class="pre">NoReverseMatch</span></code>. There is no change to the
<a class="reference internal" href="../ref/templates/builtins.html#std:templatetag-url"><code class="xref std std-ttag docutils literal"><span class="pre">{%</span> <span class="pre">url</span> <span class="pre">%}</span></code></a> tag, it causes template rendering to fail like always
when <code class="docutils literal"><span class="pre">NoReverseMatch</span></code> is raised.</p>
</li>
<li><p class="first"><a class="reference internal" href="../topics/testing/tools.html#django.test.Client.logout" title="django.test.Client.logout"><code class="xref py py-meth docutils literal"><span class="pre">django.test.Client.logout()</span></code></a> now calls
<a class="reference internal" href="../topics/auth/default.html#django.contrib.auth.logout" title="django.contrib.auth.logout"><code class="xref py py-meth docutils literal"><span class="pre">django.contrib.auth.logout()</span></code></a> which will send the
<a class="reference internal" href="../ref/contrib/auth.html#django.contrib.auth.signals.user_logged_out" title="django.contrib.auth.signals.user_logged_out"><code class="xref py py-func docutils literal"><span class="pre">user_logged_out()</span></code></a> signal.</p>
</li>
<li><p class="first"><a class="reference internal" href="../topics/auth/default.html#built-in-auth-views"><span class="std std-ref">Authentication views</span></a> are now reversed by name,
not their locations in <code class="docutils literal"><span class="pre">django.contrib.auth.views</span></code>. If you are using the
views without a <code class="docutils literal"><span class="pre">name</span></code>, you should update your <code class="docutils literal"><span class="pre">urlpatterns</span></code> to use
<a class="reference internal" href="../ref/urls.html#django.conf.urls.url" title="django.conf.urls.url"><code class="xref py py-meth docutils literal"><span class="pre">url()</span></code></a> with the <code class="docutils literal"><span class="pre">name</span></code> parameter. For example:</p>
<div class="highlight-default"><div class="highlight"><pre><span></span><span class="p">(</span><span class="s1">r'^reset/done/$'</span><span class="p">,</span> <span class="s1">'django.contrib.auth.views.password_reset_complete'</span><span class="p">)</span>
</pre></div>
</div>
<p>becomes:</p>
<div class="highlight-default"><div class="highlight"><pre><span></span><span class="n">url</span><span class="p">(</span><span class="s1">r'^reset/done/$'</span><span class="p">,</span> <span class="s1">'django.contrib.auth.views.password_reset_complete'</span><span class="p">,</span> <span class="n">name</span><span class="o">=</span><span class="s1">'password_reset_complete'</span><span class="p">)</span>
</pre></div>
</div>
</li>
<li><p class="first"><a class="reference internal" href="../ref/class-based-views/base.html#django.views.generic.base.RedirectView" title="django.views.generic.base.RedirectView"><code class="xref py py-class docutils literal"><span class="pre">RedirectView</span></code></a> now has a <cite>pattern_name</cite>
attribute which allows it to choose the target by reversing the URL.</p>
</li>
<li><p class="first">In Django 1.4 and 1.5, a blank string was unintentionally not considered to
be a valid password. This meant
<a class="reference internal" href="../ref/contrib/auth.html#django.contrib.auth.models.User.set_password" title="django.contrib.auth.models.User.set_password"><code class="xref py py-meth docutils literal"><span class="pre">set_password()</span></code></a> would save a blank
password as an unusable password like
<a class="reference internal" href="../ref/contrib/auth.html#django.contrib.auth.models.User.set_unusable_password" title="django.contrib.auth.models.User.set_unusable_password"><code class="xref py py-meth docutils literal"><span class="pre">set_unusable_password()</span></code></a> does, and
thus <a class="reference internal" href="../ref/contrib/auth.html#django.contrib.auth.models.User.check_password" title="django.contrib.auth.models.User.check_password"><code class="xref py py-meth docutils literal"><span class="pre">check_password()</span></code></a> always
returned <code class="docutils literal"><span class="pre">False</span></code> for blank passwords. This has been corrected in this
release: blank passwords are now valid.</p>
</li>
<li><p class="first">The admin <a class="reference internal" href="../ref/contrib/admin/index.html#django.contrib.admin.ModelAdmin.changelist_view" title="django.contrib.admin.ModelAdmin.changelist_view"><code class="xref py py-attr docutils literal"><span class="pre">changelist_view</span></code></a> previously
accepted a <code class="docutils literal"><span class="pre">pop</span></code> GET parameter to signify it was to be displayed in a popup.
This parameter has been renamed to <code class="docutils literal"><span class="pre">_popup</span></code> to be consistent with the rest
of the admin views. You should update your custom templates if they use the
previous parameter name.</p>
</li>
<li><p class="first"><a class="reference internal" href="../ref/validators.html#django.core.validators.validate_email" title="django.core.validators.validate_email"><code class="xref py py-meth docutils literal"><span class="pre">validate_email()</span></code></a> now accepts email addresses
with <code class="docutils literal"><span class="pre">localhost</span></code> as the domain.</p>
</li>
<li><p class="first">The <a class="reference internal" href="../ref/django-admin.html#django-admin-option---keep-pot"><code class="xref std std-djadminopt docutils literal"><span class="pre">--keep-pot</span></code></a> option was added to <a class="reference internal" href="../ref/django-admin.html#django-admin-makemessages"><code class="xref std std-djadmin docutils literal"><span class="pre">makemessages</span></code></a>
to prevent django from deleting the temporary .pot file it generates before
creating the .po file.</p>
</li>
<li><p class="first">The undocumented <code class="docutils literal"><span class="pre">django.core.servers.basehttp.WSGIServerException</span></code> has
been removed. Use <code class="docutils literal"><span class="pre">socket.error</span></code> provided by the standard library instead.
This change was also released in Django 1.5.5.</p>
</li>
<li><p class="first">The signature of <a class="reference internal" href="../ref/class-based-views/base.html#django.views.generic.base.RedirectView.get_redirect_url" title="django.views.generic.base.RedirectView.get_redirect_url"><code class="xref py py-meth docutils literal"><span class="pre">django.views.generic.base.RedirectView.get_redirect_url()</span></code></a>
has changed and now accepts positional arguments as well (<code class="docutils literal"><span class="pre">*args,</span> <span class="pre">**kwargs</span></code>).
Any unnamed captured group will now be passed to <code class="docutils literal"><span class="pre">get_redirect_url()</span></code>
which may result in a <code class="docutils literal"><span class="pre">TypeError</span></code> if you don’t update the signature of your
custom method.</p>
</li>
</ul>
</div>
</div>
<div class="section" id="s-features-deprecated-in-1-6">
<span id="s-deprecated-features-1-6"></span><span id="features-deprecated-in-1-6"></span><span id="deprecated-features-1-6"></span><h2>Features deprecated in 1.6<a class="headerlink" href="#features-deprecated-in-1-6" title="Permalink to this headline">¶</a></h2>
<div class="section" id="s-transaction-management-apis">
<span id="transaction-management-apis"></span><h3>Transaction management APIs<a class="headerlink" href="#transaction-management-apis" title="Permalink to this headline">¶</a></h3>
<p>Transaction management was completely overhauled in Django 1.6, and the
current APIs are deprecated:</p>
<ul class="simple">
<li><code class="docutils literal"><span class="pre">django.middleware.transaction.TransactionMiddleware</span></code></li>
<li><code class="docutils literal"><span class="pre">django.db.transaction.autocommit</span></code></li>
<li><code class="docutils literal"><span class="pre">django.db.transaction.commit_on_success</span></code></li>
<li><code class="docutils literal"><span class="pre">django.db.transaction.commit_manually</span></code></li>
<li>the <code class="docutils literal"><span class="pre">TRANSACTIONS_MANAGED</span></code> setting</li>
</ul>
</div>
<div class="section" id="s-django-contrib-comments">
<span id="django-contrib-comments"></span><h3><code class="docutils literal"><span class="pre">django.contrib.comments</span></code><a class="headerlink" href="#django-contrib-comments" title="Permalink to this headline">¶</a></h3>
<p>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 <a class="reference external" href="https://disqus.com/">Disqus</a>.</p>
<p>The code formerly known as <code class="docutils literal"><span class="pre">django.contrib.comments</span></code> is <a class="reference external" href="https://github.com/django/django-contrib-comments">still available
in an external repository</a>.</p>
</div>
<div class="section" id="s-support-for-postgresql-versions-older-than-8-4">
<span id="support-for-postgresql-versions-older-than-8-4"></span><h3>Support for PostgreSQL versions older than 8.4<a class="headerlink" href="#support-for-postgresql-versions-older-than-8-4" title="Permalink to this headline">¶</a></h3>
<p>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.</p>
<p>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.</p>
</div>
<div class="section" id="s-changes-to-cycle-and-firstof">
<span id="changes-to-cycle-and-firstof"></span><h3>Changes to <a class="reference internal" href="../ref/templates/builtins.html#std:templatetag-cycle"><code class="xref std std-ttag docutils literal"><span class="pre">cycle</span></code></a> and <a class="reference internal" href="../ref/templates/builtins.html#std:templatetag-firstof"><code class="xref std std-ttag docutils literal"><span class="pre">firstof</span></code></a><a class="headerlink" href="#changes-to-cycle-and-firstof" title="Permalink to this headline">¶</a></h3>
<p>The template system generally escapes all variables to avoid XSS attacks.
However, due to an accident of history, the <a class="reference internal" href="../ref/templates/builtins.html#std:templatetag-cycle"><code class="xref std std-ttag docutils literal"><span class="pre">cycle</span></code></a> and <a class="reference internal" href="../ref/templates/builtins.html#std:templatetag-firstof"><code class="xref std std-ttag docutils literal"><span class="pre">firstof</span></code></a>
tags render their arguments as-is.</p>
<p>Django 1.6 starts a process to correct this inconsistency. The <code class="docutils literal"><span class="pre">future</span></code>
template library provides alternate implementations of <a class="reference internal" href="../ref/templates/builtins.html#std:templatetag-cycle"><code class="xref std std-ttag docutils literal"><span class="pre">cycle</span></code></a> and
<a class="reference internal" href="../ref/templates/builtins.html#std:templatetag-firstof"><code class="xref std std-ttag docutils literal"><span class="pre">firstof</span></code></a> that autoescape their inputs. If you’re using these tags,
you’re encouraged to include the following line at the top of your templates to
enable the new behavior:</p>
<div class="highlight-default"><div class="highlight"><pre><span></span><span class="p">{</span><span class="o">%</span> <span class="n">load</span> <span class="n">cycle</span> <span class="kn">from</span> <span class="nn">future</span> <span class="o">%</span><span class="p">}</span>
</pre></div>
</div>
<p>or:</p>
<div class="highlight-default"><div class="highlight"><pre><span></span><span class="p">{</span><span class="o">%</span> <span class="n">load</span> <span class="n">firstof</span> <span class="kn">from</span> <span class="nn">future</span> <span class="o">%</span><span class="p">}</span>
</pre></div>
</div>
<p>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 <code class="docutils literal"><span class="pre">future</span></code> versions.</p>
<p>If necessary, you can temporarily disable auto-escaping with
<a class="reference internal" href="../ref/utils.html#django.utils.safestring.mark_safe" title="django.utils.safestring.mark_safe"><code class="xref py py-func docutils literal"><span class="pre">mark_safe()</span></code></a> or <a class="reference internal" href="../ref/templates/builtins.html#std:templatetag-autoescape"><code class="xref std std-ttag docutils literal"><span class="pre">{%</span> <span class="pre">autoescape</span> <span class="pre">off</span> <span class="pre">%}</span></code></a>.</p>
</div>
<div class="section" id="s-cache-middleware-anonymous-only-setting">
<span id="cache-middleware-anonymous-only-setting"></span><h3><code class="docutils literal"><span class="pre">CACHE_MIDDLEWARE_ANONYMOUS_ONLY</span></code> setting<a class="headerlink" href="#cache-middleware-anonymous-only-setting" title="Permalink to this headline">¶</a></h3>
<p><code class="docutils literal"><span class="pre">CacheMiddleware</span></code> and <code class="docutils literal"><span class="pre">UpdateCacheMiddleware</span></code> used to provide a way to
cache requests only if they weren’t made by a logged-in user. This mechanism
was largely ineffective because the middleware correctly takes into account the
<code class="docutils literal"><span class="pre">Vary:</span> <span class="pre">Cookie</span></code> HTTP header, and this header is being set on a variety of
occasions, such as:</p>
<ul class="simple">
<li>accessing the session, or</li>
<li>using CSRF protection, which is turned on by default, or</li>
<li>using a client-side library which sets cookies, like <a class="reference external" href="http://www.google.com/analytics/">Google Analytics</a>.</li>
</ul>
<p>This makes the cache effectively work on a per-session basis regardless of the
<code class="docutils literal"><span class="pre">CACHE_MIDDLEWARE_ANONYMOUS_ONLY</span></code> setting.</p>
</div>
<div class="section" id="s-send-broken-link-emails-setting">
<span id="send-broken-link-emails-setting"></span><h3><code class="docutils literal"><span class="pre">SEND_BROKEN_LINK_EMAILS</span></code> setting<a class="headerlink" href="#send-broken-link-emails-setting" title="Permalink to this headline">¶</a></h3>
<p><a class="reference internal" href="../ref/middleware.html#django.middleware.common.CommonMiddleware" title="django.middleware.common.CommonMiddleware"><code class="xref py py-class docutils literal"><span class="pre">CommonMiddleware</span></code></a> used to provide basic
reporting of broken links by email when <code class="docutils literal"><span class="pre">SEND_BROKEN_LINK_EMAILS</span></code> is set to
<code class="docutils literal"><span class="pre">True</span></code>.</p>
<p>Because of intractable ordering problems between
<a class="reference internal" href="../ref/middleware.html#django.middleware.common.CommonMiddleware" title="django.middleware.common.CommonMiddleware"><code class="xref py py-class docutils literal"><span class="pre">CommonMiddleware</span></code></a> and
<a class="reference internal" href="../ref/middleware.html#django.middleware.locale.LocaleMiddleware" title="django.middleware.locale.LocaleMiddleware"><code class="xref py py-class docutils literal"><span class="pre">LocaleMiddleware</span></code></a>, this feature was split
out into a new middleware:
<a class="reference internal" href="../ref/middleware.html#django.middleware.common.BrokenLinkEmailsMiddleware" title="django.middleware.common.BrokenLinkEmailsMiddleware"><code class="xref py py-class docutils literal"><span class="pre">BrokenLinkEmailsMiddleware</span></code></a>.</p>
<p>If you’re relying on this feature, you should add
<code class="docutils literal"><span class="pre">'django.middleware.common.BrokenLinkEmailsMiddleware'</span></code> to your
<a class="reference internal" href="../ref/settings.html#std:setting-MIDDLEWARE_CLASSES"><code class="xref std std-setting docutils literal"><span class="pre">MIDDLEWARE_CLASSES</span></code></a> setting and remove <code class="docutils literal"><span class="pre">SEND_BROKEN_LINK_EMAILS</span></code>
from your settings.</p>
</div>
<div class="section" id="s-has-changed-method-on-widgets">
<span id="has-changed-method-on-widgets"></span><h3><code class="docutils literal"><span class="pre">_has_changed</span></code> method on widgets<a class="headerlink" href="#has-changed-method-on-widgets" title="Permalink to this headline">¶</a></h3>
<p>If you defined your own form widgets and defined the <code class="docutils literal"><span class="pre">_has_changed</span></code> method
on a widget, you should now define this method on the form field itself.</p>
</div>
<div class="section" id="s-module-name-model-meta-attribute">
<span id="module-name-model-meta-attribute"></span><h3><code class="docutils literal"><span class="pre">module_name</span></code> model _meta attribute<a class="headerlink" href="#module-name-model-meta-attribute" title="Permalink to this headline">¶</a></h3>
<p><code class="docutils literal"><span class="pre">Model._meta.module_name</span></code> was renamed to <code class="docutils literal"><span class="pre">model_name</span></code>. Despite being a
private API, it will go through a regular deprecation path.</p>
</div>
<div class="section" id="s-get-add-change-delete-permission-model-meta-methods">
<span id="get-add-change-delete-permission-model-meta-methods"></span><h3><code class="docutils literal"><span class="pre">get_(add|change|delete)_permission</span></code> model _meta methods<a class="headerlink" href="#get-add-change-delete-permission-model-meta-methods" title="Permalink to this headline">¶</a></h3>
<p><code class="docutils literal"><span class="pre">Model._meta.get_(add|change|delete)_permission</span></code> methods were deprecated.
Even if they were not part of the public API they’ll also go through
a regular deprecation path. You can replace them with
<code class="docutils literal"><span class="pre">django.contrib.auth.get_permission_codename('action',</span> <span class="pre">Model._meta)</span></code> where
<code class="docutils literal"><span class="pre">'action'</span></code> is <code class="docutils literal"><span class="pre">'add'</span></code>, <code class="docutils literal"><span class="pre">'change'</span></code>, or <code class="docutils literal"><span class="pre">'delete'</span></code>.</p>
</div>
<div class="section" id="s-get-query-set-and-similar-methods-renamed-to-get-queryset">
<span id="get-query-set-and-similar-methods-renamed-to-get-queryset"></span><h3><code class="docutils literal"><span class="pre">get_query_set</span></code> and similar methods renamed to <code class="docutils literal"><span class="pre">get_queryset</span></code><a class="headerlink" href="#get-query-set-and-similar-methods-renamed-to-get-queryset" title="Permalink to this headline">¶</a></h3>
<p>Methods that return a <code class="docutils literal"><span class="pre">QuerySet</span></code> such as <code class="docutils literal"><span class="pre">Manager.get_query_set</span></code> or
<code class="docutils literal"><span class="pre">ModelAdmin.queryset</span></code> have been renamed to <code class="docutils literal"><span class="pre">get_queryset</span></code>.</p>
<p>If you are writing a library that implements, for example, a
<code class="docutils literal"><span class="pre">Manager.get_query_set</span></code> method, and you need to support old Django versions,
you should rename the method and conditionally add an alias with the old name:</p>
<div class="highlight-default"><div class="highlight"><pre><span></span><span class="k">class</span> <span class="nc">CustomManager</span><span class="p">(</span><span class="n">models</span><span class="o">.</span><span class="n">Manager</span><span class="p">):</span>
<span class="k">def</span> <span class="nf">get_queryset</span><span class="p">(</span><span class="bp">self</span><span class="p">):</span>
<span class="k">pass</span> <span class="c1"># ...</span>
<span class="k">if</span> <span class="n">django</span><span class="o">.</span><span class="n">VERSION</span> <span class="o"><</span> <span class="p">(</span><span class="mi">1</span><span class="p">,</span> <span class="mi">6</span><span class="p">):</span>
<span class="n">get_query_set</span> <span class="o">=</span> <span class="n">get_queryset</span>
<span class="c1"># For Django >= 1.6, models.Manager provides a get_query_set fallback</span>
<span class="c1"># that emits a warning when used.</span>
</pre></div>
</div>
<p>If you are writing a library that needs to call the <code class="docutils literal"><span class="pre">get_queryset</span></code> method and
must support old Django versions, you should write:</p>
<div class="highlight-default"><div class="highlight"><pre><span></span><span class="n">get_queryset</span> <span class="o">=</span> <span class="p">(</span><span class="n">some_manager</span><span class="o">.</span><span class="n">get_query_set</span>
<span class="k">if</span> <span class="nb">hasattr</span><span class="p">(</span><span class="n">some_manager</span><span class="p">,</span> <span class="s1">'get_query_set'</span><span class="p">)</span>
<span class="k">else</span> <span class="n">some_manager</span><span class="o">.</span><span class="n">get_queryset</span><span class="p">)</span>
<span class="k">return</span> <span class="n">get_queryset</span><span class="p">()</span> <span class="c1"># etc</span>
</pre></div>
</div>
<p>In the general case of a custom manager that both implements its own
<code class="docutils literal"><span class="pre">get_queryset</span></code> method and calls that method, and needs to work with older Django
versions, and libraries that have not been updated yet, it is useful to define
a <code class="docutils literal"><span class="pre">get_queryset_compat</span></code> method as below and use it internally to your manager:</p>
<div class="highlight-default"><div class="highlight"><pre><span></span><span class="k">class</span> <span class="nc">YourCustomManager</span><span class="p">(</span><span class="n">models</span><span class="o">.</span><span class="n">Manager</span><span class="p">):</span>
<span class="k">def</span> <span class="nf">get_queryset</span><span class="p">(</span><span class="bp">self</span><span class="p">):</span>
<span class="k">return</span> <span class="n">YourCustomQuerySet</span><span class="p">()</span> <span class="c1"># for example</span>
<span class="k">if</span> <span class="n">django</span><span class="o">.</span><span class="n">VERSION</span> <span class="o"><</span> <span class="p">(</span><span class="mi">1</span><span class="p">,</span> <span class="mi">6</span><span class="p">):</span>
<span class="n">get_query_set</span> <span class="o">=</span> <span class="n">get_queryset</span>
<span class="k">def</span> <span class="nf">active</span><span class="p">(</span><span class="bp">self</span><span class="p">):</span> <span class="c1"># for example</span>
<span class="k">return</span> <span class="bp">self</span><span class="o">.</span><span class="n">get_queryset_compat</span><span class="p">()</span><span class="o">.</span><span class="n">filter</span><span class="p">(</span><span class="n">active</span><span class="o">=</span><span class="kc">True</span><span class="p">)</span>
<span class="k">def</span> <span class="nf">get_queryset_compat</span><span class="p">(</span><span class="bp">self</span><span class="p">):</span>
<span class="n">get_queryset</span> <span class="o">=</span> <span class="p">(</span><span class="bp">self</span><span class="o">.</span><span class="n">get_query_set</span>
<span class="k">if</span> <span class="nb">hasattr</span><span class="p">(</span><span class="bp">self</span><span class="p">,</span> <span class="s1">'get_query_set'</span><span class="p">)</span>
<span class="k">else</span> <span class="bp">self</span><span class="o">.</span><span class="n">get_queryset</span><span class="p">)</span>
<span class="k">return</span> <span class="n">get_queryset</span><span class="p">()</span>
</pre></div>
</div>
<p>This helps to minimize the changes that are needed, but also works correctly in
the case of subclasses (such as <code class="docutils literal"><span class="pre">RelatedManagers</span></code> from Django 1.5) which might
override either <code class="docutils literal"><span class="pre">get_query_set</span></code> or <code class="docutils literal"><span class="pre">get_queryset</span></code>.</p>
</div>
<div class="section" id="s-shortcut-view-and-urlconf">
<span id="shortcut-view-and-urlconf"></span><h3><code class="docutils literal"><span class="pre">shortcut</span></code> view and URLconf<a class="headerlink" href="#shortcut-view-and-urlconf" title="Permalink to this headline">¶</a></h3>
<p>The <code class="docutils literal"><span class="pre">shortcut</span></code> view was moved from <code class="docutils literal"><span class="pre">django.views.defaults</span></code> to
<code class="docutils literal"><span class="pre">django.contrib.contenttypes.views</span></code> 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.</p>
<p>The URLconf <code class="docutils literal"><span class="pre">django.conf.urls.shortcut</span></code> was also deprecated. If you’re
including it in an URLconf, simply replace:</p>
<div class="highlight-default"><div class="highlight"><pre><span></span><span class="p">(</span><span class="s1">r'^prefix/'</span><span class="p">,</span> <span class="n">include</span><span class="p">(</span><span class="s1">'django.conf.urls.shortcut'</span><span class="p">)),</span>
</pre></div>
</div>
<p>with:</p>
<div class="highlight-default"><div class="highlight"><pre><span></span><span class="p">(</span><span class="s1">r'^prefix/(?P<content_type_id>\d+)/(?P<object_id>.*)/$'</span><span class="p">,</span> <span class="s1">'django.contrib.contenttypes.views.shortcut'</span><span class="p">),</span>
</pre></div>
</div>
</div>
<div class="section" id="s-modelform-without-fields-or-exclude">
<span id="modelform-without-fields-or-exclude"></span><h3><code class="docutils literal"><span class="pre">ModelForm</span></code> without <code class="docutils literal"><span class="pre">fields</span></code> or <code class="docutils literal"><span class="pre">exclude</span></code><a class="headerlink" href="#modelform-without-fields-or-exclude" title="Permalink to this headline">¶</a></h3>
<p>Previously, if you wanted a <a class="reference internal" href="../topics/forms/modelforms.html#django.forms.ModelForm" title="django.forms.ModelForm"><code class="xref py py-class docutils literal"><span class="pre">ModelForm</span></code></a> to use all fields on
the model, you could simply omit the <code class="docutils literal"><span class="pre">Meta.fields</span></code> attribute, and all fields
would be used.</p>
<p>This can lead to security problems where fields are added to the model and,
unintentionally, automatically become editable by end users. In some cases,
particular with boolean fields, it is possible for this problem to be completely
invisible. This is a form of <a class="reference external" href="https://en.wikipedia.org/wiki/Mass_assignment_vulnerability">Mass assignment vulnerability</a>.</p>
<p>For this reason, this behavior is deprecated, and using the <code class="docutils literal"><span class="pre">Meta.exclude</span></code>
option is strongly discouraged. Instead, all fields that are intended for
inclusion in the form should be listed explicitly in the <code class="docutils literal"><span class="pre">fields</span></code> attribute.</p>
<p>If this security concern really does not apply in your case, there is a shortcut
to explicitly indicate that all fields should be used - use the special value
<code class="docutils literal"><span class="pre">"__all__"</span></code> for the fields attribute:</p>
<div class="highlight-default"><div class="highlight"><pre><span></span><span class="k">class</span> <span class="nc">MyModelForm</span><span class="p">(</span><span class="n">ModelForm</span><span class="p">):</span>
<span class="k">class</span> <span class="nc">Meta</span><span class="p">:</span>
<span class="n">fields</span> <span class="o">=</span> <span class="s2">"__all__"</span>
<span class="n">model</span> <span class="o">=</span> <span class="n">MyModel</span>
</pre></div>
</div>
<p>If you have custom <code class="docutils literal"><span class="pre">ModelForms</span></code> that only need to be used in the admin, there
is another option. The admin has its own methods for defining fields
(<code class="docutils literal"><span class="pre">fieldsets</span></code> etc.), and so adding a list of fields to the <code class="docutils literal"><span class="pre">ModelForm</span></code> is
redundant. Instead, simply omit the <code class="docutils literal"><span class="pre">Meta</span></code> inner class of the <code class="docutils literal"><span class="pre">ModelForm</span></code>,
or omit the <code class="docutils literal"><span class="pre">Meta.model</span></code> attribute. Since the <code class="docutils literal"><span class="pre">ModelAdmin</span></code> subclass knows
which model it is for, it can add the necessary attributes to derive a
functioning <code class="docutils literal"><span class="pre">ModelForm</span></code>. This behavior also works for earlier Django
versions.</p>
</div>
<div class="section" id="s-updateview-and-createview-without-explicit-fields">
<span id="updateview-and-createview-without-explicit-fields"></span><h3><code class="docutils literal"><span class="pre">UpdateView</span></code> and <code class="docutils literal"><span class="pre">CreateView</span></code> without explicit fields<a class="headerlink" href="#updateview-and-createview-without-explicit-fields" title="Permalink to this headline">¶</a></h3>
<p>The generic views <a class="reference internal" href="../ref/class-based-views/generic-editing.html#django.views.generic.edit.CreateView" title="django.views.generic.edit.CreateView"><code class="xref py py-class docutils literal"><span class="pre">CreateView</span></code></a> and
<a class="reference internal" href="../ref/class-based-views/generic-editing.html#django.views.generic.edit.UpdateView" title="django.views.generic.edit.UpdateView"><code class="xref py py-class docutils literal"><span class="pre">UpdateView</span></code></a>, and anything else derived from
<a class="reference internal" href="../ref/class-based-views/mixins-editing.html#django.views.generic.edit.ModelFormMixin" title="django.views.generic.edit.ModelFormMixin"><code class="xref py py-class docutils literal"><span class="pre">ModelFormMixin</span></code></a>, are vulnerable to the
security problem described in the section above, because they can automatically
create a <code class="docutils literal"><span class="pre">ModelForm</span></code> that uses all fields for a model.</p>
<p>For this reason, if you use these views for editing models, you must also supply
the <code class="docutils literal"><span class="pre">fields</span></code> attribute (new in Django 1.6), which is a list of model fields
and works in the same way as the <a class="reference internal" href="../topics/forms/modelforms.html#django.forms.ModelForm" title="django.forms.ModelForm"><code class="xref py py-class docutils literal"><span class="pre">ModelForm</span></code></a>
<code class="docutils literal"><span class="pre">Meta.fields</span></code> attribute. Alternatively, you can set the <code class="docutils literal"><span class="pre">form_class</span></code>
attribute to a <code class="docutils literal"><span class="pre">ModelForm</span></code> that explicitly defines the fields to be used.
Defining an <code class="docutils literal"><span class="pre">UpdateView</span></code> or <code class="docutils literal"><span class="pre">CreateView</span></code> subclass to be used with a model
but without an explicit list of fields is deprecated.</p>
</div>
<div class="section" id="s-munging-of-help-text-of-model-form-fields-for-manytomanyfield-fields">
<span id="s-m2m-help-text-deprecation"></span><span id="munging-of-help-text-of-model-form-fields-for-manytomanyfield-fields"></span><span id="m2m-help-text-deprecation"></span><h3>Munging of help text of model form fields for <code class="docutils literal"><span class="pre">ManyToManyField</span></code> fields<a class="headerlink" href="#munging-of-help-text-of-model-form-fields-for-manytomanyfield-fields" title="Permalink to this headline">¶</a></h3>
<p>All special handling of the <code class="docutils literal"><span class="pre">help_text</span></code> attribute of <code class="docutils literal"><span class="pre">ManyToManyField</span></code> model
fields performed by standard model or model form fields as described in
<a class="reference internal" href="#m2m-help-text"><span class="std std-ref">Help text of model form fields for ManyToManyField fields</span></a> above is deprecated and will be removed in Django 1.8.</p>
<p>Help text of these fields will need to be handled either by applications, custom
form fields or widgets, just like happens with the rest of the model field
types.</p>
</div>
</div>
</div>
</div>
</div>
</div>
<div class="yui-b" id="sidebar">
<div class="sphinxsidebar" role="navigation" aria-label="main navigation">
<div class="sphinxsidebarwrapper">
<h3><a href="../contents.html">Table Of Contents</a></h3>
<ul>
<li><a class="reference internal" href="#">Django 1.6 release notes</a><ul>
<li><a class="reference internal" href="#python-compatibility">Python compatibility</a></li>
<li><a class="reference internal" href="#what-s-new-in-django-1-6">What’s new in Django 1.6</a><ul>
<li><a class="reference internal" href="#simplified-default-project-and-app-templates">Simplified default project and app templates</a></li>
<li><a class="reference internal" href="#improved-transaction-management">Improved transaction management</a></li>
<li><a class="reference internal" href="#persistent-database-connections">Persistent database connections</a></li>
<li><a class="reference internal" href="#discovery-of-tests-in-any-test-module">Discovery of tests in any test module</a></li>
<li><a class="reference internal" href="#time-zone-aware-aggregation">Time zone aware aggregation</a></li>
<li><a class="reference internal" href="#support-for-savepoints-in-sqlite">Support for savepoints in SQLite</a></li>
<li><a class="reference internal" href="#binaryfield-model-field"><code class="docutils literal"><span class="pre">BinaryField</span></code> model field</a></li>
<li><a class="reference internal" href="#geodjango-form-widgets">GeoDjango form widgets</a></li>
<li><a class="reference internal" href="#check-management-command-added-for-verifying-compatibility"><code class="docutils literal"><span class="pre">check</span></code> management command added for verifying compatibility</a></li>
<li><a class="reference internal" href="#model-save-algorithm-changed"><code class="docutils literal"><span class="pre">Model.save()</span></code> algorithm changed</a></li>
<li><a class="reference internal" href="#minor-features">Minor features</a></li>
</ul>
</li>
<li><a class="reference internal" href="#backwards-incompatible-changes-in-1-6">Backwards incompatible changes in 1.6</a><ul>
<li><a class="reference internal" href="#new-transaction-management-model">New transaction management model</a><ul>
<li><a class="reference internal" href="#behavior-changes">Behavior changes</a></li>
<li><a class="reference internal" href="#savepoints-and-assertnumqueries">Savepoints and <code class="docutils literal"><span class="pre">assertNumQueries</span></code></a></li>
<li><a class="reference internal" href="#autocommit-option-for-postgresql">Autocommit option for PostgreSQL</a></li>
</ul>
</li>
<li><a class="reference internal" href="#new-test-runner">New test runner</a></li>
<li><a class="reference internal" href="#removal-of-django-contrib-gis-tests-geodjangotestsuiterunner-geodjango-custom-test-runner">Removal of <code class="docutils literal"><span class="pre">django.contrib.gis.tests.GeoDjangoTestSuiteRunner</span></code> GeoDjango custom test runner</a></li>
<li><a class="reference internal" href="#custom-user-models-in-tests">Custom User models in tests</a></li>
<li><a class="reference internal" href="#time-zone-aware-day-month-and-week-day-lookups">Time zone-aware <code class="docutils literal"><span class="pre">day</span></code>, <code class="docutils literal"><span class="pre">month</span></code>, and <code class="docutils literal"><span class="pre">week_day</span></code> lookups</a></li>
<li><a class="reference internal" href="#addition-of-queryset-datetimes">Addition of <code class="docutils literal"><span class="pre">QuerySet.datetimes()</span></code></a><ul>
<li><a class="reference internal" href="#queryset-dates-returns-date-objects"><code class="docutils literal"><span class="pre">QuerySet.dates()</span></code> returns <code class="docutils literal"><span class="pre">date</span></code> objects</a></li>
<li><a class="reference internal" href="#queryset-dates-no-longer-usable-on-datetimefield"><code class="docutils literal"><span class="pre">QuerySet.dates()</span></code> no longer usable on <code class="docutils literal"><span class="pre">DateTimeField</span></code></a></li>
<li><a class="reference internal" href="#date-hierarchy-requires-time-zone-definitions"><code class="docutils literal"><span class="pre">date_hierarchy</span></code> requires time zone definitions</a></li>
<li><a class="reference internal" href="#date-list-in-generic-views-requires-time-zone-definitions"><code class="docutils literal"><span class="pre">date_list</span></code> in generic views requires time zone definitions</a></li>
</ul>
</li>
<li><a class="reference internal" href="#new-lookups-may-clash-with-model-fields">New lookups may clash with model fields</a></li>
<li><a class="reference internal" href="#booleanfield-no-longer-defaults-to-false"><code class="docutils literal"><span class="pre">BooleanField</span></code> no longer defaults to <code class="docutils literal"><span class="pre">False</span></code></a></li>
<li><a class="reference internal" href="#translations-and-comments-in-templates">Translations and comments in templates</a><ul>
<li><a class="reference internal" href="#extraction-of-translations-after-comments">Extraction of translations after comments</a></li>
<li><a class="reference internal" href="#location-of-translator-comments">Location of translator comments</a></li>
</ul>
</li>
<li><a class="reference internal" href="#quoting-in-reverse">Quoting in <code class="docutils literal"><span class="pre">reverse()</span></code></a></li>
<li><a class="reference internal" href="#storage-of-ip-addresses-in-the-comments-app">Storage of IP addresses in the comments app</a></li>
<li><a class="reference internal" href="#percent-literals-in-cursor-execute-queries">Percent literals in <code class="docutils literal"><span class="pre">cursor.execute</span></code> queries</a></li>
<li><a class="reference internal" href="#help-text-of-model-form-fields-for-manytomanyfield-fields">Help text of model form fields for ManyToManyField fields</a></li>
<li><a class="reference internal" href="#queryset-iteration">QuerySet iteration</a></li>
<li><a class="reference internal" href="#boundfield-label-tag-now-includes-the-form-s-label-suffix"><code class="docutils literal"><span class="pre">BoundField.label_tag</span></code> now includes the form’s <code class="docutils literal"><span class="pre">label_suffix</span></code></a></li>
<li><a class="reference internal" href="#admin-views-changelist-filters-get-parameter">Admin views <code class="docutils literal"><span class="pre">_changelist_filters</span></code> GET parameter</a></li>
<li><a class="reference internal" href="#django-contrib-auth-password-reset-uses-base-64-encoding-of-user-pk"><code class="docutils literal"><span class="pre">django.contrib.auth</span></code> password reset uses base 64 encoding of <code class="docutils literal"><span class="pre">User</span></code> PK</a></li>
<li><a class="reference internal" href="#default-session-serialization-switched-to-json">Default session serialization switched to JSON</a></li>
<li><a class="reference internal" href="#object-relational-mapper-changes">Object Relational Mapper changes</a></li>
<li><a class="reference internal" href="#miscellaneous">Miscellaneous</a></li>
</ul>
</li>
<li><a class="reference internal" href="#features-deprecated-in-1-6">Features deprecated in 1.6</a><ul>
<li><a class="reference internal" href="#transaction-management-apis">Transaction management APIs</a></li>
<li><a class="reference internal" href="#django-contrib-comments"><code class="docutils literal"><span class="pre">django.contrib.comments</span></code></a></li>
<li><a class="reference internal" href="#support-for-postgresql-versions-older-than-8-4">Support for PostgreSQL versions older than 8.4</a></li>
<li><a class="reference internal" href="#changes-to-cycle-and-firstof">Changes to <code class="docutils literal"><span class="pre">cycle</span></code> and <code class="docutils literal"><span class="pre">firstof</span></code></a></li>
<li><a class="reference internal" href="#cache-middleware-anonymous-only-setting"><code class="docutils literal"><span class="pre">CACHE_MIDDLEWARE_ANONYMOUS_ONLY</span></code> setting</a></li>
<li><a class="reference internal" href="#send-broken-link-emails-setting"><code class="docutils literal"><span class="pre">SEND_BROKEN_LINK_EMAILS</span></code> setting</a></li>
<li><a class="reference internal" href="#has-changed-method-on-widgets"><code class="docutils literal"><span class="pre">_has_changed</span></code> method on widgets</a></li>
<li><a class="reference internal" href="#module-name-model-meta-attribute"><code class="docutils literal"><span class="pre">module_name</span></code> model _meta attribute</a></li>
<li><a class="reference internal" href="#get-add-change-delete-permission-model-meta-methods"><code class="docutils literal"><span class="pre">get_(add|change|delete)_permission</span></code> model _meta methods</a></li>
<li><a class="reference internal" href="#get-query-set-and-similar-methods-renamed-to-get-queryset"><code class="docutils literal"><span class="pre">get_query_set</span></code> and similar methods renamed to <code class="docutils literal"><span class="pre">get_queryset</span></code></a></li>
<li><a class="reference internal" href="#shortcut-view-and-urlconf"><code class="docutils literal"><span class="pre">shortcut</span></code> view and URLconf</a></li>
<li><a class="reference internal" href="#modelform-without-fields-or-exclude"><code class="docutils literal"><span class="pre">ModelForm</span></code> without <code class="docutils literal"><span class="pre">fields</span></code> or <code class="docutils literal"><span class="pre">exclude</span></code></a></li>
<li><a class="reference internal" href="#updateview-and-createview-without-explicit-fields"><code class="docutils literal"><span class="pre">UpdateView</span></code> and <code class="docutils literal"><span class="pre">CreateView</span></code> without explicit fields</a></li>
<li><a class="reference internal" href="#munging-of-help-text-of-model-form-fields-for-manytomanyfield-fields">Munging of help text of model form fields for <code class="docutils literal"><span class="pre">ManyToManyField</span></code> fields</a></li>
</ul>
</li>
</ul>
</li>
</ul>
<h3>Browse</h3>
<ul>
<li>Prev: <a href="1.6.1.html">Django 1.6.1 release notes</a></li>
<li>Next: <a href="1.5.12.html">Django 1.5.12 release notes</a></li>
</ul>
<h3>You are here:</h3>
<ul>
<li>
<a href="../index.html">Django 1.8.19 documentation</a>
<ul><li><a href="index.html">Release notes</a>
<ul><li>Django 1.6 release notes</li></ul>
</li></ul>
</li>
</ul>
<div role="note" aria-label="source link">
<h3>This Page</h3>
<ul class="this-page-menu">
<li><a href="../_sources/releases/1.6.txt"
rel="nofollow">Show Source</a></li>
</ul>
</div>
<div id="searchbox" style="display: none" role="search">
<h3>Quick search</h3>
<form class="search" action="../search.html" method="get">
<div><input type="text" name="q" /></div>
<div><input type="submit" value="Go" /></div>
<input type="hidden" name="check_keywords" value="yes" />
<input type="hidden" name="area" value="default" />
</form>
</div>
<script type="text/javascript">$('#searchbox').show(0);</script>
</div>
</div>
<h3>Last update:</h3>
<p class="topless">Mar 10, 2018</p>
</div>
</div>
<div id="ft">
<div class="nav">
« <a href="1.6.1.html" title="Django 1.6.1 release notes">previous</a>
|
<a href="index.html" title="Release notes" accesskey="U">up</a>
|
<a href="1.5.12.html" title="Django 1.5.12 release notes">next</a> »</div>
</div>
</div>
<div class="clearer"></div>
</div>
</body>
</html>
distrib
>
Mageia
>
6
>
armv7hl
>
media
>
core-updates
>
by-pkgid
>
65530c6176058f9b54858c3b4f6385e6
>
files
>
874
