<!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">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<title>Django 1.5 release notes — Django 1.6.7 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.6.7',
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="top" title="Django 1.6.7 documentation" href="../index.html" />
<link rel="up" title="Release notes" href="index.html" />
<link rel="next" title="Django 1.4.15 release notes" href="1.4.15.html" />
<link rel="prev" title="Django 1.5.1 release notes" href="1.5.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>
<div class="document">
<div id="custom-doc" class="yui-t6">
<div id="hd">
<h1><a href="../index.html">Django 1.6.7 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.5.1.html" title="Django 1.5.1 release notes">previous</a>
|
<a href="index.html" title="Release notes" accesskey="U">up</a>
|
<a href="1.4.15.html" title="Django 1.4.15 release notes">next</a> »</div>
</div>
<div id="bd">
<div id="yui-main">
<div class="yui-b">
<div class="yui-g" id="releases-1.5">
<div class="section" id="s-django-1-5-release-notes">
<span id="django-1-5-release-notes"></span><h1>Django 1.5 release notes<a class="headerlink" href="#django-1-5-release-notes" title="Permalink to this headline">¶</a></h1>
<p><em>February 26, 2013</em></p>
<p>Welcome to Django 1.5!</p>
<p>These release notes cover the <a class="reference internal" href="#what-s-new-in-django-1-5">new features</a>, as well
as some <a class="reference internal" href="#backwards-incompatible-changes-in-1-5">backwards incompatible changes</a> you’ll want to be aware of
when upgrading from Django 1.4 or older versions. We’ve also dropped some
features, which are detailed in <a class="reference internal" href="../internals/deprecation.html"><em>our deprecation plan</em></a>, and we’ve <a class="reference internal" href="#features-deprecated-in-1-5">begun the deprecation process for some
features</a>.</p>
<div class="section" id="s-overview">
<span id="overview"></span><h2>Overview<a class="headerlink" href="#overview" title="Permalink to this headline">¶</a></h2>
<p>The biggest new feature in Django 1.5 is the <a class="reference internal" href="#configurable-user-model">configurable User model</a>. Before
Django 1.5, applications that wanted to use Django’s auth framework
(<a class="reference internal" href="../topics/auth/index.html#module-django.contrib.auth" title="django.contrib.auth: Django's authentication framework."><tt class="xref py py-mod docutils literal"><span class="pre">django.contrib.auth</span></tt></a>) were forced to use Django’s definition of a “user”.
In Django 1.5, you can now swap out the <tt class="docutils literal"><span class="pre">User</span></tt> model for one that you write
yourself. This could be a simple extension to the existing <tt class="docutils literal"><span class="pre">User</span></tt> model – for
example, you could add a Twitter or Facebook ID field – or you could completely
replace the <tt class="docutils literal"><span class="pre">User</span></tt> with one totally customized for your site.</p>
<p>Django 1.5 is also the first release with <a class="reference internal" href="#python-3-support">Python 3 support</a>! We’re labeling
this support “experimental” because we don’t yet consider it production-ready,
but everything’s in place for you to start porting your apps to Python 3.
Our next release, Django 1.6, will support Python 3 without reservations.</p>
<p>Other notable new features in Django 1.5 include:</p>
<ul class="simple">
<li><a class="reference internal" href="#support-for-saving-a-subset-of-model-s-fields">Support for saving a subset of model’s fields</a> -
<a class="reference internal" href="../ref/models/instances.html#django.db.models.Model.save" title="django.db.models.Model.save"><tt class="xref py py-meth docutils literal"><span class="pre">Model.save()</span></tt></a> now accepts an
<tt class="docutils literal"><span class="pre">update_fields</span></tt> argument, letting you specify which fields are
written back to the database when you call <tt class="docutils literal"><span class="pre">save()</span></tt>. This can help
in high-concurrency operations, and can improve performance.</li>
<li>Better <a class="reference external" href="#explicit-streaming-responses">support for streaming responses</a> via
the new <a class="reference internal" href="../ref/request-response.html#django.http.StreamingHttpResponse" title="django.http.StreamingHttpResponse"><tt class="xref py py-class docutils literal"><span class="pre">StreamingHttpResponse</span></tt></a> response class.</li>
<li><a class="reference internal" href="#geodjango">GeoDjango</a> now supports PostGIS 2.0.</li>
<li>... and more; <a class="reference external" href="#what-s-new-in-django-1-5">see below</a>.</li>
</ul>
<p>Wherever possible we try to introduce new features in a backwards-compatible
manner per <a class="reference internal" href="../misc/api-stability.html"><em>our API stability policy</em></a>.
However, as with previous releases, Django 1.5 ships with some minor
<a class="reference internal" href="#backwards-incompatible-changes-in-1-5">backwards incompatible changes</a>; people upgrading from previous versions
of Django should read that list carefully.</p>
<p>One deprecated feature worth noting is the shift to “new-style” <a class="reference internal" href="../ref/templates/builtins.html#std:templatetag-url"><tt class="xref std std-ttag docutils literal"><span class="pre">url</span></tt></a> tag.
Prior to Django 1.3, syntax like <tt class="docutils literal"><span class="pre">{%</span> <span class="pre">url</span> <span class="pre">myview</span> <span class="pre">%}</span></tt> was interpreted
incorrectly (Django considered <tt class="docutils literal"><span class="pre">"myview"</span></tt> to be a literal name of a view, not
a template variable named <tt class="docutils literal"><span class="pre">myview</span></tt>). Django 1.3 and above introduced the
<tt class="docutils literal"><span class="pre">{%</span> <span class="pre">load</span> <span class="pre">url</span> <span class="pre">from</span> <span class="pre">future</span> <span class="pre">%}</span></tt> syntax to bring in the corrected behavior where
<tt class="docutils literal"><span class="pre">myview</span></tt> was seen as a variable.</p>
<p>The upshot of this is that if you are not using <tt class="docutils literal"><span class="pre">{%</span> <span class="pre">load</span> <span class="pre">url</span> <span class="pre">from</span> <span class="pre">future</span> <span class="pre">%}</span></tt>
in your templates, you’ll need to change tags like <tt class="docutils literal"><span class="pre">{%</span> <span class="pre">url</span> <span class="pre">myview</span> <span class="pre">%}</span></tt> to
<tt class="docutils literal"><span class="pre">{%</span> <span class="pre">url</span> <span class="pre">"myview"</span> <span class="pre">%}</span></tt>. If you <em>were</em> using <tt class="docutils literal"><span class="pre">{%</span> <span class="pre">load</span> <span class="pre">url</span> <span class="pre">from</span> <span class="pre">future</span> <span class="pre">%}</span></tt> you
can simply remove that line under Django 1.5</p>
</div>
<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.5 requires Python 2.6.5 or above, though we <strong>highly recommend</strong>
Python 2.7.3 or above. Support for Python 2.5 and below has been dropped.</p>
<p>This change should affect only a small number of Django users, as most
operating-system vendors today are shipping Python 2.6 or newer as their default
version. If you’re still using Python 2.5, however, you’ll need to stick to
Django 1.4 until you can upgrade your Python version. Per <a class="reference internal" href="../internals/release-process.html"><em>our support
policy</em></a>, Django 1.4 will continue to receive
security support until the release of Django 1.6.</p>
<p>Django 1.5 does not run on a Jython final release, because Jython’s latest
release doesn’t currently support Python 2.6. However, Jython currently does
offer an alpha release featuring 2.7 support, and Django 1.5 supports that alpha
release.</p>
<div class="section" id="s-python-3-support">
<span id="python-3-support"></span><h3>Python 3 support<a class="headerlink" href="#python-3-support" title="Permalink to this headline">¶</a></h3>
<p>Django 1.5 introduces support for Python 3 - specifically, Python
3.2 and above. This comes in the form of a <strong>single</strong> codebase; you don’t
need to install a different version of Django on Python 3. This means that
you can write applications targeted for just Python 2, just Python 3, or single
applications that support both platforms.</p>
<p>However, we’re labeling this support “experimental” for now: although it’s
received extensive testing via our automated test suite, it’s received very
little real-world testing. We’ve done our best to eliminate bugs, but we can’t
be sure we covered all possible uses of Django.</p>
<p>Some features of Django aren’t available because they depend on third-party
software that hasn’t been ported to Python 3 yet, including:</p>
<ul class="simple">
<li>the MySQL database backend (depends on MySQLdb)</li>
<li><a class="reference internal" href="../ref/models/fields.html#django.db.models.ImageField" title="django.db.models.ImageField"><tt class="xref py py-class docutils literal"><span class="pre">ImageField</span></tt></a> (depends on PIL)</li>
<li><a class="reference internal" href="../topics/testing/tools.html#django.test.LiveServerTestCase" title="django.test.LiveServerTestCase"><tt class="xref py py-class docutils literal"><span class="pre">LiveServerTestCase</span></tt></a> (depends on Selenium WebDriver)</li>
</ul>
<p>Further, Django’s more than a web framework; it’s an ecosystem of pluggable
components. At this point, very few third-party applications have been ported
to Python 3, so it’s unlikely that a real-world application will have all its
dependencies satisfied under Python 3.</p>
<p>Thus, we’re recommending that Django 1.5 not be used in production under Python
3. Instead, use this opportunity to begin <a class="reference internal" href="../topics/python3.html"><em>porting applications to Python 3</em></a>. If you’re an author of a pluggable component, we encourage you
to start porting now.</p>
<p>We plan to offer first-class, production-ready support for Python 3 in our next
release, Django 1.6.</p>
</div>
</div>
<div class="section" id="s-what-s-new-in-django-1-5">
<span id="what-s-new-in-django-1-5"></span><h2>What’s new in Django 1.5<a class="headerlink" href="#what-s-new-in-django-1-5" title="Permalink to this headline">¶</a></h2>
<div class="section" id="s-configurable-user-model">
<span id="configurable-user-model"></span><h3>Configurable User model<a class="headerlink" href="#configurable-user-model" title="Permalink to this headline">¶</a></h3>
<p>In Django 1.5, you can now use your own model as the store for user-related
data. If your project needs a username with more than 30 characters, or if
you want to store user’s names in a format other than first name/last name,
or you want to put custom profile information onto your User object, you can
now do so.</p>
<p>If you have a third-party reusable application that references the User model,
you may need to make some changes to the way you reference User instances. You
should also document any specific features of the User model that your
application relies upon.</p>
<p>See the <a class="reference internal" href="../topics/auth/customizing.html#auth-custom-user"><em>documentation on custom User models</em></a> for
more details.</p>
</div>
<div class="section" id="s-support-for-saving-a-subset-of-model-s-fields">
<span id="support-for-saving-a-subset-of-model-s-fields"></span><h3>Support for saving a subset of model’s fields<a class="headerlink" href="#support-for-saving-a-subset-of-model-s-fields" title="Permalink to this headline">¶</a></h3>
<p>The method <a class="reference internal" href="../ref/models/instances.html#django.db.models.Model.save" title="django.db.models.Model.save"><tt class="xref py py-meth docutils literal"><span class="pre">Model.save()</span></tt></a> has a new
keyword argument <tt class="docutils literal"><span class="pre">update_fields</span></tt>. By using this argument it is possible to
save only a select list of model’s fields. This can be useful for performance
reasons or when trying to avoid overwriting concurrent changes.</p>
<p>Deferred instances (those loaded by <tt class="docutils literal"><span class="pre">.only()</span></tt> or <tt class="docutils literal"><span class="pre">.defer()</span></tt>) will
automatically save just the loaded fields. If any field is set manually after
load, that field will also get updated on save.</p>
<p>See the <a class="reference internal" href="../ref/models/instances.html#django.db.models.Model.save" title="django.db.models.Model.save"><tt class="xref py py-meth docutils literal"><span class="pre">Model.save()</span></tt></a> documentation for
more details.</p>
</div>
<div class="section" id="s-caching-of-related-model-instances">
<span id="caching-of-related-model-instances"></span><h3>Caching of related model instances<a class="headerlink" href="#caching-of-related-model-instances" title="Permalink to this headline">¶</a></h3>
<p>When traversing relations, the ORM will avoid re-fetching objects that were
previously loaded. For example, with the tutorial’s models:</p>
<div class="highlight-python"><div class="highlight"><pre><span class="gp">>>> </span><span class="n">first_poll</span> <span class="o">=</span> <span class="n">Poll</span><span class="o">.</span><span class="n">objects</span><span class="o">.</span><span class="n">all</span><span class="p">()[</span><span class="mi">0</span><span class="p">]</span>
<span class="gp">>>> </span><span class="n">first_choice</span> <span class="o">=</span> <span class="n">first_poll</span><span class="o">.</span><span class="n">choice_set</span><span class="o">.</span><span class="n">all</span><span class="p">()[</span><span class="mi">0</span><span class="p">]</span>
<span class="gp">>>> </span><span class="n">first_choice</span><span class="o">.</span><span class="n">poll</span> <span class="ow">is</span> <span class="n">first_poll</span>
<span class="go">True</span>
</pre></div>
</div>
<p>In Django 1.5, the third line no longer triggers a new SQL query to fetch
<tt class="docutils literal"><span class="pre">first_choice.poll</span></tt>; it was set by the second line.</p>
<p>For one-to-one relationships, both sides can be cached. For many-to-one
relationships, only the single side of the relationship can be cached. This
is particularly helpful in combination with <tt class="docutils literal"><span class="pre">prefetch_related</span></tt>.</p>
</div>
<div class="section" id="s-explicit-support-for-streaming-responses">
<span id="s-explicit-streaming-responses"></span><span id="explicit-support-for-streaming-responses"></span><span id="explicit-streaming-responses"></span><h3>Explicit support for streaming responses<a class="headerlink" href="#explicit-support-for-streaming-responses" title="Permalink to this headline">¶</a></h3>
<p>Before Django 1.5, it was possible to create a streaming response by passing
an iterator to <a class="reference internal" href="../ref/request-response.html#django.http.HttpResponse" title="django.http.HttpResponse"><tt class="xref py py-class docutils literal"><span class="pre">HttpResponse</span></tt></a>. But this was unreliable:
any middleware that accessed the <a class="reference internal" href="../ref/request-response.html#django.http.HttpResponse.content" title="django.http.HttpResponse.content"><tt class="xref py py-attr docutils literal"><span class="pre">content</span></tt></a>
attribute would consume the iterator prematurely.</p>
<p>You can now explicitly generate a streaming response with the new
<a class="reference internal" href="../ref/request-response.html#django.http.StreamingHttpResponse" title="django.http.StreamingHttpResponse"><tt class="xref py py-class docutils literal"><span class="pre">StreamingHttpResponse</span></tt></a> class. This class exposes a
<a class="reference internal" href="../ref/request-response.html#django.http.StreamingHttpResponse.streaming_content" title="django.http.StreamingHttpResponse.streaming_content"><tt class="xref py py-class docutils literal"><span class="pre">streaming_content</span></tt></a> attribute which
is an iterator.</p>
<p>Since <a class="reference internal" href="../ref/request-response.html#django.http.StreamingHttpResponse" title="django.http.StreamingHttpResponse"><tt class="xref py py-class docutils literal"><span class="pre">StreamingHttpResponse</span></tt></a> does not have a <tt class="docutils literal"><span class="pre">content</span></tt>
attribute, middleware that needs access to the response content must test for
streaming responses and behave accordingly. See <a class="reference internal" href="../topics/http/middleware.html#response-middleware"><em>process_response</em></a> for
more information.</p>
</div>
<div class="section" id="s-verbatim-template-tag">
<span id="verbatim-template-tag"></span><h3><tt class="docutils literal"><span class="pre">{%</span> <span class="pre">verbatim</span> <span class="pre">%}</span></tt> template tag<a class="headerlink" href="#verbatim-template-tag" title="Permalink to this headline">¶</a></h3>
<p>To make it easier to deal with javascript templates which collide with Django’s
syntax, you can now use the <a class="reference internal" href="../ref/templates/builtins.html#std:templatetag-verbatim"><tt class="xref std std-ttag docutils literal"><span class="pre">verbatim</span></tt></a> block tag to avoid parsing the
tag’s content.</p>
</div>
<div class="section" id="s-retrieval-of-contenttype-instances-associated-with-proxy-models">
<span id="retrieval-of-contenttype-instances-associated-with-proxy-models"></span><h3>Retrieval of <tt class="docutils literal"><span class="pre">ContentType</span></tt> instances associated with proxy models<a class="headerlink" href="#retrieval-of-contenttype-instances-associated-with-proxy-models" title="Permalink to this headline">¶</a></h3>
<p>The methods <a class="reference internal" href="../ref/contrib/contenttypes.html#django.contrib.contenttypes.models.ContentTypeManager.get_for_model" title="django.contrib.contenttypes.models.ContentTypeManager.get_for_model"><tt class="xref py py-meth docutils literal"><span class="pre">ContentTypeManager.get_for_model()</span></tt></a>
and <a class="reference internal" href="../ref/contrib/contenttypes.html#django.contrib.contenttypes.models.ContentTypeManager.get_for_models" title="django.contrib.contenttypes.models.ContentTypeManager.get_for_models"><tt class="xref py py-meth docutils literal"><span class="pre">ContentTypeManager.get_for_models()</span></tt></a>
have a new keyword argument – respectively <tt class="docutils literal"><span class="pre">for_concrete_model</span></tt> and <tt class="docutils literal"><span class="pre">for_concrete_models</span></tt>.
By passing <tt class="docutils literal"><span class="pre">False</span></tt> using this argument it is now possible to retrieve the
<a class="reference internal" href="../ref/contrib/contenttypes.html#django.contrib.contenttypes.models.ContentType" title="django.contrib.contenttypes.models.ContentType"><tt class="xref py py-class docutils literal"><span class="pre">ContentType</span></tt></a>
associated with proxy models.</p>
</div>
<div class="section" id="s-new-view-variable-in-class-based-views-context">
<span id="new-view-variable-in-class-based-views-context"></span><h3>New <tt class="docutils literal"><span class="pre">view</span></tt> variable in class-based views context<a class="headerlink" href="#new-view-variable-in-class-based-views-context" title="Permalink to this headline">¶</a></h3>
<p>In all <a class="reference internal" href="../topics/class-based-views/index.html"><em>generic class-based views</em></a>
(or any class-based view inheriting from <tt class="docutils literal"><span class="pre">ContextMixin</span></tt>), the context dictionary
contains a <tt class="docutils literal"><span class="pre">view</span></tt> variable that points to the <tt class="docutils literal"><span class="pre">View</span></tt> instance.</p>
</div>
<div class="section" id="s-geodjango">
<span id="geodjango"></span><h3>GeoDjango<a class="headerlink" href="#geodjango" title="Permalink to this headline">¶</a></h3>
<ul class="simple">
<li><a class="reference internal" href="../ref/contrib/gis/geos.html#django.contrib.gis.geos.LineString" title="django.contrib.gis.geos.LineString"><tt class="xref py py-class docutils literal"><span class="pre">LineString</span></tt></a> and
<a class="reference internal" href="../ref/contrib/gis/geos.html#django.contrib.gis.geos.MultiLineString" title="django.contrib.gis.geos.MultiLineString"><tt class="xref py py-class docutils literal"><span class="pre">MultiLineString</span></tt></a> GEOS objects now support the
<a class="reference internal" href="../ref/contrib/gis/geos.html#django.contrib.gis.geos.GEOSGeometry.interpolate" title="django.contrib.gis.geos.GEOSGeometry.interpolate"><tt class="xref py py-meth docutils literal"><span class="pre">interpolate()</span></tt></a> and
<a class="reference internal" href="../ref/contrib/gis/geos.html#django.contrib.gis.geos.GEOSGeometry.project" title="django.contrib.gis.geos.GEOSGeometry.project"><tt class="xref py py-meth docutils literal"><span class="pre">project()</span></tt></a> methods
(so-called linear referencing).</li>
<li>The <tt class="docutils literal"><span class="pre">wkb</span></tt> and <tt class="docutils literal"><span class="pre">hex</span></tt> properties of
<a class="reference internal" href="../ref/contrib/gis/geos.html#django.contrib.gis.geos.GEOSGeometry" title="django.contrib.gis.geos.GEOSGeometry"><tt class="xref py py-class docutils literal"><span class="pre">GEOSGeometry</span></tt></a> objects preserve the Z
dimension.</li>
<li>Support for PostGIS 2.0 has been added and support for GDAL < 1.5 has been
dropped.</li>
</ul>
</div>
<div class="section" id="s-new-tutorials">
<span id="new-tutorials"></span><h3>New tutorials<a class="headerlink" href="#new-tutorials" title="Permalink to this headline">¶</a></h3>
<p>Additions to the docs include a revamped <a class="reference internal" href="../intro/tutorial03.html"><em>Tutorial 3</em></a>
and a new <a class="reference internal" href="../intro/tutorial05.html"><em>tutorial on testing</em></a>. A new section,
“Advanced Tutorials”, offers <a class="reference internal" href="../intro/reusable-apps.html"><em>How to write reusable apps</em></a> as well as a step-by-step guide for new contributors in
<a class="reference internal" href="../intro/contributing.html"><em>Writing your first patch for Django</em></a>.</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>
<p>Django 1.5 also includes several smaller improvements worth noting:</p>
<ul>
<li><p class="first">The template engine now interprets <tt class="docutils literal"><span class="pre">True</span></tt>, <tt class="docutils literal"><span class="pre">False</span></tt> and <tt class="docutils literal"><span class="pre">None</span></tt> as the
corresponding Python objects.</p>
</li>
<li><p class="first"><a class="reference internal" href="../ref/utils.html#module-django.utils.timezone" title="django.utils.timezone: Timezone support."><tt class="xref py py-mod docutils literal"><span class="pre">django.utils.timezone</span></tt></a> provides a helper for converting aware
datetimes between time zones. See <a class="reference internal" href="../ref/utils.html#django.utils.timezone.localtime" title="django.utils.timezone.localtime"><tt class="xref py py-func docutils literal"><span class="pre">localtime()</span></tt></a>.</p>
</li>
<li><p class="first">The generic views support OPTIONS requests.</p>
</li>
<li><p class="first">Management commands do not raise <tt class="docutils literal"><span class="pre">SystemExit</span></tt> any more when called by code
from <a class="reference internal" href="../ref/django-admin.html#call-command"><em>call_command</em></a>. Any exception raised by the command
(mostly <a class="reference internal" href="../howto/custom-management-commands.html#ref-command-exceptions"><em>CommandError</em></a>) is propagated.</p>
<p>Moreover, when you output errors or messages in your custom commands, you
should now use <tt class="docutils literal"><span class="pre">self.stdout.write('message')</span></tt> and
<tt class="docutils literal"><span class="pre">self.stderr.write('error')</span></tt> (see the note on
<a class="reference internal" href="../howto/custom-management-commands.html#management-commands-output"><em>management commands output</em></a>).</p>
</li>
<li><p class="first">The dumpdata management command outputs one row at a time, preventing
out-of-memory errors when dumping large datasets.</p>
</li>
<li><p class="first">In the localflavor for Canada, “pq” was added to the acceptable codes for
Quebec. It’s an old abbreviation.</p>
</li>
<li><p class="first">The <a class="reference internal" href="../topics/signals.html#connecting-receiver-functions"><em>receiver</em></a> decorator is now able to
connect to more than one signal by supplying a list of signals.</p>
</li>
<li><p class="first">In the admin, you can now filter users by groups which they are members of.</p>
</li>
<li><p class="first"><a class="reference internal" href="../ref/models/querysets.html#django.db.models.query.QuerySet.bulk_create" title="django.db.models.query.QuerySet.bulk_create"><tt class="xref py py-meth docutils literal"><span class="pre">QuerySet.bulk_create()</span></tt></a> now has a batch_size
argument. By default the batch_size is unlimited except for SQLite where
single batch is limited so that 999 parameters per query isn’t exceeded.</p>
</li>
<li><p class="first">The <a class="reference internal" href="../ref/settings.html#std:setting-LOGIN_URL"><tt class="xref std std-setting docutils literal"><span class="pre">LOGIN_URL</span></tt></a> and <a class="reference internal" href="../ref/settings.html#std:setting-LOGIN_REDIRECT_URL"><tt class="xref std std-setting docutils literal"><span class="pre">LOGIN_REDIRECT_URL</span></tt></a> settings now also
accept view function names and
<a class="reference internal" href="../topics/http/urls.html#naming-url-patterns"><em>named URL patterns</em></a>. This allows you to reduce
configuration duplication. More information can be found in the
<a class="reference internal" href="../topics/auth/default.html#django.contrib.auth.decorators.login_required" title="django.contrib.auth.decorators.login_required"><tt class="xref py py-func docutils literal"><span class="pre">login_required()</span></tt></a> documentation.</p>
</li>
<li><p class="first">Django now provides a mod_wsgi <a class="reference internal" href="../howto/deployment/wsgi/apache-auth.html"><em>auth handler</em></a>.</p>
</li>
<li><p class="first">The <a class="reference internal" href="../ref/models/querysets.html#django.db.models.query.QuerySet.delete" title="django.db.models.query.QuerySet.delete"><tt class="xref py py-meth docutils literal"><span class="pre">QuerySet.delete()</span></tt></a>
and <a class="reference internal" href="../ref/models/instances.html#django.db.models.Model.delete" title="django.db.models.Model.delete"><tt class="xref py py-meth docutils literal"><span class="pre">Model.delete()</span></tt></a> can now take
fast-path in some cases. The fast-path allows for less queries and less
objects fetched into memory. See <a class="reference internal" href="../ref/models/querysets.html#django.db.models.query.QuerySet.delete" title="django.db.models.query.QuerySet.delete"><tt class="xref py py-meth docutils literal"><span class="pre">QuerySet.delete()</span></tt></a> for details.</p>
</li>
<li><p class="first">An instance of <a class="reference internal" href="../ref/urlresolvers.html#django.core.urlresolvers.ResolverMatch" title="django.core.urlresolvers.ResolverMatch"><tt class="xref py py-class docutils literal"><span class="pre">ResolverMatch</span></tt></a> is stored on
the request as <tt class="docutils literal"><span class="pre">resolver_match</span></tt>.</p>
</li>
<li><p class="first">By default, all logging messages reaching the <tt class="docutils literal"><span class="pre">django</span></tt> logger when
<a class="reference internal" href="../ref/settings.html#std:setting-DEBUG"><tt class="xref std std-setting docutils literal"><span class="pre">DEBUG</span></tt></a> is <tt class="docutils literal"><span class="pre">True</span></tt> are sent to the console (unless you redefine the
logger in your <a class="reference internal" href="../ref/settings.html#std:setting-LOGGING"><tt class="xref std std-setting docutils literal"><span class="pre">LOGGING</span></tt></a> setting).</p>
</li>
<li><p class="first">When using <a class="reference internal" href="../ref/templates/api.html#django.template.RequestContext" title="django.template.RequestContext"><tt class="xref py py-class docutils literal"><span class="pre">RequestContext</span></tt></a>, it is now possible to
look up permissions by using <tt class="docutils literal"><span class="pre">{%</span> <span class="pre">if</span> <span class="pre">'someapp.someperm'</span> <span class="pre">in</span> <span class="pre">perms</span> <span class="pre">%}</span></tt>
in templates.</p>
</li>
<li><p class="first">It’s not required any more to have <tt class="docutils literal"><span class="pre">404.html</span></tt> and <tt class="docutils literal"><span class="pre">500.html</span></tt> templates in
the root templates directory. Django will output some basic error messages for
both situations when those templates are not found. Of course, it’s still
recommended as good practice to provide those templates in order to present
pretty error pages to the user.</p>
</li>
<li><p class="first"><a class="reference internal" href="../topics/auth/index.html#module-django.contrib.auth" title="django.contrib.auth: Django's authentication framework."><tt class="xref py py-mod docutils literal"><span class="pre">django.contrib.auth</span></tt></a> provides a new signal that is emitted
whenever a user fails to login successfully. See
<a class="reference internal" href="../ref/contrib/auth.html#django.contrib.auth.signals.user_login_failed" title="django.contrib.auth.signals.user_login_failed"><tt class="xref py py-data docutils literal"><span class="pre">user_login_failed</span></tt></a></p>
</li>
<li><p class="first">The loaddata management command now supports an
<a class="reference internal" href="../ref/django-admin.html#django-admin-option---ignorenonexistent"><tt class="xref std std-djadminopt docutils literal"><span class="pre">--ignorenonexistent</span></tt></a> option to ignore data for fields that no
longer exist.</p>
</li>
<li><p class="first"><a class="reference internal" href="../topics/testing/tools.html#django.test.SimpleTestCase.assertXMLEqual" title="django.test.SimpleTestCase.assertXMLEqual"><tt class="xref py py-meth docutils literal"><span class="pre">assertXMLEqual()</span></tt></a> and
<a class="reference internal" href="../topics/testing/tools.html#django.test.SimpleTestCase.assertXMLNotEqual" title="django.test.SimpleTestCase.assertXMLNotEqual"><tt class="xref py py-meth docutils literal"><span class="pre">assertXMLNotEqual()</span></tt></a> new assertions allow
you to test equality for XML content at a semantic level, without caring for
syntax differences (spaces, attribute order, etc.).</p>
</li>
<li><p class="first">RemoteUserMiddleware now forces logout when the REMOTE_USER header
disappears during the same browser session.</p>
</li>
<li><p class="first">The <a class="reference internal" href="../topics/http/sessions.html#cached-sessions-backend"><em>cache-based session backend</em></a> can store
session data in a non-default cache.</p>
</li>
<li><p class="first">Multi-column indexes can now be created on models. Read the
<a class="reference internal" href="../ref/models/options.html#django.db.models.Options.index_together" title="django.db.models.Options.index_together"><tt class="xref py py-attr docutils literal"><span class="pre">index_together</span></tt></a> documentation for more
information.</p>
</li>
<li><p class="first">During Django’s logging configuration verbose Deprecation warnings are
enabled and warnings are captured into the logging system. Logged warnings
are routed through the <tt class="docutils literal"><span class="pre">console</span></tt> logging handler, which by default requires
<a class="reference internal" href="../ref/settings.html#std:setting-DEBUG"><tt class="xref std std-setting docutils literal"><span class="pre">DEBUG</span></tt></a> to be True for output to be generated. The result is that
DeprecationWarnings should be printed to the console in development
environments the way they have been in Python versions < 2.7.</p>
</li>
<li><p class="first">The API for <a class="reference internal" href="../ref/contrib/admin/index.html#django.contrib.admin.ModelAdmin.message_user" title="django.contrib.admin.ModelAdmin.message_user"><tt class="xref py py-meth docutils literal"><span class="pre">django.contrib.admin.ModelAdmin.message_user()</span></tt></a> method has
been modified to accept additional arguments adding capabilities similar to
<a class="reference internal" href="../ref/contrib/messages.html#django.contrib.messages.add_message" title="django.contrib.messages.add_message"><tt class="xref py py-func docutils literal"><span class="pre">django.contrib.messages.add_message()</span></tt></a>. This is useful for generating
error messages from admin actions.</p>
</li>
<li><p class="first">The admin’s list filters can now be customized per-request thanks to the new
<a class="reference internal" href="../ref/contrib/admin/index.html#django.contrib.admin.ModelAdmin.get_list_filter" title="django.contrib.admin.ModelAdmin.get_list_filter"><tt class="xref py py-meth docutils literal"><span class="pre">django.contrib.admin.ModelAdmin.get_list_filter()</span></tt></a> method.</p>
</li>
</ul>
</div>
</div>
<div class="section" id="s-backwards-incompatible-changes-in-1-5">
<span id="backwards-incompatible-changes-in-1-5"></span><h2>Backwards incompatible changes in 1.5<a class="headerlink" href="#backwards-incompatible-changes-in-1-5" 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
<em class="xref std std-ref">deprecation plan</em> 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-allowed-hosts-required-in-production">
<span id="allowed-hosts-required-in-production"></span><h3><tt class="docutils literal"><span class="pre">ALLOWED_HOSTS</span></tt> required in production<a class="headerlink" href="#allowed-hosts-required-in-production" title="Permalink to this headline">¶</a></h3>
<p>The new <a class="reference internal" href="../ref/settings.html#std:setting-ALLOWED_HOSTS"><tt class="xref std std-setting docutils literal"><span class="pre">ALLOWED_HOSTS</span></tt></a> setting validates the request’s <tt class="docutils literal"><span class="pre">Host</span></tt>
header and protects against host-poisoning attacks. This setting is now
required whenever <a class="reference internal" href="../ref/settings.html#std:setting-DEBUG"><tt class="xref std std-setting docutils literal"><span class="pre">DEBUG</span></tt></a> is <tt class="docutils literal"><span class="pre">False</span></tt>, or else
<a class="reference internal" href="../ref/request-response.html#django.http.HttpRequest.get_host" title="django.http.HttpRequest.get_host"><tt class="xref py py-meth docutils literal"><span class="pre">django.http.HttpRequest.get_host()</span></tt></a> will raise
<a class="reference internal" href="../ref/exceptions.html#django.core.exceptions.SuspiciousOperation" title="django.core.exceptions.SuspiciousOperation"><tt class="xref py py-exc docutils literal"><span class="pre">SuspiciousOperation</span></tt></a>. For more details see the
<a class="reference internal" href="../ref/settings.html#std:setting-ALLOWED_HOSTS"><tt class="xref std std-setting docutils literal"><span class="pre">full</span> <span class="pre">documentation</span></tt></a> for the new setting.</p>
</div>
<div class="section" id="s-managers-on-abstract-models">
<span id="managers-on-abstract-models"></span><h3>Managers on abstract models<a class="headerlink" href="#managers-on-abstract-models" title="Permalink to this headline">¶</a></h3>
<p>Abstract models are able to define a custom manager, and that manager
<a class="reference internal" href="../topics/db/managers.html#custom-managers-and-inheritance"><em>will be inherited by any concrete models extending the abstract model</em></a>. However, if you try to use the abstract
model to call a method on the manager, an exception will now be raised.
Previously, the call would have been permitted, but would have failed as soon
as any database operation was attempted (usually with a “table does not exist”
error from the database).</p>
<p>If you have functionality on a manager that you have been invoking using
the abstract class, you should migrate that logic to a Python
<tt class="docutils literal"><span class="pre">staticmethod</span></tt> or <tt class="docutils literal"><span class="pre">classmethod</span></tt> on the abstract class.</p>
</div>
<div class="section" id="s-context-in-year-archive-class-based-views">
<span id="context-in-year-archive-class-based-views"></span><h3>Context in year archive class-based views<a class="headerlink" href="#context-in-year-archive-class-based-views" title="Permalink to this headline">¶</a></h3>
<p>For consistency with the other date-based generic views,
<a class="reference internal" href="../ref/class-based-views/generic-date-based.html#django.views.generic.dates.YearArchiveView" title="django.views.generic.dates.YearArchiveView"><tt class="xref py py-class docutils literal"><span class="pre">YearArchiveView</span></tt></a> now passes <tt class="docutils literal"><span class="pre">year</span></tt> in
the context as a <tt class="xref py py-class docutils literal"><span class="pre">datetime.date</span></tt> rather than a string. If you are
using <tt class="docutils literal"><span class="pre">{{</span> <span class="pre">year</span> <span class="pre">}}</span></tt> in your templates, you must replace it with <tt class="docutils literal"><span class="pre">{{</span>
<span class="pre">year|date:"Y"</span> <span class="pre">}}</span></tt>.</p>
<p><tt class="docutils literal"><span class="pre">next_year</span></tt> and <tt class="docutils literal"><span class="pre">previous_year</span></tt> were also added in the context. They are
calculated according to <tt class="docutils literal"><span class="pre">allow_empty</span></tt> and <tt class="docutils literal"><span class="pre">allow_future</span></tt>.</p>
</div>
<div class="section" id="s-context-in-year-and-month-archive-class-based-views">
<span id="context-in-year-and-month-archive-class-based-views"></span><h3>Context in year and month archive class-based views<a class="headerlink" href="#context-in-year-and-month-archive-class-based-views" title="Permalink to this headline">¶</a></h3>
<p><a class="reference internal" href="../ref/class-based-views/generic-date-based.html#django.views.generic.dates.YearArchiveView" title="django.views.generic.dates.YearArchiveView"><tt class="xref py py-class docutils literal"><span class="pre">YearArchiveView</span></tt></a> and
<a class="reference internal" href="../ref/class-based-views/generic-date-based.html#django.views.generic.dates.MonthArchiveView" title="django.views.generic.dates.MonthArchiveView"><tt class="xref py py-class docutils literal"><span class="pre">MonthArchiveView</span></tt></a> were documented to
provide a <tt class="docutils literal"><span class="pre">date_list</span></tt> sorted in ascending order in the context, like their
function-based predecessors, but it actually was in descending order. In 1.5,
the documented order was restored. You may want to add (or remove) the
<tt class="docutils literal"><span class="pre">reversed</span></tt> keyword when you’re iterating on <tt class="docutils literal"><span class="pre">date_list</span></tt> in a template:</p>
<div class="highlight-python"><pre>{% for date in date_list reversed %}</pre>
</div>
<p><a class="reference internal" href="../ref/class-based-views/generic-date-based.html#django.views.generic.dates.ArchiveIndexView" title="django.views.generic.dates.ArchiveIndexView"><tt class="xref py py-class docutils literal"><span class="pre">ArchiveIndexView</span></tt></a> still provides a
<tt class="docutils literal"><span class="pre">date_list</span></tt> in descending order.</p>
</div>
<div class="section" id="s-context-in-templateview">
<span id="context-in-templateview"></span><h3>Context in TemplateView<a class="headerlink" href="#context-in-templateview" title="Permalink to this headline">¶</a></h3>
<p>For consistency with the design of the other generic views,
<a class="reference internal" href="../ref/class-based-views/base.html#django.views.generic.base.TemplateView" title="django.views.generic.base.TemplateView"><tt class="xref py py-class docutils literal"><span class="pre">TemplateView</span></tt></a> no longer passes a <tt class="docutils literal"><span class="pre">params</span></tt>
dictionary into the context, instead passing the variables from the URLconf
directly into the context.</p>
</div>
<div class="section" id="s-non-form-data-in-http-requests">
<span id="non-form-data-in-http-requests"></span><h3>Non-form data in HTTP requests<a class="headerlink" href="#non-form-data-in-http-requests" title="Permalink to this headline">¶</a></h3>
<p><a class="reference internal" href="../ref/request-response.html#django.http.HttpRequest.POST" title="django.http.HttpRequest.POST"><tt class="xref py py-attr docutils literal"><span class="pre">request.POST</span></tt></a> will no longer include data
posted via HTTP requests with non form-specific content-types in the header.
In prior versions, data posted with content-types other than
<tt class="docutils literal"><span class="pre">multipart/form-data</span></tt> or <tt class="docutils literal"><span class="pre">application/x-www-form-urlencoded</span></tt> would still
end up represented in the <a class="reference internal" href="../ref/request-response.html#django.http.HttpRequest.POST" title="django.http.HttpRequest.POST"><tt class="xref py py-attr docutils literal"><span class="pre">request.POST</span></tt></a>
attribute. Developers wishing to access the raw POST data for these cases,
should use the <a class="reference internal" href="../ref/request-response.html#django.http.HttpRequest.body" title="django.http.HttpRequest.body"><tt class="xref py py-attr docutils literal"><span class="pre">request.body</span></tt></a> attribute
instead.</p>
</div>
<div class="section" id="s-request-finished-signal">
<span id="request-finished-signal"></span><h3><a class="reference internal" href="../ref/signals.html#django.core.signals.request_finished" title="django.core.signals.request_finished"><tt class="xref py py-data docutils literal"><span class="pre">request_finished</span></tt></a> signal<a class="headerlink" href="#request-finished-signal" title="Permalink to this headline">¶</a></h3>
<p>Django used to send the <a class="reference internal" href="../ref/signals.html#django.core.signals.request_finished" title="django.core.signals.request_finished"><tt class="xref py py-data docutils literal"><span class="pre">request_finished</span></tt></a> signal
as soon as the view function returned a response. This interacted badly with
<a class="reference internal" href="../ref/request-response.html#httpresponse-streaming"><em>streaming responses</em></a> that delay content
generation.</p>
<p>This signal is now sent after the content is fully consumed by the WSGI
gateway. This might be backwards incompatible if you rely on the signal being
fired before sending the response content to the client. If you do, you should
consider using <a class="reference internal" href="../topics/http/middleware.html"><em>middleware</em></a> instead.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">Some WSGI servers and middleware do not always call <tt class="docutils literal"><span class="pre">close</span></tt> on the
response object after handling a request, most notably uWSGI prior to 1.2.6
and Sentry’s error reporting middleware up to 2.0.7. In those cases the
<tt class="docutils literal"><span class="pre">request_finished</span></tt> signal isn’t sent at all. This can result in idle
connections to database and memcache servers.</p>
</div>
</div>
<div class="section" id="s-options-put-and-delete-requests-in-the-test-client">
<span id="options-put-and-delete-requests-in-the-test-client"></span><h3>OPTIONS, PUT and DELETE requests in the test client<a class="headerlink" href="#options-put-and-delete-requests-in-the-test-client" title="Permalink to this headline">¶</a></h3>
<p>Unlike GET and POST, these HTTP methods aren’t implemented by web browsers.
Rather, they’re used in APIs, which transfer data in various formats such as
JSON or XML. Since such requests may contain arbitrary data, Django doesn’t
attempt to decode their body.</p>
<p>However, the test client used to build a query string for OPTIONS and DELETE
requests like for GET, and a request body for PUT requests like for POST. This
encoding was arbitrary and inconsistent with Django’s behavior when it
receives the requests, so it was removed in Django 1.5.</p>
<p>If you were using the <tt class="docutils literal"><span class="pre">data</span></tt> parameter in an OPTIONS or a DELETE request,
you must convert it to a query string and append it to the <tt class="docutils literal"><span class="pre">path</span></tt> parameter.</p>
<p>If you were using the <tt class="docutils literal"><span class="pre">data</span></tt> parameter in a PUT request without a
<tt class="docutils literal"><span class="pre">content_type</span></tt>, you must encode your data before passing it to the test
client and set the <tt class="docutils literal"><span class="pre">content_type</span></tt> argument.</p>
</div>
<div class="section" id="s-system-version-of-simplejson-no-longer-used">
<span id="s-simplejson-incompatibilities"></span><span id="system-version-of-simplejson-no-longer-used"></span><span id="simplejson-incompatibilities"></span><h3>System version of <tt class="xref py py-mod docutils literal"><span class="pre">simplejson</span></tt> no longer used<a class="headerlink" href="#system-version-of-simplejson-no-longer-used" title="Permalink to this headline">¶</a></h3>
<p><a class="reference internal" href="#simplejson-deprecation"><em>As explained below</em></a>, Django 1.5 deprecates
<tt class="docutils literal"><span class="pre">django.utils.simplejson</span></tt> in favor of Python 2.6’s built-in <tt class="xref py py-mod docutils literal"><span class="pre">json</span></tt>
module. In theory, this change is harmless. Unfortunately, because of
incompatibilities between versions of <tt class="xref py py-mod docutils literal"><span class="pre">simplejson</span></tt>, it may trigger errors
in some circumstances.</p>
<p>JSON-related features in Django 1.4 always used <tt class="docutils literal"><span class="pre">django.utils.simplejson</span></tt>.
This module was actually:</p>
<ul class="simple">
<li>A system version of <tt class="xref py py-mod docutils literal"><span class="pre">simplejson</span></tt>, if one was available (ie. <tt class="docutils literal"><span class="pre">import</span>
<span class="pre">simplejson</span></tt> works), if it was more recent than Django’s built-in copy or it
had the C speedups, or</li>
<li>The <tt class="xref py py-mod docutils literal"><span class="pre">json</span></tt> module from the standard library, if it was available (ie.
Python 2.6 or greater), or</li>
<li>A built-in copy of version 2.0.7 of <tt class="xref py py-mod docutils literal"><span class="pre">simplejson</span></tt>.</li>
</ul>
<p>In Django 1.5, those features use Python’s <tt class="xref py py-mod docutils literal"><span class="pre">json</span></tt> module, which is based
on version 2.0.9 of <tt class="xref py py-mod docutils literal"><span class="pre">simplejson</span></tt>.</p>
<p>There are no known incompatibilities between Django’s copy of version 2.0.7 and
Python’s copy of version 2.0.9. However, there are some incompatibilities
between other versions of <tt class="xref py py-mod docutils literal"><span class="pre">simplejson</span></tt>:</p>
<ul class="simple">
<li>While the <tt class="xref py py-mod docutils literal"><span class="pre">simplejson</span></tt> API is documented as always returning unicode
strings, the optional C implementation can return a byte string. This was
fixed in Python 2.7.</li>
<li><tt class="xref py py-class docutils literal"><span class="pre">simplejson.JSONEncoder</span></tt> gained a <tt class="docutils literal"><span class="pre">namedtuple_as_object</span></tt> keyword
argument in version 2.2.</li>
</ul>
<p>More information on these incompatibilities is available in <a class="reference external" href="https://code.djangoproject.com/ticket/18023#comment:10">ticket #18023</a>.</p>
<p>The net result is that, if you have installed <tt class="xref py py-mod docutils literal"><span class="pre">simplejson</span></tt> and your code
uses Django’s serialization internals directly – for instance
<tt class="docutils literal"><span class="pre">django.core.serializers.json.DjangoJSONEncoder</span></tt>, the switch from
<tt class="xref py py-mod docutils literal"><span class="pre">simplejson</span></tt> to <tt class="xref py py-mod docutils literal"><span class="pre">json</span></tt> could break your code. (In general, changes to
internals aren’t documented; we’re making an exception here.)</p>
<p>At this point, the maintainers of Django believe that using <tt class="xref py py-mod docutils literal"><span class="pre">json</span></tt> from
the standard library offers the strongest guarantee of backwards-compatibility.
They recommend to use it from now on.</p>
</div>
<div class="section" id="s-string-types-of-hasher-method-parameters">
<span id="string-types-of-hasher-method-parameters"></span><h3>String types of hasher method parameters<a class="headerlink" href="#string-types-of-hasher-method-parameters" title="Permalink to this headline">¶</a></h3>
<p>If you have written a <a class="reference internal" href="../topics/auth/passwords.html#auth-password-storage"><em>custom password hasher</em></a>,
your <tt class="docutils literal"><span class="pre">encode()</span></tt>, <tt class="docutils literal"><span class="pre">verify()</span></tt> or <tt class="docutils literal"><span class="pre">safe_summary()</span></tt> methods should accept
Unicode parameters (<tt class="docutils literal"><span class="pre">password</span></tt>, <tt class="docutils literal"><span class="pre">salt</span></tt> or <tt class="docutils literal"><span class="pre">encoded</span></tt>). If any of the
hashing methods need byte strings, you can use the
<a class="reference internal" href="../ref/utils.html#django.utils.encoding.force_bytes" title="django.utils.encoding.force_bytes"><tt class="xref py py-func docutils literal"><span class="pre">force_bytes()</span></tt></a> utility to encode the strings.</p>
</div>
<div class="section" id="s-validation-of-previous-page-number-and-next-page-number">
<span id="validation-of-previous-page-number-and-next-page-number"></span><h3>Validation of previous_page_number and next_page_number<a class="headerlink" href="#validation-of-previous-page-number-and-next-page-number" title="Permalink to this headline">¶</a></h3>
<p>When using <a class="reference internal" href="../topics/pagination.html"><em>object pagination</em></a>,
the <tt class="docutils literal"><span class="pre">previous_page_number()</span></tt> and <tt class="docutils literal"><span class="pre">next_page_number()</span></tt> methods of the
<a class="reference internal" href="../topics/pagination.html#django.core.paginator.Page" title="django.core.paginator.Page"><tt class="xref py py-class docutils literal"><span class="pre">Page</span></tt></a> object did not check if the returned
number was inside the existing page range.
It does check it now and raises an <a class="reference internal" href="../topics/pagination.html#django.core.paginator.InvalidPage" title="django.core.paginator.InvalidPage"><tt class="xref py py-exc docutils literal"><span class="pre">InvalidPage</span></tt></a>
exception when the number is either too low or too high.</p>
</div>
<div class="section" id="s-behavior-of-autocommit-database-option-on-postgresql-changed">
<span id="behavior-of-autocommit-database-option-on-postgresql-changed"></span><h3>Behavior of autocommit database option on PostgreSQL changed<a class="headerlink" href="#behavior-of-autocommit-database-option-on-postgresql-changed" title="Permalink to this headline">¶</a></h3>
<p>PostgreSQL’s autocommit option didn’t work as advertised previously. It did
work for single transaction block, but after the first block was left the
autocommit behavior was never restored. This bug is now fixed in 1.5. While
this is only a bug fix, it is worth checking your applications behavior if
you are using PostgreSQL together with the autocommit option.</p>
</div>
<div class="section" id="s-session-not-saved-on-500-responses">
<span id="session-not-saved-on-500-responses"></span><h3>Session not saved on 500 responses<a class="headerlink" href="#session-not-saved-on-500-responses" title="Permalink to this headline">¶</a></h3>
<p>Django’s session middleware will skip saving the session data if the
response’s status code is 500.</p>
</div>
<div class="section" id="s-email-checks-on-failed-admin-login">
<span id="email-checks-on-failed-admin-login"></span><h3>Email checks on failed admin login<a class="headerlink" href="#email-checks-on-failed-admin-login" title="Permalink to this headline">¶</a></h3>
<p>Prior to Django 1.5, if you attempted to log into the admin interface and
mistakenly used your email address instead of your username, the admin
interface would provide a warning advising that your email address was
not your username. In Django 1.5, the introduction of
<a class="reference internal" href="../topics/auth/customizing.html#auth-custom-user"><em>custom User models</em></a> has required the removal of this
warning. This doesn’t change the login behavior of the admin site; it only
affects the warning message that is displayed under one particular mode of
login failure.</p>
</div>
<div class="section" id="s-changes-in-tests-execution">
<span id="changes-in-tests-execution"></span><h3>Changes in tests execution<a class="headerlink" href="#changes-in-tests-execution" title="Permalink to this headline">¶</a></h3>
<p>Some changes have been introduced in the execution of tests that might be
backward-incompatible for some testing setups:</p>
<div class="section" id="s-database-flushing-in-django-test-transactiontestcase">
<span id="database-flushing-in-django-test-transactiontestcase"></span><h4>Database flushing in <tt class="docutils literal"><span class="pre">django.test.TransactionTestCase</span></tt><a class="headerlink" href="#database-flushing-in-django-test-transactiontestcase" title="Permalink to this headline">¶</a></h4>
<p>Previously, the test database was truncated <em>before</em> each test run in a
<a class="reference internal" href="../topics/testing/tools.html#django.test.TransactionTestCase" title="django.test.TransactionTestCase"><tt class="xref py py-class docutils literal"><span class="pre">TransactionTestCase</span></tt></a>.</p>
<p>In order to be able to run unit tests in any order and to make sure they are
always isolated from each other, <a class="reference internal" href="../topics/testing/tools.html#django.test.TransactionTestCase" title="django.test.TransactionTestCase"><tt class="xref py py-class docutils literal"><span class="pre">TransactionTestCase</span></tt></a> will
now reset the database <em>after</em> each test run instead.</p>
</div>
<div class="section" id="s-no-more-implicit-db-sequences-reset">
<span id="no-more-implicit-db-sequences-reset"></span><h4>No more implicit DB sequences reset<a class="headerlink" href="#no-more-implicit-db-sequences-reset" title="Permalink to this headline">¶</a></h4>
<p><a class="reference internal" href="../topics/testing/tools.html#django.test.TransactionTestCase" title="django.test.TransactionTestCase"><tt class="xref py py-class docutils literal"><span class="pre">TransactionTestCase</span></tt></a> tests used to reset primary key
sequences automatically together with the database flushing actions described
above.</p>
<p>This has been changed so no sequences are implicitly reset. This can cause
<a class="reference internal" href="../topics/testing/tools.html#django.test.TransactionTestCase" title="django.test.TransactionTestCase"><tt class="xref py py-class docutils literal"><span class="pre">TransactionTestCase</span></tt></a> tests that depend on hard-coded
primary key values to break.</p>
<p>The new <a class="reference internal" href="../topics/testing/advanced.html#django.test.TransactionTestCase.reset_sequences" title="django.test.TransactionTestCase.reset_sequences"><tt class="xref py py-attr docutils literal"><span class="pre">reset_sequences</span></tt></a> attribute can
be used to force the old behavior for <a class="reference internal" href="../topics/testing/tools.html#django.test.TransactionTestCase" title="django.test.TransactionTestCase"><tt class="xref py py-class docutils literal"><span class="pre">TransactionTestCase</span></tt></a>
that might need it.</p>
</div>
<div class="section" id="s-ordering-of-tests">
<span id="ordering-of-tests"></span><h4>Ordering of tests<a class="headerlink" href="#ordering-of-tests" title="Permalink to this headline">¶</a></h4>
<p>In order to make sure all <tt class="docutils literal"><span class="pre">TestCase</span></tt> code starts with a clean database,
tests are now executed in the following order:</p>
<ul class="simple">
<li>First, all unittests (including <tt class="xref py py-class docutils literal"><span class="pre">unittest.TestCase</span></tt>,
<a class="reference internal" href="../topics/testing/tools.html#django.test.SimpleTestCase" title="django.test.SimpleTestCase"><tt class="xref py py-class docutils literal"><span class="pre">SimpleTestCase</span></tt></a>, <a class="reference internal" href="../topics/testing/tools.html#django.test.TestCase" title="django.test.TestCase"><tt class="xref py py-class docutils literal"><span class="pre">TestCase</span></tt></a> and
<a class="reference internal" href="../topics/testing/tools.html#django.test.TransactionTestCase" title="django.test.TransactionTestCase"><tt class="xref py py-class docutils literal"><span class="pre">TransactionTestCase</span></tt></a>) are run with no particular ordering
guaranteed nor enforced among them.</li>
<li>Then any other tests (e.g. doctests) that may alter the database without
restoring it to its original state are run.</li>
</ul>
<p>This should not cause any problems unless you have existing doctests which
assume a <a class="reference internal" href="../topics/testing/tools.html#django.test.TransactionTestCase" title="django.test.TransactionTestCase"><tt class="xref py py-class docutils literal"><span class="pre">TransactionTestCase</span></tt></a> executed earlier left some
database state behind or unit tests that rely on some form of state being
preserved after the execution of other tests. Such tests are already very
fragile, and must now be changed to be able to run independently.</p>
</div>
</div>
<div class="section" id="s-cleaned-data-dictionary-kept-for-invalid-forms">
<span id="cleaned-data-dictionary-kept-for-invalid-forms"></span><h3><cite>cleaned_data</cite> dictionary kept for invalid forms<a class="headerlink" href="#cleaned-data-dictionary-kept-for-invalid-forms" title="Permalink to this headline">¶</a></h3>
<p>The <a class="reference internal" href="../ref/forms/api.html#django.forms.Form.cleaned_data" title="django.forms.Form.cleaned_data"><tt class="xref py py-attr docutils literal"><span class="pre">cleaned_data</span></tt></a> dictionary is now always present
after form validation. When the form doesn’t validate, it contains only the
fields that passed validation. You should test the success of the validation
with the <a class="reference internal" href="../ref/forms/api.html#django.forms.Form.is_valid" title="django.forms.Form.is_valid"><tt class="xref py py-meth docutils literal"><span class="pre">is_valid()</span></tt></a> method and not with the
presence or absence of the <a class="reference internal" href="../ref/forms/api.html#django.forms.Form.cleaned_data" title="django.forms.Form.cleaned_data"><tt class="xref py py-attr docutils literal"><span class="pre">cleaned_data</span></tt></a> attribute
on the form.</p>
</div>
<div class="section" id="s-behavior-of-syncdb-with-multiple-databases">
<span id="behavior-of-syncdb-with-multiple-databases"></span><h3>Behavior of <a class="reference internal" href="../ref/django-admin.html#django-admin-syncdb"><tt class="xref std std-djadmin docutils literal"><span class="pre">syncdb</span></tt></a> with multiple databases<a class="headerlink" href="#behavior-of-syncdb-with-multiple-databases" title="Permalink to this headline">¶</a></h3>
<p><a class="reference internal" href="../ref/django-admin.html#django-admin-syncdb"><tt class="xref std std-djadmin docutils literal"><span class="pre">syncdb</span></tt></a> now queries the database routers to determine if content
types (when <a class="reference internal" href="../ref/contrib/contenttypes.html#module-django.contrib.contenttypes" title="django.contrib.contenttypes: Provides generic interface to installed models."><tt class="xref py py-mod docutils literal"><span class="pre">contenttypes</span></tt></a> is enabled) and permissions
(when <a class="reference internal" href="../topics/auth/index.html#module-django.contrib.auth" title="django.contrib.auth: Django's authentication framework."><tt class="xref py py-mod docutils literal"><span class="pre">auth</span></tt></a> is enabled) should be created in the target
database. Previously, it created them in the default database, even when
another database was specified with the <a class="reference internal" href="../ref/django-admin.html#django-admin-option---database"><tt class="xref std std-djadminopt docutils literal"><span class="pre">--database</span></tt></a> option.</p>
<p>If you use <a class="reference internal" href="../ref/django-admin.html#django-admin-syncdb"><tt class="xref std std-djadmin docutils literal"><span class="pre">syncdb</span></tt></a> on multiple databases, you should ensure that
your routers allow synchronizing content types and permissions to only one of
them. See the docs on the <a class="reference internal" href="../topics/db/multi-db.html#contrib-app-multiple-databases"><em>behavior of contrib apps with multiple
databases</em></a> for more information.</p>
</div>
<div class="section" id="s-xml-deserializer-will-not-parse-documents-with-a-dtd">
<span id="xml-deserializer-will-not-parse-documents-with-a-dtd"></span><h3>XML deserializer will not parse documents with a DTD<a class="headerlink" href="#xml-deserializer-will-not-parse-documents-with-a-dtd" title="Permalink to this headline">¶</a></h3>
<p>In order to prevent exposure to denial-of-service attacks related to external
entity references and entity expansion, the XML model deserializer now refuses
to parse XML documents containing a DTD (DOCTYPE definition). Since the XML
serializer does not output a DTD, this will not impact typical usage, only
cases where custom-created XML documents are passed to Django’s model
deserializer.</p>
</div>
<div class="section" id="s-formsets-default-max-num">
<span id="formsets-default-max-num"></span><h3>Formsets default <tt class="docutils literal"><span class="pre">max_num</span></tt><a class="headerlink" href="#formsets-default-max-num" title="Permalink to this headline">¶</a></h3>
<p>A (default) value of <tt class="docutils literal"><span class="pre">None</span></tt> for the <tt class="docutils literal"><span class="pre">max_num</span></tt> argument to a formset factory
no longer defaults to allowing any number of forms in the formset. Instead, in
order to prevent memory-exhaustion attacks, it now defaults to a limit of 1000
forms. This limit can be raised by explicitly setting a higher value for
<tt class="docutils literal"><span class="pre">max_num</span></tt>.</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 class="simple">
<li><a class="reference internal" href="../ref/forms/fields.html#django.forms.ModelMultipleChoiceField" title="django.forms.ModelMultipleChoiceField"><tt class="xref py py-class docutils literal"><span class="pre">django.forms.ModelMultipleChoiceField</span></tt></a> now returns an empty
<tt class="docutils literal"><span class="pre">QuerySet</span></tt> as the empty value instead of an empty list.</li>
<li><a class="reference internal" href="../ref/utils.html#django.utils.http.int_to_base36" title="django.utils.http.int_to_base36"><tt class="xref py py-func docutils literal"><span class="pre">int_to_base36()</span></tt></a> properly raises a
<tt class="xref py py-exc docutils literal"><span class="pre">TypeError</span></tt> instead of <tt class="xref py py-exc docutils literal"><span class="pre">ValueError</span></tt> for
non-integer inputs.</li>
<li>The <tt class="docutils literal"><span class="pre">slugify</span></tt> template filter is now available as a standard python
function at <a class="reference internal" href="../ref/utils.html#django.utils.text.slugify" title="django.utils.text.slugify"><tt class="xref py py-func docutils literal"><span class="pre">django.utils.text.slugify()</span></tt></a>. Similarly, <tt class="docutils literal"><span class="pre">remove_tags</span></tt> is
available at <a class="reference internal" href="../ref/utils.html#django.utils.html.remove_tags" title="django.utils.html.remove_tags"><tt class="xref py py-func docutils literal"><span class="pre">django.utils.html.remove_tags()</span></tt></a>.</li>
<li>Uploaded files are no longer created as executable by default. If you need
them to be executable change <a class="reference internal" href="../ref/settings.html#std:setting-FILE_UPLOAD_PERMISSIONS"><tt class="xref std std-setting docutils literal"><span class="pre">FILE_UPLOAD_PERMISSIONS</span></tt></a> to your
needs. The new default value is <tt class="docutils literal"><span class="pre">0o666</span></tt> (octal) and the current umask value
is first masked out.</li>
<li>The <a class="reference internal" href="../topics/db/queries.html#query-expressions"><em>F() expressions</em></a> supported bitwise operators by
<tt class="docutils literal"><span class="pre">&</span></tt> and <tt class="docutils literal"><span class="pre">|</span></tt>. These operators are now available using <tt class="docutils literal"><span class="pre">.bitand()</span></tt> and
<tt class="docutils literal"><span class="pre">.bitor()</span></tt> instead. The removal of <tt class="docutils literal"><span class="pre">&</span></tt> and <tt class="docutils literal"><span class="pre">|</span></tt> was done to be consistent with
<a class="reference internal" href="../topics/db/queries.html#complex-lookups-with-q"><em>Q() expressions</em></a> and <tt class="docutils literal"><span class="pre">QuerySet</span></tt> combining where
the operators are used as boolean AND and OR operators.</li>
<li>In a <tt class="docutils literal"><span class="pre">filter()</span></tt> call, when <a class="reference internal" href="../topics/db/queries.html#query-expressions"><em>F() expressions</em></a>
contained lookups spanning multi-valued relations, they didn’t always reuse
the same relations as other lookups along the same chain. This was changed,
and now F() expressions will always use the same relations as other lookups
within the same <tt class="docutils literal"><span class="pre">filter()</span></tt> call.</li>
<li>The <a class="reference internal" href="../ref/templates/builtins.html#std:templatetag-csrf_token"><tt class="xref std std-ttag docutils literal"><span class="pre">csrf_token</span></tt></a> template tag is no longer enclosed in a div. If you need
HTML validation against pre-HTML5 Strict DTDs, you should add a div around it
in your pages.</li>
<li>The template tags library <tt class="docutils literal"><span class="pre">adminmedia</span></tt>, which only contained the
deprecated template tag <tt class="docutils literal"><span class="pre">{%</span> <span class="pre">admin_media_prefix</span> <span class="pre">%}</span></tt>, was removed.
Attempting to load it with <tt class="docutils literal"><span class="pre">{%</span> <span class="pre">load</span> <span class="pre">adminmedia</span> <span class="pre">%}</span></tt> will fail. If your
templates still contain that line you must remove it.</li>
<li>Because of an implementation oversight, it was possible to use
<a class="reference internal" href="../ref/contrib/redirects.html"><em>django.contrib.redirects</em></a> without enabling
<a class="reference internal" href="../ref/contrib/sites.html"><em>django.contrib.sites</em></a>. This isn’t allowed any
longer. If you’re using <tt class="docutils literal"><span class="pre">django.contrib.redirects</span></tt>, make sure
<a class="reference internal" href="../ref/settings.html#std:setting-INSTALLED_APPS"><tt class="xref std std-setting docutils literal"><span class="pre">INSTALLED_APPS</span></tt></a> contains <tt class="docutils literal"><span class="pre">django.contrib.sites</span></tt>.</li>
<li><a class="reference internal" href="../ref/forms/api.html#django.forms.BoundField.label_tag" title="django.forms.BoundField.label_tag"><tt class="xref py py-meth docutils literal"><span class="pre">BoundField.label_tag</span></tt></a> now
escapes its <tt class="docutils literal"><span class="pre">contents</span></tt> argument. To avoid the HTML escaping, use
<a class="reference internal" href="../ref/utils.html#django.utils.safestring.mark_safe" title="django.utils.safestring.mark_safe"><tt class="xref py py-func docutils literal"><span class="pre">django.utils.safestring.mark_safe()</span></tt></a> on the argument before passing it.</li>
<li>Accessing reverse one-to-one relations fetched via
<a class="reference internal" href="../ref/models/querysets.html#django.db.models.query.QuerySet.select_related" title="django.db.models.query.QuerySet.select_related"><tt class="xref py py-meth docutils literal"><span class="pre">select_related()</span></tt></a> now raises
<a class="reference internal" href="../ref/exceptions.html#django.core.exceptions.DoesNotExist" title="django.core.exceptions.DoesNotExist"><tt class="xref py py-exc docutils literal"><span class="pre">DoesNotExist</span></tt></a> instead of returning <tt class="docutils literal"><span class="pre">None</span></tt>.</li>
</ul>
</div>
</div>
<div class="section" id="s-features-deprecated-in-1-5">
<span id="features-deprecated-in-1-5"></span><h2>Features deprecated in 1.5<a class="headerlink" href="#features-deprecated-in-1-5" title="Permalink to this headline">¶</a></h2>
<div class="section" id="s-django-contrib-localflavor">
<span id="django-contrib-localflavor"></span><h3><tt class="docutils literal"><span class="pre">django.contrib.localflavor</span></tt><a class="headerlink" href="#django-contrib-localflavor" title="Permalink to this headline">¶</a></h3>
<p>The localflavor contrib app has been split into separate packages.
<tt class="docutils literal"><span class="pre">django.contrib.localflavor</span></tt> itself will be removed in Django 1.6, after an
<a class="reference internal" href="../topics/localflavor.html#localflavor-deprecation-policy"><em>accelerated deprecation</em></a>. The docs
provide <a class="reference internal" href="../topics/localflavor.html#localflavor-how-to-migrate"><em>migration instructions</em></a>.</p>
<p>The new packages are available <a class="reference internal" href="../topics/localflavor.html#localflavor-packages"><em>on Github</em></a>. The
core team cannot efficiently maintain these packages in the long term — it
spans just a dozen countries at this time; similar to translations, maintenance
will be handed over to interested members of the community.</p>
</div>
<div class="section" id="s-django-contrib-markup">
<span id="django-contrib-markup"></span><h3><tt class="docutils literal"><span class="pre">django.contrib.markup</span></tt><a class="headerlink" href="#django-contrib-markup" title="Permalink to this headline">¶</a></h3>
<p>The markup contrib module has been deprecated and will follow an accelerated
deprecation schedule. Direct use of python markup libraries or 3rd party tag
libraries is preferred to Django maintaining this functionality in the
framework.</p>
</div>
<div class="section" id="s-auth-profile-module">
<span id="auth-profile-module"></span><h3><a class="reference internal" href="../ref/settings.html#std:setting-AUTH_PROFILE_MODULE"><tt class="xref std std-setting docutils literal"><span class="pre">AUTH_PROFILE_MODULE</span></tt></a><a class="headerlink" href="#auth-profile-module" title="Permalink to this headline">¶</a></h3>
<p>With the introduction of <a class="reference internal" href="../topics/auth/customizing.html#auth-custom-user"><em>custom User models</em></a>, there is
no longer any need for a built-in mechanism to store user profile data.</p>
<p>You can still define user profiles models that have a one-to-one relation with
the User model - in fact, for many applications needing to associate data with
a User account, this will be an appropriate design pattern to follow. However,
the <a class="reference internal" href="../ref/settings.html#std:setting-AUTH_PROFILE_MODULE"><tt class="xref std std-setting docutils literal"><span class="pre">AUTH_PROFILE_MODULE</span></tt></a> setting, and the
<a class="reference internal" href="../ref/contrib/auth.html#django.contrib.auth.models.User.get_profile" title="django.contrib.auth.models.User.get_profile"><tt class="xref py py-meth docutils literal"><span class="pre">get_profile()</span></tt></a> method for accessing
the user profile model, should not be used any longer.</p>
</div>
<div class="section" id="s-streaming-behavior-of-httpresponse">
<span id="streaming-behavior-of-httpresponse"></span><h3>Streaming behavior of <a class="reference internal" href="../ref/request-response.html#django.http.HttpResponse" title="django.http.HttpResponse"><tt class="xref py py-class docutils literal"><span class="pre">HttpResponse</span></tt></a><a class="headerlink" href="#streaming-behavior-of-httpresponse" title="Permalink to this headline">¶</a></h3>
<p>Django 1.5 deprecates the ability to stream a response by passing an iterator
to <a class="reference internal" href="../ref/request-response.html#django.http.HttpResponse" title="django.http.HttpResponse"><tt class="xref py py-class docutils literal"><span class="pre">HttpResponse</span></tt></a>. If you rely on this behavior, switch to
<a class="reference internal" href="../ref/request-response.html#django.http.StreamingHttpResponse" title="django.http.StreamingHttpResponse"><tt class="xref py py-class docutils literal"><span class="pre">StreamingHttpResponse</span></tt></a>. See
<a class="reference internal" href="#explicit-streaming-responses"><em>Explicit support for streaming responses</em></a> above.</p>
<p>In Django 1.7 and above, the iterator will be consumed immediately by
<a class="reference internal" href="../ref/request-response.html#django.http.HttpResponse" title="django.http.HttpResponse"><tt class="xref py py-class docutils literal"><span class="pre">HttpResponse</span></tt></a>.</p>
</div>
<div class="section" id="s-django-utils-simplejson">
<span id="s-simplejson-deprecation"></span><span id="django-utils-simplejson"></span><span id="simplejson-deprecation"></span><h3><tt class="docutils literal"><span class="pre">django.utils.simplejson</span></tt><a class="headerlink" href="#django-utils-simplejson" title="Permalink to this headline">¶</a></h3>
<p>Since Django 1.5 drops support for Python 2.5, we can now rely on the
<tt class="xref py py-mod docutils literal"><span class="pre">json</span></tt> module being available in Python’s standard library, so we’ve
removed our own copy of <tt class="xref py py-mod docutils literal"><span class="pre">simplejson</span></tt>. You should now import <tt class="xref py py-mod docutils literal"><span class="pre">json</span></tt>
instead of <tt class="docutils literal"><span class="pre">django.utils.simplejson</span></tt>.</p>
<p>Unfortunately, this change might have unwanted side-effects, because of
incompatibilities between versions of <tt class="xref py py-mod docutils literal"><span class="pre">simplejson</span></tt> – see the
<a class="reference internal" href="#simplejson-incompatibilities"><em>backwards-incompatible changes</em></a> section.
If you rely on features added to <tt class="xref py py-mod docutils literal"><span class="pre">simplejson</span></tt> after it became Python’s
<tt class="xref py py-mod docutils literal"><span class="pre">json</span></tt>, you should import <tt class="xref py py-mod docutils literal"><span class="pre">simplejson</span></tt> explicitly.</p>
</div>
<div class="section" id="s-django-utils-encoding-strandunicode">
<span id="django-utils-encoding-strandunicode"></span><h3><tt class="docutils literal"><span class="pre">django.utils.encoding.StrAndUnicode</span></tt><a class="headerlink" href="#django-utils-encoding-strandunicode" title="Permalink to this headline">¶</a></h3>
<p>The <a class="reference internal" href="../ref/utils.html#django.utils.encoding.StrAndUnicode" title="django.utils.encoding.StrAndUnicode"><tt class="xref py py-class docutils literal"><span class="pre">StrAndUnicode</span></tt></a> mix-in has been deprecated.
Define a <tt class="docutils literal"><span class="pre">__str__</span></tt> method and apply the
<a class="reference internal" href="../ref/utils.html#django.utils.encoding.python_2_unicode_compatible" title="django.utils.encoding.python_2_unicode_compatible"><tt class="xref py py-func docutils literal"><span class="pre">python_2_unicode_compatible()</span></tt></a> decorator instead.</p>
</div>
<div class="section" id="s-django-utils-itercompat-product">
<span id="django-utils-itercompat-product"></span><h3><tt class="docutils literal"><span class="pre">django.utils.itercompat.product</span></tt><a class="headerlink" href="#django-utils-itercompat-product" title="Permalink to this headline">¶</a></h3>
<p>The <tt class="docutils literal"><span class="pre">django.utils.itercompat.product</span></tt> function has been deprecated. Use
the built-in <tt class="xref py py-func docutils literal"><span class="pre">itertools.product()</span></tt> instead.</p>
</div>
<div class="section" id="s-cleanup-management-command">
<span id="cleanup-management-command"></span><h3><tt class="docutils literal"><span class="pre">cleanup</span></tt> management command<a class="headerlink" href="#cleanup-management-command" title="Permalink to this headline">¶</a></h3>
<p>The <a class="reference internal" href="../ref/django-admin.html#django-admin-cleanup"><tt class="xref std std-djadmin docutils literal"><span class="pre">cleanup</span></tt></a> management command has been deprecated and replaced by
<a class="reference internal" href="../ref/django-admin.html#django-admin-clearsessions"><tt class="xref std std-djadmin docutils literal"><span class="pre">clearsessions</span></tt></a>.</p>
</div>
<div class="section" id="s-daily-cleanup-py-script">
<span id="daily-cleanup-py-script"></span><h3><tt class="docutils literal"><span class="pre">daily_cleanup.py</span></tt> script<a class="headerlink" href="#daily-cleanup-py-script" title="Permalink to this headline">¶</a></h3>
<p>The undocumented <tt class="docutils literal"><span class="pre">daily_cleanup.py</span></tt> script has been deprecated. Use the
<a class="reference internal" href="../ref/django-admin.html#django-admin-clearsessions"><tt class="xref std std-djadmin docutils literal"><span class="pre">clearsessions</span></tt></a> management command instead.</p>
</div>
<div class="section" id="s-depth-keyword-argument-in-select-related">
<span id="depth-keyword-argument-in-select-related"></span><h3><tt class="docutils literal"><span class="pre">depth</span></tt> keyword argument in <tt class="docutils literal"><span class="pre">select_related</span></tt><a class="headerlink" href="#depth-keyword-argument-in-select-related" title="Permalink to this headline">¶</a></h3>
<p>The <tt class="docutils literal"><span class="pre">depth</span></tt> keyword argument in
<a class="reference internal" href="../ref/models/querysets.html#django.db.models.query.QuerySet.select_related" title="django.db.models.query.QuerySet.select_related"><tt class="xref py py-meth docutils literal"><span class="pre">select_related()</span></tt></a> has been deprecated.
You should use field names instead.</p>
</div>
</div>
</div>
</div>
</div>
</div>
<div class="yui-b" id="sidebar">
<div class="sphinxsidebar">
<div class="sphinxsidebarwrapper">
<h3><a href="../contents.html">Table Of Contents</a></h3>
<ul>
<li><a class="reference internal" href="#">Django 1.5 release notes</a><ul>
<li><a class="reference internal" href="#overview">Overview</a></li>
<li><a class="reference internal" href="#python-compatibility">Python compatibility</a><ul>
<li><a class="reference internal" href="#python-3-support">Python 3 support</a></li>
</ul>
</li>
<li><a class="reference internal" href="#what-s-new-in-django-1-5">What’s new in Django 1.5</a><ul>
<li><a class="reference internal" href="#configurable-user-model">Configurable User model</a></li>
<li><a class="reference internal" href="#support-for-saving-a-subset-of-model-s-fields">Support for saving a subset of model’s fields</a></li>
<li><a class="reference internal" href="#caching-of-related-model-instances">Caching of related model instances</a></li>
<li><a class="reference internal" href="#explicit-support-for-streaming-responses">Explicit support for streaming responses</a></li>
<li><a class="reference internal" href="#verbatim-template-tag"><tt class="docutils literal"><span class="pre">{%</span> <span class="pre">verbatim</span> <span class="pre">%}</span></tt> template tag</a></li>
<li><a class="reference internal" href="#retrieval-of-contenttype-instances-associated-with-proxy-models">Retrieval of <tt class="docutils literal"><span class="pre">ContentType</span></tt> instances associated with proxy models</a></li>
<li><a class="reference internal" href="#new-view-variable-in-class-based-views-context">New <tt class="docutils literal"><span class="pre">view</span></tt> variable in class-based views context</a></li>
<li><a class="reference internal" href="#geodjango">GeoDjango</a></li>
<li><a class="reference internal" href="#new-tutorials">New tutorials</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-5">Backwards incompatible changes in 1.5</a><ul>
<li><a class="reference internal" href="#allowed-hosts-required-in-production"><tt class="docutils literal"><span class="pre">ALLOWED_HOSTS</span></tt> required in production</a></li>
<li><a class="reference internal" href="#managers-on-abstract-models">Managers on abstract models</a></li>
<li><a class="reference internal" href="#context-in-year-archive-class-based-views">Context in year archive class-based views</a></li>
<li><a class="reference internal" href="#context-in-year-and-month-archive-class-based-views">Context in year and month archive class-based views</a></li>
<li><a class="reference internal" href="#context-in-templateview">Context in TemplateView</a></li>
<li><a class="reference internal" href="#non-form-data-in-http-requests">Non-form data in HTTP requests</a></li>
<li><a class="reference internal" href="#request-finished-signal"><tt class="docutils literal"><span class="pre">request_finished</span></tt> signal</a></li>
<li><a class="reference internal" href="#options-put-and-delete-requests-in-the-test-client">OPTIONS, PUT and DELETE requests in the test client</a></li>
<li><a class="reference internal" href="#system-version-of-simplejson-no-longer-used">System version of <tt class="docutils literal"><span class="pre">simplejson</span></tt> no longer used</a></li>
<li><a class="reference internal" href="#string-types-of-hasher-method-parameters">String types of hasher method parameters</a></li>
<li><a class="reference internal" href="#validation-of-previous-page-number-and-next-page-number">Validation of previous_page_number and next_page_number</a></li>
<li><a class="reference internal" href="#behavior-of-autocommit-database-option-on-postgresql-changed">Behavior of autocommit database option on PostgreSQL changed</a></li>
<li><a class="reference internal" href="#session-not-saved-on-500-responses">Session not saved on 500 responses</a></li>
<li><a class="reference internal" href="#email-checks-on-failed-admin-login">Email checks on failed admin login</a></li>
<li><a class="reference internal" href="#changes-in-tests-execution">Changes in tests execution</a><ul>
<li><a class="reference internal" href="#database-flushing-in-django-test-transactiontestcase">Database flushing in <tt class="docutils literal"><span class="pre">django.test.TransactionTestCase</span></tt></a></li>
<li><a class="reference internal" href="#no-more-implicit-db-sequences-reset">No more implicit DB sequences reset</a></li>
<li><a class="reference internal" href="#ordering-of-tests">Ordering of tests</a></li>
</ul>
</li>
<li><a class="reference internal" href="#cleaned-data-dictionary-kept-for-invalid-forms"><cite>cleaned_data</cite> dictionary kept for invalid forms</a></li>
<li><a class="reference internal" href="#behavior-of-syncdb-with-multiple-databases">Behavior of <tt class="docutils literal"><span class="pre">syncdb</span></tt> with multiple databases</a></li>
<li><a class="reference internal" href="#xml-deserializer-will-not-parse-documents-with-a-dtd">XML deserializer will not parse documents with a DTD</a></li>
<li><a class="reference internal" href="#formsets-default-max-num">Formsets default <tt class="docutils literal"><span class="pre">max_num</span></tt></a></li>
<li><a class="reference internal" href="#miscellaneous">Miscellaneous</a></li>
</ul>
</li>
<li><a class="reference internal" href="#features-deprecated-in-1-5">Features deprecated in 1.5</a><ul>
<li><a class="reference internal" href="#django-contrib-localflavor"><tt class="docutils literal"><span class="pre">django.contrib.localflavor</span></tt></a></li>
<li><a class="reference internal" href="#django-contrib-markup"><tt class="docutils literal"><span class="pre">django.contrib.markup</span></tt></a></li>
<li><a class="reference internal" href="#auth-profile-module"><tt class="docutils literal"><span class="pre">AUTH_PROFILE_MODULE</span></tt></a></li>
<li><a class="reference internal" href="#streaming-behavior-of-httpresponse">Streaming behavior of <tt class="docutils literal"><span class="pre">HttpResponse</span></tt></a></li>
<li><a class="reference internal" href="#django-utils-simplejson"><tt class="docutils literal"><span class="pre">django.utils.simplejson</span></tt></a></li>
<li><a class="reference internal" href="#django-utils-encoding-strandunicode"><tt class="docutils literal"><span class="pre">django.utils.encoding.StrAndUnicode</span></tt></a></li>
<li><a class="reference internal" href="#django-utils-itercompat-product"><tt class="docutils literal"><span class="pre">django.utils.itercompat.product</span></tt></a></li>
<li><a class="reference internal" href="#cleanup-management-command"><tt class="docutils literal"><span class="pre">cleanup</span></tt> management command</a></li>
<li><a class="reference internal" href="#daily-cleanup-py-script"><tt class="docutils literal"><span class="pre">daily_cleanup.py</span></tt> script</a></li>
<li><a class="reference internal" href="#depth-keyword-argument-in-select-related"><tt class="docutils literal"><span class="pre">depth</span></tt> keyword argument in <tt class="docutils literal"><span class="pre">select_related</span></tt></a></li>
</ul>
</li>
</ul>
</li>
</ul>
<h3>Browse</h3>
<ul>
<li>Prev: <a href="1.5.1.html">Django 1.5.1 release notes</a></li>
<li>Next: <a href="1.4.15.html">Django 1.4.15 release notes</a></li>
</ul>
<h3>You are here:</h3>
<ul>
<li>
<a href="../index.html">Django 1.6.7 documentation</a>
<ul><li><a href="index.html">Release notes</a>
<ul><li>Django 1.5 release notes</li></ul>
</li></ul>
</li>
</ul>
<h3>This Page</h3>
<ul class="this-page-menu">
<li><a href="../_sources/releases/1.5.txt"
rel="nofollow">Show Source</a></li>
</ul>
<div id="searchbox" style="display: none">
<h3>Quick search</h3>
<form class="search" action="../search.html" method="get">
<input type="text" name="q" />
<input type="submit" value="Go" />
<input type="hidden" name="check_keywords" value="yes" />
<input type="hidden" name="area" value="default" />
</form>
<p class="searchtip" style="font-size: 90%">
Enter search terms or a module, class or function name.
</p>
</div>
<script type="text/javascript">$('#searchbox').show(0);</script>
</div>
</div>
<h3>Last update:</h3>
<p class="topless">Sep 26, 2014</p>
</div>
</div>
<div id="ft">
<div class="nav">
« <a href="1.5.1.html" title="Django 1.5.1 release notes">previous</a>
|
<a href="index.html" title="Release notes" accesskey="U">up</a>
|
<a href="1.4.15.html" title="Django 1.4.15 release notes">next</a> »</div>
</div>
</div>
<div class="clearer"></div>
</div>
</body>
</html>
