On March 17, 2013, the Django project and the free software community lost
a very dear friend and developer.

Malcolm was a long-time contributor to Django, a model community member, a
brilliant mind, and a friend. His contributions to Django — and to many other
open source projects — are nearly impossible to enumerate. Many on the core
Django team had their first patches reviewed by him; his mentorship enriched
us. His consideration, patience, and dedication will always be an inspiration
to us.

Django’s transaction management was overhauled. Database-level autocommit is
now turned on by default. This makes transaction handling more explicit and
should improve performance. The existing APIs were deprecated, and new APIs
were introduced, as described in the transaction management docs.

Django now supports reusing the same database connection for several requests.
This avoids the overhead of re-establishing a connection at the beginning of
each request. For backwards compatibility, this feature is disabled by
default. See Persistent connections for details.

Django 1.6 ships with a new test runner that allows more flexibility in the
location of tests. The previous runner
(django.test.simple.DjangoTestSuiteRunner) found tests only in the
models.py and tests.py modules of a Python package in
INSTALLED_APPS.

The new runner (django.test.runner.DiscoverRunner) uses the test discovery
features built into unittest2 (the version of unittest in the
Python 2.7+ standard library, and bundled with Django). With test discovery,
tests can be located in any module whose name matches the pattern test*.py.

In addition, the test labels provided to ./manage.pytest to nominate
specific tests to run must now be full Python dotted paths (or directory
paths), rather than applabel.TestCase.test_method_name pseudo-paths. This
allows running tests located anywhere in your codebase, rather than only in
INSTALLED_APPS. For more details, see Testing in Django.

The Model.save() method now
tries to directly UPDATE the database if the instance has a primary
key value. Previously SELECT was performed to determine if UPDATE
or INSERT were needed. The new algorithm needs only one query for
updating an existing row while the old algorithm needed two. See
Model.save() for more details.

In some rare cases the database doesn’t report that a matching row was
found when doing an UPDATE. An example is the PostgreSQL ONUPDATE
trigger which returns NULL. In such cases it is possible to set
django.db.models.Options.select_on_save flag to force saving to
use the old algorithm.

The assertQuerysetEqual() now checks
for undefined order and raises ValueError if undefined
order is spotted. The order is seen as undefined if the given QuerySet
isn’t ordered and there are more than one ordered values to compare against.

The default widgets for EmailField,
URLField, IntegerField,
FloatField and DecimalField use
the new type attributes available in HTML5 (type='email', type='url',
type='number'). Note that due to erratic support of the number
input type with localized numbers in current browsers, Django only uses it
when numeric fields are not localized.

For custom management commands: Verification of the presence of valid
settings in commands that ask for it by using the
BaseCommand.can_import_settings internal
option is now performed independently from handling of the locale that
should be active during the execution of the command. The latter can now be
influenced by the new
BaseCommand.leave_locale_alone internal
option. See Management commands and locales for more details.

django.forms.fields.Field.__init__ now calls super(), allowing
field mixins to implement __init__() methods that will reliably be
called.

The validate_max parameter was added to BaseFormSet and
formset_factory(), and ModelForm and inline
versions of the same. The behavior of validation for formsets with
max_num was clarified. The previously undocumented behavior that
hardened formsets against memory exhaustion attacks was documented,
and the undocumented limit of the higher of 1000 or max_num forms
was changed so it is always 1000 more than max_num.

Added BCryptSHA256PasswordHasher to resolve the password truncation issue
with bcrypt.

Pillow is now the preferred image manipulation library to use with Django.
PIL is pending deprecation (support to be removed in Django 1.8).
To upgrade, you should first uninstall PIL, then install Pillow.

The choices argument to model fields now accepts an iterable of iterables
instead of requiring an iterable of lists or tuples.

The reason phrase can be customized in HTTP responses using
reason_phrase.

When giving the URL of the next page for
django.contrib.auth.views.logout(),
django.contrib.auth.views.password_reset(),
django.contrib.auth.views.password_reset_confirm(),
and django.contrib.auth.views.password_change(), you can now pass
URL names and they will be resolved.

