<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" lang="">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<title>Django 1.5 release notes — Django 1.8.19 documentation</title>
<link rel="stylesheet" href="../_static/default.css" type="text/css" />
<link rel="stylesheet" href="../_static/pygments.css" type="text/css" />
<script type="text/javascript">
var DOCUMENTATION_OPTIONS = {
URL_ROOT: '../',
VERSION: '1.8.19',
COLLAPSE_INDEX: false,
FILE_SUFFIX: '.html',
HAS_SOURCE: true
};
</script>
<script type="text/javascript" src="../_static/jquery.js"></script>
<script type="text/javascript" src="../_static/underscore.js"></script>
<script type="text/javascript" src="../_static/doctools.js"></script>
<link rel="index" title="Index" href="../genindex.html" />
<link rel="search" title="Search" href="../search.html" />
<link rel="top" title="Django 1.8.19 documentation" href="../contents.html" />
<link rel="up" title="Release notes" href="index.html" />
<link rel="next" title="Django 1.4.22 release notes" href="1.4.22.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 role="document">
<div class="document">
<div id="custom-doc" class="yui-t6">
<div id="hd">
<h1><a href="../index.html">Django 1.8.19 documentation</a></h1>
<div id="global-nav">
<a title="Home page" href="../index.html">Home</a> |
<a title="Table of contents" href="../contents.html">Table of contents</a> |
<a title="Global index" href="../genindex.html">Index</a> |
<a title="Module index" href="../py-modindex.html">Modules</a>
</div>
<div class="nav">
« <a href="1.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.22.html" title="Django 1.4.22 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="#whats-new-1-5"><span class="std std-ref">new features</span></a>, as well as
some <a class="reference internal" href="#backwards-incompatible-1-5"><span class="std std-ref">backwards incompatible changes</span></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#deprecation-removed-in-1-5"><span class="std std-ref">our deprecation plan</span></a>, and we’ve <a class="reference internal" href="#deprecated-features-1-5"><span class="std std-ref">begun the deprecation process
for some features</span></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."><code class="xref py py-mod docutils literal"><span class="pre">django.contrib.auth</span></code></a>) were forced to use Django’s definition of a “user”.
In Django 1.5, you can now swap out the <code class="docutils literal"><span class="pre">User</span></code> model for one that you write
yourself. This could be a simple extension to the existing <code class="docutils literal"><span class="pre">User</span></code> model – for
example, you could add a Twitter or Facebook ID field – or you could completely
replace the <code class="docutils literal"><span class="pre">User</span></code> 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"><code class="xref py py-meth docutils literal"><span class="pre">Model.save()</span></code></a> now accepts an
<code class="docutils literal"><span class="pre">update_fields</span></code> argument, letting you specify which fields are
written back to the database when you call <code class="docutils literal"><span class="pre">save()</span></code>. 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"><code class="xref py py-class docutils literal"><span class="pre">StreamingHttpResponse</span></code></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"><span class="doc">our API stability policy</span></a>.
However, as with previous releases, Django 1.5 ships with some minor
<a class="reference internal" href="#backwards-incompatible-1-5"><span class="std std-ref">backwards incompatible changes</span></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"><code class="xref std std-ttag docutils literal"><span class="pre">url</span></code></a> tag.
Prior to Django 1.3, syntax like <code class="docutils literal"><span class="pre">{%</span> <span class="pre">url</span> <span class="pre">myview</span> <span class="pre">%}</span></code> was interpreted
incorrectly (Django considered <code class="docutils literal"><span class="pre">"myview"</span></code> to be a literal name of a view, not
a template variable named <code class="docutils literal"><span class="pre">myview</span></code>). Django 1.3 and above introduced the
<code 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></code> syntax to bring in the corrected behavior where
<code class="docutils literal"><span class="pre">myview</span></code> was seen as a variable.</p>
<p>The upshot of this is that if you are not using <code 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></code>
in your templates, you’ll need to change tags like <code class="docutils literal"><span class="pre">{%</span> <span class="pre">url</span> <span class="pre">myview</span> <span class="pre">%}</span></code> to
<code class="docutils literal"><span class="pre">{%</span> <span class="pre">url</span> <span class="pre">"myview"</span> <span class="pre">%}</span></code>. If you <em>were</em> using <code 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></code> 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"><span class="doc">our support
policy</span></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"><code class="xref py py-class docutils literal"><span class="pre">ImageField</span></code></a> (depends on PIL)</li>
<li><a class="reference internal" href="../topics/testing/tools.html#django.test.LiveServerTestCase" title="django.test.LiveServerTestCase"><code class="xref py py-class docutils literal"><span class="pre">LiveServerTestCase</span></code></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"><span class="doc">porting applications to Python 3</span></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="s-whats-new-1-5"></span><span id="what-s-new-in-django-1-5"></span><span id="whats-new-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"><span class="std std-ref">documentation on custom User models</span></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"><code class="xref py py-meth docutils literal"><span class="pre">Model.save()</span></code></a> has a new
keyword argument <code class="docutils literal"><span class="pre">update_fields</span></code>. 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 <code class="docutils literal"><span class="pre">.only()</span></code> or <code class="docutils literal"><span class="pre">.defer()</span></code>) 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"><code class="xref py py-meth docutils literal"><span class="pre">Model.save()</span></code></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-default"><div class="highlight"><pre><span></span><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
<code class="docutils literal"><span class="pre">first_choice.poll</span></code>; 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 <code class="docutils literal"><span class="pre">prefetch_related</span></code>.</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"><code class="xref py py-class docutils literal"><span class="pre">HttpResponse</span></code></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"><code class="xref py py-attr docutils literal"><span class="pre">content</span></code></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"><code class="xref py py-class docutils literal"><span class="pre">StreamingHttpResponse</span></code></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"><code class="xref py py-class docutils literal"><span class="pre">streaming_content</span></code></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"><code class="xref py py-class docutils literal"><span class="pre">StreamingHttpResponse</span></code></a> does not have a <code class="docutils literal"><span class="pre">content</span></code>
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"><span class="std std-ref">process_response</span></a> for
more information.</p>
</div>
<div class="section" id="s-verbatim-template-tag">
<span id="verbatim-template-tag"></span><h3><code class="docutils literal"><span class="pre">{%</span> <span class="pre">verbatim</span> <span class="pre">%}</span></code> 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"><code class="xref std std-ttag docutils literal"><span class="pre">verbatim</span></code></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 <code class="docutils literal"><span class="pre">ContentType</span></code> 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"><code class="xref py py-meth docutils literal"><span class="pre">ContentTypeManager.get_for_model()</span></code></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"><code class="xref py py-meth docutils literal"><span class="pre">ContentTypeManager.get_for_models()</span></code></a>
have a new keyword argument – respectively <code class="docutils literal"><span class="pre">for_concrete_model</span></code> and <code class="docutils literal"><span class="pre">for_concrete_models</span></code>.
By passing <code class="docutils literal"><span class="pre">False</span></code> 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"><code class="xref py py-class docutils literal"><span class="pre">ContentType</span></code></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 <code class="docutils literal"><span class="pre">view</span></code> 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"><span class="doc">generic class-based views</span></a>
(or any class-based view inheriting from <code class="docutils literal"><span class="pre">ContextMixin</span></code>), the context dictionary
contains a <code class="docutils literal"><span class="pre">view</span></code> variable that points to the <code class="docutils literal"><span class="pre">View</span></code> 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"><code class="xref py py-class docutils literal"><span class="pre">LineString</span></code></a> and
<a class="reference internal" href="../ref/contrib/gis/geos.html#django.contrib.gis.geos.MultiLineString" title="django.contrib.gis.geos.MultiLineString"><code class="xref py py-class docutils literal"><span class="pre">MultiLineString</span></code></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"><code class="xref py py-meth docutils literal"><span class="pre">interpolate()</span></code></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"><code class="xref py py-meth docutils literal"><span class="pre">project()</span></code></a> methods
(so-called linear referencing).</li>
<li>The <code class="docutils literal"><span class="pre">wkb</span></code> and <code class="docutils literal"><span class="pre">hex</span></code> properties of
<a class="reference internal" href="../ref/contrib/gis/geos.html#django.contrib.gis.geos.GEOSGeometry" title="django.contrib.gis.geos.GEOSGeometry"><code class="xref py py-class docutils literal"><span class="pre">GEOSGeometry</span></code></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"><span class="doc">Tutorial 3</span></a>
and a new <a class="reference internal" href="../intro/tutorial05.html"><span class="doc">tutorial on testing</span></a>. A new section,
“Advanced Tutorials”, offers <a class="reference internal" href="../intro/reusable-apps.html"><span class="doc">How to write reusable apps</span></a> as well as a step-by-step guide for new contributors in
<a class="reference internal" href="../intro/contributing.html"><span class="doc">Writing your first patch for Django</span></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 <code class="docutils literal"><span class="pre">True</span></code>, <code class="docutils literal"><span class="pre">False</span></code> and <code class="docutils literal"><span class="pre">None</span></code> 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."><code class="xref py py-mod docutils literal"><span class="pre">django.utils.timezone</span></code></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"><code class="xref py py-func docutils literal"><span class="pre">localtime()</span></code></a>.</p>
</li>
<li><p class="first">The generic views support OPTIONS requests.</p>
</li>
<li><p class="first">Management commands do not raise <code class="docutils literal"><span class="pre">SystemExit</span></code> any more when called by code
from <a class="reference internal" href="../ref/django-admin.html#call-command"><span class="std std-ref">call_command</span></a>. Any exception raised by the command
(mostly <a class="reference internal" href="../howto/custom-management-commands.html#ref-command-exceptions"><span class="std std-ref">CommandError</span></a>) is propagated.</p>
<p>Moreover, when you output errors or messages in your custom commands, you
should now use <code class="docutils literal"><span class="pre">self.stdout.write('message')</span></code> and
<code class="docutils literal"><span class="pre">self.stderr.write('error')</span></code> (see the note on
<a class="reference internal" href="../howto/custom-management-commands.html#management-commands-output"><span class="std std-ref">management commands output</span></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"><span class="std std-ref">receiver</span></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"><code class="xref py py-meth docutils literal"><span class="pre">QuerySet.bulk_create()</span></code></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"><code class="xref std std-setting docutils literal"><span class="pre">LOGIN_URL</span></code></a> and <a class="reference internal" href="../ref/settings.html#std:setting-LOGIN_REDIRECT_URL"><code class="xref std std-setting docutils literal"><span class="pre">LOGIN_REDIRECT_URL</span></code></a> settings now also
accept view function names and
<a class="reference internal" href="../topics/http/urls.html#naming-url-patterns"><span class="std std-ref">named URL patterns</span></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"><code class="xref py py-func docutils literal"><span class="pre">login_required()</span></code></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"><span class="doc">auth handler</span></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"><code class="xref py py-meth docutils literal"><span class="pre">QuerySet.delete()</span></code></a>
and <a class="reference internal" href="../ref/models/instances.html#django.db.models.Model.delete" title="django.db.models.Model.delete"><code class="xref py py-meth docutils literal"><span class="pre">Model.delete()</span></code></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"><code class="xref py py-meth docutils literal"><span class="pre">QuerySet.delete()</span></code></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"><code class="xref py py-class docutils literal"><span class="pre">ResolverMatch</span></code></a> is stored on
the request as <code class="docutils literal"><span class="pre">resolver_match</span></code>.</p>
</li>
<li><p class="first">By default, all logging messages reaching the <code class="docutils literal"><span class="pre">django</span></code> logger when
<a class="reference internal" href="../ref/settings.html#std:setting-DEBUG"><code class="xref std std-setting docutils literal"><span class="pre">DEBUG</span></code></a> is <code class="docutils literal"><span class="pre">True</span></code> are sent to the console (unless you redefine the
logger in your <a class="reference internal" href="../ref/settings.html#std:setting-LOGGING"><code class="xref std std-setting docutils literal"><span class="pre">LOGGING</span></code></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"><code class="xref py py-class docutils literal"><span class="pre">RequestContext</span></code></a>, it is now possible to
look up permissions by using <code 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></code>
in templates.</p>
</li>
<li><p class="first">It’s not required any more to have <code class="docutils literal"><span class="pre">404.html</span></code> and <code class="docutils literal"><span class="pre">500.html</span></code> 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."><code class="xref py py-mod docutils literal"><span class="pre">django.contrib.auth</span></code></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"><code class="xref py py-data docutils literal"><span class="pre">user_login_failed</span></code></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"><code class="xref std std-djadminopt docutils literal"><span class="pre">--ignorenonexistent</span></code></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"><code class="xref py py-meth docutils literal"><span class="pre">assertXMLEqual()</span></code></a> and
<a class="reference internal" href="../topics/testing/tools.html#django.test.SimpleTestCase.assertXMLNotEqual" title="django.test.SimpleTestCase.assertXMLNotEqual"><code class="xref py py-meth docutils literal"><span class="pre">assertXMLNotEqual()</span></code></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"><span class="std std-ref">cache-based session backend</span></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"><code class="xref py py-attr docutils literal"><span class="pre">index_together</span></code></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 <code class="docutils literal"><span class="pre">console</span></code> logging handler, which by default requires
<a class="reference internal" href="../ref/settings.html#std:setting-DEBUG"><code class="xref std std-setting docutils literal"><span class="pre">DEBUG</span></code></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"><code class="xref py py-meth docutils literal"><span class="pre">django.contrib.admin.ModelAdmin.message_user()</span></code></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"><code class="xref py py-func docutils literal"><span class="pre">django.contrib.messages.add_message()</span></code></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"><code class="xref py py-meth docutils literal"><span class="pre">django.contrib.admin.ModelAdmin.get_list_filter()</span></code></a> method.</p>
</li>
</ul>
</div>
</div>
<div class="section" id="s-backwards-incompatible-changes-in-1-5">
<span id="s-backwards-incompatible-1-5"></span><span id="backwards-incompatible-changes-in-1-5"></span><span id="backwards-incompatible-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
<a class="reference internal" href="../internals/deprecation.html#deprecation-removed-in-1-5"><span class="std std-ref">deprecation plan</span></a> for any features that
have been removed. If you haven’t updated your code within the
deprecation timeline for a given feature, its removal may appear as a
backwards incompatible change.</p>
</div>
<div class="section" id="s-allowed-hosts-required-in-production">
<span id="allowed-hosts-required-in-production"></span><h3><code class="docutils literal"><span class="pre">ALLOWED_HOSTS</span></code> 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"><code class="xref std std-setting docutils literal"><span class="pre">ALLOWED_HOSTS</span></code></a> setting validates the request’s <code class="docutils literal"><span class="pre">Host</span></code>
header and protects against host-poisoning attacks. This setting is now
required whenever <a class="reference internal" href="../ref/settings.html#std:setting-DEBUG"><code class="xref std std-setting docutils literal"><span class="pre">DEBUG</span></code></a> is <code class="docutils literal"><span class="pre">False</span></code>, or else
<a class="reference internal" href="../ref/request-response.html#django.http.HttpRequest.get_host" title="django.http.HttpRequest.get_host"><code class="xref py py-meth docutils literal"><span class="pre">django.http.HttpRequest.get_host()</span></code></a> will raise
<a class="reference internal" href="../ref/exceptions.html#django.core.exceptions.SuspiciousOperation" title="django.core.exceptions.SuspiciousOperation"><code class="xref py py-exc docutils literal"><span class="pre">SuspiciousOperation</span></code></a>. For more details see the
<a class="reference internal" href="../ref/settings.html#std:setting-ALLOWED_HOSTS"><code class="xref std std-setting docutils literal"><span class="pre">full</span> <span class="pre">documentation</span></code></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"><span class="std std-ref">will be inherited by any concrete models extending the abstract model</span></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
<code class="docutils literal"><span class="pre">staticmethod</span></code> or <code class="docutils literal"><span class="pre">classmethod</span></code> 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"><code class="xref py py-class docutils literal"><span class="pre">YearArchiveView</span></code></a> now passes <code class="docutils literal"><span class="pre">year</span></code> in
the context as a <code class="xref py py-class docutils literal"><span class="pre">datetime.date</span></code> rather than a string. If you are
using <code class="docutils literal"><span class="pre">{{</span> <span class="pre">year</span> <span class="pre">}}</span></code> in your templates, you must replace it with <code class="docutils literal"><span class="pre">{{</span>
<span class="pre">year|date:"Y"</span> <span class="pre">}}</span></code>.</p>
<p><code class="docutils literal"><span class="pre">next_year</span></code> and <code class="docutils literal"><span class="pre">previous_year</span></code> were also added in the context. They are
calculated according to <code class="docutils literal"><span class="pre">allow_empty</span></code> and <code class="docutils literal"><span class="pre">allow_future</span></code>.</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"><code class="xref py py-class docutils literal"><span class="pre">YearArchiveView</span></code></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"><code class="xref py py-class docutils literal"><span class="pre">MonthArchiveView</span></code></a> were documented to
provide a <code class="docutils literal"><span class="pre">date_list</span></code> 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
<code class="docutils literal"><span class="pre">reversed</span></code> keyword when you’re iterating on <code class="docutils literal"><span class="pre">date_list</span></code> in a template:</p>
<div class="highlight-default"><div class="highlight"><pre><span></span><span class="p">{</span><span class="o">%</span> <span class="k">for</span> <span class="n">date</span> <span class="ow">in</span> <span class="n">date_list</span> <span class="nb">reversed</span> <span class="o">%</span><span class="p">}</span>
</pre></div>
</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"><code class="xref py py-class docutils literal"><span class="pre">ArchiveIndexView</span></code></a> still provides a
<code class="docutils literal"><span class="pre">date_list</span></code> 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"><code class="xref py py-class docutils literal"><span class="pre">TemplateView</span></code></a> no longer passes a <code class="docutils literal"><span class="pre">params</span></code>
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"><code class="xref py py-attr docutils literal"><span class="pre">request.POST</span></code></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
<code class="docutils literal"><span class="pre">multipart/form-data</span></code> or <code class="docutils literal"><span class="pre">application/x-www-form-urlencoded</span></code> 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"><code class="xref py py-attr docutils literal"><span class="pre">request.POST</span></code></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"><code class="xref py py-attr docutils literal"><span class="pre">request.body</span></code></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"><code class="xref py py-data docutils literal"><span class="pre">request_finished</span></code></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"><code class="xref py py-data docutils literal"><span class="pre">request_finished</span></code></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"><span class="std std-ref">streaming responses</span></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"><span class="doc">middleware</span></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 <code class="docutils literal"><span class="pre">close</span></code> 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
<code class="docutils literal"><span class="pre">request_finished</span></code> 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 <code class="docutils literal"><span class="pre">data</span></code> parameter in an OPTIONS or a DELETE request,
you must convert it to a query string and append it to the <code class="docutils literal"><span class="pre">path</span></code> parameter.</p>
<p>If you were using the <code class="docutils literal"><span class="pre">data</span></code> parameter in a PUT request without a
<code class="docutils literal"><span class="pre">content_type</span></code>, you must encode your data before passing it to the test
client and set the <code class="docutils literal"><span class="pre">content_type</span></code> 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 <code class="docutils literal"><span class="pre">simplejson</span></code> 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"><span class="std std-ref">As explained below</span></a>, Django 1.5 deprecates
<code class="docutils literal"><span class="pre">django.utils.simplejson</span></code> in favor of Python 2.6’s built-in <code class="xref py py-mod docutils literal"><span class="pre">json</span></code>
module. In theory, this change is harmless. Unfortunately, because of
incompatibilities between versions of <code class="docutils literal"><span class="pre">simplejson</span></code>, it may trigger errors
in some circumstances.</p>
<p>JSON-related features in Django 1.4 always used <code class="docutils literal"><span class="pre">django.utils.simplejson</span></code>.
This module was actually:</p>
<ul class="simple">
<li>A system version of <code class="docutils literal"><span class="pre">simplejson</span></code>, if one was available (ie. <code class="docutils literal"><span class="pre">import</span>
<span class="pre">simplejson</span></code> works), if it was more recent than Django’s built-in copy or it
had the C speedups, or</li>
<li>The <code class="xref py py-mod docutils literal"><span class="pre">json</span></code> 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 <code class="docutils literal"><span class="pre">simplejson</span></code>.</li>
</ul>
<p>In Django 1.5, those features use Python’s <code class="xref py py-mod docutils literal"><span class="pre">json</span></code> module, which is based
on version 2.0.9 of <code class="docutils literal"><span class="pre">simplejson</span></code>.</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 <code class="docutils literal"><span class="pre">simplejson</span></code>:</p>
<ul class="simple">
<li>While the <code class="docutils literal"><span class="pre">simplejson</span></code> 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><code class="docutils literal"><span class="pre">simplejson.JSONEncoder</span></code> gained a <code class="docutils literal"><span class="pre">namedtuple_as_object</span></code> 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 <code class="docutils literal"><span class="pre">simplejson</span></code> and your code
uses Django’s serialization internals directly – for instance
<code class="docutils literal"><span class="pre">django.core.serializers.json.DjangoJSONEncoder</span></code>, the switch from
<code class="docutils literal"><span class="pre">simplejson</span></code> to <code class="xref py py-mod docutils literal"><span class="pre">json</span></code> 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 <code class="xref py py-mod docutils literal"><span class="pre">json</span></code> 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"><span class="std std-ref">custom password hasher</span></a>,
your <code class="docutils literal"><span class="pre">encode()</span></code>, <code class="docutils literal"><span class="pre">verify()</span></code> or <code class="docutils literal"><span class="pre">safe_summary()</span></code> methods should accept
Unicode parameters (<code class="docutils literal"><span class="pre">password</span></code>, <code class="docutils literal"><span class="pre">salt</span></code> or <code class="docutils literal"><span class="pre">encoded</span></code>). 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"><code class="xref py py-func docutils literal"><span class="pre">force_bytes()</span></code></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"><span class="doc">object pagination</span></a>,
the <code class="docutils literal"><span class="pre">previous_page_number()</span></code> and <code class="docutils literal"><span class="pre">next_page_number()</span></code> methods of the
<a class="reference internal" href="../topics/pagination.html#django.core.paginator.Page" title="django.core.paginator.Page"><code class="xref py py-class docutils literal"><span class="pre">Page</span></code></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"><code class="xref py py-exc docutils literal"><span class="pre">InvalidPage</span></code></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"><span class="std std-ref">custom User models</span></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 <code class="docutils literal"><span class="pre">django.test.TransactionTestCase</span></code><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"><code class="xref py py-class docutils literal"><span class="pre">TransactionTestCase</span></code></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"><code class="xref py py-class docutils literal"><span class="pre">TransactionTestCase</span></code></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"><code class="xref py py-class docutils literal"><span class="pre">TransactionTestCase</span></code></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"><code class="xref py py-class docutils literal"><span class="pre">TransactionTestCase</span></code></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"><code class="xref py py-attr docutils literal"><span class="pre">reset_sequences</span></code></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"><code class="xref py py-class docutils literal"><span class="pre">TransactionTestCase</span></code></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 <code class="docutils literal"><span class="pre">TestCase</span></code> code starts with a clean database,
tests are now executed in the following order:</p>
<ul class="simple">
<li>First, all unittests (including <code class="xref py py-class docutils literal"><span class="pre">unittest.TestCase</span></code>,
<a class="reference internal" href="../topics/testing/tools.html#django.test.SimpleTestCase" title="django.test.SimpleTestCase"><code class="xref py py-class docutils literal"><span class="pre">SimpleTestCase</span></code></a>, <a class="reference internal" href="../topics/testing/tools.html#django.test.TestCase" title="django.test.TestCase"><code class="xref py py-class docutils literal"><span class="pre">TestCase</span></code></a> and
<a class="reference internal" href="../topics/testing/tools.html#django.test.TransactionTestCase" title="django.test.TransactionTestCase"><code class="xref py py-class docutils literal"><span class="pre">TransactionTestCase</span></code></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"><code class="xref py py-class docutils literal"><span class="pre">TransactionTestCase</span></code></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"><code class="xref py py-attr docutils literal"><span class="pre">cleaned_data</span></code></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"><code class="xref py py-meth docutils literal"><span class="pre">is_valid()</span></code></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"><code class="xref py py-attr docutils literal"><span class="pre">cleaned_data</span></code></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"><code class="xref std std-djadmin docutils literal"><span class="pre">syncdb</span></code></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"><code class="xref std std-djadmin docutils literal"><span class="pre">syncdb</span></code></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."><code class="xref py py-mod docutils literal"><span class="pre">contenttypes</span></code></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."><code class="xref py py-mod docutils literal"><span class="pre">auth</span></code></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"><code class="xref std std-djadminopt docutils literal"><span class="pre">--database</span></code></a> option.</p>
<p>If you use <a class="reference internal" href="../ref/django-admin.html#django-admin-syncdb"><code class="xref std std-djadmin docutils literal"><span class="pre">syncdb</span></code></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"><span class="std std-ref">behavior of contrib apps with multiple
databases</span></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 <code class="docutils literal"><span class="pre">max_num</span></code><a class="headerlink" href="#formsets-default-max-num" title="Permalink to this headline">¶</a></h3>
<p>A (default) value of <code class="docutils literal"><span class="pre">None</span></code> for the <code class="docutils literal"><span class="pre">max_num</span></code> 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
<code class="docutils literal"><span class="pre">max_num</span></code>.</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"><code class="xref py py-class docutils literal"><span class="pre">django.forms.ModelMultipleChoiceField</span></code></a> now returns an empty
<code class="docutils literal"><span class="pre">QuerySet</span></code> 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"><code class="xref py py-func docutils literal"><span class="pre">int_to_base36()</span></code></a> properly raises a
<code class="xref py py-exc docutils literal"><span class="pre">TypeError</span></code> instead of <code class="xref py py-exc docutils literal"><span class="pre">ValueError</span></code> for non-integer inputs.</li>
<li>The <code class="docutils literal"><span class="pre">slugify</span></code> 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"><code class="xref py py-func docutils literal"><span class="pre">django.utils.text.slugify()</span></code></a>. Similarly, <code class="docutils literal"><span class="pre">remove_tags</span></code> is
available at <a class="reference internal" href="../ref/utils.html#django.utils.html.remove_tags" title="django.utils.html.remove_tags"><code class="xref py py-func docutils literal"><span class="pre">django.utils.html.remove_tags()</span></code></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"><code class="xref std std-setting docutils literal"><span class="pre">FILE_UPLOAD_PERMISSIONS</span></code></a> to your
needs. The new default value is <code class="docutils literal"><span class="pre">0o666</span></code> (octal) and the current umask value
is first masked out.</li>
<li>The <a class="reference internal" href="../ref/models/expressions.html#django.db.models.F" title="django.db.models.F"><code class="xref py py-class docutils literal"><span class="pre">F</span> <span class="pre">expressions</span></code></a> supported bitwise operators by
<code class="docutils literal"><span class="pre">&</span></code> and <code class="docutils literal"><span class="pre">|</span></code>. These operators are now available using <code class="docutils literal"><span class="pre">.bitand()</span></code> and
<code class="docutils literal"><span class="pre">.bitor()</span></code> instead. The removal of <code class="docutils literal"><span class="pre">&</span></code> and <code class="docutils literal"><span class="pre">|</span></code> was done to be
consistent with <a class="reference internal" href="../topics/db/queries.html#complex-lookups-with-q"><span class="std std-ref">Q() expressions</span></a> and
<code class="docutils literal"><span class="pre">QuerySet</span></code> combining where the operators are used as boolean AND and OR
operators.</li>
<li>In a <code class="docutils literal"><span class="pre">filter()</span></code> call, when <a class="reference internal" href="../ref/models/expressions.html#django.db.models.F" title="django.db.models.F"><code class="xref py py-class docutils literal"><span class="pre">F</span> <span class="pre">expressions</span></code></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 <code class="docutils literal"><span class="pre">filter()</span></code> call.</li>
<li>The <a class="reference internal" href="../ref/templates/builtins.html#std:templatetag-csrf_token"><code class="xref std std-ttag docutils literal"><span class="pre">csrf_token</span></code></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 <code class="docutils literal"><span class="pre">adminmedia</span></code>, which only contained the
deprecated template tag <code class="docutils literal"><span class="pre">{%</span> <span class="pre">admin_media_prefix</span> <span class="pre">%}</span></code>, was removed.
Attempting to load it with <code class="docutils literal"><span class="pre">{%</span> <span class="pre">load</span> <span class="pre">adminmedia</span> <span class="pre">%}</span></code> 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"><span class="doc">django.contrib.redirects</span></a> without enabling
<a class="reference internal" href="../ref/contrib/sites.html"><span class="doc">django.contrib.sites</span></a>. This isn’t allowed any
longer. If you’re using <code class="docutils literal"><span class="pre">django.contrib.redirects</span></code>, make sure
<a class="reference internal" href="../ref/settings.html#std:setting-INSTALLED_APPS"><code class="xref std std-setting docutils literal"><span class="pre">INSTALLED_APPS</span></code></a> contains <code class="docutils literal"><span class="pre">django.contrib.sites</span></code>.</li>
<li><a class="reference internal" href="../ref/forms/api.html#django.forms.BoundField.label_tag" title="django.forms.BoundField.label_tag"><code class="xref py py-meth docutils literal"><span class="pre">BoundField.label_tag</span></code></a> now
escapes its <code class="docutils literal"><span class="pre">contents</span></code> 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"><code class="xref py py-func docutils literal"><span class="pre">django.utils.safestring.mark_safe()</span></code></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"><code class="xref py py-meth docutils literal"><span class="pre">select_related()</span></code></a> now raises
<a class="reference internal" href="../ref/models/instances.html#django.db.models.Model.DoesNotExist" title="django.db.models.Model.DoesNotExist"><code class="xref py py-exc docutils literal"><span class="pre">DoesNotExist</span></code></a> instead of returning <code class="docutils literal"><span class="pre">None</span></code>.</li>
</ul>
</div>
</div>
<div class="section" id="s-features-deprecated-in-1-5">
<span id="s-deprecated-features-1-5"></span><span id="features-deprecated-in-1-5"></span><span id="deprecated-features-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><code class="docutils literal"><span class="pre">django.contrib.localflavor</span></code><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.
<code class="docutils literal"><span class="pre">django.contrib.localflavor</span></code> itself will be removed in Django 1.6, after an
<a class="reference internal" href="../topics/localflavor.html#localflavor-deprecation-policy"><span class="std std-ref">accelerated deprecation</span></a>. The docs
provide <a class="reference internal" href="../topics/localflavor.html#localflavor-how-to-migrate"><span class="std std-ref">migration instructions</span></a>.</p>
<p>The new packages are available <a class="reference internal" href="../topics/localflavor.html#localflavor-packages"><span class="std std-ref">on Github</span></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><code class="docutils literal"><span class="pre">django.contrib.markup</span></code><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><code class="docutils literal"><span class="pre">AUTH_PROFILE_MODULE</span></code><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"><span class="std std-ref">custom User models</span></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 <code class="docutils literal"><span class="pre">AUTH_PROFILE_MODULE</span></code> setting, and the
<code class="docutils literal"><span class="pre">django.contrib.auth.models.User.get_profile()</span></code> 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"><code class="xref py py-class docutils literal"><span class="pre">HttpResponse</span></code></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"><code class="xref py py-class docutils literal"><span class="pre">HttpResponse</span></code></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"><code class="xref py py-class docutils literal"><span class="pre">StreamingHttpResponse</span></code></a>. See
<a class="reference internal" href="#explicit-streaming-responses"><span class="std std-ref">Explicit support for streaming responses</span></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"><code class="xref py py-class docutils literal"><span class="pre">HttpResponse</span></code></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><code class="docutils literal"><span class="pre">django.utils.simplejson</span></code><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
<code class="xref py py-mod docutils literal"><span class="pre">json</span></code> module being available in Python’s standard library, so we’ve
removed our own copy of <code class="docutils literal"><span class="pre">simplejson</span></code>. You should now import <code class="xref py py-mod docutils literal"><span class="pre">json</span></code>
instead of <code class="docutils literal"><span class="pre">django.utils.simplejson</span></code>.</p>
<p>Unfortunately, this change might have unwanted side-effects, because of
incompatibilities between versions of <code class="docutils literal"><span class="pre">simplejson</span></code> – see the
<a class="reference internal" href="#simplejson-incompatibilities"><span class="std std-ref">backwards-incompatible changes</span></a> section.
If you rely on features added to <code class="docutils literal"><span class="pre">simplejson</span></code> after it became Python’s
<code class="xref py py-mod docutils literal"><span class="pre">json</span></code>, you should import <code class="docutils literal"><span class="pre">simplejson</span></code> explicitly.</p>
</div>
<div class="section" id="s-django-utils-encoding-strandunicode">
<span id="django-utils-encoding-strandunicode"></span><h3><code class="docutils literal"><span class="pre">django.utils.encoding.StrAndUnicode</span></code><a class="headerlink" href="#django-utils-encoding-strandunicode" title="Permalink to this headline">¶</a></h3>
<p>The <code class="docutils literal"><span class="pre">django.utils.encoding.StrAndUnicode</span></code> mix-in has been deprecated.
Define a <code class="docutils literal"><span class="pre">__str__</span></code> 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"><code class="xref py py-func docutils literal"><span class="pre">python_2_unicode_compatible()</span></code></a> decorator instead.</p>
</div>
<div class="section" id="s-django-utils-itercompat-product">
<span id="django-utils-itercompat-product"></span><h3><code class="docutils literal"><span class="pre">django.utils.itercompat.product</span></code><a class="headerlink" href="#django-utils-itercompat-product" title="Permalink to this headline">¶</a></h3>
<p>The <code class="docutils literal"><span class="pre">django.utils.itercompat.product</span></code> function has been deprecated. Use
the built-in <code class="xref py py-func docutils literal"><span class="pre">itertools.product()</span></code> instead.</p>
</div>
<div class="section" id="s-cleanup-management-command">
<span id="cleanup-management-command"></span><h3><code class="docutils literal"><span class="pre">cleanup</span></code> management command<a class="headerlink" href="#cleanup-management-command" title="Permalink to this headline">¶</a></h3>
<p>The <code class="docutils literal"><span class="pre">cleanup</span></code> management command has been deprecated and replaced by
<a class="reference internal" href="../ref/django-admin.html#django-admin-clearsessions"><code class="xref std std-djadmin docutils literal"><span class="pre">clearsessions</span></code></a>.</p>
</div>
<div class="section" id="s-daily-cleanup-py-script">
<span id="daily-cleanup-py-script"></span><h3><code class="docutils literal"><span class="pre">daily_cleanup.py</span></code> script<a class="headerlink" href="#daily-cleanup-py-script" title="Permalink to this headline">¶</a></h3>
<p>The undocumented <code class="docutils literal"><span class="pre">daily_cleanup.py</span></code> script has been deprecated. Use the
<a class="reference internal" href="../ref/django-admin.html#django-admin-clearsessions"><code class="xref std std-djadmin docutils literal"><span class="pre">clearsessions</span></code></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><code class="docutils literal"><span class="pre">depth</span></code> keyword argument in <code class="docutils literal"><span class="pre">select_related</span></code><a class="headerlink" href="#depth-keyword-argument-in-select-related" title="Permalink to this headline">¶</a></h3>
<p>The <code class="docutils literal"><span class="pre">depth</span></code> 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"><code class="xref py py-meth docutils literal"><span class="pre">select_related()</span></code></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" role="navigation" aria-label="main navigation">
<div class="sphinxsidebarwrapper">
<h3><a href="../contents.html">Table Of Contents</a></h3>
<ul>
<li><a class="reference internal" href="#">Django 1.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"><code class="docutils literal"><span class="pre">{%</span> <span class="pre">verbatim</span> <span class="pre">%}</span></code> template tag</a></li>
<li><a class="reference internal" href="#retrieval-of-contenttype-instances-associated-with-proxy-models">Retrieval of <code class="docutils literal"><span class="pre">ContentType</span></code> instances associated with proxy models</a></li>
<li><a class="reference internal" href="#new-view-variable-in-class-based-views-context">New <code class="docutils literal"><span class="pre">view</span></code> 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"><code class="docutils literal"><span class="pre">ALLOWED_HOSTS</span></code> 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"><code class="docutils literal"><span class="pre">request_finished</span></code> 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 <code class="docutils literal"><span class="pre">simplejson</span></code> 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 <code class="docutils literal"><span class="pre">django.test.TransactionTestCase</span></code></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 <code class="docutils literal"><span class="pre">syncdb</span></code> 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 <code class="docutils literal"><span class="pre">max_num</span></code></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"><code class="docutils literal"><span class="pre">django.contrib.localflavor</span></code></a></li>
<li><a class="reference internal" href="#django-contrib-markup"><code class="docutils literal"><span class="pre">django.contrib.markup</span></code></a></li>
<li><a class="reference internal" href="#auth-profile-module"><code class="docutils literal"><span class="pre">AUTH_PROFILE_MODULE</span></code></a></li>
<li><a class="reference internal" href="#streaming-behavior-of-httpresponse">Streaming behavior of <code class="docutils literal"><span class="pre">HttpResponse</span></code></a></li>
<li><a class="reference internal" href="#django-utils-simplejson"><code class="docutils literal"><span class="pre">django.utils.simplejson</span></code></a></li>
<li><a class="reference internal" href="#django-utils-encoding-strandunicode"><code class="docutils literal"><span class="pre">django.utils.encoding.StrAndUnicode</span></code></a></li>
<li><a class="reference internal" href="#django-utils-itercompat-product"><code class="docutils literal"><span class="pre">django.utils.itercompat.product</span></code></a></li>
<li><a class="reference internal" href="#cleanup-management-command"><code class="docutils literal"><span class="pre">cleanup</span></code> management command</a></li>
<li><a class="reference internal" href="#daily-cleanup-py-script"><code class="docutils literal"><span class="pre">daily_cleanup.py</span></code> script</a></li>
<li><a class="reference internal" href="#depth-keyword-argument-in-select-related"><code class="docutils literal"><span class="pre">depth</span></code> keyword argument in <code class="docutils literal"><span class="pre">select_related</span></code></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.22.html">Django 1.4.22 release notes</a></li>
</ul>
<h3>You are here:</h3>
<ul>
<li>
<a href="../index.html">Django 1.8.19 documentation</a>
<ul><li><a href="index.html">Release notes</a>
<ul><li>Django 1.5 release notes</li></ul>
</li></ul>
</li>
</ul>
<div role="note" aria-label="source link">
<h3>This Page</h3>
<ul class="this-page-menu">
<li><a href="../_sources/releases/1.5.txt"
rel="nofollow">Show Source</a></li>
</ul>
</div>
<div id="searchbox" style="display: none" role="search">
<h3>Quick search</h3>
<form class="search" action="../search.html" method="get">
<div><input type="text" name="q" /></div>
<div><input type="submit" value="Go" /></div>
<input type="hidden" name="check_keywords" value="yes" />
<input type="hidden" name="area" value="default" />
</form>
</div>
<script type="text/javascript">$('#searchbox').show(0);</script>
</div>
</div>
<h3>Last update:</h3>
<p class="topless">Mar 10, 2018</p>
</div>
</div>
<div id="ft">
<div class="nav">
« <a href="1.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.22.html" title="Django 1.4.22 release notes">next</a> »</div>
</div>
</div>
<div class="clearer"></div>
</div>
</body>
</html>
distrib
>
Mageia
>
6
>
armv7hl
>
media
>
core-updates
>
by-pkgid
>
65530c6176058f9b54858c3b4f6385e6
>
files
>
862
