<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<title>Django 1.2 alpha 1 release notes — Django 1.4.5 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.4.5',
COLLAPSE_INDEX: false,
FILE_SUFFIX: '.html',
HAS_SOURCE: true
};
</script>
<script type="text/javascript" src="../_static/jquery.js"></script>
<script type="text/javascript" src="../_static/underscore.js"></script>
<script type="text/javascript" src="../_static/doctools.js"></script>
<link rel="top" title="Django 1.4.5 documentation" href="../index.html" />
<link rel="up" title="Release notes" href="index.html" />
<link rel="next" title="Django 1.1 RC 1 release notes" href="1.1-rc-1.html" />
<link rel="prev" title="Django 1.2 beta 1 release notes" href="1.2-beta-1.html" />
<script type="text/javascript" src="../templatebuiltins.js"></script>
<script type="text/javascript">
(function($) {
if (!django_template_builtins) {
// templatebuiltins.js missing, do nothing.
return;
}
$(document).ready(function() {
// Hyperlink Django template tags and filters
var base = "../ref/templates/builtins.html";
if (base == "#") {
// Special case for builtins.html itself
base = "";
}
// Tags are keywords, class '.k'
$("div.highlight\\-html\\+django span.k").each(function(i, elem) {
var tagname = $(elem).text();
if ($.inArray(tagname, django_template_builtins.ttags) != -1) {
var fragment = tagname.replace(/_/, '-');
$(elem).html("<a href='" + base + "#" + fragment + "'>" + tagname + "</a>");
}
});
// Filters are functions, class '.nf'
$("div.highlight\\-html\\+django span.nf").each(function(i, elem) {
var filtername = $(elem).text();
if ($.inArray(filtername, django_template_builtins.tfilters) != -1) {
var fragment = filtername.replace(/_/, '-');
$(elem).html("<a href='" + base + "#" + fragment + "'>" + filtername + "</a>");
}
});
});
})(jQuery);
</script>
</head>
<body>
<div class="document">
<div id="custom-doc" class="yui-t6">
<div id="hd">
<h1><a href="../index.html">Django 1.4.5 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.2-beta-1.html" title="Django 1.2 beta 1 release notes">previous</a>
|
<a href="index.html" title="Release notes" accesskey="U">up</a>
|
<a href="1.1-rc-1.html" title="Django 1.1 RC 1 release notes">next</a> »</div>
</div>
<div id="bd">
<div id="yui-main">
<div class="yui-b">
<div class="yui-g" id="releases-1.2-alpha-1">
<div class="section" id="s-django-1-2-alpha-1-release-notes">
<span id="django-1-2-alpha-1-release-notes"></span><h1>Django 1.2 alpha 1 release notes<a class="headerlink" href="#django-1-2-alpha-1-release-notes" title="Permalink to this headline">¶</a></h1>
<p>January 5, 2010</p>
<p>Welcome to Django 1.2 alpha 1!</p>
<p>This is the first in a series of preview/development releases leading up to the
eventual release of Django 1.2, currently scheduled to take place in March 2010.
This release is primarily targeted at developers who are interested in trying
out new features and testing the Django codebase to help identify and resolve
bugs prior to the final 1.2 release.</p>
<p>As such, this release is <em>not</em> intended for production use, and any such use is
discouraged.</p>
<div class="section" id="s-backwards-incompatible-changes-in-1-2">
<span id="backwards-incompatible-changes-in-1-2"></span><h2>Backwards-incompatible changes in 1.2<a class="headerlink" href="#backwards-incompatible-changes-in-1-2" title="Permalink to this headline">¶</a></h2>
<div class="section" id="s-csrf-protection">
<span id="csrf-protection"></span><h3>CSRF Protection<a class="headerlink" href="#csrf-protection" title="Permalink to this headline">¶</a></h3>
<p>There have been large changes to the way that CSRF protection works, detailed in
<a class="reference internal" href="../ref/contrib/csrf.html"><em>the CSRF documentation</em></a>. The following are the major
changes that developers must be aware of:</p>
<ul>
<li><p class="first"><tt class="docutils literal"><span class="pre">CsrfResponseMiddleware</span></tt> and <tt class="docutils literal"><span class="pre">CsrfMiddleware</span></tt> have been deprecated, and
<strong>will be removed completely in Django 1.4</strong>, in favor of a template tag that
should be inserted into forms.</p>
</li>
<li><p class="first">All contrib apps use a <tt class="docutils literal"><span class="pre">csrf_protect</span></tt> decorator to protect the view. This
requires the use of the <tt class="docutils literal"><span class="pre">csrf_token</span></tt> template tag in the template, so if you
have used custom templates for contrib views, you MUST READ THE UPGRADE
INSTRUCTIONS to fix those templates.</p>
<div class="admonition-documentation-removed admonition">
<p class="first admonition-title">Documentation removed</p>
<p class="last">The upgrade notes have been removed in current Django docs. Please refer
to the docs for Django 1.3 or older to find these instructions.</p>
</div>
</li>
<li><p class="first"><tt class="docutils literal"><span class="pre">CsrfViewMiddleware</span></tt> is included in <a class="reference internal" href="../ref/settings.html#std:setting-MIDDLEWARE_CLASSES"><tt class="xref std std-setting docutils literal"><span class="pre">MIDDLEWARE_CLASSES</span></tt></a> by
default. This turns on CSRF protection by default, so that views that accept
POST requests need to be written to work with the middleware. Instructions
on how to do this are found in the CSRF docs.</p>
</li>
<li><p class="first">CSRF-related code has moved from <tt class="docutils literal"><span class="pre">contrib</span></tt> to <tt class="docutils literal"><span class="pre">core</span></tt> (with
backwards compatible imports in the old locations, which are
deprecated).</p>
</li>
</ul>
</div>
<div class="section" id="s-if-tag-changes">
<span id="if-tag-changes"></span><h3><a class="reference internal" href="../ref/templates/builtins.html#std:templatetag-if"><tt class="xref std std-ttag docutils literal"><span class="pre">if</span></tt></a> tag changes<a class="headerlink" href="#if-tag-changes" title="Permalink to this headline">¶</a></h3>
<p>Due to new features in the <a class="reference internal" href="../ref/templates/builtins.html#std:templatetag-if"><tt class="xref std std-ttag docutils literal"><span class="pre">if</span></tt></a> template tag, it no longer accepts ‘and’,
‘or’ and ‘not’ as valid <strong>variable</strong> names. Previously that worked in some
cases even though these strings were normally treated as keywords. Now, the
keyword status is always enforced, and template code like <tt class="docutils literal"><span class="pre">{%</span> <span class="pre">if</span> <span class="pre">not</span> <span class="pre">%}</span></tt> or
<tt class="docutils literal"><span class="pre">{%</span> <span class="pre">if</span> <span class="pre">and</span> <span class="pre">%}</span></tt> will throw a TemplateSyntaxError.</p>
</div>
<div class="section" id="s-lazyobject">
<span id="lazyobject"></span><h3><tt class="docutils literal"><span class="pre">LazyObject</span></tt><a class="headerlink" href="#lazyobject" title="Permalink to this headline">¶</a></h3>
<p><tt class="docutils literal"><span class="pre">LazyObject</span></tt> is an undocumented utility class used for lazily wrapping other
objects of unknown type. In Django 1.1 and earlier, it handled introspection in
a non-standard way, depending on wrapped objects implementing a public method
<tt class="docutils literal"><span class="pre">get_all_members()</span></tt>. Since this could easily lead to name clashes, it has been
changed to use the standard method, involving <tt class="docutils literal"><span class="pre">__members__</span></tt> and <tt class="docutils literal"><span class="pre">__dir__()</span></tt>.
If you used <tt class="docutils literal"><span class="pre">LazyObject</span></tt> in your own code, and implemented the
<tt class="docutils literal"><span class="pre">get_all_members()</span></tt> method for wrapped objects, you need to make the following
changes:</p>
<ul>
<li><p class="first">If your class does not have special requirements for introspection (i.e. you
have not implemented <tt class="docutils literal"><span class="pre">__getattr__()</span></tt> or other methods that allow for
attributes not discoverable by normal mechanisms), you can simply remove the
<tt class="docutils literal"><span class="pre">get_all_members()</span></tt> method. The default implementation on <tt class="docutils literal"><span class="pre">LazyObject</span></tt>
will do the right thing.</p>
</li>
<li><p class="first">If you have more complex requirements for introspection, first rename the
<tt class="docutils literal"><span class="pre">get_all_members()</span></tt> method to <tt class="docutils literal"><span class="pre">__dir__()</span></tt>. This is the standard method,
from Python 2.6 onwards, for supporting introspection. If you are require
support for Python < 2.6, add the following code to the class:</p>
<div class="highlight-python"><div class="highlight"><pre><span class="n">__members__</span> <span class="o">=</span> <span class="nb">property</span><span class="p">(</span><span class="k">lambda</span> <span class="bp">self</span><span class="p">:</span> <span class="bp">self</span><span class="o">.</span><span class="n">__dir__</span><span class="p">())</span>
</pre></div>
</div>
</li>
</ul>
</div>
<div class="section" id="s-dict-on-model-instances">
<span id="dict-on-model-instances"></span><h3><tt class="docutils literal"><span class="pre">__dict__</span></tt> on Model instances<a class="headerlink" href="#dict-on-model-instances" title="Permalink to this headline">¶</a></h3>
<p>Historically, the <tt class="docutils literal"><span class="pre">__dict__</span></tt> attribute of a model instance has only contained
attributes corresponding to the fields on a model.</p>
<p>In order to support multiple database configurations, Django 1.2 has
added a <tt class="docutils literal"><span class="pre">_state</span></tt> attribute to object instances. This attribute will
appear in <tt class="docutils literal"><span class="pre">__dict__</span></tt> for a model instance. If your code relies on
iterating over __dict__ to obtain a list of fields, you must now
filter the <tt class="docutils literal"><span class="pre">_state</span></tt> attribute of out <tt class="docutils literal"><span class="pre">__dict__</span></tt>.</p>
</div>
<div class="section" id="s-get-db-prep-methods-on-field">
<span id="get-db-prep-methods-on-field"></span><h3><tt class="docutils literal"><span class="pre">get_db_prep_*()</span></tt> methods on Field<a class="headerlink" href="#get-db-prep-methods-on-field" title="Permalink to this headline">¶</a></h3>
<p>Prior to v1.2, a custom field had the option of defining several
functions to support conversion of Python values into
database-compatible values. A custom field might look something like:</p>
<div class="highlight-python"><pre>class CustomModelField(models.Field):
# ...
def get_db_prep_save(self, value):
# ...
def get_db_prep_value(self, value):
# ...
def get_db_prep_lookup(self, lookup_type, value):
# ...</pre>
</div>
<p>In 1.2, these three methods have undergone a change in prototype, and
two extra methods have been introduced:</p>
<div class="highlight-python"><pre>class CustomModelField(models.Field):
# ...
def get_prep_value(self, value):
# ...
def get_prep_lookup(self, lookup_type, value):
# ...
def get_db_prep_save(self, value, connection):
# ...
def get_db_prep_value(self, value, connection, prepared=False):
# ...
def get_db_prep_lookup(self, lookup_type, value, connection, prepared=False):
# ...</pre>
</div>
<p>These changes are required to support multiple databases:
<tt class="docutils literal"><span class="pre">get_db_prep_*</span></tt> can no longer make any assumptions regarding the
database for which it is preparing. The <tt class="docutils literal"><span class="pre">connection</span></tt> argument now
provides the preparation methods with the specific connection for
which the value is being prepared.</p>
<p>The two new methods exist to differentiate general data preparation
requirements, and requirements that are database-specific. The
<tt class="docutils literal"><span class="pre">prepared</span></tt> argument is used to indicate to the database preparation
methods whether generic value preparation has been performed. If
an unprepared (i.e., <tt class="docutils literal"><span class="pre">prepared=False</span></tt>) value is provided to the
<tt class="docutils literal"><span class="pre">get_db_prep_*()</span></tt> calls, they should invoke the corresponding
<tt class="docutils literal"><span class="pre">get_prep_*()</span></tt> calls to perform generic data preparation.</p>
<p>Conversion functions has been provided which will transparently
convert functions adhering to the old prototype into functions
compatible with the new prototype. However, this conversion function
will be removed in Django 1.4, so you should upgrade your Field
definitions to use the new prototype.</p>
<p>If your <tt class="docutils literal"><span class="pre">get_db_prep_*()</span></tt> methods made no use of the database
connection, you should be able to upgrade by renaming
<tt class="docutils literal"><span class="pre">get_db_prep_value()</span></tt> to <tt class="docutils literal"><span class="pre">get_prep_value()</span></tt> and
<tt class="docutils literal"><span class="pre">get_db_prep_lookup()</span></tt> to <tt class="docutils literal"><span class="pre">get_prep_lookup()`.</span> <span class="pre">If</span> <span class="pre">you</span> <span class="pre">require</span>
<span class="pre">database</span> <span class="pre">specific</span> <span class="pre">conversions,</span> <span class="pre">then</span> <span class="pre">you</span> <span class="pre">will</span> <span class="pre">need</span> <span class="pre">to</span> <span class="pre">provide</span> <span class="pre">an</span>
<span class="pre">implementation</span> <span class="pre">``get_db_prep_*</span></tt> that uses the <tt class="docutils literal"><span class="pre">connection</span></tt>
argument to resolve database-specific values.</p>
</div>
<div class="section" id="s-stateful-template-tags">
<span id="stateful-template-tags"></span><h3>Stateful template tags<a class="headerlink" href="#stateful-template-tags" title="Permalink to this headline">¶</a></h3>
<p>Template tags that store rendering state on the node itself may experience
problems if they are used with the new <a class="reference internal" href="../ref/templates/api.html#template-loaders"><em>cached
template loader</em></a>.</p>
<p>All of the built-in Django template tags are safe to use with the cached
loader, but if you’re using custom template tags that come from third
party packages, or that you wrote yourself, you should ensure that the
<tt class="docutils literal"><span class="pre">Node</span></tt> implementation for each tag is thread-safe. For more
information, see
<a class="reference internal" href="../howto/custom-template-tags.html#template-tag-thread-safety"><em>template tag thread safety considerations</em></a>.</p>
</div>
<div class="section" id="s-test-runner-exit-status-code">
<span id="test-runner-exit-status-code"></span><h3>Test runner exit status code<a class="headerlink" href="#test-runner-exit-status-code" title="Permalink to this headline">¶</a></h3>
<p>The exit status code of the test runners (<tt class="docutils literal"><span class="pre">tests/runtests.py</span></tt> and <tt class="docutils literal"><span class="pre">python</span>
<span class="pre">manage.py</span> <span class="pre">test</span></tt>) no longer represents the number of failed tests, since a
failure of 256 or more tests resulted in a wrong exit status code. The exit
status code for the test runner is now 0 for success (no failing tests) and 1
for any number of test failures. If needed, the number of test failures can be
found at the end of the test runner’s output.</p>
</div>
</div>
<div class="section" id="s-features-deprecated-in-1-2">
<span id="features-deprecated-in-1-2"></span><h2>Features deprecated in 1.2<a class="headerlink" href="#features-deprecated-in-1-2" title="Permalink to this headline">¶</a></h2>
<div class="section" id="s-csrf-response-rewriting-middleware">
<span id="csrf-response-rewriting-middleware"></span><h3>CSRF response rewriting middleware<a class="headerlink" href="#csrf-response-rewriting-middleware" title="Permalink to this headline">¶</a></h3>
<p><tt class="docutils literal"><span class="pre">CsrfResponseMiddleware</span></tt>, the middleware that automatically inserted CSRF
tokens into POST forms in outgoing pages, has been deprecated in favor of a
template tag method (see above), and will be removed completely in Django
1.4. <tt class="docutils literal"><span class="pre">CsrfMiddleware</span></tt>, which includes the functionality of
<tt class="docutils literal"><span class="pre">CsrfResponseMiddleware</span></tt> and <tt class="docutils literal"><span class="pre">CsrfViewMiddleware</span></tt> has likewise been
deprecated.</p>
<p>Also, the CSRF module has moved from contrib to core, and the old
imports are deprecated, as described in the upgrading notes.</p>
<div class="admonition-documentation-removed admonition">
<p class="first admonition-title">Documentation removed</p>
<p class="last">The upgrade notes have been removed in current Django docs. Please refer
to the docs for Django 1.3 or older to find these instructions.</p>
</div>
</div>
<div class="section" id="s-smtpconnection">
<span id="smtpconnection"></span><h3><tt class="docutils literal"><span class="pre">SMTPConnection</span></tt><a class="headerlink" href="#smtpconnection" title="Permalink to this headline">¶</a></h3>
<p>The <tt class="docutils literal"><span class="pre">SMTPConnection</span></tt> class has been deprecated in favor of a generic
Email backend API. Old code that explicitly instantiated an instance
of an SMTPConnection:</p>
<div class="highlight-python"><div class="highlight"><pre><span class="kn">from</span> <span class="nn">django.core.mail</span> <span class="kn">import</span> <span class="n">SMTPConnection</span>
<span class="n">connection</span> <span class="o">=</span> <span class="n">SMTPConnection</span><span class="p">()</span>
<span class="n">messages</span> <span class="o">=</span> <span class="n">get_notification_email</span><span class="p">()</span>
<span class="n">connection</span><span class="o">.</span><span class="n">send_messages</span><span class="p">(</span><span class="n">messages</span><span class="p">)</span>
</pre></div>
</div>
<p>should now call <a class="reference internal" href="../topics/email.html#django.core.mail.get_connection" title="django.core.mail.get_connection"><tt class="xref py py-meth docutils literal"><span class="pre">get_connection()</span></tt></a> to
instantiate a generic email connection:</p>
<div class="highlight-python"><div class="highlight"><pre><span class="kn">from</span> <span class="nn">django.core.mail</span> <span class="kn">import</span> <span class="n">get_connection</span>
<span class="n">connection</span> <span class="o">=</span> <span class="n">get_connection</span><span class="p">()</span>
<span class="n">messages</span> <span class="o">=</span> <span class="n">get_notification_email</span><span class="p">()</span>
<span class="n">connection</span><span class="o">.</span><span class="n">send_messages</span><span class="p">(</span><span class="n">messages</span><span class="p">)</span>
</pre></div>
</div>
<p>Depending on the value of the <a class="reference internal" href="../ref/settings.html#std:setting-EMAIL_BACKEND"><tt class="xref std std-setting docutils literal"><span class="pre">EMAIL_BACKEND</span></tt></a> setting, this
may not return an SMTP connection. If you explicitly require an SMTP
connection with which to send email, you can explicitly request an
SMTP connection:</p>
<div class="highlight-python"><div class="highlight"><pre><span class="kn">from</span> <span class="nn">django.core.mail</span> <span class="kn">import</span> <span class="n">get_connection</span>
<span class="n">connection</span> <span class="o">=</span> <span class="n">get_connection</span><span class="p">(</span><span class="s">'django.core.mail.backends.smtp.EmailBackend'</span><span class="p">)</span>
<span class="n">messages</span> <span class="o">=</span> <span class="n">get_notification_email</span><span class="p">()</span>
<span class="n">connection</span><span class="o">.</span><span class="n">send_messages</span><span class="p">(</span><span class="n">messages</span><span class="p">)</span>
</pre></div>
</div>
<p>If your call to construct an instance of <tt class="docutils literal"><span class="pre">SMTPConnection</span></tt> required
additional arguments, those arguments can be passed to the
<a class="reference internal" href="../topics/email.html#django.core.mail.get_connection" title="django.core.mail.get_connection"><tt class="xref py py-meth docutils literal"><span class="pre">get_connection()</span></tt></a> call:</p>
<div class="highlight-python"><div class="highlight"><pre><span class="n">connection</span> <span class="o">=</span> <span class="n">get_connection</span><span class="p">(</span><span class="s">'django.core.mail.backends.smtp.EmailBackend'</span><span class="p">,</span> <span class="n">hostname</span><span class="o">=</span><span class="s">'localhost'</span><span class="p">,</span> <span class="n">port</span><span class="o">=</span><span class="mi">1234</span><span class="p">)</span>
</pre></div>
</div>
</div>
<div class="section" id="s-specifying-databases">
<span id="specifying-databases"></span><h3>Specifying databases<a class="headerlink" href="#specifying-databases" title="Permalink to this headline">¶</a></h3>
<p>Prior to Django 1.1, Django used a number of settings to control access to a
single database. Django 1.2 introduces support for multiple databases, and as
a result, the way you define database settings has changed.</p>
<p><strong>Any existing Django settings file will continue to work as expected
until Django 1.4.</strong> Old-style database settings will be automatically
translated to the new-style format.</p>
<p>In the old-style (pre 1.2) format, there were a number of
<tt class="docutils literal"><span class="pre">DATABASE_</span></tt> settings at the top level of your settings file. For
example:</p>
<div class="highlight-python"><div class="highlight"><pre><span class="n">DATABASE_NAME</span> <span class="o">=</span> <span class="s">'test_db'</span>
<span class="n">DATABASE_ENGINE</span> <span class="o">=</span> <span class="s">'postgresql_psycopg2'</span>
<span class="n">DATABASE_USER</span> <span class="o">=</span> <span class="s">'myusername'</span>
<span class="n">DATABASE_PASSWORD</span> <span class="o">=</span> <span class="s">'s3krit'</span>
</pre></div>
</div>
<p>These settings are now contained inside a dictionary named
<a class="reference internal" href="../ref/settings.html#std:setting-DATABASES"><tt class="xref std std-setting docutils literal"><span class="pre">DATABASES</span></tt></a>. Each item in the dictionary corresponds to a
single database connection, with the name <tt class="docutils literal"><span class="pre">'default'</span></tt> describing the
default database connection. The setting names have also been
shortened to reflect the fact that they are stored in a dictionary.
The sample settings given previously would now be stored using:</p>
<div class="highlight-python"><div class="highlight"><pre><span class="n">DATABASES</span> <span class="o">=</span> <span class="p">{</span>
<span class="s">'default'</span><span class="p">:</span> <span class="p">{</span>
<span class="s">'NAME'</span><span class="p">:</span> <span class="s">'test_db'</span><span class="p">,</span>
<span class="s">'ENGINE'</span><span class="p">:</span> <span class="s">'django.db.backends.postgresql_psycopg2'</span><span class="p">,</span>
<span class="s">'USER'</span><span class="p">:</span> <span class="s">'myusername'</span><span class="p">,</span>
<span class="s">'PASSWORD'</span><span class="p">:</span> <span class="s">'s3krit'</span><span class="p">,</span>
<span class="p">}</span>
<span class="p">}</span>
</pre></div>
</div>
<p>This affects the following settings:</p>
<table class="docutils">
<colgroup>
<col width="61%" />
<col width="39%" />
</colgroup>
<thead valign="bottom">
<tr class="row-odd"><th class="head">Old setting</th>
<th class="head">New Setting</th>
</tr>
</thead>
<tbody valign="top">
<tr class="row-even"><td><tt class="xref std std-setting docutils literal"><span class="pre">DATABASE_ENGINE</span></tt></td>
<td><tt class="xref std std-setting docutils literal"><span class="pre">ENGINE</span></tt></td>
</tr>
<tr class="row-odd"><td><tt class="xref std std-setting docutils literal"><span class="pre">DATABASE_HOST</span></tt></td>
<td><a class="reference internal" href="../ref/settings.html#std:setting-HOST"><tt class="xref std std-setting docutils literal"><span class="pre">HOST</span></tt></a></td>
</tr>
<tr class="row-even"><td><tt class="xref std std-setting docutils literal"><span class="pre">DATABASE_NAME</span></tt></td>
<td><a class="reference internal" href="../ref/settings.html#std:setting-NAME"><tt class="xref std std-setting docutils literal"><span class="pre">NAME</span></tt></a></td>
</tr>
<tr class="row-odd"><td><tt class="xref std std-setting docutils literal"><span class="pre">DATABASE_OPTIONS</span></tt></td>
<td><a class="reference internal" href="../ref/settings.html#std:setting-OPTIONS"><tt class="xref std std-setting docutils literal"><span class="pre">OPTIONS</span></tt></a></td>
</tr>
<tr class="row-even"><td><tt class="xref std std-setting docutils literal"><span class="pre">DATABASE_PASSWORD</span></tt></td>
<td><a class="reference internal" href="../ref/settings.html#std:setting-PASSWORD"><tt class="xref std std-setting docutils literal"><span class="pre">PASSWORD</span></tt></a></td>
</tr>
<tr class="row-odd"><td><tt class="xref std std-setting docutils literal"><span class="pre">DATABASE_PORT</span></tt></td>
<td><a class="reference internal" href="../ref/settings.html#std:setting-PORT"><tt class="xref std std-setting docutils literal"><span class="pre">PORT</span></tt></a></td>
</tr>
<tr class="row-even"><td><tt class="xref std std-setting docutils literal"><span class="pre">DATABASE_USER</span></tt></td>
<td><a class="reference internal" href="../ref/settings.html#std:setting-USER"><tt class="xref std std-setting docutils literal"><span class="pre">USER</span></tt></a></td>
</tr>
<tr class="row-odd"><td><tt class="xref std std-setting docutils literal"><span class="pre">TEST_DATABASE_CHARSET</span></tt></td>
<td><a class="reference internal" href="../ref/settings.html#std:setting-TEST_CHARSET"><tt class="xref std std-setting docutils literal"><span class="pre">TEST_CHARSET</span></tt></a></td>
</tr>
<tr class="row-even"><td><tt class="xref std std-setting docutils literal"><span class="pre">TEST_DATABASE_COLLATION</span></tt></td>
<td><a class="reference internal" href="../ref/settings.html#std:setting-TEST_COLLATION"><tt class="xref std std-setting docutils literal"><span class="pre">TEST_COLLATION</span></tt></a></td>
</tr>
<tr class="row-odd"><td><tt class="xref std std-setting docutils literal"><span class="pre">TEST_DATABASE_NAME</span></tt></td>
<td><a class="reference internal" href="../ref/settings.html#std:setting-TEST_NAME"><tt class="xref std std-setting docutils literal"><span class="pre">TEST_NAME</span></tt></a></td>
</tr>
</tbody>
</table>
<p>These changes are also required if you have manually created a database
connection using <tt class="docutils literal"><span class="pre">DatabaseWrapper()</span></tt> from your database backend of choice.</p>
<p>In addition to the change in structure, Django 1.2 removes the special
handling for the built-in database backends. All database backends
must now be specified by a fully qualified module name (i.e.,
<tt class="docutils literal"><span class="pre">django.db.backends.postgresql_psycopg2</span></tt>, rather than just
<tt class="docutils literal"><span class="pre">postgresql_psycopg2</span></tt>).</p>
</div>
<div class="section" id="s-user-messages-api">
<span id="user-messages-api"></span><h3>User Messages API<a class="headerlink" href="#user-messages-api" title="Permalink to this headline">¶</a></h3>
<p>The API for storing messages in the user <tt class="docutils literal"><span class="pre">Message</span></tt> model (via
<tt class="docutils literal"><span class="pre">user.message_set.create</span></tt>) is now deprecated and will be removed in Django
1.4 according to the standard <a class="reference internal" href="../internals/release-process.html"><em>release process</em></a>.</p>
<p>To upgrade your code, you need to replace any instances of:</p>
<div class="highlight-python"><div class="highlight"><pre><span class="n">user</span><span class="o">.</span><span class="n">message_set</span><span class="o">.</span><span class="n">create</span><span class="p">(</span><span class="s">'a message'</span><span class="p">)</span>
</pre></div>
</div>
<p>with the following:</p>
<div class="highlight-python"><div class="highlight"><pre><span class="kn">from</span> <span class="nn">django.contrib</span> <span class="kn">import</span> <span class="n">messages</span>
<span class="n">messages</span><span class="o">.</span><span class="n">add_message</span><span class="p">(</span><span class="n">request</span><span class="p">,</span> <span class="n">messages</span><span class="o">.</span><span class="n">INFO</span><span class="p">,</span> <span class="s">'a message'</span><span class="p">)</span>
</pre></div>
</div>
<p>Additionally, if you make use of the method, you need to replace the
following:</p>
<div class="highlight-python"><div class="highlight"><pre><span class="k">for</span> <span class="n">message</span> <span class="ow">in</span> <span class="n">user</span><span class="o">.</span><span class="n">get_and_delete_messages</span><span class="p">():</span>
<span class="o">...</span>
</pre></div>
</div>
<p>with:</p>
<div class="highlight-python"><div class="highlight"><pre><span class="kn">from</span> <span class="nn">django.contrib</span> <span class="kn">import</span> <span class="n">messages</span>
<span class="k">for</span> <span class="n">message</span> <span class="ow">in</span> <span class="n">messages</span><span class="o">.</span><span class="n">get_messages</span><span class="p">(</span><span class="n">request</span><span class="p">):</span>
<span class="o">...</span>
</pre></div>
</div>
<p>For more information, see the full
<a class="reference internal" href="../ref/contrib/messages.html"><em>messages documentation</em></a>. You should begin to
update your code to use the new API immediately.</p>
</div>
<div class="section" id="s-date-format-helper-functions">
<span id="date-format-helper-functions"></span><h3>Date format helper functions<a class="headerlink" href="#date-format-helper-functions" title="Permalink to this headline">¶</a></h3>
<p><tt class="docutils literal"><span class="pre">django.utils.translation.get_date_formats()</span></tt> and
<tt class="docutils literal"><span class="pre">django.utils.translation.get_partial_date_formats()</span></tt> have been deprecated
in favor of the appropriate calls to <tt class="docutils literal"><span class="pre">django.utils.formats.get_format()</span></tt>
which is locale aware when <a class="reference internal" href="../ref/settings.html#std:setting-USE_L10N"><tt class="xref std std-setting docutils literal"><span class="pre">USE_L10N</span></tt></a> is set to <tt class="docutils literal"><span class="pre">True</span></tt>, and falls
back to default settings if set to <tt class="docutils literal"><span class="pre">False</span></tt>.</p>
<p>To get the different date formats, instead of writing:</p>
<div class="highlight-python"><div class="highlight"><pre><span class="kn">from</span> <span class="nn">django.utils.translation</span> <span class="kn">import</span> <span class="n">get_date_formats</span>
<span class="n">date_format</span><span class="p">,</span> <span class="n">datetime_format</span><span class="p">,</span> <span class="n">time_format</span> <span class="o">=</span> <span class="n">get_date_formats</span><span class="p">()</span>
</pre></div>
</div>
<p>use:</p>
<div class="highlight-python"><div class="highlight"><pre><span class="kn">from</span> <span class="nn">django.utils</span> <span class="kn">import</span> <span class="n">formats</span>
<span class="n">date_format</span> <span class="o">=</span> <span class="n">formats</span><span class="o">.</span><span class="n">get_format</span><span class="p">(</span><span class="s">'DATE_FORMAT'</span><span class="p">)</span>
<span class="n">datetime_format</span> <span class="o">=</span> <span class="n">formats</span><span class="o">.</span><span class="n">get_format</span><span class="p">(</span><span class="s">'DATETIME_FORMAT'</span><span class="p">)</span>
<span class="n">time_format</span> <span class="o">=</span> <span class="n">formats</span><span class="o">.</span><span class="n">get_format</span><span class="p">(</span><span class="s">'TIME_FORMAT'</span><span class="p">)</span>
</pre></div>
</div>
<p>or, when directly formatting a date value:</p>
<div class="highlight-python"><div class="highlight"><pre><span class="kn">from</span> <span class="nn">django.utils</span> <span class="kn">import</span> <span class="n">formats</span>
<span class="n">value_formatted</span> <span class="o">=</span> <span class="n">formats</span><span class="o">.</span><span class="n">date_format</span><span class="p">(</span><span class="n">value</span><span class="p">,</span> <span class="s">'DATETIME_FORMAT'</span><span class="p">)</span>
</pre></div>
</div>
<p>The same applies to the globals found in <tt class="docutils literal"><span class="pre">django.forms.fields</span></tt>:</p>
<ul class="simple">
<li><tt class="docutils literal"><span class="pre">DEFAULT_DATE_INPUT_FORMATS</span></tt></li>
<li><tt class="docutils literal"><span class="pre">DEFAULT_TIME_INPUT_FORMATS</span></tt></li>
<li><tt class="docutils literal"><span class="pre">DEFAULT_DATETIME_INPUT_FORMATS</span></tt></li>
</ul>
<p>Use <tt class="docutils literal"><span class="pre">django.utils.formats.get_format()</span></tt> to get the appropriate formats.</p>
</div>
</div>
<div class="section" id="s-what-s-new-in-django-1-2-alpha-1">
<span id="what-s-new-in-django-1-2-alpha-1"></span><h2>What’s new in Django 1.2 alpha 1<a class="headerlink" href="#what-s-new-in-django-1-2-alpha-1" title="Permalink to this headline">¶</a></h2>
<p>The following new features are present as of this alpha release; this
release also marks the end of major feature development for the 1.2
release cycle. Some minor features will continue development until the
1.2 beta release, however.</p>
<div class="section" id="s-csrf-support">
<span id="csrf-support"></span><h3>CSRF support<a class="headerlink" href="#csrf-support" title="Permalink to this headline">¶</a></h3>
<p>Django now has much improved protection against <a class="reference internal" href="../ref/contrib/csrf.html"><em>Cross-Site
Request Forgery (CSRF) attacks</em></a>. This type of attack
occurs when a malicious Web site contains a link, a form button or
some javascript that is intended to perform some action on your Web
site, using the credentials of a logged-in user who visits the
malicious site in their browser. A related type of attack, ‘login
CSRF’, where an attacking site tricks a user’s browser into logging
into a site with someone else’s credentials, is also covered.</p>
</div>
<div class="section" id="s-email-backends">
<span id="email-backends"></span><h3>Email Backends<a class="headerlink" href="#email-backends" title="Permalink to this headline">¶</a></h3>
<p>You can now <a class="reference internal" href="../topics/email.html#topic-email-backends"><em>configure the way that Django sends email</em></a>. Instead of using SMTP to send all email, you
can now choose a configurable email backend to send messages. If your
hosting provider uses a sandbox or some other non-SMTP technique for
sending mail, you can now construct an email backend that will allow
Django’s standard <a class="reference internal" href="../topics/email.html"><em>mail sending methods</em></a> to use
those facilities.</p>
<p>This also makes it easier to debug mail sending - Django ships with
backend implementations that allow you to send email to a
<a class="reference internal" href="../topics/email.html#topic-email-file-backend"><em>file</em></a>, to the
<a class="reference internal" href="../topics/email.html#topic-email-console-backend"><em>console</em></a>, or to
<a class="reference internal" href="../topics/email.html#topic-email-memory-backend"><em>memory</em></a> - you can even configure all
email to be <a class="reference internal" href="../topics/email.html#topic-email-dummy-backend"><em>thrown away</em></a>.</p>
</div>
<div class="section" id="s-messages-framework">
<span id="messages-framework"></span><h3>Messages Framework<a class="headerlink" href="#messages-framework" title="Permalink to this headline">¶</a></h3>
<p>Django now includes a robust and configurable <a class="reference internal" href="../ref/contrib/messages.html"><em>messages framework</em></a> with built-in support for cookie- and session-based
messaging, for both anonymous and authenticated clients. The messages framework
replaces the deprecated user message API and allows you to temporarily store
messages in one request and retrieve them for display in a subsequent request
(usually the next one).</p>
</div>
<div class="section" id="s-support-for-multiple-databases">
<span id="support-for-multiple-databases"></span><h3>Support for multiple databases<a class="headerlink" href="#support-for-multiple-databases" title="Permalink to this headline">¶</a></h3>
<p>Django 1.2 adds the ability to use <a class="reference internal" href="../topics/db/multi-db.html"><em>more than one database</em></a> in your Django project. Queries can be
issued at a specific database with the <cite>using()</cite> method on
querysets; individual objects can be saved to a specific database
by providing a <tt class="docutils literal"><span class="pre">using</span></tt> argument when you save the instance.</p>
</div>
<div class="section" id="s-smart-if-tag">
<span id="smart-if-tag"></span><h3>‘Smart’ if tag<a class="headerlink" href="#smart-if-tag" title="Permalink to this headline">¶</a></h3>
<p>The <a class="reference internal" href="../ref/templates/builtins.html#std:templatetag-if"><tt class="xref std std-ttag docutils literal"><span class="pre">if</span></tt></a> tag has been upgraded to be much more powerful. First, support
for comparison operators has been added. No longer will you have to type:</p>
<div class="highlight-html+django"><div class="highlight"><pre><span class="cp">{%</span> <span class="k">ifnotequal</span> <span class="nv">a</span> <span class="nv">b</span> <span class="cp">%}</span>
...
<span class="cp">{%</span> <span class="k">endifnotequal</span> <span class="cp">%}</span>
</pre></div>
</div>
<p>...as you can now do:</p>
<div class="highlight-html+django"><div class="highlight"><pre><span class="cp">{%</span> <span class="k">if</span> <span class="nv">a</span> <span class="p">!</span><span class="o">=</span> <span class="nv">b</span> <span class="cp">%}</span>
...
<span class="cp">{%</span> <span class="k">endif</span> <span class="cp">%}</span>
</pre></div>
</div>
<p>The operators supported are <tt class="docutils literal"><span class="pre">==</span></tt>, <tt class="docutils literal"><span class="pre">!=</span></tt>, <tt class="docutils literal"><span class="pre"><</span></tt>, <tt class="docutils literal"><span class="pre">></span></tt>, <tt class="docutils literal"><span class="pre"><=</span></tt>, <tt class="docutils literal"><span class="pre">>=</span></tt> and
<tt class="docutils literal"><span class="pre">in</span></tt>, all of which work like the Python operators, in addition to <tt class="docutils literal"><span class="pre">and</span></tt>,
<tt class="docutils literal"><span class="pre">or</span></tt> and <tt class="docutils literal"><span class="pre">not</span></tt> which were already supported.</p>
<p>Also, filters may now be used in the <tt class="docutils literal"><span class="pre">if</span></tt> expression. For example:</p>
<div class="highlight-html+django"><div class="highlight"><pre><span class="nt"><div</span>
<span class="cp">{%</span> <span class="k">if</span> <span class="nv">user.email</span><span class="o">|</span><span class="nf">lower</span> <span class="o">==</span> <span class="nv">message.recipient</span><span class="o">|</span><span class="nf">lower</span> <span class="cp">%}</span>
<span class="na">class=</span><span class="s">"highlight"</span>
<span class="cp">{%</span> <span class="k">endif</span> <span class="cp">%}</span>
<span class="nt">></span><span class="cp">{{</span> <span class="nv">message</span> <span class="cp">}}</span><span class="nt"></div></span>
</pre></div>
</div>
</div>
<div class="section" id="s-template-caching">
<span id="template-caching"></span><h3>Template caching<a class="headerlink" href="#template-caching" title="Permalink to this headline">¶</a></h3>
<p>In previous versions of Django, every time you rendered a template it
would be reloaded from disk. In Django 1.2, you can use a <a class="reference internal" href="../ref/templates/api.html#template-loaders"><em>cached
template loader</em></a> to load templates once, then use
the cached result for every subsequent render. This can lead to a
significant performance improvement if your templates are broken into
lots of smaller subtemplates (using the <tt class="docutils literal"><span class="pre">{%</span> <span class="pre">extends</span> <span class="pre">%}</span></tt> or <tt class="docutils literal"><span class="pre">{%</span>
<span class="pre">include</span> <span class="pre">%}</span></tt> tags).</p>
<p>As a side effect, it is now much easier to support non-Django template
languages. For more details, see the <a class="reference internal" href="../ref/templates/api.html#topic-template-alternate-language"><em>notes on supporting
non-Django template languages</em></a>.</p>
</div>
<div class="section" id="s-natural-keys-in-fixtures">
<span id="natural-keys-in-fixtures"></span><h3>Natural keys in fixtures<a class="headerlink" href="#natural-keys-in-fixtures" title="Permalink to this headline">¶</a></h3>
<p>Fixtures can refer to remote objects using
<a class="reference internal" href="../topics/serialization.html#topics-serialization-natural-keys"><em>Natural keys</em></a>. This lookup scheme is an
alternative to the normal primary-key based object references in a
fixture, improving readability, and resolving problems referring to
objects whose primary key value may not be predictable or known.</p>
</div>
<div class="section" id="s-bigintegerfield">
<span id="bigintegerfield"></span><h3><tt class="docutils literal"><span class="pre">BigIntegerField</span></tt><a class="headerlink" href="#bigintegerfield" title="Permalink to this headline">¶</a></h3>
<p>Models can now use a 64 bit <a class="reference internal" href="../ref/models/fields.html#django.db.models.BigIntegerField" title="django.db.models.BigIntegerField"><tt class="xref py py-class docutils literal"><span class="pre">BigIntegerField</span></tt></a> type.</p>
</div>
<div class="section" id="s-fast-failure-for-tests">
<span id="fast-failure-for-tests"></span><h3>Fast Failure for Tests<a class="headerlink" href="#fast-failure-for-tests" title="Permalink to this headline">¶</a></h3>
<p>The <a class="reference internal" href="../ref/django-admin.html#django-admin-test"><tt class="xref std std-djadmin docutils literal"><span class="pre">test</span></tt></a> subcommand of <tt class="docutils literal"><span class="pre">django-admin.py</span></tt>, and the <tt class="docutils literal"><span class="pre">runtests.py</span></tt>
script used to run Django’s own test suite, support a new <tt class="docutils literal"><span class="pre">--failfast</span></tt> option.
When specified, this option causes the test runner to exit after encountering
a failure instead of continuing with the test run. In addition, the handling
of <tt class="docutils literal"><span class="pre">Ctrl-C</span></tt> during a test run has been improved to trigger a graceful exit
from the test run that reports details of the tests run before the interruption.</p>
</div>
<div class="section" id="s-improved-localization">
<span id="improved-localization"></span><h3>Improved localization<a class="headerlink" href="#improved-localization" title="Permalink to this headline">¶</a></h3>
<p>Django’s <a class="reference internal" href="../topics/i18n/index.html"><em>internationalization framework</em></a> has been
expanded by locale aware formatting and form processing. That means, if
enabled, dates and numbers on templates will be displayed using the format
specified for the current locale. Django will also use localized formats
when parsing data in forms.
See <a class="reference internal" href="../topics/i18n/formatting.html#format-localization"><em>Format localization</em></a> for more details.</p>
</div>
<div class="section" id="s-added-readonly-fields-to-modeladmin">
<span id="added-readonly-fields-to-modeladmin"></span><h3>Added <tt class="docutils literal"><span class="pre">readonly_fields</span></tt> to <tt class="docutils literal"><span class="pre">ModelAdmin</span></tt><a class="headerlink" href="#added-readonly-fields-to-modeladmin" title="Permalink to this headline">¶</a></h3>
<p><a class="reference internal" href="../ref/contrib/admin/index.html#django.contrib.admin.ModelAdmin.readonly_fields" title="django.contrib.admin.ModelAdmin.readonly_fields"><tt class="xref py py-attr docutils literal"><span class="pre">django.contrib.admin.ModelAdmin.readonly_fields</span></tt></a> has been added to
enable non-editable fields in add/change pages for models and inlines. Field
and calculated values can be displayed along side editable fields.</p>
</div>
<div class="section" id="s-customizable-syntax-highlighting">
<span id="customizable-syntax-highlighting"></span><h3>Customizable syntax highlighting<a class="headerlink" href="#customizable-syntax-highlighting" title="Permalink to this headline">¶</a></h3>
<p>You can now use the <tt class="docutils literal"><span class="pre">DJANGO_COLORS</span></tt> environment variable to modify
or disable the colors used by <tt class="docutils literal"><span class="pre">django-admin.py</span></tt> to provide
<a class="reference internal" href="../ref/django-admin.html#syntax-coloring"><em>syntax highlighting</em></a>.</p>
</div>
</div>
<div class="section" id="s-the-django-1-2-roadmap">
<span id="the-django-1-2-roadmap"></span><h2>The Django 1.2 roadmap<a class="headerlink" href="#the-django-1-2-roadmap" title="Permalink to this headline">¶</a></h2>
<p>Before the final Django 1.2 release, several other preview/development
releases will be made available. The current schedule consists of at
least the following:</p>
<ul class="simple">
<li>Week of <strong>January 26, 2010</strong>: First Django 1.2 beta release. Final
feature freeze for Django 1.2.</li>
<li>Week of <strong>March 2, 2010</strong>: First Django 1.2 release
candidate. String freeze for translations.</li>
<li>Week of <strong>March 9, 2010</strong>: Django 1.2 final release.</li>
</ul>
<p>If necessary, additional alpha, beta or release-candidate packages
will be issued prior to the final 1.2 release. Django 1.2 will be
released approximately one week after the final release candidate.</p>
</div>
<div class="section" id="s-what-you-can-do-to-help">
<span id="what-you-can-do-to-help"></span><h2>What you can do to help<a class="headerlink" href="#what-you-can-do-to-help" title="Permalink to this headline">¶</a></h2>
<p>In order to provide a high-quality 1.2 release, we need your help. Although this
alpha release is, again, <em>not</em> intended for production use, you can help the
Django team by trying out the alpha codebase in a safe test environment and
reporting any bugs or issues you encounter. The Django ticket tracker is the
central place to search for open issues:</p>
<ul class="simple">
<li><a class="reference external" href="https://code.djangoproject.com/timeline">https://code.djangoproject.com/timeline</a></li>
</ul>
<p>Please open new tickets if no existing ticket corresponds to a problem you’re
running into.</p>
<p>Additionally, discussion of Django development, including progress toward the
1.2 release, takes place daily on the django-developers mailing list:</p>
<ul class="simple">
<li><a class="reference external" href="http://groups.google.com/group/django-developers">http://groups.google.com/group/django-developers</a></li>
</ul>
<p>... and in the <tt class="docutils literal"><span class="pre">#django-dev</span></tt> IRC channel on <tt class="docutils literal"><span class="pre">irc.freenode.net</span></tt>. If you’re
interested in helping out with Django’s development, feel free to join the
discussions there.</p>
<p>Django’s online documentation also includes pointers on how to contribute to
Django:</p>
<ul class="simple">
<li><a class="reference internal" href="../internals/contributing/index.html"><em>How to contribute to Django</em></a></li>
</ul>
<p>Contributions on any level – developing code, writing documentation or simply
triaging tickets and helping to test proposed bugfixes – are always welcome and
appreciated.</p>
<p>Development sprints for Django 1.2 will also be taking place at PyCon
US 2010, on the dedicated sprint days (February 22 through 25), and
anyone who wants to help out is welcome to join in, either in person
at PyCon or virtually in the IRC channel or on the mailing list.</p>
</div>
</div>
</div>
</div>
</div>
<div class="yui-b" id="sidebar">
<div class="sphinxsidebar">
<div class="sphinxsidebarwrapper">
<h3><a href="../contents.html">Table Of Contents</a></h3>
<ul>
<li><a class="reference internal" href="#">Django 1.2 alpha 1 release notes</a><ul>
<li><a class="reference internal" href="#backwards-incompatible-changes-in-1-2">Backwards-incompatible changes in 1.2</a><ul>
<li><a class="reference internal" href="#csrf-protection">CSRF Protection</a></li>
<li><a class="reference internal" href="#if-tag-changes"><tt class="docutils literal"><span class="pre">if</span></tt> tag changes</a></li>
<li><a class="reference internal" href="#lazyobject"><tt class="docutils literal"><span class="pre">LazyObject</span></tt></a></li>
<li><a class="reference internal" href="#dict-on-model-instances"><tt class="docutils literal"><span class="pre">__dict__</span></tt> on Model instances</a></li>
<li><a class="reference internal" href="#get-db-prep-methods-on-field"><tt class="docutils literal"><span class="pre">get_db_prep_*()</span></tt> methods on Field</a></li>
<li><a class="reference internal" href="#stateful-template-tags">Stateful template tags</a></li>
<li><a class="reference internal" href="#test-runner-exit-status-code">Test runner exit status code</a></li>
</ul>
</li>
<li><a class="reference internal" href="#features-deprecated-in-1-2">Features deprecated in 1.2</a><ul>
<li><a class="reference internal" href="#csrf-response-rewriting-middleware">CSRF response rewriting middleware</a></li>
<li><a class="reference internal" href="#smtpconnection"><tt class="docutils literal"><span class="pre">SMTPConnection</span></tt></a></li>
<li><a class="reference internal" href="#specifying-databases">Specifying databases</a></li>
<li><a class="reference internal" href="#user-messages-api">User Messages API</a></li>
<li><a class="reference internal" href="#date-format-helper-functions">Date format helper functions</a></li>
</ul>
</li>
<li><a class="reference internal" href="#what-s-new-in-django-1-2-alpha-1">What’s new in Django 1.2 alpha 1</a><ul>
<li><a class="reference internal" href="#csrf-support">CSRF support</a></li>
<li><a class="reference internal" href="#email-backends">Email Backends</a></li>
<li><a class="reference internal" href="#messages-framework">Messages Framework</a></li>
<li><a class="reference internal" href="#support-for-multiple-databases">Support for multiple databases</a></li>
<li><a class="reference internal" href="#smart-if-tag">‘Smart’ if tag</a></li>
<li><a class="reference internal" href="#template-caching">Template caching</a></li>
<li><a class="reference internal" href="#natural-keys-in-fixtures">Natural keys in fixtures</a></li>
<li><a class="reference internal" href="#bigintegerfield"><tt class="docutils literal"><span class="pre">BigIntegerField</span></tt></a></li>
<li><a class="reference internal" href="#fast-failure-for-tests">Fast Failure for Tests</a></li>
<li><a class="reference internal" href="#improved-localization">Improved localization</a></li>
<li><a class="reference internal" href="#added-readonly-fields-to-modeladmin">Added <tt class="docutils literal"><span class="pre">readonly_fields</span></tt> to <tt class="docutils literal"><span class="pre">ModelAdmin</span></tt></a></li>
<li><a class="reference internal" href="#customizable-syntax-highlighting">Customizable syntax highlighting</a></li>
</ul>
</li>
<li><a class="reference internal" href="#the-django-1-2-roadmap">The Django 1.2 roadmap</a></li>
<li><a class="reference internal" href="#what-you-can-do-to-help">What you can do to help</a></li>
</ul>
</li>
</ul>
<h3>Browse</h3>
<ul>
<li>Prev: <a href="1.2-beta-1.html">Django 1.2 beta 1 release notes</a></li>
<li>Next: <a href="1.1-rc-1.html">Django 1.1 RC 1 release notes</a></li>
</ul>
<h3>You are here:</h3>
<ul>
<li>
<a href="../index.html">Django 1.4.5 documentation</a>
<ul><li><a href="index.html">Release notes</a>
<ul><li>Django 1.2 alpha 1 release notes</li></ul>
</li></ul>
</li>
</ul>
<h3>This Page</h3>
<ul class="this-page-menu">
<li><a href="../_sources/releases/1.2-alpha-1.txt"
rel="nofollow">Show Source</a></li>
</ul>
<div id="searchbox" style="display: none">
<h3>Quick search</h3>
<form class="search" action="../search.html" method="get">
<input type="text" name="q" />
<input type="submit" value="Go" />
<input type="hidden" name="check_keywords" value="yes" />
<input type="hidden" name="area" value="default" />
</form>
<p class="searchtip" style="font-size: 90%">
Enter search terms or a module, class or function name.
</p>
</div>
<script type="text/javascript">$('#searchbox').show(0);</script>
</div>
</div>
<h3>Last update:</h3>
<p class="topless">Feb 21, 2013</p>
</div>
</div>
<div id="ft">
<div class="nav">
« <a href="1.2-beta-1.html" title="Django 1.2 beta 1 release notes">previous</a>
|
<a href="index.html" title="Release notes" accesskey="U">up</a>
|
<a href="1.1-rc-1.html" title="Django 1.1 RC 1 release notes">next</a> »</div>
</div>
</div>
<div class="clearer"></div>
</div>
</body>
</html>