The new dumpdata--pks option specifies the primary keys of objects
to dump. This option can only be used with one model.

Added QuerySet methods first()
and last() which are convenience
methods returning the first or last object matching the filters. Returns
None if there are no objects matching.

GenericForeignKey now takes an optional for_concrete_model argument,
which when set to False allows the field to reference proxy models. The
default is True to retain the old behavior.

The LocaleMiddleware now stores the active
language in session if it is not present there. This prevents loss of
language settings after session flush, e.g. logout.

SuspiciousOperation has been differentiated
into a number of subclasses, and each will log to a matching named logger
under the django.security logging hierarchy. Along with this change,
a handler400 mechanism and default view are used whenever
a SuspiciousOperation reaches the WSGI handler to return an
HttpResponseBadRequest.

The DoesNotExist exception now includes a
message indicating the name of the attribute used for the lookup.

The get_or_create() method no longer
requires at least one keyword argument.

ModelAdmin now preserves filters on the list view
after creating, editing or deleting an object. It’s possible to restore the previous
behavior of clearing filters by setting the
preserve_filters attribute to False.

Raw queries (Manager.raw() or cursor.execute()) can now use the
“pyformat” parameter style, where placeholders in the query are given as
'%(name)s' and the parameters are passed as a dictionary rather than
a list (except on SQLite). This has long been possible (but not officially
supported) on MySQL and PostgreSQL, and is now also available on Oracle.

The default iteration count for the PBKDF2 password hasher has been
increased by 20%. This backwards compatible change will not affect
existing passwords or users who have subclassed
django.contrib.auth.hashers.PBKDF2PasswordHasher to change the
default value. Passwords will be upgraded to use
the new iteration count as necessary.

In addition to the changes outlined in this section, be sure to review the
deprecation plan 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.

The changes in transaction management may result in additional statements to
create, release or rollback savepoints. This is more likely to happen with
SQLite, since it didn’t support savepoints until this release.

If tests using assertNumQueries() fail
because of a higher number of queries than expected, check that the extra
queries are related to savepoints, and adjust the expected number of queries
accordingly.

In order to maintain greater consistency with Python’s unittest module, the
new test runner (django.test.runner.DiscoverRunner) does not automatically
support some types of tests that were supported by the previous runner:

Tests in models.py and tests/__init__.py files will no longer be
found and run. Move them to a file whose name begins with test.

Django bundles a modified version of the doctest module from the Python
standard library (in django.test._doctest) and includes some additional
doctest utilities. These utilities are deprecated and will be removed in Django
1.8; doctest suites should be updated to work with the standard library’s
doctest module (or converted to unittest-compatible tests).

If you wish to delay updates to your test suite, you can set your
TEST_RUNNER setting to django.test.simple.DjangoTestSuiteRunner
to fully restore the old test behavior. DjangoTestSuiteRunner is deprecated
but will not be removed from Django until version 1.8.

This is for developers working on the GeoDjango application itself and related
to the item above about changes in the test runners:

The django.contrib.gis.tests.GeoDjangoTestSuiteRunner test runner has been
removed and the standalone GeoDjango tests execution setup it implemented isn’t
supported anymore. To run the GeoDjango tests simply use the new
DiscoverRunner and specify the django.contrib.gis app.

The introduction of the new test runner has also slightly changed the way that
test models are imported. As a result, any test that overrides AUTH_USER_MODEL
to test behavior with one of Django’s test user models (
django.contrib.auth.tests.custom_user.CustomUser and
django.contrib.auth.tests.custom_user.ExtensionUser) must now
explicitly import the User model in your test module:

When the time zone support added in Django 1.4
was active, QuerySet.dates()
lookups returned unexpected results, because the aggregation was performed in
UTC. To fix this, Django 1.6 introduces a new API, QuerySet.datetimes(). This requires a few changes in
your code.

For the same reason, accessing date_list in the context of a date-based
generic view requires time zone definitions in the database when the view is
based on a DateTimeField and USE_TZ is
True. Learn more.

