<!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.7 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.6.11 release notes" href="1.6.11.html" />
<link rel="prev" title="Django 1.7.1 release notes" href="1.7.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.7.1.html" title="Django 1.7.1 release notes">previous</a>
|
<a href="index.html" title="Release notes" accesskey="U">up</a>
|
<a href="1.6.11.html" title="Django 1.6.11 release notes">next</a> »</div>
</div>
<div id="bd">
<div id="yui-main">
<div class="yui-b">
<div class="yui-g" id="releases-1.7">
<div class="section" id="s-django-1-7-release-notes">
<span id="django-1-7-release-notes"></span><h1>Django 1.7 release notes<a class="headerlink" href="#django-1-7-release-notes" title="Permalink to this headline">¶</a></h1>
<p><em>September 2, 2014</em></p>
<p>Welcome to Django 1.7!</p>
<p>These release notes cover the <a class="reference internal" href="#whats-new-1-7"><span class="std std-ref">new features</span></a>, as well as
some <a class="reference internal" href="#backwards-incompatible-1-7"><span class="std std-ref">backwards incompatible changes</span></a> you’ll
want to be aware of when upgrading from Django 1.6 or older versions. We’ve
<a class="reference internal" href="#deprecated-features-1-7"><span class="std std-ref">begun the deprecation process for some features</span></a>, and some features have reached the end of their
deprecation process and <a class="reference internal" href="#removed-features-1-7"><span class="std std-ref">have been removed</span></a>.</p>
<div class="section" id="s-python-compatibility">
<span id="python-compatibility"></span><h2>Python compatibility<a class="headerlink" href="#python-compatibility" title="Permalink to this headline">¶</a></h2>
<p>Django 1.7 requires Python 2.7, 3.2, 3.3, or 3.4. We <strong>highly recommend</strong> and
only officially support the latest release of each series.</p>
<p>The Django 1.6 series is the last to support Python 2.6. Django 1.7 is the
first release to support Python 3.4.</p>
<p>This change should affect only a small number of Django users, as most
operating-system vendors today are shipping Python 2.7 or newer as their default
version. If you’re still using Python 2.6, however, you’ll need to stick to
Django 1.6 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.6 will continue to receive
security support until the release of Django 1.8.</p>
</div>
<div class="section" id="s-what-s-new-in-django-1-7">
<span id="s-whats-new-1-7"></span><span id="what-s-new-in-django-1-7"></span><span id="whats-new-1-7"></span><h2>What’s new in Django 1.7<a class="headerlink" href="#what-s-new-in-django-1-7" title="Permalink to this headline">¶</a></h2>
<div class="section" id="s-schema-migrations">
<span id="schema-migrations"></span><h3>Schema migrations<a class="headerlink" href="#schema-migrations" title="Permalink to this headline">¶</a></h3>
<p>Django now has built-in support for schema migrations. It allows models
to be updated, changed, and deleted by creating migration files that represent
the model changes and which can be run on any development, staging or production
database.</p>
<p>Migrations are covered in <a class="reference internal" href="../topics/migrations.html"><span class="doc">their own documentation</span></a>,
but a few of the key features are:</p>
<ul>
<li><p class="first"><code class="docutils literal"><span class="pre">syncdb</span></code> has been deprecated and replaced by <code class="docutils literal"><span class="pre">migrate</span></code>. Don’t worry -
calls to <code class="docutils literal"><span class="pre">syncdb</span></code> will still work as before.</p>
</li>
<li><p class="first">A new <code class="docutils literal"><span class="pre">makemigrations</span></code> command provides an easy way to autodetect changes
to your models and make migrations for them.</p>
<p><a class="reference internal" href="../ref/signals.html#django.db.models.signals.pre_syncdb" title="django.db.models.signals.pre_syncdb"><code class="xref py py-data docutils literal"><span class="pre">pre_syncdb</span></code></a> and
<a class="reference internal" href="../ref/signals.html#django.db.models.signals.post_syncdb" title="django.db.models.signals.post_syncdb"><code class="xref py py-data docutils literal"><span class="pre">post_syncdb</span></code></a> have been deprecated,
to be replaced by <a class="reference internal" href="../ref/signals.html#django.db.models.signals.pre_migrate" title="django.db.models.signals.pre_migrate"><code class="xref py py-data docutils literal"><span class="pre">pre_migrate</span></code></a> and
<a class="reference internal" href="../ref/signals.html#django.db.models.signals.post_migrate" title="django.db.models.signals.post_migrate"><code class="xref py py-data docutils literal"><span class="pre">post_migrate</span></code></a> respectively. These
new signals have slightly different arguments. Check the
documentation for details.</p>
</li>
<li><p class="first">The <code class="docutils literal"><span class="pre">allow_syncdb</span></code> method on database routers is now called <code class="docutils literal"><span class="pre">allow_migrate</span></code>,
but still performs the same function. Routers with <code class="docutils literal"><span class="pre">allow_syncdb</span></code> methods
will still work, but that method name is deprecated and you should change
it as soon as possible (nothing more than renaming is required).</p>
</li>
<li><p class="first"><code class="docutils literal"><span class="pre">initial_data</span></code> fixtures are no longer loaded for apps with migrations; if
you want to load initial data for an app, we suggest you create a migration for
your application and define a <a class="reference internal" href="../ref/migration-operations.html#django.db.migrations.operations.RunPython" title="django.db.migrations.operations.RunPython"><code class="xref py py-class docutils literal"><span class="pre">RunPython</span></code></a>
or <a class="reference internal" href="../ref/migration-operations.html#django.db.migrations.operations.RunSQL" title="django.db.migrations.operations.RunSQL"><code class="xref py py-class docutils literal"><span class="pre">RunSQL</span></code></a> operation in the <code class="docutils literal"><span class="pre">operations</span></code> section of the migration.</p>
</li>
<li><p class="first">Test rollback behavior is different for apps with migrations; in particular,
Django will no longer emulate rollbacks on non-transactional databases or
inside <code class="docutils literal"><span class="pre">TransactionTestCase</span></code> <a class="reference internal" href="../topics/testing/overview.html#test-case-serialized-rollback"><span class="std std-ref">unless specifically requested</span></a>.</p>
</li>
<li><p class="first">It is not advised to have apps without migrations depend on (have a
<a class="reference internal" href="../ref/models/fields.html#ref-foreignkey"><span class="std std-ref">ForeignKey</span></a> or <a class="reference internal" href="../ref/models/fields.html#ref-manytomany"><span class="std std-ref">ManyToManyField</span></a> to) apps with migrations. Read the
<a class="reference internal" href="../topics/migrations.html#unmigrated-dependencies"><span class="std std-ref">dependencies documentation</span></a> for more.</p>
</li>
<li><p class="first">If you are upgrading from South, see our <a class="reference internal" href="../topics/migrations.html#upgrading-from-south"><span class="std std-ref">Upgrading from South</span></a>
documentation, and third-party app authors should read the
<a class="reference external" href="http://south.readthedocs.org/en/latest/releasenotes/1.0.html#library-migration-path">South 1.0 release notes</a>
for details on how to support South and Django migrations simultaneously.</p>
</li>
</ul>
</div>
<div class="section" id="s-app-loading-refactor">
<span id="s-app-loading-refactor-17-release-note"></span><span id="app-loading-refactor"></span><span id="app-loading-refactor-17-release-note"></span><h3>App-loading refactor<a class="headerlink" href="#app-loading-refactor" title="Permalink to this headline">¶</a></h3>
<p>Historically, Django applications were tightly linked to models. A singleton
known as the “app cache” dealt with both installed applications and models.
The models module was used as an identifier for applications in many APIs.</p>
<p>As the concept of <a class="reference internal" href="../ref/applications.html"><span class="doc">Django applications</span></a> matured, this
code showed some shortcomings. It has been refactored into an “app registry”
where models modules no longer have a central role and where it’s possible to
attach configuration data to applications.</p>
<p>Improvements thus far include:</p>
<ul class="simple">
<li>Applications can run code at startup, before Django does anything else, with
the <a class="reference internal" href="../ref/applications.html#django.apps.AppConfig.ready" title="django.apps.AppConfig.ready"><code class="xref py py-meth docutils literal"><span class="pre">ready()</span></code></a> method of their configuration.</li>
<li>Application labels are assigned correctly to models even when they’re
defined outside of <code class="docutils literal"><span class="pre">models.py</span></code>. You don’t have to set
<a class="reference internal" href="../ref/models/options.html#django.db.models.Options.app_label" title="django.db.models.Options.app_label"><code class="xref py py-attr docutils literal"><span class="pre">app_label</span></code></a> explicitly any more.</li>
<li>It is possible to omit <code class="docutils literal"><span class="pre">models.py</span></code> entirely if an application doesn’t
have any models.</li>
<li>Applications can be relabeled with the <a class="reference internal" href="../ref/applications.html#django.apps.AppConfig.label" title="django.apps.AppConfig.label"><code class="xref py py-attr docutils literal"><span class="pre">label</span></code></a>
attribute of application configurations, to work around label conflicts.</li>
<li>The name of applications can be customized in the admin with the
<a class="reference internal" href="../ref/applications.html#django.apps.AppConfig.verbose_name" title="django.apps.AppConfig.verbose_name"><code class="xref py py-attr docutils literal"><span class="pre">verbose_name</span></code></a> of application configurations.</li>
<li>The admin automatically calls <a class="reference internal" href="../ref/contrib/admin/index.html#django.contrib.admin.autodiscover" title="django.contrib.admin.autodiscover"><code class="xref py py-func docutils literal"><span class="pre">autodiscover()</span></code></a>
when Django starts. You can consequently remove this line from your
URLconf.</li>
<li>Django imports all application configurations and models as soon as it
starts, through a deterministic and straightforward process. This should
make it easier to diagnose import issues such as import loops.</li>
</ul>
</div>
<div class="section" id="s-new-method-on-field-subclasses">
<span id="new-method-on-field-subclasses"></span><h3>New method on Field subclasses<a class="headerlink" href="#new-method-on-field-subclasses" title="Permalink to this headline">¶</a></h3>
<p>To help power both schema migrations and to enable easier addition of
composite keys in future releases of Django, the
<a class="reference internal" href="../ref/models/fields.html#django.db.models.Field" title="django.db.models.Field"><code class="xref py py-class docutils literal"><span class="pre">Field</span></code></a> API now has a new required method:
<code class="docutils literal"><span class="pre">deconstruct()</span></code>.</p>
<p>This method takes no arguments, and returns a tuple of four items:</p>
<ul class="simple">
<li><code class="docutils literal"><span class="pre">name</span></code>: The field’s attribute name on its parent model, or None if it is not part of a model</li>
<li><code class="docutils literal"><span class="pre">path</span></code>: A dotted, Python path to the class of this field, including the class name.</li>
<li><code class="docutils literal"><span class="pre">args</span></code>: Positional arguments, as a list</li>
<li><code class="docutils literal"><span class="pre">kwargs</span></code>: Keyword arguments, as a dict</li>
</ul>
<p>These four values allow any field to be serialized into a file, as well as
allowing the field to be copied safely, both essential parts of these new features.</p>
<p>This change should not affect you unless you write custom Field subclasses;
if you do, you may need to reimplement the <code class="docutils literal"><span class="pre">deconstruct()</span></code> method if your
subclass changes the method signature of <code class="docutils literal"><span class="pre">__init__</span></code> in any way. If your
field just inherits from a built-in Django field and doesn’t override <code class="docutils literal"><span class="pre">__init__</span></code>,
no changes are necessary.</p>
<p>If you do need to override <code class="docutils literal"><span class="pre">deconstruct()</span></code>, a good place to start is the
built-in Django fields (<code class="docutils literal"><span class="pre">django/db/models/fields/__init__.py</span></code>) as several
fields, including <code class="docutils literal"><span class="pre">DecimalField</span></code> and <code class="docutils literal"><span class="pre">DateField</span></code>, override it and show how
to call the method on the superclass and simply add or remove extra arguments.</p>
<p>This also means that all arguments to fields must themselves be serializable;
to see what we consider serializable, and to find out how to make your own
classes serializable, read the
<a class="reference internal" href="../topics/migrations.html#migration-serializing"><span class="std std-ref">migration serialization documentation</span></a>.</p>
</div>
<div class="section" id="s-calling-custom-queryset-methods-from-the-manager">
<span id="calling-custom-queryset-methods-from-the-manager"></span><h3>Calling custom <code class="docutils literal"><span class="pre">QuerySet</span></code> methods from the <code class="docutils literal"><span class="pre">Manager</span></code><a class="headerlink" href="#calling-custom-queryset-methods-from-the-manager" title="Permalink to this headline">¶</a></h3>
<p>Historically, the recommended way to make reusable model queries was to create
methods on a custom <code class="docutils literal"><span class="pre">Manager</span></code> class. The problem with this approach was that
after the first method call, you’d get back a <code class="docutils literal"><span class="pre">QuerySet</span></code> instance and
couldn’t call additional custom manager methods.</p>
<p>Though not documented, it was common to work around this issue by creating a
custom <code class="docutils literal"><span class="pre">QuerySet</span></code> so that custom methods could be chained; but the solution
had a number of drawbacks:</p>
<ul class="simple">
<li>The custom <code class="docutils literal"><span class="pre">QuerySet</span></code> and its custom methods were lost after the first
call to <code class="docutils literal"><span class="pre">values()</span></code> or <code class="docutils literal"><span class="pre">values_list()</span></code>.</li>
<li>Writing a custom <code class="docutils literal"><span class="pre">Manager</span></code> was still necessary to return the custom
<code class="docutils literal"><span class="pre">QuerySet</span></code> class and all methods that were desired on the <code class="docutils literal"><span class="pre">Manager</span></code>
had to be proxied to the <code class="docutils literal"><span class="pre">QuerySet</span></code>. The whole process went against
the DRY principle.</li>
</ul>
<p>The <a class="reference internal" href="../ref/models/querysets.html#django.db.models.query.QuerySet.as_manager" title="django.db.models.query.QuerySet.as_manager"><code class="xref py py-meth docutils literal"><span class="pre">QuerySet.as_manager()</span></code></a>
class method can now directly <a class="reference internal" href="../topics/db/managers.html#create-manager-with-queryset-methods"><span class="std std-ref">create Manager with QuerySet methods</span></a>:</p>
<div class="highlight-default"><div class="highlight"><pre><span></span><span class="k">class</span> <span class="nc">FoodQuerySet</span><span class="p">(</span><span class="n">models</span><span class="o">.</span><span class="n">QuerySet</span><span class="p">):</span>
<span class="k">def</span> <span class="nf">pizzas</span><span class="p">(</span><span class="bp">self</span><span class="p">):</span>
<span class="k">return</span> <span class="bp">self</span><span class="o">.</span><span class="n">filter</span><span class="p">(</span><span class="n">kind</span><span class="o">=</span><span class="s1">'pizza'</span><span class="p">)</span>
<span class="k">def</span> <span class="nf">vegetarian</span><span class="p">(</span><span class="bp">self</span><span class="p">):</span>
<span class="k">return</span> <span class="bp">self</span><span class="o">.</span><span class="n">filter</span><span class="p">(</span><span class="n">vegetarian</span><span class="o">=</span><span class="kc">True</span><span class="p">)</span>
<span class="k">class</span> <span class="nc">Food</span><span class="p">(</span><span class="n">models</span><span class="o">.</span><span class="n">Model</span><span class="p">):</span>
<span class="n">kind</span> <span class="o">=</span> <span class="n">models</span><span class="o">.</span><span class="n">CharField</span><span class="p">(</span><span class="n">max_length</span><span class="o">=</span><span class="mi">50</span><span class="p">)</span>
<span class="n">vegetarian</span> <span class="o">=</span> <span class="n">models</span><span class="o">.</span><span class="n">BooleanField</span><span class="p">(</span><span class="n">default</span><span class="o">=</span><span class="kc">False</span><span class="p">)</span>
<span class="n">objects</span> <span class="o">=</span> <span class="n">FoodQuerySet</span><span class="o">.</span><span class="n">as_manager</span><span class="p">()</span>
<span class="n">Food</span><span class="o">.</span><span class="n">objects</span><span class="o">.</span><span class="n">pizzas</span><span class="p">()</span><span class="o">.</span><span class="n">vegetarian</span><span class="p">()</span>
</pre></div>
</div>
</div>
<div class="section" id="s-using-a-custom-manager-when-traversing-reverse-relations">
<span id="using-a-custom-manager-when-traversing-reverse-relations"></span><h3>Using a custom manager when traversing reverse relations<a class="headerlink" href="#using-a-custom-manager-when-traversing-reverse-relations" title="Permalink to this headline">¶</a></h3>
<p>It is now possible to <a class="reference internal" href="../topics/db/queries.html#using-custom-reverse-manager"><span class="std std-ref">specify a custom manager</span></a> when traversing a reverse relationship:</p>
<div class="highlight-default"><div class="highlight"><pre><span></span><span class="k">class</span> <span class="nc">Blog</span><span class="p">(</span><span class="n">models</span><span class="o">.</span><span class="n">Model</span><span class="p">):</span>
<span class="k">pass</span>
<span class="k">class</span> <span class="nc">Entry</span><span class="p">(</span><span class="n">models</span><span class="o">.</span><span class="n">Model</span><span class="p">):</span>
<span class="n">blog</span> <span class="o">=</span> <span class="n">models</span><span class="o">.</span><span class="n">ForeignKey</span><span class="p">(</span><span class="n">Blog</span><span class="p">)</span>
<span class="n">objects</span> <span class="o">=</span> <span class="n">models</span><span class="o">.</span><span class="n">Manager</span><span class="p">()</span> <span class="c1"># Default Manager</span>
<span class="n">entries</span> <span class="o">=</span> <span class="n">EntryManager</span><span class="p">()</span> <span class="c1"># Custom Manager</span>
<span class="n">b</span> <span class="o">=</span> <span class="n">Blog</span><span class="o">.</span><span class="n">objects</span><span class="o">.</span><span class="n">get</span><span class="p">(</span><span class="nb">id</span><span class="o">=</span><span class="mi">1</span><span class="p">)</span>
<span class="n">b</span><span class="o">.</span><span class="n">entry_set</span><span class="p">(</span><span class="n">manager</span><span class="o">=</span><span class="s1">'entries'</span><span class="p">)</span><span class="o">.</span><span class="n">all</span><span class="p">()</span>
</pre></div>
</div>
</div>
<div class="section" id="s-new-system-check-framework">
<span id="new-system-check-framework"></span><h3>New system check framework<a class="headerlink" href="#new-system-check-framework" title="Permalink to this headline">¶</a></h3>
<p>We’ve added a new <a class="reference internal" href="../ref/checks.html"><span class="doc">System check framework</span></a> for
detecting common problems (like invalid models) and providing hints for
resolving those problems. The framework is extensible so you can add your
own checks for your own apps and libraries.</p>
<p>To perform system checks, you use the <a class="reference internal" href="../ref/django-admin.html#django-admin-check"><code class="xref std std-djadmin docutils literal"><span class="pre">check</span></code></a> management command.
This command replaces the older <a class="reference internal" href="../ref/django-admin.html#django-admin-validate"><code class="xref std std-djadmin docutils literal"><span class="pre">validate</span></code></a> management command.</p>
</div>
<div class="section" id="s-new-prefetch-object-for-advanced-prefetch-related-operations">
<span id="new-prefetch-object-for-advanced-prefetch-related-operations"></span><h3>New <code class="docutils literal"><span class="pre">Prefetch</span></code> object for advanced <code class="docutils literal"><span class="pre">prefetch_related</span></code> operations.<a class="headerlink" href="#new-prefetch-object-for-advanced-prefetch-related-operations" title="Permalink to this headline">¶</a></h3>
<p>The new <a class="reference internal" href="../ref/models/querysets.html#django.db.models.Prefetch" title="django.db.models.Prefetch"><code class="xref py py-class docutils literal"><span class="pre">Prefetch</span></code></a> object allows customizing
prefetch operations.</p>
<p>You can specify the <code class="docutils literal"><span class="pre">QuerySet</span></code> used to traverse a given relation
or customize the storage location of prefetch results.</p>
<p>This enables things like filtering prefetched relations, calling
<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> from a prefetched
relation, or prefetching the same relation multiple times with different
querysets. See <a class="reference internal" href="../ref/models/querysets.html#django.db.models.query.QuerySet.prefetch_related" title="django.db.models.query.QuerySet.prefetch_related"><code class="xref py py-meth docutils literal"><span class="pre">prefetch_related()</span></code></a>
for more details.</p>
</div>
<div class="section" id="s-admin-shortcuts-support-time-zones">
<span id="admin-shortcuts-support-time-zones"></span><h3>Admin shortcuts support time zones<a class="headerlink" href="#admin-shortcuts-support-time-zones" title="Permalink to this headline">¶</a></h3>
<p>The “today” and “now” shortcuts next to date and time input widgets in the
admin are now operating in the <a class="reference internal" href="../topics/i18n/timezones.html#default-current-time-zone"><span class="std std-ref">current time zone</span></a>. Previously, they used the browser time zone,
which could result in saving the wrong value when it didn’t match the current
time zone on the server.</p>
<p>In addition, the widgets now display a help message when the browser and
server time zone are different, to clarify how the value inserted in the field
will be interpreted.</p>
</div>
<div class="section" id="s-using-database-cursors-as-context-managers">
<span id="using-database-cursors-as-context-managers"></span><h3>Using database cursors as context managers<a class="headerlink" href="#using-database-cursors-as-context-managers" title="Permalink to this headline">¶</a></h3>
<p>Prior to Python 2.7, database cursors could be used as a context manager. The
specific backend’s cursor defined the behavior of the context manager. The
behavior of magic method lookups was changed with Python 2.7 and cursors were
no longer usable as context managers.</p>
<p>Django 1.7 allows a cursor to be used as a context manager. That is,
the following can be used:</p>
<div class="highlight-default"><div class="highlight"><pre><span></span><span class="k">with</span> <span class="n">connection</span><span class="o">.</span><span class="n">cursor</span><span class="p">()</span> <span class="k">as</span> <span class="n">c</span><span class="p">:</span>
<span class="n">c</span><span class="o">.</span><span class="n">execute</span><span class="p">(</span><span class="o">...</span><span class="p">)</span>
</pre></div>
</div>
<p>instead of:</p>
<div class="highlight-default"><div class="highlight"><pre><span></span><span class="n">c</span> <span class="o">=</span> <span class="n">connection</span><span class="o">.</span><span class="n">cursor</span><span class="p">()</span>
<span class="k">try</span><span class="p">:</span>
<span class="n">c</span><span class="o">.</span><span class="n">execute</span><span class="p">(</span><span class="o">...</span><span class="p">)</span>
<span class="k">finally</span><span class="p">:</span>
<span class="n">c</span><span class="o">.</span><span class="n">close</span><span class="p">()</span>
</pre></div>
</div>
</div>
<div class="section" id="s-custom-lookups">
<span id="custom-lookups"></span><h3>Custom lookups<a class="headerlink" href="#custom-lookups" title="Permalink to this headline">¶</a></h3>
<p>It is now possible to write custom lookups and transforms for the ORM.
Custom lookups work just like Django’s built-in lookups (e.g. <code class="docutils literal"><span class="pre">lte</span></code>,
<code class="docutils literal"><span class="pre">icontains</span></code>) while transforms are a new concept.</p>
<p>The <a class="reference internal" href="../ref/models/lookups.html#django.db.models.Lookup" title="django.db.models.Lookup"><code class="xref py py-class docutils literal"><span class="pre">django.db.models.Lookup</span></code></a> class provides a way to add lookup
operators for model fields. As an example it is possible to add <code class="docutils literal"><span class="pre">day_lte</span></code>
operator for <code class="docutils literal"><span class="pre">DateFields</span></code>.</p>
<p>The <a class="reference internal" href="../ref/models/lookups.html#django.db.models.Transform" title="django.db.models.Transform"><code class="xref py py-class docutils literal"><span class="pre">django.db.models.Transform</span></code></a> class allows transformations of
database values prior to the final lookup. For example it is possible to
write a <code class="docutils literal"><span class="pre">year</span></code> transform that extracts year from the field’s value.
Transforms allow for chaining. After the <code class="docutils literal"><span class="pre">year</span></code> transform has been added
to <code class="docutils literal"><span class="pre">DateField</span></code> it is possible to filter on the transformed value, for
example <code class="docutils literal"><span class="pre">qs.filter(author__birthdate__year__lte=1981)</span></code>.</p>
<p>For more information about both custom lookups and transforms refer to
the <a class="reference internal" href="../howto/custom-lookups.html"><span class="doc">custom lookups</span></a> documentation.</p>
</div>
<div class="section" id="s-improvements-to-form-error-handling">
<span id="improvements-to-form-error-handling"></span><h3>Improvements to <code class="docutils literal"><span class="pre">Form</span></code> error handling<a class="headerlink" href="#improvements-to-form-error-handling" title="Permalink to this headline">¶</a></h3>
<div class="section" id="s-form-add-error">
<span id="form-add-error"></span><h4><code class="docutils literal"><span class="pre">Form.add_error()</span></code><a class="headerlink" href="#form-add-error" title="Permalink to this headline">¶</a></h4>
<p>Previously there were two main patterns for handling errors in forms:</p>
<ul class="simple">
<li>Raising a <a class="reference internal" href="../ref/exceptions.html#django.core.exceptions.ValidationError" title="django.core.exceptions.ValidationError"><code class="xref py py-exc docutils literal"><span class="pre">ValidationError</span></code></a> from within certain
functions (e.g. <code class="docutils literal"><span class="pre">Field.clean()</span></code>, <code class="docutils literal"><span class="pre">Form.clean_<fieldname>()</span></code>, or
<code class="docutils literal"><span class="pre">Form.clean()</span></code> for non-field errors.)</li>
<li>Fiddling with <code class="docutils literal"><span class="pre">Form._errors</span></code> when targeting a specific field in
<code class="docutils literal"><span class="pre">Form.clean()</span></code> or adding errors from outside of a “clean” method
(e.g. directly from a view).</li>
</ul>
<p>Using the former pattern was straightforward since the form can guess from the
context (i.e. which method raised the exception) where the errors belong and
automatically process them. This remains the canonical way of adding errors
when possible. However the latter was fiddly and error-prone, since the burden
of handling edge cases fell on the user.</p>
<p>The new <a class="reference internal" href="../ref/forms/api.html#django.forms.Form.add_error" title="django.forms.Form.add_error"><code class="xref py py-meth docutils literal"><span class="pre">add_error()</span></code></a> method allows adding errors
to specific form fields from anywhere without having to worry about the details
such as creating instances of <code class="docutils literal"><span class="pre">django.forms.utils.ErrorList</span></code> or dealing with
<code class="docutils literal"><span class="pre">Form.cleaned_data</span></code>. This new API replaces manipulating <code class="docutils literal"><span class="pre">Form._errors</span></code>
which now becomes a private API.</p>
<p>See <a class="reference internal" href="../ref/forms/validation.html#validating-fields-with-clean"><span class="std std-ref">Cleaning and validating fields that depend on each other</span></a> for an example using
<code class="docutils literal"><span class="pre">Form.add_error()</span></code>.</p>
</div>
<div class="section" id="s-error-metadata">
<span id="error-metadata"></span><h4>Error metadata<a class="headerlink" href="#error-metadata" title="Permalink to this headline">¶</a></h4>
<p>The <a class="reference internal" href="../ref/exceptions.html#django.core.exceptions.ValidationError" title="django.core.exceptions.ValidationError"><code class="xref py py-exc docutils literal"><span class="pre">ValidationError</span></code></a> constructor accepts metadata
such as error <code class="docutils literal"><span class="pre">code</span></code> or <code class="docutils literal"><span class="pre">params</span></code> which are then available for interpolating
into the error message (see <a class="reference internal" href="../ref/forms/validation.html#raising-validation-error"><span class="std std-ref">Raising ValidationError</span></a> for more details);
however, before Django 1.7 those metadata were discarded as soon as the errors
were added to <a class="reference internal" href="../ref/forms/api.html#django.forms.Form.errors" title="django.forms.Form.errors"><code class="xref py py-attr docutils literal"><span class="pre">Form.errors</span></code></a>.</p>
<p><a class="reference internal" href="../ref/forms/api.html#django.forms.Form.errors" title="django.forms.Form.errors"><code class="xref py py-attr docutils literal"><span class="pre">Form.errors</span></code></a> and
<code class="docutils literal"><span class="pre">django.forms.utils.ErrorList</span></code> now store the <code class="docutils literal"><span class="pre">ValidationError</span></code> instances
so these metadata can be retrieved at any time through the new
<a class="reference internal" href="../ref/forms/api.html#django.forms.Form.errors.as_data" title="django.forms.Form.errors.as_data"><code class="xref py py-meth docutils literal"><span class="pre">Form.errors.as_data</span></code></a> method.</p>
<p>The retrieved <code class="docutils literal"><span class="pre">ValidationError</span></code> instances can then be identified thanks to
their error <code class="docutils literal"><span class="pre">code</span></code> which enables things like rewriting the error’s message
or writing custom logic in a view when a given error is present. It can also
be used to serialize the errors in a custom format such as XML.</p>
<p>The new <a class="reference internal" href="../ref/forms/api.html#django.forms.Form.errors.as_json" title="django.forms.Form.errors.as_json"><code class="xref py py-meth docutils literal"><span class="pre">Form.errors.as_json()</span></code></a>
method is a convenience method which returns error messages along with error
codes serialized as JSON. <code class="docutils literal"><span class="pre">as_json()</span></code> uses <code class="docutils literal"><span class="pre">as_data()</span></code> and gives an idea
of how the new system could be extended.</p>
</div>
<div class="section" id="s-error-containers-and-backward-compatibility">
<span id="error-containers-and-backward-compatibility"></span><h4>Error containers and backward compatibility<a class="headerlink" href="#error-containers-and-backward-compatibility" title="Permalink to this headline">¶</a></h4>
<p>Heavy changes to the various error containers were necessary in order
to support the features above, specifically
<a class="reference internal" href="../ref/forms/api.html#django.forms.Form.errors" title="django.forms.Form.errors"><code class="xref py py-attr docutils literal"><span class="pre">Form.errors</span></code></a>,
<code class="docutils literal"><span class="pre">django.forms.utils.ErrorList</span></code>, and the internal storages of
<a class="reference internal" href="../ref/exceptions.html#django.core.exceptions.ValidationError" title="django.core.exceptions.ValidationError"><code class="xref py py-exc docutils literal"><span class="pre">ValidationError</span></code></a>. These containers which used
to store error strings now store <code class="docutils literal"><span class="pre">ValidationError</span></code> instances and public APIs
have been adapted to make this as transparent as possible, but if you’ve been
using private APIs, some of the changes are backwards incompatible; see
<a class="reference internal" href="#validation-error-constructor-and-internal-storage"><span class="std std-ref">ValidationError constructor and internal storage</span></a> for more details.</p>
</div>
</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>
<div class="section" id="s-django-contrib-admin">
<span id="django-contrib-admin"></span><h4><a class="reference internal" href="../ref/contrib/admin/index.html#module-django.contrib.admin" title="django.contrib.admin: Django's admin site."><code class="xref py py-mod docutils literal"><span class="pre">django.contrib.admin</span></code></a><a class="headerlink" href="#django-contrib-admin" title="Permalink to this headline">¶</a></h4>
<ul class="simple">
<li>You can now implement <a class="reference internal" href="../ref/contrib/admin/index.html#django.contrib.admin.AdminSite.site_header" title="django.contrib.admin.AdminSite.site_header"><code class="xref py py-attr docutils literal"><span class="pre">site_header</span></code></a>,
<a class="reference internal" href="../ref/contrib/admin/index.html#django.contrib.admin.AdminSite.site_title" title="django.contrib.admin.AdminSite.site_title"><code class="xref py py-attr docutils literal"><span class="pre">site_title</span></code></a>, and
<a class="reference internal" href="../ref/contrib/admin/index.html#django.contrib.admin.AdminSite.index_title" title="django.contrib.admin.AdminSite.index_title"><code class="xref py py-attr docutils literal"><span class="pre">index_title</span></code></a> attributes on a custom
<a class="reference internal" href="../ref/contrib/admin/index.html#django.contrib.admin.AdminSite" title="django.contrib.admin.AdminSite"><code class="xref py py-class docutils literal"><span class="pre">AdminSite</span></code></a> in order to easily change the admin
site’s page title and header text. No more needing to override templates!</li>
<li>Buttons in <a class="reference internal" href="../ref/contrib/admin/index.html#module-django.contrib.admin" title="django.contrib.admin: Django's admin site."><code class="xref py py-mod docutils literal"><span class="pre">django.contrib.admin</span></code></a> now use the <code class="docutils literal"><span class="pre">border-radius</span></code> CSS
property for rounded corners rather than GIF background images.</li>
<li>Some admin templates now have <code class="docutils literal"><span class="pre">app-<app_name></span></code> and <code class="docutils literal"><span class="pre">model-<model_name></span></code>
classes in their <code class="docutils literal"><span class="pre"><body></span></code> tag to allow customizing the CSS per app or per
model.</li>
<li>The admin changelist cells now have a <code class="docutils literal"><span class="pre">field-<field_name></span></code> class in the
HTML to enable style customizations.</li>
<li>The admin’s search fields 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_search_fields" title="django.contrib.admin.ModelAdmin.get_search_fields"><code class="xref py py-meth docutils literal"><span class="pre">django.contrib.admin.ModelAdmin.get_search_fields()</span></code></a> method.</li>
<li>The <a class="reference internal" href="../ref/contrib/admin/index.html#django.contrib.admin.ModelAdmin.get_fields" title="django.contrib.admin.ModelAdmin.get_fields"><code class="xref py py-meth docutils literal"><span class="pre">ModelAdmin.get_fields()</span></code></a> method may be overridden to
customize the value of <a class="reference internal" href="../ref/contrib/admin/index.html#django.contrib.admin.ModelAdmin.fields" title="django.contrib.admin.ModelAdmin.fields"><code class="xref py py-attr docutils literal"><span class="pre">ModelAdmin.fields</span></code></a>.</li>
<li>In addition to the existing <code class="docutils literal"><span class="pre">admin.site.register</span></code> syntax, you can use the
new <a class="reference internal" href="../ref/contrib/admin/index.html#django.contrib.admin.register" title="django.contrib.admin.register"><code class="xref py py-func docutils literal"><span class="pre">register()</span></code></a> decorator to register a
<a class="reference internal" href="../ref/contrib/admin/index.html#django.contrib.admin.ModelAdmin" title="django.contrib.admin.ModelAdmin"><code class="xref py py-class docutils literal"><span class="pre">ModelAdmin</span></code></a>.</li>
<li>You may specify <a class="reference internal" href="../ref/contrib/admin/index.html#django.contrib.admin.ModelAdmin.list_display_links" title="django.contrib.admin.ModelAdmin.list_display_links"><code class="xref py py-meth docutils literal"><span class="pre">ModelAdmin.list_display_links</span></code></a> <code class="docutils literal"><span class="pre">=</span> <span class="pre">None</span></code> to disable
links on the change list page grid.</li>
<li>You may now specify <a class="reference internal" href="../ref/contrib/admin/index.html#django.contrib.admin.ModelAdmin.view_on_site" title="django.contrib.admin.ModelAdmin.view_on_site"><code class="xref py py-attr docutils literal"><span class="pre">ModelAdmin.view_on_site</span></code></a> to control whether or not to
display the “View on site” link.</li>
<li>You can specify a descending ordering for a <a class="reference internal" href="../ref/contrib/admin/index.html#django.contrib.admin.ModelAdmin.list_display" title="django.contrib.admin.ModelAdmin.list_display"><code class="xref py py-attr docutils literal"><span class="pre">ModelAdmin.list_display</span></code></a> value by prefixing the
<code class="docutils literal"><span class="pre">admin_order_field</span></code> value with a hyphen.</li>
<li>The <a class="reference internal" href="../ref/contrib/admin/index.html#django.contrib.admin.ModelAdmin.get_changeform_initial_data" title="django.contrib.admin.ModelAdmin.get_changeform_initial_data"><code class="xref py py-meth docutils literal"><span class="pre">ModelAdmin.get_changeform_initial_data()</span></code></a> method may be
overridden to define custom behavior for setting initial change form data.</li>
</ul>
</div>
<div class="section" id="s-django-contrib-auth">
<span id="django-contrib-auth"></span><h4><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><a class="headerlink" href="#django-contrib-auth" title="Permalink to this headline">¶</a></h4>
<ul class="simple">
<li>Any <code class="docutils literal"><span class="pre">**kwargs</span></code> passed to
<a class="reference internal" href="../ref/contrib/auth.html#django.contrib.auth.models.User.email_user" title="django.contrib.auth.models.User.email_user"><code class="xref py py-meth docutils literal"><span class="pre">email_user()</span></code></a> are passed to the
underlying <a class="reference internal" href="../topics/email.html#django.core.mail.send_mail" title="django.core.mail.send_mail"><code class="xref py py-meth docutils literal"><span class="pre">send_mail()</span></code></a> call.</li>
<li>The <a class="reference internal" href="../topics/auth/default.html#django.contrib.auth.decorators.permission_required" title="django.contrib.auth.decorators.permission_required"><code class="xref py py-func docutils literal"><span class="pre">permission_required()</span></code></a> decorator can
take a list of permissions as well as a single permission.</li>
<li>You can override the new <a class="reference internal" href="../topics/auth/default.html#django.contrib.auth.forms.AuthenticationForm.confirm_login_allowed" title="django.contrib.auth.forms.AuthenticationForm.confirm_login_allowed"><code class="xref py py-meth docutils literal"><span class="pre">AuthenticationForm.confirm_login_allowed()</span></code></a> method
to more easily customize the login policy.</li>
<li><a class="reference internal" href="../topics/auth/default.html#django.contrib.auth.views.password_reset" title="django.contrib.auth.views.password_reset"><code class="xref py py-func docutils literal"><span class="pre">django.contrib.auth.views.password_reset()</span></code></a> takes an optional
<code class="docutils literal"><span class="pre">html_email_template_name</span></code> parameter used to send a multipart HTML email
for password resets.</li>
<li>The <a class="reference internal" href="../topics/auth/customizing.html#django.contrib.auth.models.AbstractBaseUser.get_session_auth_hash" title="django.contrib.auth.models.AbstractBaseUser.get_session_auth_hash"><code class="xref py py-meth docutils literal"><span class="pre">AbstractBaseUser.get_session_auth_hash()</span></code></a>
method was added and if your <a class="reference internal" href="../ref/settings.html#std:setting-AUTH_USER_MODEL"><code class="xref std std-setting docutils literal"><span class="pre">AUTH_USER_MODEL</span></code></a> inherits from
<a class="reference internal" href="../topics/auth/customizing.html#django.contrib.auth.models.AbstractBaseUser" title="django.contrib.auth.models.AbstractBaseUser"><code class="xref py py-class docutils literal"><span class="pre">AbstractBaseUser</span></code></a>, changing a user’s
password now invalidates old sessions if the
<a class="reference internal" href="../ref/middleware.html#django.contrib.auth.middleware.SessionAuthenticationMiddleware" title="django.contrib.auth.middleware.SessionAuthenticationMiddleware"><code class="xref py py-class docutils literal"><span class="pre">SessionAuthenticationMiddleware</span></code></a> is
enabled. See <a class="reference internal" href="../topics/auth/default.html#session-invalidation-on-password-change"><span class="std std-ref">Session invalidation on password change</span></a> for more details
including upgrade considerations when enabling this new middleware.</li>
</ul>
</div>
<div class="section" id="s-django-contrib-formtools">
<span id="django-contrib-formtools"></span><h4><code class="docutils literal"><span class="pre">django.contrib.formtools</span></code><a class="headerlink" href="#django-contrib-formtools" title="Permalink to this headline">¶</a></h4>
<ul class="simple">
<li>Calls to <code class="xref py py-meth docutils literal"><span class="pre">WizardView.done()</span></code> now include a
<code class="docutils literal"><span class="pre">form_dict</span></code> to allow easier access to forms by their step name.</li>
</ul>
</div>
<div class="section" id="s-django-contrib-gis">
<span id="django-contrib-gis"></span><h4><a class="reference internal" href="../ref/contrib/gis/index.html#module-django.contrib.gis" title="django.contrib.gis: Geographic Information System (GIS) extensions for Django"><code class="xref py py-mod docutils literal"><span class="pre">django.contrib.gis</span></code></a><a class="headerlink" href="#django-contrib-gis" title="Permalink to this headline">¶</a></h4>
<ul class="simple">
<li>The default OpenLayers library version included in widgets has been updated
from 2.11 to 2.13.</li>
<li>Prepared geometries now also support the <code class="docutils literal"><span class="pre">crosses</span></code>, <code class="docutils literal"><span class="pre">disjoint</span></code>,
<code class="docutils literal"><span class="pre">overlaps</span></code>, <code class="docutils literal"><span class="pre">touches</span></code> and <code class="docutils literal"><span class="pre">within</span></code> predicates, if GEOS 3.3 or later is
installed.</li>
</ul>
</div>
<div class="section" id="s-django-contrib-messages">
<span id="django-contrib-messages"></span><h4><a class="reference internal" href="../ref/contrib/messages.html#module-django.contrib.messages" title="django.contrib.messages: Provides cookie- and session-based temporary message storage."><code class="xref py py-mod docutils literal"><span class="pre">django.contrib.messages</span></code></a><a class="headerlink" href="#django-contrib-messages" title="Permalink to this headline">¶</a></h4>
<ul class="simple">
<li>The backends for <a class="reference internal" href="../ref/contrib/messages.html#module-django.contrib.messages" title="django.contrib.messages: Provides cookie- and session-based temporary message storage."><code class="xref py py-mod docutils literal"><span class="pre">django.contrib.messages</span></code></a> that use cookies, will now
follow the <a class="reference internal" href="../ref/settings.html#std:setting-SESSION_COOKIE_SECURE"><code class="xref std std-setting docutils literal"><span class="pre">SESSION_COOKIE_SECURE</span></code></a> and
<a class="reference internal" href="../ref/settings.html#std:setting-SESSION_COOKIE_HTTPONLY"><code class="xref std std-setting docutils literal"><span class="pre">SESSION_COOKIE_HTTPONLY</span></code></a> settings.</li>
<li>The <a class="reference internal" href="../ref/contrib/messages.html#message-displaying"><span class="std std-ref">messages context processor</span></a> now adds a
dictionary of default levels under the name <code class="docutils literal"><span class="pre">DEFAULT_MESSAGE_LEVELS</span></code>.</li>
<li><a class="reference internal" href="../ref/contrib/messages.html#django.contrib.messages.storage.base.Message" title="django.contrib.messages.storage.base.Message"><code class="xref py py-class docutils literal"><span class="pre">Message</span></code></a> objects now have a
<code class="docutils literal"><span class="pre">level_tag</span></code> attribute that contains the string representation of the
message level.</li>
</ul>
</div>
<div class="section" id="s-django-contrib-redirects">
<span id="django-contrib-redirects"></span><h4><a class="reference internal" href="../ref/contrib/redirects.html#module-django.contrib.redirects" title="django.contrib.redirects: A framework for managing redirects."><code class="xref py py-mod docutils literal"><span class="pre">django.contrib.redirects</span></code></a><a class="headerlink" href="#django-contrib-redirects" title="Permalink to this headline">¶</a></h4>
<ul class="simple">
<li><a class="reference internal" href="../ref/contrib/redirects.html#django.contrib.redirects.middleware.RedirectFallbackMiddleware" title="django.contrib.redirects.middleware.RedirectFallbackMiddleware"><code class="xref py py-class docutils literal"><span class="pre">RedirectFallbackMiddleware</span></code></a>
has two new attributes
(<a class="reference internal" href="../ref/contrib/redirects.html#django.contrib.redirects.middleware.RedirectFallbackMiddleware.response_gone_class" title="django.contrib.redirects.middleware.RedirectFallbackMiddleware.response_gone_class"><code class="xref py py-attr docutils literal"><span class="pre">response_gone_class</span></code></a>
and
<a class="reference internal" href="../ref/contrib/redirects.html#django.contrib.redirects.middleware.RedirectFallbackMiddleware.response_redirect_class" title="django.contrib.redirects.middleware.RedirectFallbackMiddleware.response_redirect_class"><code class="xref py py-attr docutils literal"><span class="pre">response_redirect_class</span></code></a>)
that specify the types 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> instances the
middleware returns.</li>
</ul>
</div>
<div class="section" id="s-django-contrib-sessions">
<span id="django-contrib-sessions"></span><h4><a class="reference internal" href="../topics/http/sessions.html#module-django.contrib.sessions" title="django.contrib.sessions: Provides session management for Django projects."><code class="xref py py-mod docutils literal"><span class="pre">django.contrib.sessions</span></code></a><a class="headerlink" href="#django-contrib-sessions" title="Permalink to this headline">¶</a></h4>
<ul class="simple">
<li>The <code class="docutils literal"><span class="pre">"django.contrib.sessions.backends.cached_db"</span></code> session backend now
respects <a class="reference internal" href="../ref/settings.html#std:setting-SESSION_CACHE_ALIAS"><code class="xref std std-setting docutils literal"><span class="pre">SESSION_CACHE_ALIAS</span></code></a>. In previous versions, it always used
the <cite>default</cite> cache.</li>
</ul>
</div>
<div class="section" id="s-django-contrib-sitemaps">
<span id="django-contrib-sitemaps"></span><h4><a class="reference internal" href="../ref/contrib/sitemaps.html#module-django.contrib.sitemaps" title="django.contrib.sitemaps: A framework for generating Google sitemap XML files."><code class="xref py py-mod docutils literal"><span class="pre">django.contrib.sitemaps</span></code></a><a class="headerlink" href="#django-contrib-sitemaps" title="Permalink to this headline">¶</a></h4>
<ul class="simple">
<li>The <a class="reference internal" href="../ref/contrib/sitemaps.html#module-django.contrib.sitemaps" title="django.contrib.sitemaps: A framework for generating Google sitemap XML files."><code class="xref py py-mod docutils literal"><span class="pre">sitemap</span> <span class="pre">framework</span></code></a> now makes use of
<a class="reference internal" href="../ref/contrib/sitemaps.html#django.contrib.sitemaps.Sitemap.lastmod" title="django.contrib.sitemaps.Sitemap.lastmod"><code class="xref py py-attr docutils literal"><span class="pre">lastmod</span></code></a> to set a <code class="docutils literal"><span class="pre">Last-Modified</span></code>
header in the response. This makes it possible for the
<a class="reference internal" href="../ref/middleware.html#django.middleware.http.ConditionalGetMiddleware" title="django.middleware.http.ConditionalGetMiddleware"><code class="xref py py-class docutils literal"><span class="pre">ConditionalGetMiddleware</span></code></a> to handle
conditional <code class="docutils literal"><span class="pre">GET</span></code> requests for sitemaps which set <code class="docutils literal"><span class="pre">lastmod</span></code>.</li>
</ul>
</div>
<div class="section" id="s-django-contrib-sites">
<span id="django-contrib-sites"></span><h4><a class="reference internal" href="../ref/contrib/sites.html#module-django.contrib.sites" title="django.contrib.sites: Lets you operate multiple Web sites from the same database and Django project"><code class="xref py py-mod docutils literal"><span class="pre">django.contrib.sites</span></code></a><a class="headerlink" href="#django-contrib-sites" title="Permalink to this headline">¶</a></h4>
<ul class="simple">
<li>The new <a class="reference internal" href="../ref/middleware.html#django.contrib.sites.middleware.CurrentSiteMiddleware" title="django.contrib.sites.middleware.CurrentSiteMiddleware"><code class="xref py py-class docutils literal"><span class="pre">django.contrib.sites.middleware.CurrentSiteMiddleware</span></code></a> allows
setting the current site on each request.</li>
</ul>
</div>
<div class="section" id="s-django-contrib-staticfiles">
<span id="django-contrib-staticfiles"></span><h4><a class="reference internal" href="../ref/contrib/staticfiles.html#module-django.contrib.staticfiles" title="django.contrib.staticfiles: An app for handling static files."><code class="xref py py-mod docutils literal"><span class="pre">django.contrib.staticfiles</span></code></a><a class="headerlink" href="#django-contrib-staticfiles" title="Permalink to this headline">¶</a></h4>
<ul>
<li><p class="first">The <a class="reference internal" href="../ref/contrib/staticfiles.html#staticfiles-storages"><span class="std std-ref">static files storage classes</span></a> may be
subclassed to override the permissions that collected static files and
directories receive by setting the
<a class="reference internal" href="../ref/files/storage.html#django.core.files.storage.FileSystemStorage.file_permissions_mode" title="django.core.files.storage.FileSystemStorage.file_permissions_mode"><code class="xref py py-attr docutils literal"><span class="pre">file_permissions_mode</span></code></a>
and <a class="reference internal" href="../ref/files/storage.html#django.core.files.storage.FileSystemStorage.directory_permissions_mode" title="django.core.files.storage.FileSystemStorage.directory_permissions_mode"><code class="xref py py-attr docutils literal"><span class="pre">directory_permissions_mode</span></code></a>
parameters. See <a class="reference internal" href="../ref/contrib/staticfiles.html#django-admin-collectstatic"><code class="xref std std-djadmin docutils literal"><span class="pre">collectstatic</span></code></a> for example usage.</p>
</li>
<li><p class="first">The <a class="reference internal" href="../ref/contrib/staticfiles.html#django.contrib.staticfiles.storage.CachedStaticFilesStorage" title="django.contrib.staticfiles.storage.CachedStaticFilesStorage"><code class="xref py py-class docutils literal"><span class="pre">CachedStaticFilesStorage</span></code></a>
backend gets a sibling class called
<a class="reference internal" href="../ref/contrib/staticfiles.html#django.contrib.staticfiles.storage.ManifestStaticFilesStorage" title="django.contrib.staticfiles.storage.ManifestStaticFilesStorage"><code class="xref py py-class docutils literal"><span class="pre">ManifestStaticFilesStorage</span></code></a>
that doesn’t use the cache system at all but instead a JSON file called
<code class="docutils literal"><span class="pre">staticfiles.json</span></code> for storing the mapping between the original file name
(e.g. <code class="docutils literal"><span class="pre">css/styles.css</span></code>) and the hashed file name (e.g.
<code class="docutils literal"><span class="pre">css/styles.55e7cbb9ba48.css</span></code>). The <code class="docutils literal"><span class="pre">staticfiles.json</span></code> file is created
when running the <a class="reference internal" href="../ref/contrib/staticfiles.html#django-admin-collectstatic"><code class="xref std std-djadmin docutils literal"><span class="pre">collectstatic</span></code></a> management command and should
be a less expensive alternative for remote storages such as Amazon S3.</p>
<p>See the <a class="reference internal" href="../ref/contrib/staticfiles.html#django.contrib.staticfiles.storage.ManifestStaticFilesStorage" title="django.contrib.staticfiles.storage.ManifestStaticFilesStorage"><code class="xref py py-class docutils literal"><span class="pre">ManifestStaticFilesStorage</span></code></a>
docs for more information.</p>
</li>
<li><p class="first"><a class="reference internal" href="../ref/contrib/staticfiles.html#django-admin-findstatic"><code class="xref std std-djadmin docutils literal"><span class="pre">findstatic</span></code></a> now accepts verbosity flag level 2, meaning it will
show the relative paths of the directories it searched. See
<a class="reference internal" href="../ref/contrib/staticfiles.html#django-admin-findstatic"><code class="xref std std-djadmin docutils literal"><span class="pre">findstatic</span></code></a> for example output.</p>
</li>
</ul>
</div>
<div class="section" id="s-django-contrib-syndication">
<span id="django-contrib-syndication"></span><h4><a class="reference internal" href="../ref/contrib/syndication.html#module-django.contrib.syndication" title="django.contrib.syndication: A framework for generating syndication feeds, in RSS and Atom, quite easily."><code class="xref py py-mod docutils literal"><span class="pre">django.contrib.syndication</span></code></a><a class="headerlink" href="#django-contrib-syndication" title="Permalink to this headline">¶</a></h4>
<ul class="simple">
<li>The <a class="reference internal" href="../ref/utils.html#django.utils.feedgenerator.Atom1Feed" title="django.utils.feedgenerator.Atom1Feed"><code class="xref py py-class docutils literal"><span class="pre">Atom1Feed</span></code></a> syndication feed’s
<code class="docutils literal"><span class="pre">updated</span></code> element now utilizes <code class="docutils literal"><span class="pre">updateddate</span></code> instead of <code class="docutils literal"><span class="pre">pubdate</span></code>,
allowing the <code class="docutils literal"><span class="pre">published</span></code> element to be included in the feed (which
relies on <code class="docutils literal"><span class="pre">pubdate</span></code>).</li>
</ul>
</div>
<div class="section" id="s-cache">
<span id="cache"></span><h4>Cache<a class="headerlink" href="#cache" title="Permalink to this headline">¶</a></h4>
<ul class="simple">
<li>Access to caches configured in <a class="reference internal" href="../ref/settings.html#std:setting-CACHES"><code class="xref std std-setting docutils literal"><span class="pre">CACHES</span></code></a> is now available via
<a class="reference internal" href="../topics/cache.html#django.core.cache.caches" title="django.core.cache.caches"><code class="xref py py-data docutils literal"><span class="pre">django.core.cache.caches</span></code></a>. This dict-like object provides a different
instance per thread. It supersedes <a class="reference internal" href="../topics/cache.html#django.core.cache.get_cache" title="django.core.cache.get_cache"><code class="xref py py-func docutils literal"><span class="pre">django.core.cache.get_cache()</span></code></a> which
is now deprecated.</li>
<li>If you instantiate cache backends directly, be aware that they aren’t
thread-safe any more, as <a class="reference internal" href="../topics/cache.html#django.core.cache.caches" title="django.core.cache.caches"><code class="xref py py-data docutils literal"><span class="pre">django.core.cache.caches</span></code></a> now yields
different instances per thread.</li>
<li>Defining the <a class="reference internal" href="../ref/settings.html#std:setting-CACHES-TIMEOUT"><code class="xref std std-setting docutils literal"><span class="pre">TIMEOUT</span></code></a> argument of the
<a class="reference internal" href="../ref/settings.html#std:setting-CACHES"><code class="xref std std-setting docutils literal"><span class="pre">CACHES</span></code></a> setting as <code class="docutils literal"><span class="pre">None</span></code> will set the cache keys as
“non-expiring” by default. Previously, it was only possible to pass
<code class="docutils literal"><span class="pre">timeout=None</span></code> to the cache backend’s <code class="docutils literal"><span class="pre">set()</span></code> method.</li>
</ul>
</div>
<div class="section" id="s-cross-site-request-forgery">
<span id="cross-site-request-forgery"></span><h4>Cross Site Request Forgery<a class="headerlink" href="#cross-site-request-forgery" title="Permalink to this headline">¶</a></h4>
<ul class="simple">
<li>The <a class="reference internal" href="../ref/settings.html#std:setting-CSRF_COOKIE_AGE"><code class="xref std std-setting docutils literal"><span class="pre">CSRF_COOKIE_AGE</span></code></a> setting facilitates the use of session-based
CSRF cookies.</li>
</ul>
</div>
<div class="section" id="s-email">
<span id="email"></span><h4>Email<a class="headerlink" href="#email" title="Permalink to this headline">¶</a></h4>
<ul class="simple">
<li><a class="reference internal" href="../topics/email.html#django.core.mail.send_mail" title="django.core.mail.send_mail"><code class="xref py py-func docutils literal"><span class="pre">send_mail()</span></code></a> now accepts an <code class="docutils literal"><span class="pre">html_message</span></code>
parameter for sending a multipart <code class="docutils literal"><span class="pre">text/plain</span></code> and <code class="docutils literal"><span class="pre">text/html</span></code> email.</li>
<li>The SMTP <a class="reference internal" href="../topics/email.html#django.core.mail.backends.smtp.EmailBackend" title="django.core.mail.backends.smtp.EmailBackend"><code class="xref py py-class docutils literal"><span class="pre">EmailBackend</span></code></a> now accepts a
<code class="docutils literal"><span class="pre">timeout</span></code> parameter.</li>
</ul>
</div>
<div class="section" id="s-file-storage">
<span id="file-storage"></span><h4>File Storage<a class="headerlink" href="#file-storage" title="Permalink to this headline">¶</a></h4>
<ul class="simple">
<li>File locking on Windows previously depended on the PyWin32 package; if it
wasn’t installed, file locking failed silently. That dependency has been
removed, and file locking is now implemented natively on both Windows
and Unix.</li>
</ul>
</div>
<div class="section" id="s-file-uploads">
<span id="file-uploads"></span><h4>File Uploads<a class="headerlink" href="#file-uploads" title="Permalink to this headline">¶</a></h4>
<ul class="simple">
<li>The new <a class="reference internal" href="../ref/files/uploads.html#django.core.files.uploadedfile.UploadedFile.content_type_extra" title="django.core.files.uploadedfile.UploadedFile.content_type_extra"><code class="xref py py-attr docutils literal"><span class="pre">UploadedFile.content_type_extra</span></code></a> attribute
contains extra parameters passed to the <code class="docutils literal"><span class="pre">content-type</span></code> header on a file
upload.</li>
<li>The new <a class="reference internal" href="../ref/settings.html#std:setting-FILE_UPLOAD_DIRECTORY_PERMISSIONS"><code class="xref std std-setting docutils literal"><span class="pre">FILE_UPLOAD_DIRECTORY_PERMISSIONS</span></code></a> setting controls
the file system permissions of directories created during file upload, like
<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> does for the files themselves.</li>
<li>The <a class="reference internal" href="../ref/models/fields.html#django.db.models.FileField.upload_to" title="django.db.models.FileField.upload_to"><code class="xref py py-attr docutils literal"><span class="pre">FileField.upload_to</span></code></a>
attribute is now optional. If it is omitted or given <code class="docutils literal"><span class="pre">None</span></code> or an empty
string, a subdirectory won’t be used for storing the uploaded files.</li>
<li>Uploaded files are now explicitly closed before the response is delivered to
the client. Partially uploaded files are also closed as long as they are
named <code class="docutils literal"><span class="pre">file</span></code> in the upload handler.</li>
<li><a class="reference internal" href="../ref/files/storage.html#django.core.files.storage.Storage.get_available_name" title="django.core.files.storage.Storage.get_available_name"><code class="xref py py-meth docutils literal"><span class="pre">Storage.get_available_name()</span></code></a> now appends an
underscore plus a random 7 character alphanumeric string (e.g.
<code class="docutils literal"><span class="pre">"_x3a1gho"</span></code>), rather than iterating through an underscore followed by a
number (e.g. <code class="docutils literal"><span class="pre">"_1"</span></code>, <code class="docutils literal"><span class="pre">"_2"</span></code>, etc.) to prevent a denial-of-service attack.
This change was also made in the 1.6.6, 1.5.9, and 1.4.14 security releases.</li>
</ul>
</div>
<div class="section" id="s-forms">
<span id="forms"></span><h4>Forms<a class="headerlink" href="#forms" title="Permalink to this headline">¶</a></h4>
<ul class="simple">
<li>The <code class="docutils literal"><span class="pre"><label></span></code> and <code class="docutils literal"><span class="pre"><input></span></code> tags rendered by
<a class="reference internal" href="../ref/forms/widgets.html#django.forms.RadioSelect" title="django.forms.RadioSelect"><code class="xref py py-class docutils literal"><span class="pre">RadioSelect</span></code></a> and
<a class="reference internal" href="../ref/forms/widgets.html#django.forms.CheckboxSelectMultiple" title="django.forms.CheckboxSelectMultiple"><code class="xref py py-class docutils literal"><span class="pre">CheckboxSelectMultiple</span></code></a> when looping over the radio
buttons or checkboxes now include <code class="docutils literal"><span class="pre">for</span></code> and <code class="docutils literal"><span class="pre">id</span></code> attributes, respectively.
Each radio button or checkbox includes an <code class="docutils literal"><span class="pre">id_for_label</span></code> attribute to
output the element’s ID.</li>
<li>The <code class="docutils literal"><span class="pre"><textarea></span></code> tags rendered by <a class="reference internal" href="../ref/forms/widgets.html#django.forms.Textarea" title="django.forms.Textarea"><code class="xref py py-class docutils literal"><span class="pre">Textarea</span></code></a> now
include a <code class="docutils literal"><span class="pre">maxlength</span></code> attribute if the <a class="reference internal" href="../ref/models/fields.html#django.db.models.TextField" title="django.db.models.TextField"><code class="xref py py-class docutils literal"><span class="pre">TextField</span></code></a>
model field has a <code class="docutils literal"><span class="pre">max_length</span></code>.</li>
<li><a class="reference internal" href="../ref/models/fields.html#django.db.models.Field.choices" title="django.db.models.Field.choices"><code class="xref py py-attr docutils literal"><span class="pre">Field.choices</span></code></a> now allows you to
customize the “empty choice” label by including a tuple with an empty string
or <code class="docutils literal"><span class="pre">None</span></code> for the key and the custom label as the value. The default blank
option <code class="docutils literal"><span class="pre">"----------"</span></code> will be omitted in this case.</li>
<li><a class="reference internal" href="../ref/forms/fields.html#django.forms.MultiValueField" title="django.forms.MultiValueField"><code class="xref py py-class docutils literal"><span class="pre">MultiValueField</span></code></a> allows optional subfields by setting
the <code class="docutils literal"><span class="pre">require_all_fields</span></code> argument to <code class="docutils literal"><span class="pre">False</span></code>. The <code class="docutils literal"><span class="pre">required</span></code> attribute
for each individual field will be respected, and a new <code class="docutils literal"><span class="pre">incomplete</span></code>
validation error will be raised when any required fields are empty.</li>
<li>The <a class="reference internal" href="../ref/forms/api.html#django.forms.Form.clean" title="django.forms.Form.clean"><code class="xref py py-meth docutils literal"><span class="pre">clean()</span></code></a> method on a form no longer needs to
return <code class="docutils literal"><span class="pre">self.cleaned_data</span></code>. If it does return a changed dictionary then
that will still be used.</li>
<li>After a temporary regression in Django 1.6, it’s now possible again to make
<a class="reference internal" href="../ref/forms/fields.html#django.forms.TypedChoiceField" title="django.forms.TypedChoiceField"><code class="xref py py-class docutils literal"><span class="pre">TypedChoiceField</span></code></a> <code class="docutils literal"><span class="pre">coerce</span></code> method return an arbitrary
value.</li>
<li><a class="reference internal" href="../ref/forms/widgets.html#django.forms.extras.widgets.SelectDateWidget.months" title="django.forms.extras.widgets.SelectDateWidget.months"><code class="xref py py-attr docutils literal"><span class="pre">SelectDateWidget.months</span></code></a> can be used to
customize the wording of the months displayed in the select widget.</li>
<li>The <code class="docutils literal"><span class="pre">min_num</span></code> and <code class="docutils literal"><span class="pre">validate_min</span></code> parameters were added to
<a class="reference internal" href="../ref/forms/formsets.html#django.forms.formsets.formset_factory" title="django.forms.formsets.formset_factory"><code class="xref py py-func docutils literal"><span class="pre">formset_factory()</span></code></a> to allow validating
a minimum number of submitted forms.</li>
<li>The metaclasses used by <code class="docutils literal"><span class="pre">Form</span></code> and <code class="docutils literal"><span class="pre">ModelForm</span></code> have been reworked to
support more inheritance scenarios. The previous limitation that prevented
inheriting from both <code class="docutils literal"><span class="pre">Form</span></code> and <code class="docutils literal"><span class="pre">ModelForm</span></code> simultaneously have been
removed as long as <code class="docutils literal"><span class="pre">ModelForm</span></code> appears first in the MRO.</li>
<li>It’s now possible to remove a field from a <code class="docutils literal"><span class="pre">Form</span></code> when subclassing by
setting the name to <code class="docutils literal"><span class="pre">None</span></code>.</li>
<li>It’s now possible to customize the error messages for <code class="docutils literal"><span class="pre">ModelForm</span></code>’s
<code class="docutils literal"><span class="pre">unique</span></code>, <code class="docutils literal"><span class="pre">unique_for_date</span></code>, and <code class="docutils literal"><span class="pre">unique_together</span></code> constraints.
In order to support <code class="docutils literal"><span class="pre">unique_together</span></code> or any other <code class="docutils literal"><span class="pre">NON_FIELD_ERROR</span></code>,
<code class="docutils literal"><span class="pre">ModelForm</span></code> now looks for the <code class="docutils literal"><span class="pre">NON_FIELD_ERROR</span></code> key in the
<code class="docutils literal"><span class="pre">error_messages</span></code> dictionary of the <code class="docutils literal"><span class="pre">ModelForm</span></code>’s inner <code class="docutils literal"><span class="pre">Meta</span></code> class.
See <a class="reference internal" href="../topics/forms/modelforms.html#considerations-regarding-model-errormessages"><span class="std std-ref">considerations regarding model’s error_messages</span></a> for more details.</li>
</ul>
</div>
<div class="section" id="s-internationalization">
<span id="internationalization"></span><h4>Internationalization<a class="headerlink" href="#internationalization" title="Permalink to this headline">¶</a></h4>
<ul class="simple">
<li>The <a class="reference internal" href="../ref/middleware.html#django.middleware.locale.LocaleMiddleware.response_redirect_class" title="django.middleware.locale.LocaleMiddleware.response_redirect_class"><code class="xref py py-attr docutils literal"><span class="pre">django.middleware.locale.LocaleMiddleware.response_redirect_class</span></code></a>
attribute allows you to customize the redirects issued by the middleware.</li>
<li>The <a class="reference internal" href="../ref/middleware.html#django.middleware.locale.LocaleMiddleware" title="django.middleware.locale.LocaleMiddleware"><code class="xref py py-class docutils literal"><span class="pre">LocaleMiddleware</span></code></a> now stores the user’s
selected language with the session key <code class="docutils literal"><span class="pre">_language</span></code>. This should only be
accessed using the <a class="reference internal" href="../ref/utils.html#django.utils.translation.LANGUAGE_SESSION_KEY" title="django.utils.translation.LANGUAGE_SESSION_KEY"><code class="xref py py-data docutils literal"><span class="pre">LANGUAGE_SESSION_KEY</span></code></a>
constant. Previously it was stored with the key <code class="docutils literal"><span class="pre">django_language</span></code> and the
<code class="docutils literal"><span class="pre">LANGUAGE_SESSION_KEY</span></code> constant did not exist, but keys reserved for Django
should start with an underscore. For backwards compatibility <code class="docutils literal"><span class="pre">django_language</span></code>
is still read from in 1.7. Sessions will be migrated to the new key
as they are written.</li>
<li>The <a class="reference internal" href="../topics/i18n/translation.html#std:templatetag-blocktrans"><code class="xref std std-ttag docutils literal"><span class="pre">blocktrans</span></code></a> tag now supports a <code class="docutils literal"><span class="pre">trimmed</span></code> option. This
option will remove newline characters from the beginning and the end of the
content of the <code class="docutils literal"><span class="pre">{%</span> <span class="pre">blocktrans</span> <span class="pre">%}</span></code> tag, replace any whitespace at the
beginning and end of a line and merge all lines into one using a space
character to separate them. This is quite useful for indenting the content of
a <code class="docutils literal"><span class="pre">{%</span> <span class="pre">blocktrans</span> <span class="pre">%}</span></code> tag without having the indentation characters end up
in the corresponding entry in the PO file, which makes the translation
process easier.</li>
<li>When you run <a class="reference internal" href="../ref/django-admin.html#django-admin-makemessages"><code class="xref std std-djadmin docutils literal"><span class="pre">makemessages</span></code></a> from the root directory of your project,
any extracted strings will now be automatically distributed to the proper
app or project message file. See <a class="reference internal" href="../topics/i18n/translation.html#how-to-create-language-files"><span class="std std-ref">Localization: how to create language files</span></a> for
details.</li>
<li>The <a class="reference internal" href="../ref/django-admin.html#django-admin-makemessages"><code class="xref std std-djadmin docutils literal"><span class="pre">makemessages</span></code></a> command now always adds the <code class="docutils literal"><span class="pre">--previous</span></code>
command line flag to the <code class="docutils literal"><span class="pre">msgmerge</span></code> command, keeping previously translated
strings in po files for fuzzy strings.</li>
<li>The following settings to adjust the language cookie options were introduced:
<a class="reference internal" href="../ref/settings.html#std:setting-LANGUAGE_COOKIE_AGE"><code class="xref std std-setting docutils literal"><span class="pre">LANGUAGE_COOKIE_AGE</span></code></a>, <a class="reference internal" href="../ref/settings.html#std:setting-LANGUAGE_COOKIE_DOMAIN"><code class="xref std std-setting docutils literal"><span class="pre">LANGUAGE_COOKIE_DOMAIN</span></code></a>
and <a class="reference internal" href="../ref/settings.html#std:setting-LANGUAGE_COOKIE_PATH"><code class="xref std std-setting docutils literal"><span class="pre">LANGUAGE_COOKIE_PATH</span></code></a>.</li>
<li>Added <a class="reference internal" href="../topics/i18n/formatting.html#format-localization"><span class="std std-ref">format definitions</span></a> for Esperanto.</li>
</ul>
</div>
<div class="section" id="s-management-commands">
<span id="management-commands"></span><h4>Management Commands<a class="headerlink" href="#management-commands" title="Permalink to this headline">¶</a></h4>
<ul>
<li><p class="first">The <a class="reference internal" href="../ref/django-admin.html#django-admin-option---no-color"><code class="xref std std-djadminopt docutils literal"><span class="pre">--no-color</span></code></a> option for <code class="docutils literal"><span class="pre">django-admin</span></code> allows you to
disable the colorization of management command output.</p>
</li>
<li><p class="first">The new <a class="reference internal" href="../ref/django-admin.html#django-admin-option---natural-foreign"><code class="xref std std-djadminopt docutils literal"><span class="pre">--natural-foreign</span></code></a> and <a class="reference internal" href="../ref/django-admin.html#django-admin-option---natural-primary"><code class="xref std std-djadminopt docutils literal"><span class="pre">--natural-primary</span></code></a>
options for <a class="reference internal" href="../ref/django-admin.html#django-admin-dumpdata"><code class="xref std std-djadmin docutils literal"><span class="pre">dumpdata</span></code></a>, and the new <code class="docutils literal"><span class="pre">use_natural_foreign_keys</span></code> and
<code class="docutils literal"><span class="pre">use_natural_primary_keys</span></code> arguments for <code class="docutils literal"><span class="pre">serializers.serialize()</span></code>, allow
the use of natural primary keys when serializing.</p>
</li>
<li><p class="first">It is no longer necessary to provide the cache table name or 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 for the <a class="reference internal" href="../ref/django-admin.html#django-admin-createcachetable"><code class="xref std std-djadmin docutils literal"><span class="pre">createcachetable</span></code></a> command.
Django takes this information from your settings file. If you have configured
multiple caches or multiple databases, all cache tables are created.</p>
</li>
<li><p class="first">The <a class="reference internal" href="../ref/django-admin.html#django-admin-runserver"><code class="xref std std-djadmin docutils literal"><span class="pre">runserver</span></code></a> command received several improvements:</p>
<ul class="simple">
<li>On Linux systems, if <a class="reference external" href="https://pypi.python.org/pypi/pyinotify">pyinotify</a> is installed, the development server will
reload immediately when a file is changed. Previously, it polled the
filesystem for changes every second. That caused a small delay before
reloads and reduced battery life on laptops.</li>
<li>In addition, the development server automatically reloads when a
translation file is updated, i.e. after running
<a class="reference internal" href="../ref/django-admin.html#django-admin-compilemessages"><code class="xref std std-djadmin docutils literal"><span class="pre">compilemessages</span></code></a>.</li>
<li>All HTTP requests are logged to the console, including requests for static
files or <code class="docutils literal"><span class="pre">favicon.ico</span></code> that used to be filtered out.</li>
</ul>
</li>
<li><p class="first">Management commands can now produce syntax colored output under Windows if
the ANSICON third-party tool is installed and active.</p>
</li>
<li><p class="first"><a class="reference internal" href="../ref/contrib/staticfiles.html#django-admin-collectstatic"><code class="xref std std-djadmin docutils literal"><span class="pre">collectstatic</span></code></a> command with symlink option is now supported on
Windows NT 6 (Windows Vista and newer).</p>
</li>
<li><p class="first"><a class="reference internal" href="../howto/initial-data.html#initial-sql"><span class="std std-ref">Providing initial SQL data</span></a> now works better if the <a class="reference external" href="https://pypi.python.org/pypi/sqlparse">sqlparse</a> Python library is
installed.</p>
<p>Note that it’s deprecated in favor of the
<a class="reference internal" href="../ref/migration-operations.html#django.db.migrations.operations.RunSQL" title="django.db.migrations.operations.RunSQL"><code class="xref py py-class docutils literal"><span class="pre">RunSQL</span></code></a> operation of migrations,
which benefits from the improved behavior.</p>
</li>
</ul>
</div>
<div class="section" id="s-models">
<span id="models"></span><h4>Models<a class="headerlink" href="#models" title="Permalink to this headline">¶</a></h4>
<ul class="simple">
<li>The <a class="reference internal" href="../ref/models/querysets.html#django.db.models.query.QuerySet.update_or_create" title="django.db.models.query.QuerySet.update_or_create"><code class="xref py py-meth docutils literal"><span class="pre">QuerySet.update_or_create()</span></code></a> method was added.</li>
<li>The new <a class="reference internal" href="../ref/models/options.html#django.db.models.Options.default_permissions" title="django.db.models.Options.default_permissions"><code class="xref py py-attr docutils literal"><span class="pre">default_permissions</span></code></a> model
<code class="docutils literal"><span class="pre">Meta</span></code> option allows you to customize (or disable) creation of the default
add, change, and delete permissions.</li>
<li>Explicit <a class="reference internal" href="../ref/models/fields.html#django.db.models.OneToOneField" title="django.db.models.OneToOneField"><code class="xref py py-class docutils literal"><span class="pre">OneToOneField</span></code></a> for
<a class="reference internal" href="../topics/db/models.html#multi-table-inheritance"><span class="std std-ref">Multi-table inheritance</span></a> are now discovered in abstract classes.</li>
<li>It is now possible to avoid creating a backward relation for
<a class="reference internal" href="../ref/models/fields.html#django.db.models.OneToOneField" title="django.db.models.OneToOneField"><code class="xref py py-class docutils literal"><span class="pre">OneToOneField</span></code></a> by setting its
<a class="reference internal" href="../ref/models/fields.html#django.db.models.ForeignKey.related_name" title="django.db.models.ForeignKey.related_name"><code class="xref py py-attr docutils literal"><span class="pre">related_name</span></code></a> to
<code class="docutils literal"><span class="pre">'+'</span></code> or ending it with <code class="docutils literal"><span class="pre">'+'</span></code>.</li>
<li><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> support the power operator
(<code class="docutils literal"><span class="pre">**</span></code>).</li>
<li>The <code class="docutils literal"><span class="pre">remove()</span></code> and <code class="docutils literal"><span class="pre">clear()</span></code> methods of the related managers created by
<code class="docutils literal"><span class="pre">ForeignKey</span></code> and <code class="docutils literal"><span class="pre">GenericForeignKey</span></code> now accept the <code class="docutils literal"><span class="pre">bulk</span></code> keyword
argument to control whether or not to perform operations in bulk
(i.e. using <code class="docutils literal"><span class="pre">QuerySet.update()</span></code>). Defaults to <code class="docutils literal"><span class="pre">True</span></code>.</li>
<li>It is now possible to use <code class="docutils literal"><span class="pre">None</span></code> as a query value for the <a class="reference internal" href="../ref/models/querysets.html#std:fieldlookup-iexact"><code class="xref std std-lookup docutils literal"><span class="pre">iexact</span></code></a>
lookup.</li>
<li>It is now possible to pass a callable as value for the attribute
<a class="reference internal" href="../ref/models/fields.html#django.db.models.ForeignKey.limit_choices_to" title="django.db.models.ForeignKey.limit_choices_to"><code class="xref py py-attr docutils literal"><span class="pre">limit_choices_to</span></code></a> when defining a
<code class="docutils literal"><span class="pre">ForeignKey</span></code> or <code class="docutils literal"><span class="pre">ManyToManyField</span></code>.</li>
<li>Calling <a class="reference internal" href="../ref/models/querysets.html#django.db.models.query.QuerySet.only" title="django.db.models.query.QuerySet.only"><code class="xref py py-meth docutils literal"><span class="pre">only()</span></code></a> and
<a class="reference internal" href="../ref/models/querysets.html#django.db.models.query.QuerySet.defer" title="django.db.models.query.QuerySet.defer"><code class="xref py py-meth docutils literal"><span class="pre">defer()</span></code></a> on the result of
<a class="reference internal" href="../ref/models/querysets.html#django.db.models.query.QuerySet.values" title="django.db.models.query.QuerySet.values"><code class="xref py py-meth docutils literal"><span class="pre">QuerySet.values()</span></code></a> now raises
an error (before that, it would either result in a database error or
incorrect data).</li>
<li>You can use a single list for <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>
(rather than a list of lists) when specifying a single set of fields.</li>
<li>Custom intermediate models having more than one foreign key to any of the
models participating in a many-to-many relationship are now permitted,
provided you explicitly specify which foreign keys should be used by setting
the new <a class="reference internal" href="../ref/models/fields.html#django.db.models.ManyToManyField.through_fields" title="django.db.models.ManyToManyField.through_fields"><code class="xref py py-attr docutils literal"><span class="pre">ManyToManyField.through_fields</span></code></a>
argument.</li>
<li>Assigning a model instance to a non-relation field will now throw an error.
Previously this used to work if the field accepted integers as input as it
took the primary key.</li>
<li>Integer fields are now validated against database backend specific min and
max values based on their <a class="reference internal" href="../ref/models/fields.html#django.db.models.Field.get_internal_type" title="django.db.models.Field.get_internal_type"><code class="xref py py-meth docutils literal"><span class="pre">internal_type</span></code></a>.
Previously model field validation didn’t prevent values out of their associated
column data type range from being saved resulting in an integrity error.</li>
<li>It is now possible to explicitly <a class="reference internal" href="../ref/models/querysets.html#django.db.models.query.QuerySet.order_by" title="django.db.models.query.QuerySet.order_by"><code class="xref py py-meth docutils literal"><span class="pre">order_by()</span></code></a>
a relation <code class="docutils literal"><span class="pre">_id</span></code> field by using its attribute name.</li>
</ul>
</div>
<div class="section" id="s-signals">
<span id="signals"></span><h4>Signals<a class="headerlink" href="#signals" title="Permalink to this headline">¶</a></h4>
<ul class="simple">
<li>The <code class="docutils literal"><span class="pre">enter</span></code> argument was added to the
<a class="reference internal" href="../ref/signals.html#django.test.signals.setting_changed" title="django.test.signals.setting_changed"><code class="xref py py-data docutils literal"><span class="pre">setting_changed</span></code></a> signal.</li>
<li>The model signals can be now be connected to using a <code class="docutils literal"><span class="pre">str</span></code> of the
<code class="docutils literal"><span class="pre">'app_label.ModelName'</span></code> form – just like related fields – to lazily
reference their senders.</li>
</ul>
</div>
<div class="section" id="s-templates">
<span id="templates"></span><h4>Templates<a class="headerlink" href="#templates" title="Permalink to this headline">¶</a></h4>
<ul class="simple">
<li>The <a class="reference internal" href="../ref/templates/api.html#django.template.Context.push" title="django.template.Context.push"><code class="xref py py-meth docutils literal"><span class="pre">Context.push()</span></code></a> method now returns
a context manager which automatically calls <a class="reference internal" href="../ref/templates/api.html#django.template.Context.pop" title="django.template.Context.pop"><code class="xref py py-meth docutils literal"><span class="pre">pop()</span></code></a> upon exiting the <code class="docutils literal"><span class="pre">with</span></code> statement.
Additionally, <a class="reference internal" href="../ref/templates/api.html#django.template.Context.push" title="django.template.Context.push"><code class="xref py py-meth docutils literal"><span class="pre">push()</span></code></a> now accepts
parameters that are passed to the <code class="docutils literal"><span class="pre">dict</span></code> constructor used to build the new
context level.</li>
<li>The new <a class="reference internal" href="../ref/templates/api.html#django.template.Context.flatten" title="django.template.Context.flatten"><code class="xref py py-meth docutils literal"><span class="pre">Context.flatten()</span></code></a> method
returns a <code class="docutils literal"><span class="pre">Context</span></code>‘s stack as one flat dictionary.</li>
<li><code class="docutils literal"><span class="pre">Context</span></code> objects can now be compared for equality (internally, this
uses <a class="reference internal" href="../ref/templates/api.html#django.template.Context.flatten" title="django.template.Context.flatten"><code class="xref py py-meth docutils literal"><span class="pre">Context.flatten()</span></code></a> so the
internal structure of each <code class="docutils literal"><span class="pre">Context</span></code>‘s stack doesn’t matter as long as their
flattened version is identical).</li>
<li>The <a class="reference internal" href="../ref/templates/builtins.html#std:templatetag-widthratio"><code class="xref std std-ttag docutils literal"><span class="pre">widthratio</span></code></a> template tag now accepts an <code class="docutils literal"><span class="pre">"as"</span></code> parameter to
capture the result in a variable.</li>
<li>The <a class="reference internal" href="../ref/templates/builtins.html#std:templatetag-include"><code class="xref std std-ttag docutils literal"><span class="pre">include</span></code></a> template tag will now also accept anything with a
<code class="docutils literal"><span class="pre">render()</span></code> method (such as a <code class="docutils literal"><span class="pre">Template</span></code>) as an argument. String
arguments will be looked up using
<a class="reference internal" href="../topics/templates.html#django.template.loader.get_template" title="django.template.loader.get_template"><code class="xref py py-func docutils literal"><span class="pre">get_template()</span></code></a> as always.</li>
<li>It is now possible to <a class="reference internal" href="../ref/templates/builtins.html#std:templatetag-include"><code class="xref std std-ttag docutils literal"><span class="pre">include</span></code></a> templates recursively.</li>
<li>Template objects now have an origin attribute set when
<code class="docutils literal"><span class="pre">TEMPLATE_DEBUG</span></code> is <code class="docutils literal"><span class="pre">True</span></code>. This allows template origins to be
inspected and logged outside of the <code class="docutils literal"><span class="pre">django.template</span></code> infrastructure.</li>
<li><code class="docutils literal"><span class="pre">TypeError</span></code> exceptions are no longer silenced when raised during the
rendering of a template.</li>
<li>The following functions now accept a <code class="docutils literal"><span class="pre">dirs</span></code> parameter which is a list or
tuple to override <code class="docutils literal"><span class="pre">TEMPLATE_DIRS</span></code>:<ul>
<li><a class="reference internal" href="../topics/templates.html#django.template.loader.get_template" title="django.template.loader.get_template"><code class="xref py py-func docutils literal"><span class="pre">django.template.loader.get_template()</span></code></a></li>
<li><a class="reference internal" href="../topics/templates.html#django.template.loader.select_template" title="django.template.loader.select_template"><code class="xref py py-func docutils literal"><span class="pre">django.template.loader.select_template()</span></code></a></li>
<li><a class="reference internal" href="../topics/http/shortcuts.html#django.shortcuts.render" title="django.shortcuts.render"><code class="xref py py-func docutils literal"><span class="pre">django.shortcuts.render()</span></code></a></li>
<li><a class="reference internal" href="../topics/http/shortcuts.html#django.shortcuts.render_to_response" title="django.shortcuts.render_to_response"><code class="xref py py-func docutils literal"><span class="pre">django.shortcuts.render_to_response()</span></code></a></li>
</ul>
</li>
<li>The <a class="reference internal" href="../ref/templates/builtins.html#std:templatefilter-time"><code class="xref std std-tfilter docutils literal"><span class="pre">time</span></code></a> filter now accepts timezone-related <a class="reference internal" href="../ref/templates/builtins.html#date-and-time-formatting-specifiers"><span class="std std-ref">format
specifiers</span></a> <code class="docutils literal"><span class="pre">'e'</span></code>, <code class="docutils literal"><span class="pre">'O'</span></code> , <code class="docutils literal"><span class="pre">'T'</span></code>
and <code class="docutils literal"><span class="pre">'Z'</span></code> and is able to digest <a class="reference internal" href="../topics/i18n/timezones.html#naive-vs-aware-datetimes"><span class="std std-ref">time-zone-aware</span></a> <code class="docutils literal"><span class="pre">datetime</span></code> instances performing the expected
rendering.</li>
<li>The <a class="reference internal" href="../topics/cache.html#std:templatetag-cache"><code class="xref std std-ttag docutils literal"><span class="pre">cache</span></code></a> tag will now try to use the cache called
“template_fragments” if it exists and fall back to using the default cache
otherwise. It also now accepts an optional <code class="docutils literal"><span class="pre">using</span></code> keyword argument to
control which cache it uses.</li>
<li>The new <a class="reference internal" href="../ref/templates/builtins.html#std:templatefilter-truncatechars_html"><code class="xref std std-tfilter docutils literal"><span class="pre">truncatechars_html</span></code></a> filter truncates a string to be no
longer than the specified number of characters, taking HTML into account.</li>
</ul>
</div>
<div class="section" id="s-requests-and-responses">
<span id="requests-and-responses"></span><h4>Requests and Responses<a class="headerlink" href="#requests-and-responses" title="Permalink to this headline">¶</a></h4>
<ul class="simple">
<li>The new <a class="reference internal" href="../ref/request-response.html#django.http.HttpRequest.scheme" title="django.http.HttpRequest.scheme"><code class="xref py py-attr docutils literal"><span class="pre">HttpRequest.scheme</span></code></a> attribute
specifies the scheme of the request (<code class="docutils literal"><span class="pre">http</span></code> or <code class="docutils literal"><span class="pre">https</span></code> normally).</li>
<li>The shortcut <a class="reference internal" href="../topics/http/shortcuts.html#django.shortcuts.redirect" title="django.shortcuts.redirect"><code class="xref py py-func docutils literal"><span class="pre">redirect()</span></code></a> now supports
relative URLs.</li>
<li>The new <a class="reference internal" href="../ref/request-response.html#django.http.JsonResponse" title="django.http.JsonResponse"><code class="xref py py-class docutils literal"><span class="pre">JsonResponse</span></code></a> subclass 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> helps easily create JSON-encoded responses.</li>
</ul>
</div>
<div class="section" id="s-tests">
<span id="tests"></span><h4>Tests<a class="headerlink" href="#tests" title="Permalink to this headline">¶</a></h4>
<ul class="simple">
<li><a class="reference internal" href="../topics/testing/advanced.html#django.test.runner.DiscoverRunner" title="django.test.runner.DiscoverRunner"><code class="xref py py-class docutils literal"><span class="pre">DiscoverRunner</span></code></a> has two new attributes,
<a class="reference internal" href="../topics/testing/advanced.html#django.test.runner.DiscoverRunner.test_suite" title="django.test.runner.DiscoverRunner.test_suite"><code class="xref py py-attr docutils literal"><span class="pre">test_suite</span></code></a> and
<a class="reference internal" href="../topics/testing/advanced.html#django.test.runner.DiscoverRunner.test_runner" title="django.test.runner.DiscoverRunner.test_runner"><code class="xref py py-attr docutils literal"><span class="pre">test_runner</span></code></a>, which facilitate
overriding the way tests are collected and run.</li>
<li>The <code class="docutils literal"><span class="pre">fetch_redirect_response</span></code> argument was added to
<a class="reference internal" href="../topics/testing/tools.html#django.test.SimpleTestCase.assertRedirects" title="django.test.SimpleTestCase.assertRedirects"><code class="xref py py-meth docutils literal"><span class="pre">assertRedirects()</span></code></a>. Since the test
client can’t fetch externals URLs, this allows you to use <code class="docutils literal"><span class="pre">assertRedirects</span></code>
with redirects that aren’t part of your Django app.</li>
<li>Correct handling of scheme when making comparisons in
<a class="reference internal" href="../topics/testing/tools.html#django.test.SimpleTestCase.assertRedirects" title="django.test.SimpleTestCase.assertRedirects"><code class="xref py py-meth docutils literal"><span class="pre">assertRedirects()</span></code></a>.</li>
<li>The <code class="docutils literal"><span class="pre">secure</span></code> argument was added to all the request methods of
<a class="reference internal" href="../topics/testing/tools.html#django.test.Client" title="django.test.Client"><code class="xref py py-class docutils literal"><span class="pre">Client</span></code></a>. If <code class="docutils literal"><span class="pre">True</span></code>, the request will be made
through HTTPS.</li>
<li><a class="reference internal" href="../topics/testing/tools.html#django.test.TransactionTestCase.assertNumQueries" title="django.test.TransactionTestCase.assertNumQueries"><code class="xref py py-meth docutils literal"><span class="pre">assertNumQueries()</span></code></a> now prints
out the list of executed queries if the assertion fails.</li>
<li>The <code class="docutils literal"><span class="pre">WSGIRequest</span></code> instance generated by the test handler is now attached to
the <a class="reference internal" href="../topics/testing/tools.html#django.test.Response.wsgi_request" title="django.test.Response.wsgi_request"><code class="xref py py-attr docutils literal"><span class="pre">django.test.Response.wsgi_request</span></code></a> attribute.</li>
<li>The database settings for testing have been collected into a dictionary
named <a class="reference internal" href="../ref/settings.html#std:setting-DATABASE-TEST"><code class="xref std std-setting docutils literal"><span class="pre">TEST</span></code></a>.</li>
</ul>
</div>
<div class="section" id="s-utilities">
<span id="utilities"></span><h4>Utilities<a class="headerlink" href="#utilities" title="Permalink to this headline">¶</a></h4>
<ul class="simple">
<li>Improved <a class="reference internal" href="../ref/utils.html#django.utils.html.strip_tags" title="django.utils.html.strip_tags"><code class="xref py py-func docutils literal"><span class="pre">strip_tags()</span></code></a> accuracy (but it still cannot
guarantee an HTML-safe result, as stated in the documentation).</li>
</ul>
</div>
<div class="section" id="s-validators">
<span id="validators"></span><h4>Validators<a class="headerlink" href="#validators" title="Permalink to this headline">¶</a></h4>
<ul class="simple">
<li><a class="reference internal" href="../ref/validators.html#django.core.validators.RegexValidator" title="django.core.validators.RegexValidator"><code class="xref py py-class docutils literal"><span class="pre">RegexValidator</span></code></a> now accepts the optional
<a class="reference internal" href="../ref/validators.html#django.core.validators.RegexValidator.flags" title="django.core.validators.RegexValidator.flags"><code class="xref py py-attr docutils literal"><span class="pre">flags</span></code></a> and
Boolean <a class="reference internal" href="../ref/validators.html#django.core.validators.RegexValidator.inverse_match" title="django.core.validators.RegexValidator.inverse_match"><code class="xref py py-attr docutils literal"><span class="pre">inverse_match</span></code></a> arguments.
The <a class="reference internal" href="../ref/validators.html#django.core.validators.RegexValidator.inverse_match" title="django.core.validators.RegexValidator.inverse_match"><code class="xref py py-attr docutils literal"><span class="pre">inverse_match</span></code></a> attribute
determines if the <a class="reference internal" href="../ref/exceptions.html#django.core.exceptions.ValidationError" title="django.core.exceptions.ValidationError"><code class="xref py py-exc docutils literal"><span class="pre">ValidationError</span></code></a> should
be raised when the regular expression pattern matches (<code class="docutils literal"><span class="pre">True</span></code>) or does not
match (<code class="docutils literal"><span class="pre">False</span></code>, by default) the provided <code class="docutils literal"><span class="pre">value</span></code>. The
<a class="reference internal" href="../ref/validators.html#django.core.validators.RegexValidator.flags" title="django.core.validators.RegexValidator.flags"><code class="xref py py-attr docutils literal"><span class="pre">flags</span></code></a> attribute sets the flags
used when compiling a regular expression string.</li>
<li><a class="reference internal" href="../ref/validators.html#django.core.validators.URLValidator" title="django.core.validators.URLValidator"><code class="xref py py-class docutils literal"><span class="pre">URLValidator</span></code></a> now accepts an optional
<code class="docutils literal"><span class="pre">schemes</span></code> argument which allows customization of the accepted URI schemes
(instead of the defaults <code class="docutils literal"><span class="pre">http(s)</span></code> and <code class="docutils literal"><span class="pre">ftp(s)</span></code>).</li>
<li><a class="reference internal" href="../ref/validators.html#django.core.validators.validate_email" title="django.core.validators.validate_email"><code class="xref py py-func docutils literal"><span class="pre">validate_email()</span></code></a> now accepts addresses with
IPv6 literals, like <code class="docutils literal"><span class="pre">example@[2001:db8::1]</span></code>, as specified in RFC 5321.</li>
</ul>
</div>
</div>
</div>
<div class="section" id="s-backwards-incompatible-changes-in-1-7">
<span id="s-backwards-incompatible-1-7"></span><span id="backwards-incompatible-changes-in-1-7"></span><span id="backwards-incompatible-1-7"></span><h2>Backwards incompatible changes in 1.7<a class="headerlink" href="#backwards-incompatible-changes-in-1-7" 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-7"><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-allow-syncdb-allow-migrate">
<span id="allow-syncdb-allow-migrate"></span><h3>allow_syncdb/allow_migrate<a class="headerlink" href="#allow-syncdb-allow-migrate" title="Permalink to this headline">¶</a></h3>
<p>While Django will still look at <code class="docutils literal"><span class="pre">allow_syncdb</span></code> methods even though they
should be renamed to <code class="docutils literal"><span class="pre">allow_migrate</span></code>, there is a subtle difference in which
models get passed to these methods.</p>
<p>For apps with migrations, <code class="docutils literal"><span class="pre">allow_migrate</span></code> will now get passed
<a class="reference internal" href="../topics/migrations.html#historical-models"><span class="std std-ref">historical models</span></a>, which are special versioned models
without custom attributes, methods or managers. Make sure your <code class="docutils literal"><span class="pre">allow_migrate</span></code>
methods are only referring to fields or other items in <code class="docutils literal"><span class="pre">model._meta</span></code>.</p>
</div>
<div class="section" id="s-initial-data">
<span id="initial-data"></span><h3>initial_data<a class="headerlink" href="#initial-data" title="Permalink to this headline">¶</a></h3>
<p>Apps with migrations will not load <code class="docutils literal"><span class="pre">initial_data</span></code> fixtures when they have
finished migrating. Apps without migrations will continue to load these fixtures
during the phase of <code class="docutils literal"><span class="pre">migrate</span></code> which emulates the old <code class="docutils literal"><span class="pre">syncdb</span></code> behavior,
but any new apps will not have this support.</p>
<p>Instead, you are encouraged to load initial data in migrations if you need it
(using the <code class="docutils literal"><span class="pre">RunPython</span></code> operation and your model classes);
this has the added advantage that your initial data will not need updating
every time you change the schema.</p>
<p>Additionally, like the rest of Django’s old <code class="docutils literal"><span class="pre">syncdb</span></code> code, <code class="docutils literal"><span class="pre">initial_data</span></code>
has been started down the deprecation path and will be removed in Django 1.9.</p>
</div>
<div class="section" id="s-deconstruct-and-serializability">
<span id="deconstruct-and-serializability"></span><h3>deconstruct() and serializability<a class="headerlink" href="#deconstruct-and-serializability" title="Permalink to this headline">¶</a></h3>
<p>Django now requires all Field classes and all of their constructor arguments
to be serializable. If you modify the constructor signature in your custom
Field in any way, you’ll need to implement a deconstruct() method;
we’ve expanded the custom field documentation with <a class="reference internal" href="../howto/custom-model-fields.html#custom-field-deconstruct-method"><span class="std std-ref">instructions
on implementing this method</span></a>.</p>
<p>The requirement for all field arguments to be
<a class="reference internal" href="../topics/migrations.html#migration-serializing"><span class="std std-ref">serializable</span></a> means that any custom class
instances being passed into Field constructors - things like custom Storage
subclasses, for instance - need to have a <a class="reference internal" href="../topics/migrations.html#custom-deconstruct-method"><span class="std std-ref">deconstruct method defined on
them as well</span></a>, though Django provides a handy
class decorator that will work for most applications.</p>
</div>
<div class="section" id="s-app-loading-changes">
<span id="app-loading-changes"></span><h3>App-loading changes<a class="headerlink" href="#app-loading-changes" title="Permalink to this headline">¶</a></h3>
<div class="section" id="s-start-up-sequence">
<span id="start-up-sequence"></span><h4>Start-up sequence<a class="headerlink" href="#start-up-sequence" title="Permalink to this headline">¶</a></h4>
<p>Django 1.7 loads application configurations and models as soon as it starts.
While this behavior is more straightforward and is believed to be more robust,
regressions cannot be ruled out. See <a class="reference internal" href="../ref/applications.html#applications-troubleshooting"><span class="std std-ref">Troubleshooting</span></a> for
solutions to some problems you may encounter.</p>
</div>
<div class="section" id="s-standalone-scripts">
<span id="standalone-scripts"></span><h4>Standalone scripts<a class="headerlink" href="#standalone-scripts" title="Permalink to this headline">¶</a></h4>
<p>If you’re using Django in a plain Python script — rather than a management
command — and you rely on the <span class="target" id="index-0"></span><a class="reference internal" href="../topics/settings.html#envvar-DJANGO_SETTINGS_MODULE"><code class="xref std std-envvar docutils literal"><span class="pre">DJANGO_SETTINGS_MODULE</span></code></a> environment
variable, you must now explicitly initialize Django at the beginning of your
script with:</p>
<div class="highlight-default"><div class="highlight"><pre><span></span><span class="gp">>>> </span><span class="kn">import</span> <span class="nn">django</span>
<span class="gp">>>> </span><span class="n">django</span><span class="o">.</span><span class="n">setup</span><span class="p">()</span>
</pre></div>
</div>
<p>Otherwise, you will hit an <code class="docutils literal"><span class="pre">AppRegistryNotReady</span></code> exception.</p>
</div>
<div class="section" id="s-wsgi-scripts">
<span id="wsgi-scripts"></span><h4>WSGI scripts<a class="headerlink" href="#wsgi-scripts" title="Permalink to this headline">¶</a></h4>
<p>Until Django 1.3, the recommended way to create a WSGI application was:</p>
<div class="highlight-default"><div class="highlight"><pre><span></span><span class="kn">import</span> <span class="nn">django.core.handlers.wsgi</span>
<span class="n">application</span> <span class="o">=</span> <span class="n">django</span><span class="o">.</span><span class="n">core</span><span class="o">.</span><span class="n">handlers</span><span class="o">.</span><span class="n">wsgi</span><span class="o">.</span><span class="n">WSGIHandler</span><span class="p">()</span>
</pre></div>
</div>
<p>In Django 1.4, support for WSGI was improved and the API changed to:</p>
<div class="highlight-default"><div class="highlight"><pre><span></span><span class="kn">from</span> <span class="nn">django.core.wsgi</span> <span class="k">import</span> <span class="n">get_wsgi_application</span>
<span class="n">application</span> <span class="o">=</span> <span class="n">get_wsgi_application</span><span class="p">()</span>
</pre></div>
</div>
<p>If you’re still using the former style in your WSGI script, you need to
upgrade to the latter, or you will hit an <code class="docutils literal"><span class="pre">AppRegistryNotReady</span></code> exception.</p>
</div>
<div class="section" id="s-app-registry-consistency">
<span id="app-registry-consistency"></span><h4>App registry consistency<a class="headerlink" href="#app-registry-consistency" title="Permalink to this headline">¶</a></h4>
<p>It is no longer possible to have multiple installed applications with the same
label. In previous versions of Django, this didn’t always work correctly, but
didn’t crash outright either.</p>
<p>If you have two apps with the same label, you should create an
<a class="reference internal" href="../ref/applications.html#django.apps.AppConfig" title="django.apps.AppConfig"><code class="xref py py-class docutils literal"><span class="pre">AppConfig</span></code></a> for one of them and override its
<a class="reference internal" href="../ref/applications.html#django.apps.AppConfig.label" title="django.apps.AppConfig.label"><code class="xref py py-class docutils literal"><span class="pre">label</span></code></a> there. You should then adjust your code
wherever it references this application or its models with the old label.</p>
<p>It isn’t possible to import the same model twice through different paths any
more. As of Django 1.6, this may happen only if you’re manually putting a
directory and a subdirectory on <span class="target" id="index-1"></span><code class="xref std std-envvar docutils literal"><span class="pre">PYTHONPATH</span></code>. Refer to the section on
the new project layout in the <a class="reference internal" href="1.4.html"><span class="doc">1.4 release notes</span></a> for
migration instructions.</p>
<p>You should make sure that:</p>
<ul class="simple">
<li>All models are defined in applications that are listed in
<a class="reference internal" href="../ref/settings.html#std:setting-INSTALLED_APPS"><code class="xref std std-setting docutils literal"><span class="pre">INSTALLED_APPS</span></code></a> or have an explicit
<a class="reference internal" href="../ref/models/options.html#django.db.models.Options.app_label" title="django.db.models.Options.app_label"><code class="xref py py-attr docutils literal"><span class="pre">app_label</span></code></a>.</li>
<li>Models aren’t imported as a side-effect of loading their application.
Specifically, you shouldn’t import models in the root module of an
application nor in the module that define its configuration class.</li>
</ul>
<p>Django will enforce these requirements as of version 1.9, after a deprecation
period.</p>
</div>
<div class="section" id="s-subclassing-appcommand">
<span id="subclassing-appcommand"></span><h4>Subclassing AppCommand<a class="headerlink" href="#subclassing-appcommand" title="Permalink to this headline">¶</a></h4>
<p>Subclasses of <a class="reference internal" href="../howto/custom-management-commands.html#django.core.management.AppCommand" title="django.core.management.AppCommand"><code class="xref py py-class docutils literal"><span class="pre">AppCommand</span></code></a> must now implement a
<a class="reference internal" href="../howto/custom-management-commands.html#django.core.management.AppCommand.handle_app_config" title="django.core.management.AppCommand.handle_app_config"><code class="xref py py-meth docutils literal"><span class="pre">handle_app_config()</span></code></a> method instead of
<code class="docutils literal"><span class="pre">handle_app()</span></code>. This method receives an <a class="reference internal" href="../ref/applications.html#django.apps.AppConfig" title="django.apps.AppConfig"><code class="xref py py-class docutils literal"><span class="pre">AppConfig</span></code></a>
instance instead of a models module.</p>
</div>
<div class="section" id="s-introspecting-applications">
<span id="introspecting-applications"></span><h4>Introspecting applications<a class="headerlink" href="#introspecting-applications" title="Permalink to this headline">¶</a></h4>
<p>Since <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> now supports application configuration classes
in addition to application modules, you should review code that accesses this
setting directly and use the app registry (<a class="reference internal" href="../ref/applications.html#django.apps.apps" title="django.apps.apps"><code class="xref py py-attr docutils literal"><span class="pre">django.apps.apps</span></code></a>) instead.</p>
<p>The app registry has preserved some features of the old app cache. Even though
the app cache was a private API, obsolete methods and arguments will be
removed through a standard deprecation path, with the exception of the
following changes that take effect immediately:</p>
<ul class="simple">
<li><code class="docutils literal"><span class="pre">get_model</span></code> raises <code class="xref py py-exc docutils literal"><span class="pre">LookupError</span></code> instead of returning <code class="docutils literal"><span class="pre">None</span></code> when no
model is found.</li>
<li>The <code class="docutils literal"><span class="pre">only_installed</span></code> argument of <code class="docutils literal"><span class="pre">get_model</span></code> and <code class="docutils literal"><span class="pre">get_models</span></code> no
longer exists, nor does the <code class="docutils literal"><span class="pre">seed_cache</span></code> argument of <code class="docutils literal"><span class="pre">get_model</span></code>.</li>
</ul>
</div>
</div>
<div class="section" id="s-management-commands-and-order-of-installed-apps">
<span id="management-commands-and-order-of-installed-apps"></span><h3>Management commands and order of <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><a class="headerlink" href="#management-commands-and-order-of-installed-apps" title="Permalink to this headline">¶</a></h3>
<p>When several applications provide management commands with the same name,
Django loads the command from the application that comes first in
<a class="reference internal" href="../ref/settings.html#std:setting-INSTALLED_APPS"><code class="xref std std-setting docutils literal"><span class="pre">INSTALLED_APPS</span></code></a>. Previous versions loaded the command from the
application that came last.</p>
<p>This brings discovery of management commands in line with other parts of
Django that rely on the order of <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>, such as static
files, templates, and translations.</p>
</div>
<div class="section" id="s-validationerror-constructor-and-internal-storage">
<span id="s-validation-error-constructor-and-internal-storage"></span><span id="validationerror-constructor-and-internal-storage"></span><span id="validation-error-constructor-and-internal-storage"></span><h3><code class="docutils literal"><span class="pre">ValidationError</span></code> constructor and internal storage<a class="headerlink" href="#validationerror-constructor-and-internal-storage" title="Permalink to this headline">¶</a></h3>
<p>The behavior of the <code class="docutils literal"><span class="pre">ValidationError</span></code> constructor has changed when it
receives a container of errors as an argument (e.g. a <code class="docutils literal"><span class="pre">list</span></code> or an
<code class="docutils literal"><span class="pre">ErrorList</span></code>):</p>
<ul class="simple">
<li>It converts any strings it finds to instances of <code class="docutils literal"><span class="pre">ValidationError</span></code>
before adding them to its internal storage.</li>
<li>It doesn’t store the given container but rather copies its content to its
own internal storage; previously the container itself was added to the
<code class="docutils literal"><span class="pre">ValidationError</span></code> instance and used as internal storage.</li>
</ul>
<p>This means that if you access the <code class="docutils literal"><span class="pre">ValidationError</span></code> internal storages, such
as <code class="docutils literal"><span class="pre">error_list</span></code>; <code class="docutils literal"><span class="pre">error_dict</span></code>; or the return value of
<code class="docutils literal"><span class="pre">update_error_dict()</span></code> you may find instances of <code class="docutils literal"><span class="pre">ValidationError</span></code> where you
would have previously found strings.</p>
<p>Also if you directly assigned the return value of <code class="docutils literal"><span class="pre">update_error_dict()</span></code>
to <code class="docutils literal"><span class="pre">Form._errors</span></code> you may inadvertently add <cite>list</cite> instances where
<code class="docutils literal"><span class="pre">ErrorList</span></code> instances are expected. This is a problem because unlike a
simple <cite>list</cite>, an <code class="docutils literal"><span class="pre">ErrorList</span></code> knows how to handle instances of
<code class="docutils literal"><span class="pre">ValidationError</span></code>.</p>
<p>Most use-cases that warranted using these private APIs are now covered by
the newly introduced <a class="reference internal" href="../ref/forms/api.html#django.forms.Form.add_error" title="django.forms.Form.add_error"><code class="xref py py-meth docutils literal"><span class="pre">Form.add_error()</span></code></a>
method:</p>
<div class="highlight-default"><div class="highlight"><pre><span></span><span class="c1"># Old pattern:</span>
<span class="k">try</span><span class="p">:</span>
<span class="c1"># ...</span>
<span class="k">except</span> <span class="n">ValidationError</span> <span class="k">as</span> <span class="n">e</span><span class="p">:</span>
<span class="bp">self</span><span class="o">.</span><span class="n">_errors</span> <span class="o">=</span> <span class="n">e</span><span class="o">.</span><span class="n">update_error_dict</span><span class="p">(</span><span class="bp">self</span><span class="o">.</span><span class="n">_errors</span><span class="p">)</span>
<span class="c1"># New pattern:</span>
<span class="k">try</span><span class="p">:</span>
<span class="c1"># ...</span>
<span class="k">except</span> <span class="n">ValidationError</span> <span class="k">as</span> <span class="n">e</span><span class="p">:</span>
<span class="bp">self</span><span class="o">.</span><span class="n">add_error</span><span class="p">(</span><span class="kc">None</span><span class="p">,</span> <span class="n">e</span><span class="p">)</span>
</pre></div>
</div>
<p>If you need both Django <= 1.6 and 1.7 compatibility you can’t use
<a class="reference internal" href="../ref/forms/api.html#django.forms.Form.add_error" title="django.forms.Form.add_error"><code class="xref py py-meth docutils literal"><span class="pre">Form.add_error()</span></code></a> since it
wasn’t available before Django 1.7, but you can use the following
workaround to convert any <code class="docutils literal"><span class="pre">list</span></code> into <code class="docutils literal"><span class="pre">ErrorList</span></code>:</p>
<div class="highlight-default"><div class="highlight"><pre><span></span><span class="k">try</span><span class="p">:</span>
<span class="c1"># ...</span>
<span class="k">except</span> <span class="n">ValidationError</span> <span class="k">as</span> <span class="n">e</span><span class="p">:</span>
<span class="bp">self</span><span class="o">.</span><span class="n">_errors</span> <span class="o">=</span> <span class="n">e</span><span class="o">.</span><span class="n">update_error_dict</span><span class="p">(</span><span class="bp">self</span><span class="o">.</span><span class="n">_errors</span><span class="p">)</span>
<span class="c1"># Additional code to ensure ``ErrorDict`` is exclusively</span>
<span class="c1"># composed of ``ErrorList`` instances.</span>
<span class="k">for</span> <span class="n">field</span><span class="p">,</span> <span class="n">error_list</span> <span class="ow">in</span> <span class="bp">self</span><span class="o">.</span><span class="n">_errors</span><span class="o">.</span><span class="n">items</span><span class="p">():</span>
<span class="k">if</span> <span class="ow">not</span> <span class="nb">isinstance</span><span class="p">(</span><span class="n">error_list</span><span class="p">,</span> <span class="bp">self</span><span class="o">.</span><span class="n">error_class</span><span class="p">):</span>
<span class="bp">self</span><span class="o">.</span><span class="n">_errors</span><span class="p">[</span><span class="n">field</span><span class="p">]</span> <span class="o">=</span> <span class="bp">self</span><span class="o">.</span><span class="n">error_class</span><span class="p">(</span><span class="n">error_list</span><span class="p">)</span>
</pre></div>
</div>
</div>
<div class="section" id="s-behavior-of-locmemcache-regarding-pickle-errors">
<span id="behavior-of-locmemcache-regarding-pickle-errors"></span><h3>Behavior of <code class="docutils literal"><span class="pre">LocMemCache</span></code> regarding pickle errors<a class="headerlink" href="#behavior-of-locmemcache-regarding-pickle-errors" title="Permalink to this headline">¶</a></h3>
<p>An inconsistency existed in previous versions of Django regarding how pickle
errors are handled by different cache backends.
<code class="docutils literal"><span class="pre">django.core.cache.backends.locmem.LocMemCache</span></code> used to fail silently when
such an error occurs, which is inconsistent with other backends and leads to
cache-specific errors. This has been fixed in Django 1.7, see
<a class="reference external" href="https://code.djangoproject.com/ticket/21200">#21200</a> for more details.</p>
</div>
<div class="section" id="s-cache-keys-are-now-generated-from-the-request-s-absolute-url">
<span id="cache-keys-are-now-generated-from-the-request-s-absolute-url"></span><h3>Cache keys are now generated from the request’s absolute URL<a class="headerlink" href="#cache-keys-are-now-generated-from-the-request-s-absolute-url" title="Permalink to this headline">¶</a></h3>
<p>Previous versions of Django generated cache keys using a request’s path and
query string but not the scheme or host. If a Django application was serving
multiple subdomains or domains, cache keys could collide. In Django 1.7, cache
keys vary by the absolute URL of the request including scheme, host, path, and
query string. For example, the URL portion of a cache key is now generated from
<code class="docutils literal"><span class="pre">http://www.example.com/path/to/?key=val</span></code> rather than <code class="docutils literal"><span class="pre">/path/to/?key=val</span></code>.
The cache keys generated by Django 1.7 will be different from the keys
generated by older versions of Django. After upgrading to Django 1.7, the first
request to any previously cached URL will be a cache miss.</p>
</div>
<div class="section" id="s-passing-none-to-manager-db-manager">
<span id="passing-none-to-manager-db-manager"></span><h3>Passing <code class="docutils literal"><span class="pre">None</span></code> to <code class="docutils literal"><span class="pre">Manager.db_manager()</span></code><a class="headerlink" href="#passing-none-to-manager-db-manager" title="Permalink to this headline">¶</a></h3>
<p>In previous versions of Django, it was possible to use
<code class="docutils literal"><span class="pre">db_manager(using=None)</span></code> on a model manager instance to obtain a manager
instance using default routing behavior, overriding any manually specified
database routing. In Django 1.7, a value of <code class="docutils literal"><span class="pre">None</span></code> passed to db_manager will
produce a router that <em>retains</em> any manually assigned database routing – the
manager will <em>not</em> be reset. This was necessary to resolve an inconsistency in
the way routing information cascaded over joins. See <a class="reference external" href="https://code.djangoproject.com/ticket/13724">#13724</a> for more
details.</p>
</div>
<div class="section" id="s-pytz-may-be-required">
<span id="pytz-may-be-required"></span><h3>pytz may be required<a class="headerlink" href="#pytz-may-be-required" title="Permalink to this headline">¶</a></h3>
<p>If your project handles datetimes before 1970 or after 2037 and Django raises
a <code class="xref py py-exc docutils literal"><span class="pre">ValueError</span></code> when encountering them, you will have to install <a class="reference external" href="https://pypi.python.org/pypi/pytz/">pytz</a>. You
may be affected by this problem if you use Django’s time zone-related date
formats or <a class="reference internal" href="../ref/contrib/syndication.html#module-django.contrib.syndication" title="django.contrib.syndication: A framework for generating syndication feeds, in RSS and Atom, quite easily."><code class="xref py py-mod docutils literal"><span class="pre">django.contrib.syndication</span></code></a>.</p>
</div>
<div class="section" id="s-remove-and-clear-methods-of-related-managers">
<span id="remove-and-clear-methods-of-related-managers"></span><h3><code class="docutils literal"><span class="pre">remove()</span></code> and <code class="docutils literal"><span class="pre">clear()</span></code> methods of related managers<a class="headerlink" href="#remove-and-clear-methods-of-related-managers" title="Permalink to this headline">¶</a></h3>
<p>The <code class="docutils literal"><span class="pre">remove()</span></code> and <code class="docutils literal"><span class="pre">clear()</span></code> methods of the related managers created by
<code class="docutils literal"><span class="pre">ForeignKey</span></code>, <code class="docutils literal"><span class="pre">GenericForeignKey</span></code>, and <code class="docutils literal"><span class="pre">ManyToManyField</span></code> suffered from a
number of issues. Some operations ran multiple data modifying queries without
wrapping them in a transaction, and some operations didn’t respect default
filtering when it was present (i.e. when the default manager on the related
model implemented a custom <code class="docutils literal"><span class="pre">get_queryset()</span></code>).</p>
<p>Fixing the issues introduced some backward incompatible changes:</p>
<ul class="simple">
<li>The default implementation of <code class="docutils literal"><span class="pre">remove()</span></code> for <code class="docutils literal"><span class="pre">ForeignKey</span></code> related managers
changed from a series of <code class="docutils literal"><span class="pre">Model.save()</span></code> calls to a single
<code class="docutils literal"><span class="pre">QuerySet.update()</span></code> call. The change means that <code class="docutils literal"><span class="pre">pre_save</span></code> and
<code class="docutils literal"><span class="pre">post_save</span></code> signals aren’t sent anymore. You can use the <code class="docutils literal"><span class="pre">bulk=False</span></code>
keyword argument to revert to the previous behavior.</li>
<li>The <code class="docutils literal"><span class="pre">remove()</span></code> and <code class="docutils literal"><span class="pre">clear()</span></code> methods for <code class="docutils literal"><span class="pre">GenericForeignKey</span></code> related
managers now perform bulk delete. The <code class="docutils literal"><span class="pre">Model.delete()</span></code> method isn’t called
on each instance anymore. You can use the <code class="docutils literal"><span class="pre">bulk=False</span></code> keyword argument to
revert to the previous behavior.</li>
<li>The <code class="docutils literal"><span class="pre">remove()</span></code> and <code class="docutils literal"><span class="pre">clear()</span></code> methods for <code class="docutils literal"><span class="pre">ManyToManyField</span></code> related
managers perform nested queries when filtering is involved, which may or
may not be an issue depending on your database and your data itself.
See <a class="reference internal" href="../ref/models/querysets.html#nested-queries-performance"><span class="std std-ref">this note</span></a> for more details.</li>
</ul>
</div>
<div class="section" id="s-admin-login-redirection-strategy">
<span id="admin-login-redirection-strategy"></span><h3>Admin login redirection strategy<a class="headerlink" href="#admin-login-redirection-strategy" title="Permalink to this headline">¶</a></h3>
<p>Historically, the Django admin site passed the request from an unauthorized or
unauthenticated user directly to the login view, without HTTP redirection. In
Django 1.7, this behavior changed to conform to a more traditional workflow
where any unauthorized request to an admin page will be redirected (by HTTP
status code 302) to the login page, with the <code class="docutils literal"><span class="pre">next</span></code> parameter set to the
referring path. The user will be redirected there after a successful login.</p>
<p>Note also that the admin login form has been updated to not contain the
<code class="docutils literal"><span class="pre">this_is_the_login_form</span></code> field (now unused) and the <code class="docutils literal"><span class="pre">ValidationError</span></code> code
has been set to the more regular <code class="docutils literal"><span class="pre">invalid_login</span></code> key.</p>
</div>
<div class="section" id="s-select-for-update-requires-a-transaction">
<span id="select-for-update-requires-a-transaction"></span><h3><code class="docutils literal"><span class="pre">select_for_update()</span></code> requires a transaction<a class="headerlink" href="#select-for-update-requires-a-transaction" title="Permalink to this headline">¶</a></h3>
<p>Historically, queries that use
<a class="reference internal" href="../ref/models/querysets.html#django.db.models.query.QuerySet.select_for_update" title="django.db.models.query.QuerySet.select_for_update"><code class="xref py py-meth docutils literal"><span class="pre">select_for_update()</span></code></a> could be
executed in autocommit mode, outside of a transaction. Before Django
1.6, Django’s automatic transactions mode allowed this to be used to
lock records until the next write operation. Django 1.6 introduced
database-level autocommit; since then, execution in such a context
voids the effect of <code class="docutils literal"><span class="pre">select_for_update()</span></code>. It is, therefore, assumed
now to be an error and raises an exception.</p>
<p>This change was made because such errors can be caused by including an
app which expects global transactions (e.g. <a class="reference internal" href="../ref/settings.html#std:setting-DATABASE-ATOMIC_REQUESTS"><code class="xref std std-setting docutils literal"><span class="pre">ATOMIC_REQUESTS</span></code></a> set to <code class="docutils literal"><span class="pre">True</span></code>), or Django’s old autocommit
behavior, in a project which runs without them; and further, such
errors may manifest as data-corruption bugs. It was also made in
Django 1.6.3.</p>
<p>This change may cause test failures if you use <code class="docutils literal"><span class="pre">select_for_update()</span></code>
in a test class which is a subclass of
<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> rather than
<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>.</p>
</div>
<div class="section" id="s-contrib-middleware-removed-from-default-middleware-classes">
<span id="contrib-middleware-removed-from-default-middleware-classes"></span><h3>Contrib middleware removed from default <a class="reference internal" href="../ref/settings.html#std:setting-MIDDLEWARE_CLASSES"><code class="xref std std-setting docutils literal"><span class="pre">MIDDLEWARE_CLASSES</span></code></a><a class="headerlink" href="#contrib-middleware-removed-from-default-middleware-classes" title="Permalink to this headline">¶</a></h3>
<p>The <a class="reference internal" href="#app-loading-refactor-17-release-note"><span class="std std-ref">app-loading refactor</span></a>
deprecated using models from apps which are not part of the
<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> setting. This exposed an incompatibility between
the default <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> and <a class="reference internal" href="../ref/settings.html#std:setting-MIDDLEWARE_CLASSES"><code class="xref std std-setting docutils literal"><span class="pre">MIDDLEWARE_CLASSES</span></code></a> in the
global defaults (<code class="docutils literal"><span class="pre">django.conf.global_settings</span></code>). To bring these settings in
sync and prevent deprecation warnings when doing things like testing reusable
apps with minimal settings,
<a class="reference internal" href="../ref/middleware.html#django.contrib.sessions.middleware.SessionMiddleware" title="django.contrib.sessions.middleware.SessionMiddleware"><code class="xref py py-class docutils literal"><span class="pre">SessionMiddleware</span></code></a>,
<a class="reference internal" href="../ref/middleware.html#django.contrib.auth.middleware.AuthenticationMiddleware" title="django.contrib.auth.middleware.AuthenticationMiddleware"><code class="xref py py-class docutils literal"><span class="pre">AuthenticationMiddleware</span></code></a>, and
<a class="reference internal" href="../ref/middleware.html#django.contrib.messages.middleware.MessageMiddleware" title="django.contrib.messages.middleware.MessageMiddleware"><code class="xref py py-class docutils literal"><span class="pre">MessageMiddleware</span></code></a> were removed
from the defaults. These classes will still be included in the default settings
generated by <a class="reference internal" href="../ref/django-admin.html#django-admin-startproject"><code class="xref std std-djadmin docutils literal"><span class="pre">startproject</span></code></a>. Most projects will not be affected by
this change but if you were not previously declaring the
<a class="reference internal" href="../ref/settings.html#std:setting-MIDDLEWARE_CLASSES"><code class="xref std std-setting docutils literal"><span class="pre">MIDDLEWARE_CLASSES</span></code></a> in your project settings and relying on the
global default you should ensure that the new defaults are in line with your
project’s needs. You should also check for any code that accesses
<code class="docutils literal"><span class="pre">django.conf.global_settings.MIDDLEWARE_CLASSES</span></code> directly.</p>
</div>
<div class="section" id="s-miscellaneous">
<span id="miscellaneous"></span><h3>Miscellaneous<a class="headerlink" href="#miscellaneous" title="Permalink to this headline">¶</a></h3>
<ul>
<li><p class="first">The <a class="reference internal" href="../ref/files/uploads.html#django.core.files.uploadhandler.FileUploadHandler.new_file" title="django.core.files.uploadhandler.FileUploadHandler.new_file"><code class="xref py py-meth docutils literal"><span class="pre">django.core.files.uploadhandler.FileUploadHandler.new_file()</span></code></a>
method is now passed an additional <code class="docutils literal"><span class="pre">content_type_extra</span></code> parameter. If you
have a custom <a class="reference internal" href="../ref/files/uploads.html#django.core.files.uploadhandler.FileUploadHandler" title="django.core.files.uploadhandler.FileUploadHandler"><code class="xref py py-class docutils literal"><span class="pre">FileUploadHandler</span></code></a>
that implements <code class="docutils literal"><span class="pre">new_file()</span></code>, be sure it accepts this new parameter.</p>
</li>
<li><p class="first"><a class="reference internal" href="../topics/forms/modelforms.html#django.forms.models.BaseModelFormSet" title="django.forms.models.BaseModelFormSet"><code class="xref py py-class docutils literal"><span class="pre">ModelFormSet</span></code></a>s no longer
delete instances when <code class="docutils literal"><span class="pre">save(commit=False)</span></code> is called. See
<a class="reference internal" href="../topics/forms/formsets.html#django.forms.formsets.BaseFormSet.can_delete" title="django.forms.formsets.BaseFormSet.can_delete"><code class="xref py py-attr docutils literal"><span class="pre">can_delete</span></code></a> for instructions on how
to manually delete objects from deleted forms.</p>
</li>
<li><p class="first">Loading empty fixtures emits a <code class="docutils literal"><span class="pre">RuntimeWarning</span></code> rather than raising
<a class="reference internal" href="../howto/custom-management-commands.html#django.core.management.CommandError" title="django.core.management.CommandError"><code class="xref py py-class docutils literal"><span class="pre">CommandError</span></code></a>.</p>
</li>
<li><p class="first"><a class="reference internal" href="../ref/contrib/staticfiles.html#django.contrib.staticfiles.views.serve" title="django.contrib.staticfiles.views.serve"><code class="xref py py-func docutils literal"><span class="pre">django.contrib.staticfiles.views.serve()</span></code></a> will now raise an
<a class="reference internal" href="../topics/http/views.html#django.http.Http404" title="django.http.Http404"><code class="xref py py-exc docutils literal"><span class="pre">Http404</span></code></a> exception instead of
<a class="reference internal" href="../ref/exceptions.html#django.core.exceptions.ImproperlyConfigured" title="django.core.exceptions.ImproperlyConfigured"><code class="xref py py-exc docutils literal"><span class="pre">ImproperlyConfigured</span></code></a> 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">False</span></code>. This change removes the need to conditionally add the view to
your root URLconf, which in turn makes it safe to reverse by name. It also
removes the ability for visitors to generate spurious HTTP 500 errors by
requesting static files that don’t exist or haven’t been collected yet.</p>
</li>
<li><p class="first">The <a class="reference internal" href="../ref/models/instances.html#django.db.models.Model.__eq__" title="django.db.models.Model.__eq__"><code class="xref py py-meth docutils literal"><span class="pre">django.db.models.Model.__eq__()</span></code></a> method is now defined in a
way where instances of a proxy model and its base model are considered
equal when primary keys match. Previously only instances of exact same
class were considered equal on primary key match.</p>
</li>
<li><p class="first">The <a class="reference internal" href="../ref/models/instances.html#django.db.models.Model.__eq__" title="django.db.models.Model.__eq__"><code class="xref py py-meth docutils literal"><span class="pre">django.db.models.Model.__eq__()</span></code></a> method has changed such that
two <code class="docutils literal"><span class="pre">Model</span></code> instances without primary key values won’t be considered
equal (unless they are the same instance).</p>
</li>
<li><p class="first">The <a class="reference internal" href="../ref/models/instances.html#django.db.models.Model.__hash__" title="django.db.models.Model.__hash__"><code class="xref py py-meth docutils literal"><span class="pre">django.db.models.Model.__hash__()</span></code></a> method will now raise <code class="docutils literal"><span class="pre">TypeError</span></code>
when called on an instance without a primary key value. This is done to
avoid mutable <code class="docutils literal"><span class="pre">__hash__</span></code> values in containers.</p>
</li>
<li><p class="first"><a class="reference internal" href="../ref/models/fields.html#django.db.models.AutoField" title="django.db.models.AutoField"><code class="xref py py-class docutils literal"><span class="pre">AutoField</span></code></a> columns in SQLite databases will now be
created using the <code class="docutils literal"><span class="pre">AUTOINCREMENT</span></code> option, which guarantees monotonic
increments. This will cause primary key numbering behavior to change on
SQLite, becoming consistent with most other SQL databases. This will only
apply to newly created tables. If you have a database created with an older
version of Django, you will need to migrate it to take advantage of this
feature. For example, you could do the following:</p>
<ol class="arabic simple">
<li>Use <a class="reference internal" href="../ref/django-admin.html#django-admin-dumpdata"><code class="xref std std-djadmin docutils literal"><span class="pre">dumpdata</span></code></a> to save your data.</li>
<li>Rename the existing database file (keep it as a backup).</li>
<li>Run <a class="reference internal" href="../ref/django-admin.html#django-admin-migrate"><code class="xref std std-djadmin docutils literal"><span class="pre">migrate</span></code></a> to create the updated schema.</li>
<li>Use <a class="reference internal" href="../ref/django-admin.html#django-admin-loaddata"><code class="xref std std-djadmin docutils literal"><span class="pre">loaddata</span></code></a> to import the fixtures you exported in (1).</li>
</ol>
</li>
<li><p class="first"><code class="docutils literal"><span class="pre">django.contrib.auth.models.AbstractUser</span></code> no longer defines a
<a class="reference internal" href="../ref/models/instances.html#django.db.models.Model.get_absolute_url" title="django.db.models.Model.get_absolute_url"><code class="xref py py-meth docutils literal"><span class="pre">get_absolute_url()</span></code></a> method. The old definition
returned <code class="docutils literal"><span class="pre">"/users/%s/"</span> <span class="pre">%</span> <span class="pre">urlquote(self.username)</span></code> which was arbitrary
since applications may or may not define such a url in <code class="docutils literal"><span class="pre">urlpatterns</span></code>.
Define a <code class="docutils literal"><span class="pre">get_absolute_url()</span></code> method on your own custom user object or use
<a class="reference internal" href="../ref/settings.html#std:setting-ABSOLUTE_URL_OVERRIDES"><code class="xref std std-setting docutils literal"><span class="pre">ABSOLUTE_URL_OVERRIDES</span></code></a> if you want a URL for your user.</p>
</li>
<li><p class="first">The static asset-serving functionality of the
<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">django.test.LiveServerTestCase</span></code></a> class has been simplified: Now it’s
only able to serve content already present in <a class="reference internal" href="../ref/settings.html#std:setting-STATIC_ROOT"><code class="xref std std-setting docutils literal"><span class="pre">STATIC_ROOT</span></code></a> when
tests are run. The ability to transparently serve all the static assets
(similarly to what one gets with <a class="reference internal" href="../ref/settings.html#std:setting-DEBUG"><code class="xref std std-setting docutils literal"><span class="pre">DEBUG</span> <span class="pre">=</span> <span class="pre">True</span></code></a> at
development-time) has been moved to a new class that lives in the
<code class="docutils literal"><span class="pre">staticfiles</span></code> application (the one actually in charge of such feature):
<a class="reference internal" href="../ref/contrib/staticfiles.html#django.contrib.staticfiles.testing.StaticLiveServerTestCase" title="django.contrib.staticfiles.testing.StaticLiveServerTestCase"><code class="xref py py-class docutils literal"><span class="pre">django.contrib.staticfiles.testing.StaticLiveServerTestCase</span></code></a>. In other
words, <code class="docutils literal"><span class="pre">LiveServerTestCase</span></code> itself is less powerful but at the same time
has less magic.</p>
<p>Rationale behind this is removal of dependency of non-contrib code on
contrib applications.</p>
</li>
<li><p class="first">The old cache URI syntax (e.g. <code class="docutils literal"><span class="pre">"locmem://"</span></code>) is no longer supported. It
still worked, even though it was not documented or officially supported. If
you’re still using it, please update to the current <a class="reference internal" href="../ref/settings.html#std:setting-CACHES"><code class="xref std std-setting docutils literal"><span class="pre">CACHES</span></code></a> syntax.</p>
</li>
<li><p class="first">The default ordering of <code class="docutils literal"><span class="pre">Form</span></code> fields in case of inheritance has changed to
follow normal Python MRO. Fields are now discovered by iterating through the
MRO in reverse with the topmost class coming last. This only affects you if
you relied on the default field ordering while having fields defined on both
the current class <em>and</em> on a parent <code class="docutils literal"><span class="pre">Form</span></code>.</p>
</li>
<li><p class="first">The <code class="docutils literal"><span class="pre">required</span></code> argument of
<a class="reference internal" href="../ref/forms/widgets.html#django.forms.extras.widgets.SelectDateWidget" title="django.forms.extras.widgets.SelectDateWidget"><code class="xref py py-class docutils literal"><span class="pre">SelectDateWidget</span></code></a> has been removed.
This widget now respects the form field’s <code class="docutils literal"><span class="pre">is_required</span></code> attribute like
other widgets.</p>
</li>
<li><p class="first"><code class="docutils literal"><span class="pre">Widget.is_hidden</span></code> is now a read-only property, getting its value by
introspecting the presence of <code class="docutils literal"><span class="pre">input_type</span> <span class="pre">==</span> <span class="pre">'hidden'</span></code>.</p>
</li>
<li><p class="first"><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 chains in the
same way as other similar calls like <code class="docutils literal"><span class="pre">prefetch_related</span></code>. That is,
<code class="docutils literal"><span class="pre">select_related('foo',</span> <span class="pre">'bar')</span></code> is equivalent to
<code class="docutils literal"><span class="pre">select_related('foo').select_related('bar')</span></code>. Previously the latter would
have been equivalent to <code class="docutils literal"><span class="pre">select_related('bar')</span></code>.</p>
</li>
<li><p class="first">GeoDjango dropped support for GEOS < 3.1.</p>
</li>
<li><p class="first">The <code class="docutils literal"><span class="pre">init_connection_state</span></code> method of database backends now executes in
autocommit mode (unless you set <a class="reference internal" href="../ref/settings.html#std:setting-DATABASE-AUTOCOMMIT"><code class="xref std std-setting docutils literal"><span class="pre">AUTOCOMMIT</span></code></a>
to <code class="docutils literal"><span class="pre">False</span></code>). If you maintain a custom database backend, you should check
that method.</p>
</li>
<li><p class="first">The <code class="docutils literal"><span class="pre">django.db.backends.BaseDatabaseFeatures.allows_primary_key_0</span></code>
attribute has been renamed to <code class="docutils literal"><span class="pre">allows_auto_pk_0</span></code> to better describe it.
It’s <code class="docutils literal"><span class="pre">True</span></code> for all database backends included with Django except MySQL
which does allow primary keys with value 0. It only forbids <em>autoincrement</em>
primary keys with value 0.</p>
</li>
<li><p class="first">Shadowing model fields defined in a parent model has been forbidden as this
creates ambiguity in the expected model behavior. In addition, clashing
fields in the model inheritance hierarchy result in a system check error.
For example, if you use multi-inheritance, you need to define custom primary
key fields on parent models, otherwise the default <code class="docutils literal"><span class="pre">id</span></code> fields will clash.
See <a class="reference internal" href="../topics/db/models.html#model-multiple-inheritance-topic"><span class="std std-ref">Multiple inheritance</span></a> for details.</p>
</li>
<li><p class="first"><code class="docutils literal"><span class="pre">django.utils.translation.parse_accept_lang_header()</span></code> now returns
lowercase locales, instead of the case as it was provided. As locales should
be treated case-insensitive this allows us to speed up locale detection.</p>
</li>
<li><p class="first"><code class="docutils literal"><span class="pre">django.utils.translation.get_language_from_path()</span></code> and
<code class="docutils literal"><span class="pre">django.utils.translation.trans_real.get_supported_language_variant()</span></code>
now no longer have a <code class="docutils literal"><span class="pre">supported</span></code> argument.</p>
</li>
<li><p class="first">The <code class="docutils literal"><span class="pre">shortcut</span></code> view in <code class="docutils literal"><span class="pre">django.contrib.contenttypes.views</span></code> now supports
protocol-relative URLs (e.g. <code class="docutils literal"><span class="pre">//example.com</span></code>).</p>
</li>
<li><p class="first"><a class="reference internal" href="../ref/contrib/contenttypes.html#django.contrib.contenttypes.fields.GenericRelation" title="django.contrib.contenttypes.fields.GenericRelation"><code class="xref py py-class docutils literal"><span class="pre">GenericRelation</span></code></a> now supports an
optional <code class="docutils literal"><span class="pre">related_query_name</span></code> argument. Setting <code class="docutils literal"><span class="pre">related_query_name</span></code> adds
a relation from the related object back to the content type for filtering,
ordering and other query operations.</p>
</li>
<li><p class="first">When running tests on PostgreSQL, the <a class="reference internal" href="../ref/settings.html#std:setting-USER"><code class="xref std std-setting docutils literal"><span class="pre">USER</span></code></a> will need read access
to the built-in <code class="docutils literal"><span class="pre">postgres</span></code> database. This is in lieu of the previous
behavior of connecting to the actual non-test database.</p>
</li>
<li><p class="first">As part of the <a class="reference internal" href="../ref/checks.html"><span class="doc">System check framework</span></a>, <a class="reference internal" href="../topics/checks.html#field-checking"><span class="std std-ref">fields,
models, and model managers</span></a> all implement a <code class="docutils literal"><span class="pre">check()</span></code>
method that is registered with the check framework. If you have an existing
method called <code class="docutils literal"><span class="pre">check()</span></code> on one of these objects, you will need to rename it.</p>
</li>
<li><p class="first">As noted above in the “Cache” section of “Minor Features”, defining the
<a class="reference internal" href="../ref/settings.html#std:setting-CACHES-TIMEOUT"><code class="xref std std-setting docutils literal"><span class="pre">TIMEOUT</span></code></a> argument of the
<a class="reference internal" href="../ref/settings.html#std:setting-CACHES"><code class="xref std std-setting docutils literal"><span class="pre">CACHES</span></code></a> setting as <code class="docutils literal"><span class="pre">None</span></code> will set the cache keys as
“non-expiring”. Previously, with the memcache backend, a
<a class="reference internal" href="../ref/settings.html#std:setting-CACHES-TIMEOUT"><code class="xref std std-setting docutils literal"><span class="pre">TIMEOUT</span></code></a> of <code class="docutils literal"><span class="pre">0</span></code> would set non-expiring keys,
but this was inconsistent with the set-and-expire (i.e. no caching) behavior
of <code class="docutils literal"><span class="pre">set("key",</span> <span class="pre">"value",</span> <span class="pre">timeout=0)</span></code>. If you want non-expiring keys,
please update your settings to use <code class="docutils literal"><span class="pre">None</span></code> instead of <code class="docutils literal"><span class="pre">0</span></code> as the latter
now designates set-and-expire in the settings as well.</p>
</li>
<li><p class="first">The <code class="docutils literal"><span class="pre">sql*</span></code> management commands now respect the <code class="docutils literal"><span class="pre">allow_migrate()</span></code> method
of <a class="reference internal" href="../ref/settings.html#std:setting-DATABASE_ROUTERS"><code class="xref std std-setting docutils literal"><span class="pre">DATABASE_ROUTERS</span></code></a>. If you have models synced to non-default
databases, use 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> flag to get SQL for those
models (previously they would always be included in the output).</p>
</li>
<li><p class="first">Decoding the query string from URLs now falls back to the ISO-8859-1 encoding
when the input is not valid UTF-8.</p>
</li>
<li><p class="first">With the addition of the
<a class="reference internal" href="../ref/middleware.html#django.contrib.auth.middleware.SessionAuthenticationMiddleware" title="django.contrib.auth.middleware.SessionAuthenticationMiddleware"><code class="xref py py-class docutils literal"><span class="pre">SessionAuthenticationMiddleware</span></code></a> to
the default project template (pre-1.7.2 only), a database must be created
before accessing a page using <a class="reference internal" href="../ref/django-admin.html#django-admin-runserver"><code class="xref std std-djadmin docutils literal"><span class="pre">runserver</span></code></a>.</p>
</li>
<li><p class="first">The addition of the <code class="docutils literal"><span class="pre">schemes</span></code> argument to <code class="docutils literal"><span class="pre">URLValidator</span></code> will appear
as a backwards-incompatible change if you were previously using a custom
regular expression to validate schemes. Any scheme not listed in <code class="docutils literal"><span class="pre">schemes</span></code>
will fail validation, even if the regular expression matches the given URL.</p>
</li>
</ul>
</div>
</div>
<div class="section" id="s-features-deprecated-in-1-7">
<span id="s-deprecated-features-1-7"></span><span id="features-deprecated-in-1-7"></span><span id="deprecated-features-1-7"></span><h2>Features deprecated in 1.7<a class="headerlink" href="#features-deprecated-in-1-7" title="Permalink to this headline">¶</a></h2>
<div class="section" id="s-django-core-cache-get-cache">
<span id="django-core-cache-get-cache"></span><h3><code class="docutils literal"><span class="pre">django.core.cache.get_cache</span></code><a class="headerlink" href="#django-core-cache-get-cache" title="Permalink to this headline">¶</a></h3>
<p><a class="reference internal" href="../topics/cache.html#django.core.cache.get_cache" title="django.core.cache.get_cache"><code class="xref py py-func docutils literal"><span class="pre">django.core.cache.get_cache()</span></code></a> has been supplanted by
<a class="reference internal" href="../topics/cache.html#django.core.cache.caches" title="django.core.cache.caches"><code class="xref py py-data docutils literal"><span class="pre">django.core.cache.caches</span></code></a>.</p>
</div>
<div class="section" id="s-django-utils-dictconfig-django-utils-importlib">
<span id="django-utils-dictconfig-django-utils-importlib"></span><h3><code class="docutils literal"><span class="pre">django.utils.dictconfig</span></code>/<code class="docutils literal"><span class="pre">django.utils.importlib</span></code><a class="headerlink" href="#django-utils-dictconfig-django-utils-importlib" title="Permalink to this headline">¶</a></h3>
<p><code class="docutils literal"><span class="pre">django.utils.dictconfig</span></code> and <code class="docutils literal"><span class="pre">django.utils.importlib</span></code> were copies of
respectively <code class="xref py py-mod docutils literal"><span class="pre">logging.config</span></code> and <code class="xref py py-mod docutils literal"><span class="pre">importlib</span></code> provided for Python
versions prior to 2.7. They have been deprecated.</p>
</div>
<div class="section" id="s-django-utils-module-loading-import-by-path">
<span id="django-utils-module-loading-import-by-path"></span><h3><code class="docutils literal"><span class="pre">django.utils.module_loading.import_by_path</span></code><a class="headerlink" href="#django-utils-module-loading-import-by-path" title="Permalink to this headline">¶</a></h3>
<p>The current <a class="reference internal" href="../ref/utils.html#django.utils.module_loading.import_by_path" title="django.utils.module_loading.import_by_path"><code class="xref py py-meth docutils literal"><span class="pre">import_by_path()</span></code></a> function
catches <code class="docutils literal"><span class="pre">AttributeError</span></code>, <code class="docutils literal"><span class="pre">ImportError</span></code> and <code class="docutils literal"><span class="pre">ValueError</span></code> exceptions,
and re-raises <a class="reference internal" href="../ref/exceptions.html#django.core.exceptions.ImproperlyConfigured" title="django.core.exceptions.ImproperlyConfigured"><code class="xref py py-exc docutils literal"><span class="pre">ImproperlyConfigured</span></code></a>. Such
exception masking makes it needlessly hard to diagnose circular import
problems, because it makes it look like the problem comes from inside Django.
It has been deprecated in favor of
<a class="reference internal" href="../ref/utils.html#django.utils.module_loading.import_string" title="django.utils.module_loading.import_string"><code class="xref py py-meth docutils literal"><span class="pre">import_string()</span></code></a>.</p>
</div>
<div class="section" id="s-django-utils-tzinfo">
<span id="django-utils-tzinfo"></span><h3><code class="docutils literal"><span class="pre">django.utils.tzinfo</span></code><a class="headerlink" href="#django-utils-tzinfo" title="Permalink to this headline">¶</a></h3>
<p><code class="docutils literal"><span class="pre">django.utils.tzinfo</span></code> provided two <code class="xref py py-class docutils literal"><span class="pre">tzinfo</span></code> subclasses,
<code class="docutils literal"><span class="pre">LocalTimezone</span></code> and <code class="docutils literal"><span class="pre">FixedOffset</span></code>. They’ve been deprecated in favor of
more correct alternatives provided by <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>,
<a class="reference internal" href="../ref/utils.html#django.utils.timezone.get_default_timezone" title="django.utils.timezone.get_default_timezone"><code class="xref py py-func docutils literal"><span class="pre">django.utils.timezone.get_default_timezone()</span></code></a> and
<a class="reference internal" href="../ref/utils.html#django.utils.timezone.get_fixed_timezone" title="django.utils.timezone.get_fixed_timezone"><code class="xref py py-func docutils literal"><span class="pre">django.utils.timezone.get_fixed_timezone()</span></code></a>.</p>
</div>
<div class="section" id="s-django-utils-unittest">
<span id="django-utils-unittest"></span><h3><code class="docutils literal"><span class="pre">django.utils.unittest</span></code><a class="headerlink" href="#django-utils-unittest" title="Permalink to this headline">¶</a></h3>
<p><code class="docutils literal"><span class="pre">django.utils.unittest</span></code> provided uniform access to the <code class="docutils literal"><span class="pre">unittest2</span></code> library
on all Python versions. Since <code class="docutils literal"><span class="pre">unittest2</span></code> became the standard library’s
<code class="xref py py-mod docutils literal"><span class="pre">unittest</span></code> module in Python 2.7, and Django 1.7 drops support for older
Python versions, this module isn’t useful anymore. It has been deprecated. Use
<code class="xref py py-mod docutils literal"><span class="pre">unittest</span></code> instead.</p>
</div>
<div class="section" id="s-django-utils-datastructures-sorteddict">
<span id="django-utils-datastructures-sorteddict"></span><h3><code class="docutils literal"><span class="pre">django.utils.datastructures.SortedDict</span></code><a class="headerlink" href="#django-utils-datastructures-sorteddict" title="Permalink to this headline">¶</a></h3>
<p>As <code class="xref py py-class docutils literal"><span class="pre">OrderedDict</span></code> was added to the standard library in
Python 2.7, <a class="reference internal" href="../ref/utils.html#django.utils.datastructures.SortedDict" title="django.utils.datastructures.SortedDict"><code class="xref py py-class docutils literal"><span class="pre">SortedDict</span></code></a> is no longer
needed and has been deprecated.</p>
<p>The two additional, deprecated methods provided by <code class="docutils literal"><span class="pre">SortedDict</span></code> (<code class="docutils literal"><span class="pre">insert()</span></code>
and <code class="docutils literal"><span class="pre">value_for_index()</span></code>) have been removed. If you relied on these methods to
alter structures like form fields, you should now treat these <code class="docutils literal"><span class="pre">OrderedDict</span></code>s
as immutable objects and override them to change their content.</p>
<p>For example, you might want to override <code class="docutils literal"><span class="pre">MyFormClass.base_fields</span></code> (although
this attribute isn’t considered a public API) to change the ordering of fields
for all <code class="docutils literal"><span class="pre">MyFormClass</span></code> instances; or similarly, you could override
<code class="docutils literal"><span class="pre">self.fields</span></code> from inside <code class="docutils literal"><span class="pre">MyFormClass.__init__()</span></code>, to change the fields
for a particular form instance. For example (from Django itself):</p>
<div class="highlight-default"><div class="highlight"><pre><span></span><span class="n">PasswordChangeForm</span><span class="o">.</span><span class="n">base_fields</span> <span class="o">=</span> <span class="n">OrderedDict</span><span class="p">(</span>
<span class="p">(</span><span class="n">k</span><span class="p">,</span> <span class="n">PasswordChangeForm</span><span class="o">.</span><span class="n">base_fields</span><span class="p">[</span><span class="n">k</span><span class="p">])</span>
<span class="k">for</span> <span class="n">k</span> <span class="ow">in</span> <span class="p">[</span><span class="s1">'old_password'</span><span class="p">,</span> <span class="s1">'new_password1'</span><span class="p">,</span> <span class="s1">'new_password2'</span><span class="p">]</span>
<span class="p">)</span>
</pre></div>
</div>
</div>
<div class="section" id="s-custom-sql-location-for-models-package">
<span id="custom-sql-location-for-models-package"></span><h3>Custom SQL location for models package<a class="headerlink" href="#custom-sql-location-for-models-package" title="Permalink to this headline">¶</a></h3>
<p>Previously, if models were organized in a package (<code class="docutils literal"><span class="pre">myapp/models/</span></code>) rather
than simply <code class="docutils literal"><span class="pre">myapp/models.py</span></code>, Django would look for <a class="reference internal" href="../howto/initial-data.html#initial-sql"><span class="std std-ref">initial SQL data</span></a> in <code class="docutils literal"><span class="pre">myapp/models/sql/</span></code>. This bug has been fixed so that Django
will search <code class="docutils literal"><span class="pre">myapp/sql/</span></code> as documented. After this issue was fixed, migrations
were added which deprecates initial SQL data. Thus, while this change still
exists, the deprecation is irrelevant as the entire feature will be removed in
Django 1.9.</p>
</div>
<div class="section" id="s-reorganization-of-django-contrib-sites">
<span id="reorganization-of-django-contrib-sites"></span><h3>Reorganization of <code class="docutils literal"><span class="pre">django.contrib.sites</span></code><a class="headerlink" href="#reorganization-of-django-contrib-sites" title="Permalink to this headline">¶</a></h3>
<p><code class="docutils literal"><span class="pre">django.contrib.sites</span></code> provides reduced functionality when it isn’t in
<a class="reference internal" href="../ref/settings.html#std:setting-INSTALLED_APPS"><code class="xref std std-setting docutils literal"><span class="pre">INSTALLED_APPS</span></code></a>. The app-loading refactor adds some constraints in
that situation. As a consequence, two objects were moved, and the old
locations are deprecated:</p>
<ul class="simple">
<li><a class="reference internal" href="../ref/contrib/sites.html#django.contrib.sites.requests.RequestSite" title="django.contrib.sites.requests.RequestSite"><code class="xref py py-class docutils literal"><span class="pre">RequestSite</span></code></a> now lives in
<code class="docutils literal"><span class="pre">django.contrib.sites.requests</span></code>.</li>
<li><a class="reference internal" href="../ref/contrib/sites.html#django.contrib.sites.shortcuts.get_current_site" title="django.contrib.sites.shortcuts.get_current_site"><code class="xref py py-func docutils literal"><span class="pre">get_current_site()</span></code></a> now lives in
<code class="docutils literal"><span class="pre">django.contrib.sites.shortcuts</span></code>.</li>
</ul>
</div>
<div class="section" id="s-declared-fieldsets-attribute-on-modeladmin">
<span id="declared-fieldsets-attribute-on-modeladmin"></span><h3><code class="docutils literal"><span class="pre">declared_fieldsets</span></code> attribute on <code class="docutils literal"><span class="pre">ModelAdmin</span></code><a class="headerlink" href="#declared-fieldsets-attribute-on-modeladmin" title="Permalink to this headline">¶</a></h3>
<p><code class="docutils literal"><span class="pre">ModelAdmin.declared_fieldsets</span></code> has been deprecated. Despite being a private
API, it will go through a regular deprecation path. This attribute was mostly
used by methods that bypassed <code class="docutils literal"><span class="pre">ModelAdmin.get_fieldsets()</span></code> but this was
considered a bug and has been addressed.</p>
</div>
<div class="section" id="s-reorganization-of-django-contrib-contenttypes">
<span id="reorganization-of-django-contrib-contenttypes"></span><h3>Reorganization of <code class="docutils literal"><span class="pre">django.contrib.contenttypes</span></code><a class="headerlink" href="#reorganization-of-django-contrib-contenttypes" title="Permalink to this headline">¶</a></h3>
<p>Since <code class="docutils literal"><span class="pre">django.contrib.contenttypes.generic</span></code> defined both admin and model
related objects, an import of this module could trigger unexpected side effects.
As a consequence, its contents were split into <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>
submodules and the <code class="docutils literal"><span class="pre">django.contrib.contenttypes.generic</span></code> module is deprecated:</p>
<ul class="simple">
<li><a class="reference internal" href="../ref/contrib/contenttypes.html#django.contrib.contenttypes.fields.GenericForeignKey" title="django.contrib.contenttypes.fields.GenericForeignKey"><code class="xref py py-class docutils literal"><span class="pre">GenericForeignKey</span></code></a> and
<a class="reference internal" href="../ref/contrib/contenttypes.html#django.contrib.contenttypes.fields.GenericRelation" title="django.contrib.contenttypes.fields.GenericRelation"><code class="xref py py-class docutils literal"><span class="pre">GenericRelation</span></code></a> now live in
<a class="reference internal" href="../ref/contrib/contenttypes.html#module-django.contrib.contenttypes.fields" title="django.contrib.contenttypes.fields"><code class="xref py py-mod docutils literal"><span class="pre">fields</span></code></a>.</li>
<li><a class="reference internal" href="../ref/contrib/contenttypes.html#django.contrib.contenttypes.forms.BaseGenericInlineFormSet" title="django.contrib.contenttypes.forms.BaseGenericInlineFormSet"><code class="xref py py-class docutils literal"><span class="pre">BaseGenericInlineFormSet</span></code></a> and
<a class="reference internal" href="../ref/contrib/contenttypes.html#django.contrib.contenttypes.forms.generic_inlineformset_factory" title="django.contrib.contenttypes.forms.generic_inlineformset_factory"><code class="xref py py-func docutils literal"><span class="pre">generic_inlineformset_factory()</span></code></a> now
live in <a class="reference internal" href="../ref/contrib/contenttypes.html#module-django.contrib.contenttypes.forms" title="django.contrib.contenttypes.forms"><code class="xref py py-mod docutils literal"><span class="pre">forms</span></code></a>.</li>
<li><a class="reference internal" href="../ref/contrib/contenttypes.html#django.contrib.contenttypes.admin.GenericInlineModelAdmin" title="django.contrib.contenttypes.admin.GenericInlineModelAdmin"><code class="xref py py-class docutils literal"><span class="pre">GenericInlineModelAdmin</span></code></a>,
<a class="reference internal" href="../ref/contrib/contenttypes.html#django.contrib.contenttypes.admin.GenericStackedInline" title="django.contrib.contenttypes.admin.GenericStackedInline"><code class="xref py py-class docutils literal"><span class="pre">GenericStackedInline</span></code></a> and
<a class="reference internal" href="../ref/contrib/contenttypes.html#django.contrib.contenttypes.admin.GenericTabularInline" title="django.contrib.contenttypes.admin.GenericTabularInline"><code class="xref py py-class docutils literal"><span class="pre">GenericTabularInline</span></code></a> now live in
<a class="reference internal" href="../ref/contrib/contenttypes.html#module-django.contrib.contenttypes.admin" title="django.contrib.contenttypes.admin"><code class="xref py py-mod docutils literal"><span class="pre">admin</span></code></a>.</li>
</ul>
</div>
<div class="section" id="s-syncdb">
<span id="syncdb"></span><h3><code class="docutils literal"><span class="pre">syncdb</span></code><a class="headerlink" href="#syncdb" title="Permalink to this headline">¶</a></h3>
<p>The <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> command has been deprecated in favor of the new <a class="reference internal" href="../ref/django-admin.html#django-admin-migrate"><code class="xref std std-djadmin docutils literal"><span class="pre">migrate</span></code></a>
command. <code class="docutils literal"><span class="pre">migrate</span></code> takes the same arguments as <code class="docutils literal"><span class="pre">syncdb</span></code> used to plus a few
more, so it’s safe to just change the name you’re calling and nothing else.</p>
</div>
<div class="section" id="s-util-modules-renamed-to-utils">
<span id="util-modules-renamed-to-utils"></span><h3><code class="docutils literal"><span class="pre">util</span></code> modules renamed to <code class="docutils literal"><span class="pre">utils</span></code><a class="headerlink" href="#util-modules-renamed-to-utils" title="Permalink to this headline">¶</a></h3>
<p>The following instances of <code class="docutils literal"><span class="pre">util.py</span></code> in the Django codebase have been renamed
to <code class="docutils literal"><span class="pre">utils.py</span></code> in an effort to unify all util and utils references:</p>
<ul class="simple">
<li><code class="docutils literal"><span class="pre">django.contrib.admin.util</span></code></li>
<li><code class="docutils literal"><span class="pre">django.contrib.gis.db.backends.util</span></code></li>
<li><code class="docutils literal"><span class="pre">django.db.backends.util</span></code></li>
<li><code class="docutils literal"><span class="pre">django.forms.util</span></code></li>
</ul>
</div>
<div class="section" id="s-get-formsets-method-on-modeladmin">
<span id="get-formsets-method-on-modeladmin"></span><h3><code class="docutils literal"><span class="pre">get_formsets</span></code> method on <code class="docutils literal"><span class="pre">ModelAdmin</span></code><a class="headerlink" href="#get-formsets-method-on-modeladmin" title="Permalink to this headline">¶</a></h3>
<p><code class="docutils literal"><span class="pre">ModelAdmin.get_formsets</span></code> has been deprecated in favor of the new
<a class="reference internal" href="../ref/contrib/admin/index.html#django.contrib.admin.ModelAdmin.get_formsets_with_inlines" title="django.contrib.admin.ModelAdmin.get_formsets_with_inlines"><code class="xref py py-meth docutils literal"><span class="pre">get_formsets_with_inlines()</span></code></a>, in order to
better handle the case of selectively showing inlines on a <code class="docutils literal"><span class="pre">ModelAdmin</span></code>.</p>
</div>
<div class="section" id="s-ipaddressfield">
<span id="ipaddressfield"></span><h3><code class="docutils literal"><span class="pre">IPAddressField</span></code><a class="headerlink" href="#ipaddressfield" title="Permalink to this headline">¶</a></h3>
<p>The <a class="reference internal" href="../ref/models/fields.html#django.db.models.IPAddressField" title="django.db.models.IPAddressField"><code class="xref py py-class docutils literal"><span class="pre">django.db.models.IPAddressField</span></code></a> and
<a class="reference internal" href="../ref/forms/fields.html#django.forms.IPAddressField" title="django.forms.IPAddressField"><code class="xref py py-class docutils literal"><span class="pre">django.forms.IPAddressField</span></code></a> fields have been deprecated in favor of
<a class="reference internal" href="../ref/models/fields.html#django.db.models.GenericIPAddressField" title="django.db.models.GenericIPAddressField"><code class="xref py py-class docutils literal"><span class="pre">django.db.models.GenericIPAddressField</span></code></a> and
<a class="reference internal" href="../ref/forms/fields.html#django.forms.GenericIPAddressField" title="django.forms.GenericIPAddressField"><code class="xref py py-class docutils literal"><span class="pre">django.forms.GenericIPAddressField</span></code></a>.</p>
</div>
<div class="section" id="s-basememcachedcache-get-memcache-timeout-method">
<span id="basememcachedcache-get-memcache-timeout-method"></span><h3><code class="docutils literal"><span class="pre">BaseMemcachedCache._get_memcache_timeout</span></code> method<a class="headerlink" href="#basememcachedcache-get-memcache-timeout-method" title="Permalink to this headline">¶</a></h3>
<p>The <code class="docutils literal"><span class="pre">BaseMemcachedCache._get_memcache_timeout()</span></code> method has been renamed to
<code class="docutils literal"><span class="pre">get_backend_timeout()</span></code>. Despite being a private API, it will go through the
normal deprecation.</p>
</div>
<div class="section" id="s-natural-key-serialization-options">
<span id="natural-key-serialization-options"></span><h3>Natural key serialization options<a class="headerlink" href="#natural-key-serialization-options" title="Permalink to this headline">¶</a></h3>
<p>The <code class="docutils literal"><span class="pre">--natural</span></code> and <code class="docutils literal"><span class="pre">-n</span></code> options for <a class="reference internal" href="../ref/django-admin.html#django-admin-dumpdata"><code class="xref std std-djadmin docutils literal"><span class="pre">dumpdata</span></code></a> have been
deprecated. Use <a class="reference internal" href="../ref/django-admin.html#django-admin-option---natural-foreign"><code class="xref std std-djadminopt docutils literal"><span class="pre">--natural-foreign</span></code></a> instead.</p>
<p>Similarly, the <code class="docutils literal"><span class="pre">use_natural_keys</span></code> argument for <code class="docutils literal"><span class="pre">serializers.serialize()</span></code>
has been deprecated. Use <code class="docutils literal"><span class="pre">use_natural_foreign_keys</span></code> instead.</p>
</div>
<div class="section" id="s-merging-of-post-and-get-arguments-into-wsgirequest-request">
<span id="merging-of-post-and-get-arguments-into-wsgirequest-request"></span><h3>Merging of <code class="docutils literal"><span class="pre">POST</span></code> and <code class="docutils literal"><span class="pre">GET</span></code> arguments into <code class="docutils literal"><span class="pre">WSGIRequest.REQUEST</span></code><a class="headerlink" href="#merging-of-post-and-get-arguments-into-wsgirequest-request" title="Permalink to this headline">¶</a></h3>
<p>It was already strongly suggested that you use <code class="docutils literal"><span class="pre">GET</span></code> and <code class="docutils literal"><span class="pre">POST</span></code> instead of
<code class="docutils literal"><span class="pre">REQUEST</span></code>, because the former are more explicit. The property <code class="docutils literal"><span class="pre">REQUEST</span></code> is
deprecated and will be removed in Django 1.9.</p>
</div>
<div class="section" id="s-django-utils-datastructures-mergedict-class">
<span id="django-utils-datastructures-mergedict-class"></span><h3><code class="docutils literal"><span class="pre">django.utils.datastructures.MergeDict</span></code> class<a class="headerlink" href="#django-utils-datastructures-mergedict-class" title="Permalink to this headline">¶</a></h3>
<p><code class="docutils literal"><span class="pre">MergeDict</span></code> exists primarily to support merging <code class="docutils literal"><span class="pre">POST</span></code> and <code class="docutils literal"><span class="pre">GET</span></code>
arguments into a <code class="docutils literal"><span class="pre">REQUEST</span></code> property on <code class="docutils literal"><span class="pre">WSGIRequest</span></code>. To merge
dictionaries, use <code class="docutils literal"><span class="pre">dict.update()</span></code> instead. The class <code class="docutils literal"><span class="pre">MergeDict</span></code> is
deprecated and will be removed in Django 1.9.</p>
</div>
<div class="section" id="s-language-codes-zh-cn-zh-tw-and-fy-nl">
<span id="language-codes-zh-cn-zh-tw-and-fy-nl"></span><h3>Language codes <code class="docutils literal"><span class="pre">zh-cn</span></code>, <code class="docutils literal"><span class="pre">zh-tw</span></code> and <code class="docutils literal"><span class="pre">fy-nl</span></code><a class="headerlink" href="#language-codes-zh-cn-zh-tw-and-fy-nl" title="Permalink to this headline">¶</a></h3>
<p>The currently used language codes for Simplified Chinese <code class="docutils literal"><span class="pre">zh-cn</span></code>,
Traditional Chinese <code class="docutils literal"><span class="pre">zh-tw</span></code> and (Western) Frysian <code class="docutils literal"><span class="pre">fy-nl</span></code> are deprecated
and should be replaced by the language codes <code class="docutils literal"><span class="pre">zh-hans</span></code>, <code class="docutils literal"><span class="pre">zh-hant</span></code> and
<code class="docutils literal"><span class="pre">fy</span></code> respectively. If you use these language codes, you should rename the
locale directories and update your settings to reflect these changes. The
deprecated language codes will be removed in Django 1.9.</p>
</div>
<div class="section" id="s-django-utils-functional-memoize-function">
<span id="django-utils-functional-memoize-function"></span><h3><code class="docutils literal"><span class="pre">django.utils.functional.memoize</span></code> function<a class="headerlink" href="#django-utils-functional-memoize-function" title="Permalink to this headline">¶</a></h3>
<p>The function <code class="docutils literal"><span class="pre">memoize</span></code> is deprecated and should be replaced by the
<code class="docutils literal"><span class="pre">functools.lru_cache</span></code> decorator (available from Python 3.2 onwards).</p>
<p>Django ships a backport of this decorator for older Python versions and it’s
available at <code class="docutils literal"><span class="pre">django.utils.lru_cache.lru_cache</span></code>. The deprecated function will
be removed in Django 1.9.</p>
</div>
<div class="section" id="s-geo-sitemaps">
<span id="geo-sitemaps"></span><h3>Geo Sitemaps<a class="headerlink" href="#geo-sitemaps" title="Permalink to this headline">¶</a></h3>
<p>Google has retired support for the Geo Sitemaps format. Hence Django support
for Geo Sitemaps is deprecated and will be removed in Django 1.8.</p>
</div>
<div class="section" id="s-passing-callable-arguments-to-queryset-methods">
<span id="passing-callable-arguments-to-queryset-methods"></span><h3>Passing callable arguments to queryset methods<a class="headerlink" href="#passing-callable-arguments-to-queryset-methods" title="Permalink to this headline">¶</a></h3>
<p>Callable arguments for querysets were an undocumented feature that was
unreliable. It’s been deprecated and will be removed in Django 1.9.</p>
<p>Callable arguments were evaluated when a queryset was constructed rather than
when it was evaluated, thus this feature didn’t offer any benefit compared to
evaluating arguments before passing them to queryset and created confusion that
the arguments may have been evaluated at query time.</p>
</div>
<div class="section" id="s-admin-for-setting">
<span id="admin-for-setting"></span><h3><code class="docutils literal"><span class="pre">ADMIN_FOR</span></code> setting<a class="headerlink" href="#admin-for-setting" title="Permalink to this headline">¶</a></h3>
<p>The <code class="docutils literal"><span class="pre">ADMIN_FOR</span></code> feature, part of the admindocs, has been removed. You can
remove the setting from your configuration at your convenience.</p>
</div>
<div class="section" id="s-splitdatetimewidget-with-datetimefield">
<span id="splitdatetimewidget-with-datetimefield"></span><h3><code class="docutils literal"><span class="pre">SplitDateTimeWidget</span></code> with <code class="docutils literal"><span class="pre">DateTimeField</span></code><a class="headerlink" href="#splitdatetimewidget-with-datetimefield" title="Permalink to this headline">¶</a></h3>
<p><code class="docutils literal"><span class="pre">SplitDateTimeWidget</span></code> support in <a class="reference internal" href="../ref/forms/fields.html#django.forms.DateTimeField" title="django.forms.DateTimeField"><code class="xref py py-class docutils literal"><span class="pre">DateTimeField</span></code></a> is
deprecated, use <code class="docutils literal"><span class="pre">SplitDateTimeWidget</span></code> with
<a class="reference internal" href="../ref/forms/fields.html#django.forms.SplitDateTimeField" title="django.forms.SplitDateTimeField"><code class="xref py py-class docutils literal"><span class="pre">SplitDateTimeField</span></code></a> instead.</p>
</div>
<div class="section" id="s-validate">
<span id="validate"></span><h3><code class="docutils literal"><span class="pre">validate</span></code><a class="headerlink" href="#validate" title="Permalink to this headline">¶</a></h3>
<p><a class="reference internal" href="../ref/django-admin.html#django-admin-validate"><code class="xref std std-djadmin docutils literal"><span class="pre">validate</span></code></a> command is deprecated in favor of <a class="reference internal" href="../ref/django-admin.html#django-admin-check"><code class="xref std std-djadmin docutils literal"><span class="pre">check</span></code></a> command.</p>
</div>
<div class="section" id="s-django-core-management-basecommand">
<span id="django-core-management-basecommand"></span><h3><code class="docutils literal"><span class="pre">django.core.management.BaseCommand</span></code><a class="headerlink" href="#django-core-management-basecommand" title="Permalink to this headline">¶</a></h3>
<p><code class="docutils literal"><span class="pre">requires_model_validation</span></code> is deprecated in favor of a new
<code class="docutils literal"><span class="pre">requires_system_checks</span></code> flag. If the latter flag is missing, then the
value of the former flag is used. Defining both <code class="docutils literal"><span class="pre">requires_system_checks</span></code> and
<code class="docutils literal"><span class="pre">requires_model_validation</span></code> results in an error.</p>
<p>The <code class="docutils literal"><span class="pre">check()</span></code> method has replaced the old <code class="docutils literal"><span class="pre">validate()</span></code> method.</p>
</div>
<div class="section" id="s-modeladmin-validators">
<span id="modeladmin-validators"></span><h3><code class="docutils literal"><span class="pre">ModelAdmin</span></code> validators<a class="headerlink" href="#modeladmin-validators" title="Permalink to this headline">¶</a></h3>
<p>The <code class="docutils literal"><span class="pre">ModelAdmin.validator_class</span></code> and <code class="docutils literal"><span class="pre">default_validator_class</span></code> attributes
are deprecated in favor of the new <code class="docutils literal"><span class="pre">checks_class</span></code> attribute.</p>
<p>The <code class="docutils literal"><span class="pre">ModelAdmin.validate()</span></code> method is deprecated in favor of
<code class="docutils literal"><span class="pre">ModelAdmin.check()</span></code>.</p>
<p>The <code class="docutils literal"><span class="pre">django.contrib.admin.validation</span></code> module is deprecated.</p>
</div>
<div class="section" id="s-django-db-backends-databasevalidation-validate-field">
<span id="django-db-backends-databasevalidation-validate-field"></span><h3><code class="docutils literal"><span class="pre">django.db.backends.DatabaseValidation.validate_field</span></code><a class="headerlink" href="#django-db-backends-databasevalidation-validate-field" title="Permalink to this headline">¶</a></h3>
<p>This method is deprecated in favor of a new <code class="docutils literal"><span class="pre">check_field</span></code> method.
The functionality required by <code class="docutils literal"><span class="pre">check_field()</span></code> is the same as that provided
by <code class="docutils literal"><span class="pre">validate_field()</span></code>, but the output format is different. Third-party database
backends needing this functionality should provide an implementation of
<code class="docutils literal"><span class="pre">check_field()</span></code>.</p>
</div>
<div class="section" id="s-loading-ssi-and-url-template-tags-from-future-library">
<span id="loading-ssi-and-url-template-tags-from-future-library"></span><h3>Loading <code class="docutils literal"><span class="pre">ssi</span></code> and <code class="docutils literal"><span class="pre">url</span></code> template tags from <code class="docutils literal"><span class="pre">future</span></code> library<a class="headerlink" href="#loading-ssi-and-url-template-tags-from-future-library" title="Permalink to this headline">¶</a></h3>
<p>Django 1.3 introduced <code class="docutils literal"><span class="pre">{%</span> <span class="pre">load</span> <span class="pre">ssi</span> <span class="pre">from</span> <span class="pre">future</span> <span class="pre">%}</span></code> and
<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 for forward compatibility of the
<a class="reference internal" href="../ref/templates/builtins.html#std:templatetag-ssi"><code class="xref std std-ttag docutils literal"><span class="pre">ssi</span></code></a> and <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> template tags. This syntax is now deprecated and
will be removed in Django 1.9. You can simply remove the
<code class="docutils literal"><span class="pre">{%</span> <span class="pre">load</span> <span class="pre">...</span> <span class="pre">from</span> <span class="pre">future</span> <span class="pre">%}</span></code> tags.</p>
</div>
<div class="section" id="s-django-utils-text-javascript-quote">
<span id="django-utils-text-javascript-quote"></span><h3><code class="docutils literal"><span class="pre">django.utils.text.javascript_quote</span></code><a class="headerlink" href="#django-utils-text-javascript-quote" title="Permalink to this headline">¶</a></h3>
<p><code class="docutils literal"><span class="pre">javascript_quote()</span></code> was an undocumented function present in <code class="docutils literal"><span class="pre">django.utils.text</span></code>.
It was used internally in the <a class="reference internal" href="../topics/i18n/translation.html#javascript-catalog-view"><span class="std std-ref">javascript_catalog view</span></a>
whose implementation was changed to make use of <code class="docutils literal"><span class="pre">json.dumps()</span></code> instead.
If you were relying on this function to provide safe output from untrusted
strings, you should use <code class="docutils literal"><span class="pre">django.utils.html.escapejs</span></code> or the
<a class="reference internal" href="../ref/templates/builtins.html#std:templatefilter-escapejs"><code class="xref std std-tfilter docutils literal"><span class="pre">escapejs</span></code></a> template filter.
If all you need is to generate valid JavaScript strings, you can simply use
<code class="docutils literal"><span class="pre">json.dumps()</span></code>.</p>
</div>
<div class="section" id="s-fix-ampersands-utils-method-and-template-filter">
<span id="fix-ampersands-utils-method-and-template-filter"></span><h3><code class="docutils literal"><span class="pre">fix_ampersands</span></code> utils method and template filter<a class="headerlink" href="#fix-ampersands-utils-method-and-template-filter" title="Permalink to this headline">¶</a></h3>
<p>The <code class="docutils literal"><span class="pre">django.utils.html.fix_ampersands</span></code> method and the <code class="docutils literal"><span class="pre">fix_ampersands</span></code>
template filter are deprecated, as the escaping of ampersands is already taken care
of by Django’s standard HTML escaping features. Combining this with <code class="docutils literal"><span class="pre">fix_ampersands</span></code>
would either result in double escaping, or, if the output is assumed to be safe,
a risk of introducing XSS vulnerabilities. Along with <code class="docutils literal"><span class="pre">fix_ampersands</span></code>,
<code class="docutils literal"><span class="pre">django.utils.html.clean_html</span></code> is deprecated, an undocumented function that calls
<code class="docutils literal"><span class="pre">fix_ampersands</span></code>.
As this is an accelerated deprecation, <code class="docutils literal"><span class="pre">fix_ampersands</span></code> and <code class="docutils literal"><span class="pre">clean_html</span></code>
will be removed in Django 1.8.</p>
</div>
<div class="section" id="s-reorganization-of-database-test-settings">
<span id="reorganization-of-database-test-settings"></span><h3>Reorganization of database test settings<a class="headerlink" href="#reorganization-of-database-test-settings" title="Permalink to this headline">¶</a></h3>
<p>All database settings with a <code class="docutils literal"><span class="pre">TEST_</span></code> prefix have been deprecated in favor of
entries in a <a class="reference internal" href="../ref/settings.html#std:setting-DATABASE-TEST"><code class="xref std std-setting docutils literal"><span class="pre">TEST</span></code></a> dictionary in the database
settings. The old settings will be supported until Django 1.9. For backwards
compatibility with older versions of Django, you can define both versions of
the settings as long as they match.</p>
</div>
<div class="section" id="s-fastcgi-support">
<span id="fastcgi-support"></span><h3>FastCGI support<a class="headerlink" href="#fastcgi-support" title="Permalink to this headline">¶</a></h3>
<p>FastCGI support via the <code class="docutils literal"><span class="pre">runfcgi</span></code> management command will be removed in
Django 1.9. Please deploy your project using WSGI.</p>
</div>
<div class="section" id="s-moved-objects-in-contrib-sites">
<span id="moved-objects-in-contrib-sites"></span><h3>Moved objects in <code class="docutils literal"><span class="pre">contrib.sites</span></code><a class="headerlink" href="#moved-objects-in-contrib-sites" title="Permalink to this headline">¶</a></h3>
<p>Following the app-loading refactor, two objects in
<code class="docutils literal"><span class="pre">django.contrib.sites.models</span></code> needed to be moved because they must be
available without importing <code class="docutils literal"><span class="pre">django.contrib.sites.models</span></code> when
<code class="docutils literal"><span class="pre">django.contrib.sites</span></code> isn’t installed. Import <code class="docutils literal"><span class="pre">RequestSite</span></code> from
<code class="docutils literal"><span class="pre">django.contrib.sites.requests</span></code> and <code class="docutils literal"><span class="pre">get_current_site()</span></code> from
<code class="docutils literal"><span class="pre">django.contrib.sites.shortcuts</span></code>. The old import locations will work until
Django 1.9.</p>
</div>
<div class="section" id="s-django-forms-forms-get-declared-fields">
<span id="django-forms-forms-get-declared-fields"></span><h3><code class="docutils literal"><span class="pre">django.forms.forms.get_declared_fields()</span></code><a class="headerlink" href="#django-forms-forms-get-declared-fields" title="Permalink to this headline">¶</a></h3>
<p>Django no longer uses this functional internally. Even though it’s a private
API, it’ll go through the normal deprecation cycle.</p>
</div>
<div class="section" id="s-private-query-lookup-apis">
<span id="private-query-lookup-apis"></span><h3>Private Query Lookup APIs<a class="headerlink" href="#private-query-lookup-apis" title="Permalink to this headline">¶</a></h3>
<p>Private APIs <code class="docutils literal"><span class="pre">django.db.models.sql.where.WhereNode.make_atom()</span></code> and
<code class="docutils literal"><span class="pre">django.db.models.sql.where.Constraint</span></code> are deprecated in favor of the new
<a class="reference internal" href="../ref/models/lookups.html"><span class="doc">custom lookups API</span></a>.</p>
</div>
</div>
<div class="section" id="s-features-removed-in-1-7">
<span id="s-removed-features-1-7"></span><span id="features-removed-in-1-7"></span><span id="removed-features-1-7"></span><h2>Features removed in 1.7<a class="headerlink" href="#features-removed-in-1-7" title="Permalink to this headline">¶</a></h2>
<p>These features have reached the end of their
<a class="reference internal" href="../internals/deprecation.html#deprecation-removed-in-1-7"><span class="std std-ref">deprecation cycle</span></a> and so have been
removed in Django 1.7 (please see the
<a class="reference internal" href="../internals/deprecation.html#deprecation-removed-in-1-7"><span class="std std-ref">deprecation timeline</span></a> for more details):</p>
<ul class="simple">
<li><code class="docutils literal"><span class="pre">django.utils.simplejson</span></code> is removed.</li>
<li><code class="docutils literal"><span class="pre">django.utils.itercompat.product</span></code> is removed.</li>
<li>INSTALLED_APPS and TEMPLATE_DIRS are no longer corrected from a plain
string into a tuple.</li>
<li><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="reference internal" href="../ref/template-response.html#django.template.response.SimpleTemplateResponse" title="django.template.response.SimpleTemplateResponse"><code class="xref py py-class docutils literal"><span class="pre">SimpleTemplateResponse</span></code></a>,
<a class="reference internal" href="../ref/template-response.html#django.template.response.TemplateResponse" title="django.template.response.TemplateResponse"><code class="xref py py-class docutils literal"><span class="pre">TemplateResponse</span></code></a>,
<a class="reference internal" href="../topics/http/shortcuts.html#django.shortcuts.render_to_response" title="django.shortcuts.render_to_response"><code class="xref py py-func docutils literal"><span class="pre">render_to_response()</span></code></a>,
<a class="reference internal" href="../ref/contrib/sitemaps.html#django.contrib.sitemaps.views.index" title="django.contrib.sitemaps.views.index"><code class="xref py py-func docutils literal"><span class="pre">index()</span></code></a>, and
<a class="reference internal" href="../ref/contrib/sitemaps.html#django.contrib.sitemaps.views.sitemap" title="django.contrib.sitemaps.views.sitemap"><code class="xref py py-func docutils literal"><span class="pre">sitemap()</span></code></a> no longer take a <code class="docutils literal"><span class="pre">mimetype</span></code>
argument</li>
<li><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> immediately consumes its content if it’s
an iterator.</li>
<li>The <code class="docutils literal"><span class="pre">AUTH_PROFILE_MODULE</span></code> setting, and the <code class="docutils literal"><span class="pre">get_profile()</span></code> method on
the User model are removed.</li>
<li>The <code class="docutils literal"><span class="pre">cleanup</span></code> management command is removed.</li>
<li>The <code class="docutils literal"><span class="pre">daily_cleanup.py</span></code> script is removed.</li>
<li><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> no longer has a
<code class="docutils literal"><span class="pre">depth</span></code> keyword argument.</li>
<li>The <code class="docutils literal"><span class="pre">get_warnings_state()</span></code>/<code class="docutils literal"><span class="pre">restore_warnings_state()</span></code>
functions from <a class="reference internal" href="../topics/testing/advanced.html#module-django.test.utils" title="django.test.utils: Helpers to write custom test runners."><code class="xref py py-mod docutils literal"><span class="pre">django.test.utils</span></code></a> and the <code class="docutils literal"><span class="pre">save_warnings_state()</span></code>/
<code class="docutils literal"><span class="pre">restore_warnings_state()</span></code>
<a class="reference internal" href="../topics/testing/tools.html#django-testcase-subclasses"><span class="std std-ref">django.test.*TestCase</span></a> are removed.</li>
<li>The <code class="docutils literal"><span class="pre">check_for_test_cookie</span></code> method in
<a class="reference internal" href="../topics/auth/default.html#django.contrib.auth.forms.AuthenticationForm" title="django.contrib.auth.forms.AuthenticationForm"><code class="xref py py-class docutils literal"><span class="pre">AuthenticationForm</span></code></a> is removed.</li>
<li>The version of <a class="reference internal" href="../topics/auth/default.html#django.contrib.auth.views.password_reset_confirm" title="django.contrib.auth.views.password_reset_confirm"><code class="xref py py-func docutils literal"><span class="pre">django.contrib.auth.views.password_reset_confirm()</span></code></a> that
supports base36 encoded user IDs
(<code class="docutils literal"><span class="pre">django.contrib.auth.views.password_reset_confirm_uidb36</span></code>) is removed.</li>
<li>The <code class="docutils literal"><span class="pre">django.utils.encoding.StrAndUnicode</span></code> mix-in is removed.</li>
</ul>
</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.7 release notes</a><ul>
<li><a class="reference internal" href="#python-compatibility">Python compatibility</a></li>
<li><a class="reference internal" href="#what-s-new-in-django-1-7">What’s new in Django 1.7</a><ul>
<li><a class="reference internal" href="#schema-migrations">Schema migrations</a></li>
<li><a class="reference internal" href="#app-loading-refactor">App-loading refactor</a></li>
<li><a class="reference internal" href="#new-method-on-field-subclasses">New method on Field subclasses</a></li>
<li><a class="reference internal" href="#calling-custom-queryset-methods-from-the-manager">Calling custom <code class="docutils literal"><span class="pre">QuerySet</span></code> methods from the <code class="docutils literal"><span class="pre">Manager</span></code></a></li>
<li><a class="reference internal" href="#using-a-custom-manager-when-traversing-reverse-relations">Using a custom manager when traversing reverse relations</a></li>
<li><a class="reference internal" href="#new-system-check-framework">New system check framework</a></li>
<li><a class="reference internal" href="#new-prefetch-object-for-advanced-prefetch-related-operations">New <code class="docutils literal"><span class="pre">Prefetch</span></code> object for advanced <code class="docutils literal"><span class="pre">prefetch_related</span></code> operations.</a></li>
<li><a class="reference internal" href="#admin-shortcuts-support-time-zones">Admin shortcuts support time zones</a></li>
<li><a class="reference internal" href="#using-database-cursors-as-context-managers">Using database cursors as context managers</a></li>
<li><a class="reference internal" href="#custom-lookups">Custom lookups</a></li>
<li><a class="reference internal" href="#improvements-to-form-error-handling">Improvements to <code class="docutils literal"><span class="pre">Form</span></code> error handling</a><ul>
<li><a class="reference internal" href="#form-add-error"><code class="docutils literal"><span class="pre">Form.add_error()</span></code></a></li>
<li><a class="reference internal" href="#error-metadata">Error metadata</a></li>
<li><a class="reference internal" href="#error-containers-and-backward-compatibility">Error containers and backward compatibility</a></li>
</ul>
</li>
<li><a class="reference internal" href="#minor-features">Minor features</a><ul>
<li><a class="reference internal" href="#django-contrib-admin"><code class="docutils literal"><span class="pre">django.contrib.admin</span></code></a></li>
<li><a class="reference internal" href="#django-contrib-auth"><code class="docutils literal"><span class="pre">django.contrib.auth</span></code></a></li>
<li><a class="reference internal" href="#django-contrib-formtools"><code class="docutils literal"><span class="pre">django.contrib.formtools</span></code></a></li>
<li><a class="reference internal" href="#django-contrib-gis"><code class="docutils literal"><span class="pre">django.contrib.gis</span></code></a></li>
<li><a class="reference internal" href="#django-contrib-messages"><code class="docutils literal"><span class="pre">django.contrib.messages</span></code></a></li>
<li><a class="reference internal" href="#django-contrib-redirects"><code class="docutils literal"><span class="pre">django.contrib.redirects</span></code></a></li>
<li><a class="reference internal" href="#django-contrib-sessions"><code class="docutils literal"><span class="pre">django.contrib.sessions</span></code></a></li>
<li><a class="reference internal" href="#django-contrib-sitemaps"><code class="docutils literal"><span class="pre">django.contrib.sitemaps</span></code></a></li>
<li><a class="reference internal" href="#django-contrib-sites"><code class="docutils literal"><span class="pre">django.contrib.sites</span></code></a></li>
<li><a class="reference internal" href="#django-contrib-staticfiles"><code class="docutils literal"><span class="pre">django.contrib.staticfiles</span></code></a></li>
<li><a class="reference internal" href="#django-contrib-syndication"><code class="docutils literal"><span class="pre">django.contrib.syndication</span></code></a></li>
<li><a class="reference internal" href="#cache">Cache</a></li>
<li><a class="reference internal" href="#cross-site-request-forgery">Cross Site Request Forgery</a></li>
<li><a class="reference internal" href="#email">Email</a></li>
<li><a class="reference internal" href="#file-storage">File Storage</a></li>
<li><a class="reference internal" href="#file-uploads">File Uploads</a></li>
<li><a class="reference internal" href="#forms">Forms</a></li>
<li><a class="reference internal" href="#internationalization">Internationalization</a></li>
<li><a class="reference internal" href="#management-commands">Management Commands</a></li>
<li><a class="reference internal" href="#models">Models</a></li>
<li><a class="reference internal" href="#signals">Signals</a></li>
<li><a class="reference internal" href="#templates">Templates</a></li>
<li><a class="reference internal" href="#requests-and-responses">Requests and Responses</a></li>
<li><a class="reference internal" href="#tests">Tests</a></li>
<li><a class="reference internal" href="#utilities">Utilities</a></li>
<li><a class="reference internal" href="#validators">Validators</a></li>
</ul>
</li>
</ul>
</li>
<li><a class="reference internal" href="#backwards-incompatible-changes-in-1-7">Backwards incompatible changes in 1.7</a><ul>
<li><a class="reference internal" href="#allow-syncdb-allow-migrate">allow_syncdb/allow_migrate</a></li>
<li><a class="reference internal" href="#initial-data">initial_data</a></li>
<li><a class="reference internal" href="#deconstruct-and-serializability">deconstruct() and serializability</a></li>
<li><a class="reference internal" href="#app-loading-changes">App-loading changes</a><ul>
<li><a class="reference internal" href="#start-up-sequence">Start-up sequence</a></li>
<li><a class="reference internal" href="#standalone-scripts">Standalone scripts</a></li>
<li><a class="reference internal" href="#wsgi-scripts">WSGI scripts</a></li>
<li><a class="reference internal" href="#app-registry-consistency">App registry consistency</a></li>
<li><a class="reference internal" href="#subclassing-appcommand">Subclassing AppCommand</a></li>
<li><a class="reference internal" href="#introspecting-applications">Introspecting applications</a></li>
</ul>
</li>
<li><a class="reference internal" href="#management-commands-and-order-of-installed-apps">Management commands and order of <code class="docutils literal"><span class="pre">INSTALLED_APPS</span></code></a></li>
<li><a class="reference internal" href="#validationerror-constructor-and-internal-storage"><code class="docutils literal"><span class="pre">ValidationError</span></code> constructor and internal storage</a></li>
<li><a class="reference internal" href="#behavior-of-locmemcache-regarding-pickle-errors">Behavior of <code class="docutils literal"><span class="pre">LocMemCache</span></code> regarding pickle errors</a></li>
<li><a class="reference internal" href="#cache-keys-are-now-generated-from-the-request-s-absolute-url">Cache keys are now generated from the request’s absolute URL</a></li>
<li><a class="reference internal" href="#passing-none-to-manager-db-manager">Passing <code class="docutils literal"><span class="pre">None</span></code> to <code class="docutils literal"><span class="pre">Manager.db_manager()</span></code></a></li>
<li><a class="reference internal" href="#pytz-may-be-required">pytz may be required</a></li>
<li><a class="reference internal" href="#remove-and-clear-methods-of-related-managers"><code class="docutils literal"><span class="pre">remove()</span></code> and <code class="docutils literal"><span class="pre">clear()</span></code> methods of related managers</a></li>
<li><a class="reference internal" href="#admin-login-redirection-strategy">Admin login redirection strategy</a></li>
<li><a class="reference internal" href="#select-for-update-requires-a-transaction"><code class="docutils literal"><span class="pre">select_for_update()</span></code> requires a transaction</a></li>
<li><a class="reference internal" href="#contrib-middleware-removed-from-default-middleware-classes">Contrib middleware removed from default <code class="docutils literal"><span class="pre">MIDDLEWARE_CLASSES</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-7">Features deprecated in 1.7</a><ul>
<li><a class="reference internal" href="#django-core-cache-get-cache"><code class="docutils literal"><span class="pre">django.core.cache.get_cache</span></code></a></li>
<li><a class="reference internal" href="#django-utils-dictconfig-django-utils-importlib"><code class="docutils literal"><span class="pre">django.utils.dictconfig</span></code>/<code class="docutils literal"><span class="pre">django.utils.importlib</span></code></a></li>
<li><a class="reference internal" href="#django-utils-module-loading-import-by-path"><code class="docutils literal"><span class="pre">django.utils.module_loading.import_by_path</span></code></a></li>
<li><a class="reference internal" href="#django-utils-tzinfo"><code class="docutils literal"><span class="pre">django.utils.tzinfo</span></code></a></li>
<li><a class="reference internal" href="#django-utils-unittest"><code class="docutils literal"><span class="pre">django.utils.unittest</span></code></a></li>
<li><a class="reference internal" href="#django-utils-datastructures-sorteddict"><code class="docutils literal"><span class="pre">django.utils.datastructures.SortedDict</span></code></a></li>
<li><a class="reference internal" href="#custom-sql-location-for-models-package">Custom SQL location for models package</a></li>
<li><a class="reference internal" href="#reorganization-of-django-contrib-sites">Reorganization of <code class="docutils literal"><span class="pre">django.contrib.sites</span></code></a></li>
<li><a class="reference internal" href="#declared-fieldsets-attribute-on-modeladmin"><code class="docutils literal"><span class="pre">declared_fieldsets</span></code> attribute on <code class="docutils literal"><span class="pre">ModelAdmin</span></code></a></li>
<li><a class="reference internal" href="#reorganization-of-django-contrib-contenttypes">Reorganization of <code class="docutils literal"><span class="pre">django.contrib.contenttypes</span></code></a></li>
<li><a class="reference internal" href="#syncdb"><code class="docutils literal"><span class="pre">syncdb</span></code></a></li>
<li><a class="reference internal" href="#util-modules-renamed-to-utils"><code class="docutils literal"><span class="pre">util</span></code> modules renamed to <code class="docutils literal"><span class="pre">utils</span></code></a></li>
<li><a class="reference internal" href="#get-formsets-method-on-modeladmin"><code class="docutils literal"><span class="pre">get_formsets</span></code> method on <code class="docutils literal"><span class="pre">ModelAdmin</span></code></a></li>
<li><a class="reference internal" href="#ipaddressfield"><code class="docutils literal"><span class="pre">IPAddressField</span></code></a></li>
<li><a class="reference internal" href="#basememcachedcache-get-memcache-timeout-method"><code class="docutils literal"><span class="pre">BaseMemcachedCache._get_memcache_timeout</span></code> method</a></li>
<li><a class="reference internal" href="#natural-key-serialization-options">Natural key serialization options</a></li>
<li><a class="reference internal" href="#merging-of-post-and-get-arguments-into-wsgirequest-request">Merging of <code class="docutils literal"><span class="pre">POST</span></code> and <code class="docutils literal"><span class="pre">GET</span></code> arguments into <code class="docutils literal"><span class="pre">WSGIRequest.REQUEST</span></code></a></li>
<li><a class="reference internal" href="#django-utils-datastructures-mergedict-class"><code class="docutils literal"><span class="pre">django.utils.datastructures.MergeDict</span></code> class</a></li>
<li><a class="reference internal" href="#language-codes-zh-cn-zh-tw-and-fy-nl">Language codes <code class="docutils literal"><span class="pre">zh-cn</span></code>, <code class="docutils literal"><span class="pre">zh-tw</span></code> and <code class="docutils literal"><span class="pre">fy-nl</span></code></a></li>
<li><a class="reference internal" href="#django-utils-functional-memoize-function"><code class="docutils literal"><span class="pre">django.utils.functional.memoize</span></code> function</a></li>
<li><a class="reference internal" href="#geo-sitemaps">Geo Sitemaps</a></li>
<li><a class="reference internal" href="#passing-callable-arguments-to-queryset-methods">Passing callable arguments to queryset methods</a></li>
<li><a class="reference internal" href="#admin-for-setting"><code class="docutils literal"><span class="pre">ADMIN_FOR</span></code> setting</a></li>
<li><a class="reference internal" href="#splitdatetimewidget-with-datetimefield"><code class="docutils literal"><span class="pre">SplitDateTimeWidget</span></code> with <code class="docutils literal"><span class="pre">DateTimeField</span></code></a></li>
<li><a class="reference internal" href="#validate"><code class="docutils literal"><span class="pre">validate</span></code></a></li>
<li><a class="reference internal" href="#django-core-management-basecommand"><code class="docutils literal"><span class="pre">django.core.management.BaseCommand</span></code></a></li>
<li><a class="reference internal" href="#modeladmin-validators"><code class="docutils literal"><span class="pre">ModelAdmin</span></code> validators</a></li>
<li><a class="reference internal" href="#django-db-backends-databasevalidation-validate-field"><code class="docutils literal"><span class="pre">django.db.backends.DatabaseValidation.validate_field</span></code></a></li>
<li><a class="reference internal" href="#loading-ssi-and-url-template-tags-from-future-library">Loading <code class="docutils literal"><span class="pre">ssi</span></code> and <code class="docutils literal"><span class="pre">url</span></code> template tags from <code class="docutils literal"><span class="pre">future</span></code> library</a></li>
<li><a class="reference internal" href="#django-utils-text-javascript-quote"><code class="docutils literal"><span class="pre">django.utils.text.javascript_quote</span></code></a></li>
<li><a class="reference internal" href="#fix-ampersands-utils-method-and-template-filter"><code class="docutils literal"><span class="pre">fix_ampersands</span></code> utils method and template filter</a></li>
<li><a class="reference internal" href="#reorganization-of-database-test-settings">Reorganization of database test settings</a></li>
<li><a class="reference internal" href="#fastcgi-support">FastCGI support</a></li>
<li><a class="reference internal" href="#moved-objects-in-contrib-sites">Moved objects in <code class="docutils literal"><span class="pre">contrib.sites</span></code></a></li>
<li><a class="reference internal" href="#django-forms-forms-get-declared-fields"><code class="docutils literal"><span class="pre">django.forms.forms.get_declared_fields()</span></code></a></li>
<li><a class="reference internal" href="#private-query-lookup-apis">Private Query Lookup APIs</a></li>
</ul>
</li>
<li><a class="reference internal" href="#features-removed-in-1-7">Features removed in 1.7</a></li>
</ul>
</li>
</ul>
<h3>Browse</h3>
<ul>
<li>Prev: <a href="1.7.1.html">Django 1.7.1 release notes</a></li>
<li>Next: <a href="1.6.11.html">Django 1.6.11 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.7 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.7.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.7.1.html" title="Django 1.7.1 release notes">previous</a>
|
<a href="index.html" title="Release notes" accesskey="U">up</a>
|
<a href="1.6.11.html" title="Django 1.6.11 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
>
886