Django 1.6 introduces hour, minute, and second lookups on
DateTimeField. If you had model fields called
hour, minute, or second, the new lookups will clash with you field
names. Append an explicit exact lookup if this is an issue.

When a BooleanField doesn’t have an explicit
default, the implicit default value is
None. In previous version of Django, it was False, but that didn’t
represent accurately the lack of a value.

Code that relies on the default value being False may raise an exception
when saving new model instances to the database, because None isn’t an
acceptable value for a BooleanField. You should
either specify default=False in the field definition, or ensure the field
is set to True or False before saving the object.

When reversing URLs, Django didn’t apply django.utils.http.urlquote
to arguments before interpolating them in URL patterns. This bug is fixed in
Django 1.6. If you worked around this bug by applying URL quoting before
passing arguments to reverse(), this may result in double-quoting. If this
happens, simply remove the URL quoting from your code. You will also have to
replace special characters in URLs used in
assertRedirects() with their encoded
versions.

The comments app now uses a
GenericIPAddressField for storing commenters’ IP addresses, to support
comments submitted from IPv6 addresses. Until now, it stored them in an
IPAddressField, which is only meant to support IPv4. When saving a comment
made from an IPv6 address, the address would be silently truncated on MySQL
databases, and raise an exception on Oracle. You will need to change the
column type in your database to benefit from this change.

For MySQL, execute this query on your project’s database:

ALTERTABLEdjango_commentsMODIFYip_addressVARCHAR(39);

For Oracle, execute this query:

ALTERTABLEDJANGO_COMMENTSMODIFY(ip_addressVARCHAR2(39));

If you do not apply this change, the behavior is unchanged: on MySQL, IPv6
addresses are silently truncated; on Oracle, an exception is generated. No
database change is needed for SQLite or PostgreSQL databases.

When you are running raw SQL queries through the
cursor.execute method, the rule about doubling
percent literals (%) inside the query has been unified. Past behavior
depended on the database backend. Now, across all backends, you only need to
double literal percent characters if you are also providing replacement
parameters. For example:

# No parameters, no percent doublingcursor.execute("SELECT foo FROM bar WHERE baz = '30%'")# Parameters passed, non-placeholders have to be doubledcursor.execute("SELECT foo FROM bar WHERE baz = '30%%' and id = %s",[self.id])

HTML rendering of model form fields corresponding to
ManyToManyField model fields used to get the
hard-coded sentence:

Hold down “Control”, or “Command” on a Mac, to select more than one.

(or its translation to the active locale) imposed as the help legend shown along
them if neither model nor formhelp_text attributes were specified by the
user (or this string was appended to any help_text that was provided).

Since this happened at the model layer, there was no way to prevent the text
from appearing in cases where it wasn’t applicable such as form fields that
implement user interactions that don’t involve a keyboard and/or a mouse.

Starting with Django 1.6, as an ad-hoc temporary backward-compatibility
provision, the logic to add the “Hold down…” sentence has been moved to the
model form field layer and modified to add the text only when the associated
widget is SelectMultiple or selected subclasses.

The change can affect you in a backward incompatible way if you employ custom
model form fields and/or widgets for ManyToManyField model fields whose UIs
do rely on the automatic provision of the mentioned hard-coded sentence. These
form field implementations need to adapt to the new scenario by providing their
own handling of the help_text attribute.

The QuerySet iteration was changed to immediately convert all fetched
rows to Model objects. In Django 1.5 and earlier the fetched rows were
converted to Model objects in chunks of 100.

Existing code will work, but the amount of rows converted to objects
might change in certain use cases. Such usages include partially looping
over a queryset or any usage which ends up doing __bool__ or
__contains__.

Notably most database backends did fetch all the rows in one go already in
1.5.

It is still possible to convert the fetched rows to Model objects
lazily by using the iterator()
method.

you’ll want to remove the colon (or whatever other separator you may be
using) to avoid duplicating it when upgrading to Django 1.6. The following
template in Django 1.6 will render identically to the above template in Django
1.5, except that the colon will appear inside the <label> element.

If you want to keep the current behavior of rendering label_tag without
the label_suffix, instantiate the form label_suffix=''. You can also
customize the label_suffix on a per-field basis using the new
label_suffix parameter on label_tag().

To achieve preserving and restoring list view filters, admin views now
pass around the _changelist_filters GET parameter. It’s important that you
account for that change if you have custom admin templates or if your tests
rely on the previous URLs. If you want to revert to the original behavior you
can set the
preserve_filters attribute to False.

Past versions of Django used base 36 encoding of the User primary key in
the password reset views and URLs
(django.contrib.auth.views.password_reset_confirm()). Base 36 encoding is
sufficient if the user primary key is an integer, however, with the
introduction of custom user models in Django 1.5, that assumption may no longer
be true.

django.contrib.auth.views.password_reset_confirm() has been modified to
take a uidb64 parameter instead of uidb36. If you are reversing this
view, for example in a custom password_reset_email.html template, be sure
to update your code.

A temporary shim for django.contrib.auth.views.password_reset_confirm()
that will allow password reset links generated prior to Django 1.6 to continue
to work has been added to provide backwards compatibility; this will be removed
in Django 1.7. Thus, as long as your site has been running Django 1.6 for more
than PASSWORD_RESET_TIMEOUT_DAYS, this change will have no effect.
If not (for example, if you upgrade directly from Django 1.5 to Django 1.7),
then any password reset links generated before you upgrade to Django 1.7 or
later won’t work after the upgrade.

In addition, if you have any custom password reset URLs, you will need to
update them by replacing uidb36 with uidb64 and the dash that follows
that pattern with a slash. Also add _\- to the list of characters that may
match the uidb64 pattern.

You may also want to add the shim to support the old style reset links. Using
the example above, you would modify the existing url by replacing
django.contrib.auth.views.password_reset_confirm with
django.contrib.auth.views.password_reset_confirm_uidb36 and also remove
the name argument so it doesn’t conflict with the new url:

Historically, django.contrib.sessions used pickle to serialize
session data before storing it in the backend. If you’re using the signed
cookie session backend and SECRET_KEY is
known by an attacker (there isn’t an inherent vulnerability in Django that
would cause it to leak), the attacker could insert a string into his session
which, when unpickled, executes arbitrary code on the server. The technique for
doing so is simple and easily available on the internet. Although the cookie
session storage signs the cookie-stored data to prevent tampering, a
SECRET_KEY leak immediately escalates to a remote code execution
vulnerability.

This attack can be mitigated by serializing session data using JSON rather
than pickle. To facilitate this, Django 1.5.3 introduced a new setting,
SESSION_SERIALIZER, to customize the session serialization format.
For backwards compatibility, this setting defaulted to using pickle
in Django 1.5.3, but we’ve changed the default to JSON in 1.6. If you upgrade
and switch from pickle to JSON, sessions created before the upgrade will be
lost. While JSON serialization does not support all Python objects like
pickle does, we highly recommend using JSON-serialized sessions. Be
aware of the following when checking your code to determine if JSON
serialization will work for your application:

JSON requires string keys, so you will likely run into problems if you are
using non-string keys in request.session.

Setting session expiration by passing datetime values to
set_expiry() will
not work as datetime values are not serializable in JSON. You can use
integer values instead.

Preparation for new features. For example the ORM is now internally ready
for multicolumn foreign keys.

General cleanup.

These changes can result in some compatibility problems. For example, some
queries will now generate different table aliases. This can affect
QuerySet.extra(). In addition
some queries will now produce different results. An example is
exclude(condition)
where the condition is a complex one (referencing multijoins inside
Qobjects). In many cases the affected
queries didn’t produce correct results in Django 1.5 but do now.
Unfortunately there are also cases that produce different results, but
neither Django 1.5 nor 1.6 produce correct results.

The django.db.models.query.EmptyQuerySet can’t be instantiated any more -
it is only usable as a marker class for checking if
none() has been called:
isinstance(qs.none(),EmptyQuerySet)

If your CSS/JavaScript code used to access HTML input widgets by type, you
should review it as type='text' widgets might be now output as
type='email', type='url' or type='number' depending on their
corresponding field type.

Form field’s error_messages that contain a
placeholder should now always use a named placeholder ("Value'%(value)s'istoobig" instead of "Value'%s'istoobig"). See the corresponding
field documentation for details about the names of the placeholders. The
changes in 1.6 particularly affect DecimalField and
ModelMultipleChoiceField.

Due to a change in the form validation workflow,
TypedChoiceFieldcoerce method should always
return a value present in the choices field attribute. That limitation
should be lift again in Django 1.7.

There have been changes in the way timeouts are handled in cache backends.
Explicitly passing in timeout=None no longer results in using the
default timeout. It will now set a non-expiring timeout. Passing 0 into the
memcache backend no longer uses the default timeout, and now will
set-and-expire-immediately the value.

The django.contrib.flatpages app used to set custom HTTP headers for
debugging purposes. This functionality was not documented and made caching
ineffective so it has been removed, along with its generic implementation,
previously available in django.core.xheaders.

The XViewMiddleware has been moved from django.middleware.doc to
django.contrib.admindocs.middleware because it is an implementation
detail of admindocs, proven not to be reusable in general.

GenericIPAddressField will now only allow
blank values if null values are also allowed. Creating a
GenericIPAddressField where blank is allowed but null is not
will trigger a model validation error because blank values are always
stored as null. Previously, storing a blank value in a field which
did not allow null would cause a database exception at runtime.

If a NoReverseMatch exception is raised from a method when rendering a
template, it is not silenced. For example, {{obj.view_href}} will
cause template rendering to fail if view_href() raises
NoReverseMatch. There is no change to the {%url%} tag, it
causes template rendering to fail like always when NoReverseMatch is
raised.

Authentication views are now reversed by name,
not their locations in django.contrib.auth.views. If you are using the
views without a name, you should update your urlpatterns to use
url() with the name parameter. For example:

RedirectView now has a pattern_name
attribute which allows it to choose the target by reversing the URL.

In Django 1.4 and 1.5, a blank string was unintentionally not considered to
be a valid password. This meant
set_password() would save a blank
password as an unusable password like
set_unusable_password() does, and
thus check_password() always
returned False for blank passwords. This has been corrected in this
release: blank passwords are now valid.

The admin changelist_view previously
accepted a pop GET parameter to signify it was to be displayed in a popup.
This parameter has been renamed to _popup to be consistent with the rest
of the admin views. You should update your custom templates if they use the
previous parameter name.

The new makemessages--keep-pot option prevents deleting the
temporary .pot file generated before creating the .po file.

The undocumented django.core.servers.basehttp.WSGIServerException has
been removed. Use socket.error provided by the standard library instead.
This change was also released in Django 1.5.5.

The signature of django.views.generic.base.RedirectView.get_redirect_url()
has changed and now accepts positional arguments as well (*args,**kwargs).
Any unnamed captured group will now be passed to get_redirect_url()
which may result in a TypeError if you don’t update the signature of your
custom method.

Django’s comment framework has been deprecated and is no longer supported. It
will be available in Django 1.6 and 1.7, and removed in Django 1.8. Most users
will be better served with a custom solution, or a hosted product like Disqus.

The end of upstream support periods was reached in December 2011 for
PostgreSQL 8.2 and in February 2013 for 8.3. As a consequence, Django 1.6 sets
8.4 as the minimum PostgreSQL version it officially supports.

You’re strongly encouraged to use the most recent version of PostgreSQL
available, because of performance improvements and to take advantage of the
native streaming replication available in PostgreSQL 9.x.

The template system generally escapes all variables to avoid XSS attacks.
However, due to an accident of history, the cycle and firstof
tags render their arguments as-is.

Django 1.6 starts a process to correct this inconsistency. The future
template library provides alternate implementations of cycle and
firstof that autoescape their inputs. If you’re using these tags,
you’re encouraged to include the following line at the top of your templates to
enable the new behavior:

{%loadcyclefromfuture%}

or:

{%loadfirstoffromfuture%}

The tags implementing the old behavior have been deprecated, and in Django
1.8, the old behavior will be replaced with the new behavior. To ensure
compatibility with future versions of Django, existing templates should be
modified to use the future versions.

CacheMiddleware and UpdateCacheMiddleware used to provide a way to
cache requests only if they weren’t made by a logged-in user. This mechanism
was largely ineffective because the middleware correctly takes into account the
Vary:Cookie HTTP header, and this header is being set on a variety of
occasions, such as:

Model._meta.get_(add|change|delete)_permission methods were deprecated.
Even if they were not part of the public API they’ll also go through
a regular deprecation path. You can replace them with
django.contrib.auth.get_permission_codename('action',Model._meta) where
'action' is 'add', 'change', or 'delete'.

Methods that return a QuerySet such as Manager.get_query_set or
ModelAdmin.queryset have been renamed to get_queryset.

If you are writing a library that implements, for example, a
Manager.get_query_set method, and you need to support old Django versions,
you should rename the method and conditionally add an alias with the old name:

In the general case of a custom manager that both implements its own
get_queryset method and calls that method, and needs to work with older Django
versions, and libraries that have not been updated yet, it is useful to define
a get_queryset_compat method as below and use it internally to your manager:

classYourCustomManager(models.Manager):defget_queryset(self):returnYourCustomQuerySet()# for exampleifdjango.VERSION<(1,6):get_query_set=get_querysetdefactive(self):# for examplereturnself.get_queryset_compat().filter(active=True)defget_queryset_compat(self):get_queryset=(self.get_query_setifhasattr(self,'get_query_set')elseself.get_queryset)returnget_queryset()

This helps to minimize the changes that are needed, but also works correctly in
the case of subclasses (such as RelatedManagers from Django 1.5) which might
override either get_query_set or get_queryset.

The shortcut view was moved from django.views.defaults to
django.contrib.contenttypes.views shortly after the 1.0 release, but the
old location was never deprecated. This oversight was corrected in Django 1.6
and you should now use the new location.

The URLconf django.conf.urls.shortcut was also deprecated. If you’re
including it in an URLconf, simply replace:

Previously, if you wanted a ModelForm to use all fields on
the model, you could simply omit the Meta.fields attribute, and all fields
would be used.

This can lead to security problems where fields are added to the model and,
unintentionally, automatically become editable by end users. In some cases,
particular with boolean fields, it is possible for this problem to be completely
invisible. This is a form of Mass assignment vulnerability.

For this reason, this behavior is deprecated, and using the Meta.exclude
option is strongly discouraged. Instead, all fields that are intended for
inclusion in the form should be listed explicitly in the fields attribute.

If this security concern really does not apply in your case, there is a shortcut
to explicitly indicate that all fields should be used - use the special value
"__all__" for the fields attribute:

classMyModelForm(ModelForm):classMeta:fields="__all__"model=MyModel

If you have custom ModelForms that only need to be used in the admin, there
is another option. The admin has its own methods for defining fields
(fieldsets etc.), and so adding a list of fields to the ModelForm is
redundant. Instead, simply omit the Meta inner class of the ModelForm,
or omit the Meta.model attribute. Since the ModelAdmin subclass knows
which model it is for, it can add the necessary attributes to derive a
functioning ModelForm. This behavior also works for earlier Django
versions.

The generic views CreateView and
UpdateView, and anything else derived from
ModelFormMixin, are vulnerable to the
security problem described in the section above, because they can automatically
create a ModelForm that uses all fields for a model.

For this reason, if you use these views for editing models, you must also supply
the fields attribute (new in Django 1.6), which is a list of model fields
and works in the same way as the ModelFormMeta.fields attribute. Alternatively, you can set the form_class
attribute to a ModelForm that explicitly defines the fields to be used.
Defining an UpdateView or CreateView subclass to be used with a model
but without an explicit list of fields is deprecated.