November 6, 2013
\nWelcome to Django 1.6!
\nThese release notes cover the new features, as well as\nsome backwards incompatible changes you’ll\nwant to be aware of when upgrading from Django 1.5 or older versions. We’ve\nalso dropped some features, which are detailed in our deprecation plan, and we’ve begun the deprecation process\nfor some features.
\nDjango 1.6, like Django 1.5, requires Python 2.6.5 or above. Python 3 is also\nofficially supported. We highly recommend the latest minor release for each\nsupported Python series (2.6.X, 2.7.X, 3.2.X, and 3.3.X).
\nDjango 1.6 will be the final release series to support Python 2.6; beginning\nwith Django 1.7, the minimum supported Python version will be 2.7.
\nPython 3.4 is not supported, but support will be added in Django 1.7.
\nThe default templates used by startproject and startapp\nhave been simplified and modernized. The admin is now enabled by default in new projects; the\nsites framework no longer is. clickjacking\nprevention is now on and the database defaults to\nSQLite.
If the default templates don’t suit your tastes, you can use custom\nproject and app templates.
\nDjango’s transaction management was overhauled. Database-level autocommit is\nnow turned on by default. This makes transaction handling more explicit and\nshould improve performance. The existing APIs were deprecated, and new APIs\nwere introduced, as described in the transaction management docs.
\nDjango now supports reusing the same database connection for several requests.\nThis avoids the overhead of reestablishing a connection at the beginning of\neach request. For backwards compatibility, this feature is disabled by\ndefault. See Persistent connections for details.
\nDjango 1.6 ships with a new test runner that allows more flexibility in the\nlocation of tests. The previous runner\n(django.test.simple.DjangoTestSuiteRunner) found tests only in the\nmodels.py and tests.py modules of a Python package in\nINSTALLED_APPS.
The new runner (django.test.runner.DiscoverRunner) uses the test discovery\nfeatures built into unittest2 (the version of unittest in the\nPython 2.7+ standard library, and bundled with Django). With test discovery,\ntests can be located in any module whose name matches the pattern test*.py.
In addition, the test labels provided to ./manage.py test to nominate\nspecific tests to run must now be full Python dotted paths (or directory\npaths), rather than applabel.TestCase.test_method_name pseudo-paths. This\nallows running tests located anywhere in your codebase, rather than only in\nINSTALLED_APPS. For more details, see Testing in Django.
This change is backwards-incompatible; see the backwards-incompatibility\nnotes.
\nThe support for time zones introduced in\nDjango 1.4 didn’t work well with QuerySet.dates(): aggregation was always performed in\nUTC. This limitation was lifted in Django 1.6. Use QuerySet.datetimes() to perform time zone aware\naggregation on a DateTimeField.
Django 1.6 adds support for savepoints in SQLite, with some limitations.
\nBinaryField model fieldLink to this heading#A new django.db.models.BinaryField model field allows storage of raw\nbinary data in the database.
GeoDjango now provides form fields and widgets for its geo-specialized fields. They are\nOpenLayers-based by default, but they can be customized to use any other JS\nframework.
\ncheck management command added for verifying compatibilityLink to this heading#A check management command was added, enabling you to verify if your\ncurrent configuration (currently oriented at settings) is compatible with the\ncurrent version of Django.
Model.save() algorithm changedLink to this heading#The Model.save() method now\ntries to directly UPDATE the database if the instance has a primary\nkey value. Previously SELECT was performed to determine if UPDATE\nor INSERT were needed. The new algorithm needs only one query for\nupdating an existing row while the old algorithm needed two. See\nModel.save() for more details.
In some rare cases the database doesn’t report that a matching row was\nfound when doing an UPDATE. An example is the PostgreSQL ON UPDATE\ntrigger which returns NULL. In such cases it is possible to set\ndjango.db.models.Options.select_on_save flag to force saving to\nuse the old algorithm.
Authentication backends can raise PermissionDenied to immediately fail\nthe authentication chain.
The HttpOnly flag can be set on the CSRF cookie with\nCSRF_COOKIE_HTTPONLY.
The assertQuerysetEqual() now checks\nfor undefined order and raises ValueError if undefined\norder is spotted. The order is seen as undefined if the given QuerySet\nisn’t ordered and there is more than one ordered value to compare against.
Added earliest() for symmetry with\nlatest().
In addition to year, month and day, the ORM\nnow supports hour, minute and second lookups.
Django now wraps all PEP 249 exceptions.
The default widgets for EmailField,\nURLField, IntegerField,\nFloatField and DecimalField use\nthe new type attributes available in HTML5 (type='email', type='url',\ntype='number'). Note that due to erratic support of the number\ninput type with localized numbers in current browsers, Django only uses it\nwhen numeric fields are not localized.
The number argument for lazy plural translations can be provided at translation time rather than\nat definition time.
For custom management commands: Verification of the presence of valid\nsettings in commands that ask for it by using the\nBaseCommand.can_import_settings internal\noption is now performed independently from handling of the locale that\nshould be active during the execution of the command. The latter can now be\ninfluenced by the new\nBaseCommand.leave_locale_alone internal\noption. See Management commands and locales for more details.
The success_url of\nDeletionMixin is now interpolated with\nits object’s __dict__.
HttpResponseRedirect and\nHttpResponsePermanentRedirect now provide an url\nattribute (equivalent to the URL the response will redirect to).
The MemcachedCache cache backend now uses the latest pickle\nprotocol available.
Added SuccessMessageMixin which\nprovides a success_message attribute for\nFormView based classes.
Added the django.db.models.ForeignKey.db_constraint and\ndjango.db.models.ManyToManyField.db_constraint options.
The jQuery library embedded in the admin has been upgraded to version 1.9.1.
Syndication feeds (django.contrib.syndication) can now pass extra\ncontext through to feed templates using a new\nFeed.get_context_data() callback.
The admin list columns have a column-<field_name> class in the HTML\nso the columns header can be styled with CSS, e.g. to set a column width.
The isolation level can be customized under\nPostgreSQL.
The blocktrans template tag now respects\nTEMPLATE_STRING_IF_INVALID for variables not present in the\ncontext, just like other template constructs.
SimpleLazyObjects will now present more helpful representations in shell\ndebugging situations.
Generic GeometryField is now editable\nwith the OpenLayers widget in the admin.
The documentation contains a deployment checklist.
The diffsettings command gained a --all option.
django.forms.fields.Field.__init__ now calls super(), allowing\nfield mixins to implement __init__() methods that will reliably be\ncalled.
The validate_max parameter was added to BaseFormSet and\nformset_factory(), and ModelForm and inline\nversions of the same. The behavior of validation for formsets with\nmax_num was clarified. The previously undocumented behavior that\nhardened formsets against memory exhaustion attacks was documented,\nand the undocumented limit of the higher of 1000 or max_num forms\nwas changed so it is always 1000 more than max_num.
Added BCryptSHA256PasswordHasher to resolve the password truncation issue\nwith bcrypt.
Pillow is now the preferred image manipulation library to use with\nDjango. PIL is pending deprecation (support to be removed in Django\n1.8). To upgrade, you should first uninstall PIL, then install\nPillow.
ModelForm accepts several new Meta\noptions.
Fields included in the localized_fields list will be localized\n(by setting localize on the form field).
The labels, help_texts and error_messages options may be used\nto customize the default fields, see\nOverriding the default fields for details.
The choices argument to model fields now accepts an iterable of iterables\ninstead of requiring an iterable of lists or tuples.
The reason phrase can be customized in HTTP responses using\nreason_phrase.
When giving the URL of the next page for\ndjango.contrib.auth.views.logout(),\ndjango.contrib.auth.views.password_reset(),\ndjango.contrib.auth.views.password_reset_confirm(),\nand django.contrib.auth.views.password_change(), you can now pass\nURL names and they will be resolved.
The new dumpdata --pks option specifies the primary keys of objects\nto dump. This option can only be used with one model.
Added QuerySet methods first()\nand last() which are convenience\nmethods returning the first or last object matching the filters. Returns\nNone if there are no objects matching.
View and\nRedirectView now support HTTP PATCH\nmethod.
GenericForeignKey now takes an optional for_concrete_model argument,\nwhich when set to False allows the field to reference proxy models. The\ndefault is True to retain the old behavior.
The LocaleMiddleware now stores the active\nlanguage in session if it is not present there. This prevents loss of\nlanguage settings after session flush, e.g. logout.
SuspiciousOperation has been differentiated\ninto a number of subclasses, and each will log to a matching named logger\nunder the django.security logging hierarchy. Along with this change,\na handler400 mechanism and default view are used whenever\na SuspiciousOperation reaches the WSGI handler to return an\nHttpResponseBadRequest.
The DoesNotExist exception now includes a\nmessage indicating the name of the attribute used for the lookup.
The get_or_create() method no longer\nrequires at least one keyword argument.
The SimpleTestCase class includes a new assertion\nhelper for testing formset errors:\ndjango.test.SimpleTestCase.assertFormsetError().
The list of related fields added to a\nQuerySet by\nselect_related() can be cleared using\nselect_related(None).
The get_extra() and\nget_max_num() methods on\nInlineModelAdmin may be overridden to\ncustomize the extra and maximum number of inline forms.
Formsets now have a\ntotal_error_count() method.
ModelForm fields can now override error messages\ndefined in model fields by using the\nerror_messages argument of a Field’s\nconstructor. To take advantage of this new feature with your custom fields,\nsee the updated recommendation for raising\na ValidationError.
ModelAdmin now preserves filters on the list\nview after creating, editing or deleting an object. It’s possible to restore\nthe previous behavior of clearing filters by setting the\npreserve_filters attribute to\nFalse.
Added\nFormMixin.get_prefix\n(which returns\nFormMixin.prefix by\ndefault) to allow customizing the prefix of the\nform.
Raw queries (Manager.raw() or cursor.execute()) can now use the\n“pyformat” parameter style, where placeholders in the query are given as\n'%(name)s' and the parameters are passed as a dictionary rather than\na list (except on SQLite). This has long been possible (but not officially\nsupported) on MySQL and PostgreSQL, and is now also available on Oracle.
The default iteration count for the PBKDF2 password hasher has been\nincreased by 20%. This backwards compatible change will not affect\nexisting passwords or users who have subclassed\ndjango.contrib.auth.hashers.PBKDF2PasswordHasher to change the\ndefault value. Passwords will be upgraded to use\nthe new iteration count as necessary.
Database-level autocommit is enabled by default in Django 1.6. While this\ndoesn’t change the general spirit of Django’s transaction management, there\nare a few backwards-incompatibilities.
\nassertNumQueriesLink to this heading#The changes in transaction management may result in additional statements to\ncreate, release or rollback savepoints. This is more likely to happen with\nSQLite, since it didn’t support savepoints until this release.
\nIf tests using assertNumQueries() fail\nbecause of a higher number of queries than expected, check that the extra\nqueries are related to savepoints, and adjust the expected number of queries\naccordingly.
In previous versions, database-level autocommit was only an option for\nPostgreSQL, and it was disabled by default. This option is now ignored and can\nbe removed.
\nIn order to maintain greater consistency with Python’s unittest module, the\nnew test runner (django.test.runner.DiscoverRunner) does not automatically\nsupport some types of tests that were supported by the previous runner:
Tests in models.py and tests/__init__.py files will no longer be\nfound and run. Move them to a file whose name begins with test.
Doctests will no longer be automatically discovered. To integrate doctests in\nyour test suite, follow the recommendations in the Python documentation.
Django bundles a modified version of the doctest module from the Python\nstandard library (in django.test._doctest) and includes some additional\ndoctest utilities. These utilities are deprecated and will be removed in Django\n1.8; doctest suites should be updated to work with the standard library’s\ndoctest module (or converted to unittest-compatible tests).
If you wish to delay updates to your test suite, you can set your\nTEST_RUNNER setting to django.test.simple.DjangoTestSuiteRunner\nto fully restore the old test behavior. DjangoTestSuiteRunner is deprecated\nbut will not be removed from Django until version 1.8.
django.contrib.gis.tests.GeoDjangoTestSuiteRunner GeoDjango custom test runnerLink to this heading#This is for developers working on the GeoDjango application itself and related\nto the item above about changes in the test runners:
\nThe django.contrib.gis.tests.GeoDjangoTestSuiteRunner test runner has been\nremoved and the standalone GeoDjango tests execution setup it implemented isn’t\nsupported anymore. To run the GeoDjango tests simply use the new\nDiscoverRunner and specify the django.contrib.gis app.
The introduction of the new test runner has also slightly changed the way that\ntest models are imported. As a result, any test that overrides\nAUTH_USER_MODEL to test behavior with one of Django’s test user models (\ndjango.contrib.auth.tests.custom_user.CustomUser and\ndjango.contrib.auth.tests.custom_user.ExtensionUser) must now\nexplicitly import the User model in your test module:
from django.contrib.auth.tests.custom_user import CustomUser\n\n\n@override_settings(AUTH_USER_MODEL="auth.CustomUser")\nclass CustomUserFeatureTests(TestCase):\n def test_something(self):\n # Test code here\n ...\nThis import forces the custom user model to be registered. Without this import,\nthe test will be unable to swap in the custom user model, and you will get an\nerror reporting:
\nImproperlyConfigured: AUTH_USER_MODEL refers to model 'auth.CustomUser' that\nhas not been installed\nday, month, and week_day lookupsLink to this heading#Django 1.6 introduces time zone support for day, month,\nand week_day lookups when USE_TZ is True. These\nlookups were previously performed in UTC regardless of the current time zone.
This requires time zone definitions in the database. If you’re using SQLite, you must install\npytz. If you’re using MySQL, you must install pytz and load the time zone\ntables with mysql_tzinfo_to_sql.
\nQuerySet.datetimes()Link to this heading#When the time zone support added in Django 1.4\nwas active, QuerySet.dates()\nlookups returned unexpected results, because the aggregation was performed in\nUTC. To fix this, Django 1.6 introduces a new API, QuerySet.datetimes(). This requires a few changes in\nyour code.
QuerySet.dates() returns date objectsLink to this heading#QuerySet.dates() now returns a\nlist of date. It used to return a list of\ndatetime.
QuerySet.datetimes()\nreturns a list of datetime.
QuerySet.dates() no longer usable on DateTimeFieldLink to this heading#QuerySet.dates() raises an\nerror if it’s used on DateTimeField when time\nzone support is active. Use QuerySet.datetimes() instead.
date_hierarchy requires time zone definitionsLink to this heading#The date_hierarchy feature of the\nadmin now relies on QuerySet.datetimes() when it’s used on a\nDateTimeField.
This requires time zone definitions in the database when USE_TZ is\nTrue. Learn more.
date_list in generic views requires time zone definitionsLink to this heading#For the same reason, accessing date_list in the context of a date-based\ngeneric view requires time zone definitions in the database when the view is\nbased on a DateTimeField and USE_TZ is\nTrue. Learn more.
Django 1.6 introduces hour, minute, and second lookups on\nDateTimeField. If you had model fields called\nhour, minute, or second, the new lookups will clash with you field\nnames. Append an explicit exact lookup if this is an issue.
BooleanField no longer defaults to FalseLink to this heading#When a BooleanField doesn’t have an explicit\ndefault, the implicit default value is\nNone. In previous version of Django, it was False, but that didn’t\nrepresent accurately the lack of a value.
Code that relies on the default value being False may raise an exception\nwhen saving new model instances to the database, because None isn’t an\nacceptable value for a BooleanField. You should\neither specify default=False in the field definition, or ensure the field\nis set to True or False before saving the object.
Extraction of translatable literals from templates with the\nmakemessages command now correctly detects i18n constructs when\nthey are located after a {# / #}-type comment on the same line. E.g.:
{# A comment #}{% trans "This literal was incorrectly ignored. Not anymore" %}\nComments for translators in templates specified using {# / #} need to\nbe at the end of a line. If they are not, the comments are ignored and\nmakemessages will generate a warning. For example:
{# Translators: This is ignored #}{% trans "Translate me" %}\n{{ title }}{# Translators: Extracted and associated with 'Welcome' below #}\n<h1>{% trans "Welcome" %}</h1>\nreverse()Link to this heading#When reversing URLs, Django didn’t apply django.utils.http.urlquote\nto arguments before interpolating them in URL patterns. This bug is fixed in\nDjango 1.6. If you worked around this bug by applying URL quoting before\npassing arguments to reverse(), this may result in double-quoting. If this\nhappens, simply remove the URL quoting from your code. You will also have to\nreplace special characters in URLs used in\nassertRedirects() with their encoded\nversions.
The comments app now uses a\nGenericIPAddressField for storing commenters’ IP addresses, to support\ncomments submitted from IPv6 addresses. Until now, it stored them in an\nIPAddressField, which is only meant to support IPv4. When saving a comment\nmade from an IPv6 address, the address would be silently truncated on MySQL\ndatabases, and raise an exception on Oracle. You will need to change the\ncolumn type in your database to benefit from this change.
For MySQL, execute this query on your project’s database:
\nALTER TABLE django_comments MODIFY ip_address VARCHAR(39);\nFor Oracle, execute this query:
\nALTER TABLE DJANGO_COMMENTS MODIFY (ip_address VARCHAR2(39));\nIf you do not apply this change, the behavior is unchanged: on MySQL, IPv6\naddresses are silently truncated; on Oracle, an exception is generated. No\ndatabase change is needed for SQLite or PostgreSQL databases.
\ncursor.execute queriesLink to this heading#When you are running raw SQL queries through the\ncursor.execute method, the rule about doubling\npercent literals (%) inside the query has been unified. Past behavior\ndepended on the database backend. Now, across all backends, you only need to\ndouble literal percent characters if you are also providing replacement\nparameters. For example:
# No parameters, no percent doubling\ncursor.execute("SELECT foo FROM bar WHERE baz = '30%'")\n\n# Parameters passed, non-placeholders have to be doubled\ncursor.execute("SELECT foo FROM bar WHERE baz = '30%%' and id = %s", [self.id])\nSQLite users need to check and update such queries.
HTML rendering of model form fields corresponding to\nManyToManyField model fields used to get the\nhardcoded sentence:
\n\nHold down “Control”, or “Command” on a Mac, to select more than one.
\n
(or its translation to the active locale) imposed as the help legend shown\nalong them if neither model nor\nform help_text attributes were\nspecified by the user (or this string was appended to any help_text that\nwas provided).
Since this happened at the model layer, there was no way to prevent the text\nfrom appearing in cases where it wasn’t applicable such as form fields that\nimplement user interactions that don’t involve a keyboard and/or a mouse.
\nStarting with Django 1.6, as an ad-hoc temporary backward-compatibility\nprovision, the logic to add the “Hold down…” sentence has been moved to the\nmodel form field layer and modified to add the text only when the associated\nwidget is SelectMultiple or selected subclasses.
The change can affect you in a backward incompatible way if you employ custom\nmodel form fields and/or widgets for ManyToManyField model fields whose UIs\ndo rely on the automatic provision of the mentioned hardcoded sentence. These\nform field implementations need to adapt to the new scenario by providing their\nown handling of the help_text attribute.
Applications that use Django model form\nfacilities together with Django built-in form fields\nand widgets aren’t affected but need to be aware of\nwhat’s described in Munging of help text of model form fields for ManyToManyField fields below.
\nThe QuerySet iteration was changed to immediately convert all fetched\nrows to Model objects. In Django 1.5 and earlier the fetched rows were\nconverted to Model objects in chunks of 100.
Existing code will work, but the amount of rows converted to objects\nmight change in certain use cases. Such usages include partially looping\nover a queryset or any usage which ends up doing __bool__ or\n__contains__.
Notably most database backends did fetch all the rows in one go already in\n1.5.
\nIt is still possible to convert the fetched rows to Model objects\nlazily by using the iterator()\nmethod.
BoundField.label_tag now includes the form’s label_suffixLink to this heading#This is consistent with how methods like\nForm.as_p and\nForm.as_ul render labels.
If you manually render label_tag in your templates:
{{ form.my_field.label_tag }}: {{ form.my_field }}\nyou’ll want to remove the colon (or whatever other separator you may be\nusing) to avoid duplicating it when upgrading to Django 1.6. The following\ntemplate in Django 1.6 will render identically to the above template in Django\n1.5, except that the colon will appear inside the <label> element.
{{ form.my_field.label_tag }} {{ form.my_field }}\nwill render something like:
\n<label for="id_my_field">My Field:</label> <input id="id_my_field" type="text" name="my_field" />\nIf you want to keep the current behavior of rendering label_tag without\nthe label_suffix, instantiate the form label_suffix=''. You can also\ncustomize the label_suffix on a per-field basis using the new\nlabel_suffix parameter on label_tag().
_changelist_filters GET parameterLink to this heading#To achieve preserving and restoring list view filters, admin views now\npass around the _changelist_filters GET parameter. It’s important that you\naccount for that change if you have custom admin templates or if your tests\nrely on the previous URLs. If you want to revert to the original behavior you\ncan set the\npreserve_filters attribute to False.
django.contrib.auth password reset uses base 64 encoding of User PKLink to this heading#Past versions of Django used base 36 encoding of the User primary key in\nthe password reset views and URLs\n(django.contrib.auth.views.password_reset_confirm()). Base 36 encoding is\nsufficient if the user primary key is an integer, however, with the\nintroduction of custom user models in Django 1.5, that assumption may no longer\nbe true.
django.contrib.auth.views.password_reset_confirm() has been modified to\ntake a uidb64 parameter instead of uidb36. If you are reversing this\nview, for example in a custom password_reset_email.html template, be sure\nto update your code.
A temporary shim for django.contrib.auth.views.password_reset_confirm()\nthat will allow password reset links generated prior to Django 1.6 to continue\nto work has been added to provide backwards compatibility; this will be removed\nin Django 1.7. Thus, as long as your site has been running Django 1.6 for more\nthan PASSWORD_RESET_TIMEOUT_DAYS, this change will have no effect.\nIf not (for example, if you upgrade directly from Django 1.5 to Django 1.7),\nthen any password reset links generated before you upgrade to Django 1.7 or\nlater won’t work after the upgrade.
In addition, if you have any custom password reset URLs, you will need to\nupdate them by replacing uidb36 with uidb64 and the dash that follows\nthat pattern with a slash. Also add _\\- to the list of characters that may\nmatch the uidb64 pattern.
For example:
\nurl(\n r"^reset/(?P<uidb36>[0-9A-Za-z]+)-(?P<token>.+)/$",\n "django.contrib.auth.views.password_reset_confirm",\n name="password_reset_confirm",\n),\nbecomes:
\nurl(\n r"^reset/(?P<uidb64>[0-9A-Za-z_\\-]+)/(?P<token>.+)/$",\n "django.contrib.auth.views.password_reset_confirm",\n name="password_reset_confirm",\n),\nYou may also want to add the shim to support the old style reset links. Using\nthe example above, you would modify the existing url by replacing\ndjango.contrib.auth.views.password_reset_confirm with\ndjango.contrib.auth.views.password_reset_confirm_uidb36 and also remove\nthe name argument so it doesn’t conflict with the new url:
url(\n r"^reset/(?P<uidb36>[0-9A-Za-z]+)-(?P<token>.+)/$",\n "django.contrib.auth.views.password_reset_confirm_uidb36",\n),\nYou can remove this URL pattern after your app has been deployed with Django\n1.6 for PASSWORD_RESET_TIMEOUT_DAYS.
Historically, django.contrib.sessions used pickle to serialize\nsession data before storing it in the backend. If you’re using the signed\ncookie session backend and SECRET_KEY is\nknown by an attacker (there isn’t an inherent vulnerability in Django that\nwould cause it to leak), the attacker could insert a string into their session\nwhich, when unpickled, executes arbitrary code on the server. The technique for\ndoing so is simple and easily available on the internet. Although the cookie\nsession storage signs the cookie-stored data to prevent tampering, a\nSECRET_KEY leak immediately escalates to a remote code execution\nvulnerability.
This attack can be mitigated by serializing session data using JSON rather\nthan pickle. To facilitate this, Django 1.5.3 introduced a new setting,\nSESSION_SERIALIZER, to customize the session serialization format.\nFor backwards compatibility, this setting defaulted to using pickle\nin Django 1.5.3, but we’ve changed the default to JSON in 1.6. If you upgrade\nand switch from pickle to JSON, sessions created before the upgrade will be\nlost. While JSON serialization does not support all Python objects like\npickle does, we highly recommend using JSON-serialized sessions. Be\naware of the following when checking your code to determine if JSON\nserialization will work for your application:
JSON requires string keys, so you will likely run into problems if you are\nusing non-string keys in request.session.
Setting session expiration by passing datetime values to\nset_expiry() will\nnot work as datetime values are not serializable in JSON. You can use\ninteger values instead.
See the Session serialization documentation for more details.
\nDjango 1.6 contains many changes to the ORM. These changes fall mostly in\nthree categories:
\nBug fixes (e.g. proper join clauses for generic relations, query combining,\njoin promotion, and join trimming fixes)
Preparation for new features. For example the ORM is now internally ready\nfor multicolumn foreign keys.
General cleanup.
These changes can result in some compatibility problems. For example, some\nqueries will now generate different table aliases. This can affect\nQuerySet.extra(). In addition\nsome queries will now produce different results. An example is\nexclude(condition)\nwhere the condition is a complex one (referencing multijoins inside\nQ objects). In many cases the affected\nqueries didn’t produce correct results in Django 1.5 but do now.\nUnfortunately there are also cases that produce different results, but\nneither Django 1.5 nor 1.6 produce correct results.
Finally, there have been many changes to the ORM internal APIs.
\nThe django.db.models.query.EmptyQuerySet can’t be instantiated any more -\nit is only usable as a marker class for checking if\nnone() has been called:\nisinstance(qs.none(), EmptyQuerySet)
If your CSS/JavaScript code used to access HTML input widgets by type, you\nshould review it as type='text' widgets might be now output as\ntype='email', type='url' or type='number' depending on their\ncorresponding field type.
Form field’s error_messages that contain a\nplaceholder should now always use a named placeholder ("Value '%(value)s'\nis too big" instead of "Value '%s' is too big"). See the corresponding\nfield documentation for details about the names of the placeholders. The\nchanges in 1.6 particularly affect DecimalField and\nModelMultipleChoiceField.
Some error_messages for\nIntegerField, EmailField,\nIPAddressField, GenericIPAddressField, and\nSlugField have been suppressed because they\nduplicated error messages already provided by validators tied to the fields.
Due to a change in the form validation workflow,\nTypedChoiceField coerce method should always\nreturn a value present in the choices field attribute. That limitation\nshould be lifted again in Django 1.7.
There have been changes in the way timeouts are handled in cache backends.\nExplicitly passing in timeout=None no longer results in using the\ndefault timeout. It will now set a non-expiring timeout. Passing 0 into the\nmemcache backend no longer uses the default timeout, and now will\nset-and-expire-immediately the value.
The django.contrib.flatpages app used to set custom HTTP headers for\ndebugging purposes. This functionality was not documented and made caching\nineffective so it has been removed, along with its generic implementation,\npreviously available in django.core.xheaders.
The XViewMiddleware has been moved from django.middleware.doc to\ndjango.contrib.admindocs.middleware because it is an implementation\ndetail of admindocs, proven not to be reusable in general.
GenericIPAddressField will now only allow\nblank values if null values are also allowed. Creating a\nGenericIPAddressField where blank is allowed but null is not\nwill trigger a model validation error because blank values are always\nstored as null. Previously, storing a blank value in a field which\ndid not allow null would cause a database exception at runtime.
If a NoReverseMatch exception is raised from a method when rendering a\ntemplate, it is not silenced. For example, {{ obj.view_href }} will\ncause template rendering to fail if view_href() raises\nNoReverseMatch. There is no change to the {% url %} tag, it\ncauses template rendering to fail like always when NoReverseMatch is\nraised.
django.test.Client.logout() now calls\ndjango.contrib.auth.logout() which will send the\nuser_logged_out() signal.
Authentication views are now reversed by name,\nnot their locations in django.contrib.auth.views. If you are using the\nviews without a name, you should update your urlpatterns to use\ndjango.conf.urls.url() with the name parameter. For example:
(r"^reset/done/$", "django.contrib.auth.views.password_reset_complete")\nbecomes:
\nurl(\n r"^reset/done/$",\n "django.contrib.auth.views.password_reset_complete",\n name="password_reset_complete",\n)\nRedirectView now has a pattern_name\nattribute 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\nbe a valid password. This meant\nset_password() would save a blank\npassword as an unusable password like\nset_unusable_password() does, and\nthus check_password() always\nreturned False for blank passwords. This has been corrected in this\nrelease: blank passwords are now valid.
The admin changelist_view previously\naccepted a pop GET parameter to signify it was to be displayed in a\npopup. This parameter has been renamed to _popup to be consistent with\nthe rest of the admin views. You should update your custom templates if they\nuse the previous parameter name.
validate_email() now accepts email addresses\nwith localhost as the domain.
The new makemessages --keep-pot option prevents deleting the\ntemporary .pot file generated before creating the .po file.
The undocumented django.core.servers.basehttp.WSGIServerException has\nbeen removed. Use socket.error provided by the standard library instead.\nThis change was also released in Django 1.5.5.
The signature of\ndjango.views.generic.base.RedirectView.get_redirect_url() has changed\nand now accepts positional arguments as well (*args, **kwargs). Any\nunnamed captured group will now be passed to get_redirect_url() which may\nresult in a TypeError if you don’t update the signature of your custom\nmethod.
Transaction management was completely overhauled in Django 1.6, and the\ncurrent APIs are deprecated:
\ndjango.middleware.transaction.TransactionMiddleware
django.db.transaction.autocommit
django.db.transaction.commit_on_success
django.db.transaction.commit_manually
the TRANSACTIONS_MANAGED setting
django.contrib.commentsLink to this heading#Django’s comment framework has been deprecated and is no longer supported. It\nwill be available in Django 1.6 and 1.7, and removed in Django 1.8. Most users\nwill be better served with a custom solution, or a hosted product like\nDisqus.
\nThe code formerly known as django.contrib.comments is still available\nin an external repository.
The end of upstream support periods was reached in December 2011 for\nPostgreSQL 8.2 and in February 2013 for 8.3. As a consequence, Django 1.6 sets\n8.4 as the minimum PostgreSQL version it officially supports.
\nYou’re strongly encouraged to use the most recent version of PostgreSQL\navailable, because of performance improvements and to take advantage of the\nnative streaming replication available in PostgreSQL 9.x.
\ncycle and firstofLink to this heading#The template system generally escapes all variables to avoid XSS attacks.\nHowever, due to an accident of history, the cycle and firstof\ntags render their arguments as-is.
Django 1.6 starts a process to correct this inconsistency. The future\ntemplate library provides alternate implementations of cycle and\nfirstof that autoescape their inputs. If you’re using these tags,\nyou’re encouraged to include the following line at the top of your templates to\nenable the new behavior:
{% load cycle from future %}\nor:
\n{% load firstof from future %}\nThe tags implementing the old behavior have been deprecated, and in Django\n1.8, the old behavior will be replaced with the new behavior. To ensure\ncompatibility with future versions of Django, existing templates should be\nmodified to use the future versions.
If necessary, you can temporarily disable auto-escaping with\nmark_safe() or {% autoescape off %}.
CACHE_MIDDLEWARE_ANONYMOUS_ONLY settingLink to this heading#CacheMiddleware and UpdateCacheMiddleware used to provide a way to\ncache requests only if they weren’t made by a logged-in user. This mechanism\nwas largely ineffective because the middleware correctly takes into account the\nVary: Cookie HTTP header, and this header is being set on a variety of\noccasions, such as:
accessing the session, or
using CSRF protection, which is turned on by default, or
using a client-side library which sets cookies, like Google Analytics.
This makes the cache effectively work on a per-session basis regardless of the\nCACHE_MIDDLEWARE_ANONYMOUS_ONLY setting.
SEND_BROKEN_LINK_EMAILS settingLink to this heading#CommonMiddleware used to provide basic\nreporting of broken links by email when SEND_BROKEN_LINK_EMAILS is set to\nTrue.
Because of intractable ordering problems between\nCommonMiddleware and\nLocaleMiddleware, this feature was split\nout into a new middleware:\nBrokenLinkEmailsMiddleware.
If you’re relying on this feature, you should add\n'django.middleware.common.BrokenLinkEmailsMiddleware' to your\nMIDDLEWARE_CLASSES setting and remove SEND_BROKEN_LINK_EMAILS\nfrom your settings.
_has_changed method on widgetsLink to this heading#If you defined your own form widgets and defined the _has_changed method\non a widget, you should now define this method on the form field itself.
module_name model _meta attributeLink to this heading#Model._meta.module_name was renamed to model_name. Despite being a\nprivate API, it will go through a regular deprecation path.
get_(add|change|delete)_permission model _meta methodsLink to this heading#Model._meta.get_(add|change|delete)_permission methods were deprecated.\nEven if they were not part of the public API they’ll also go through\na regular deprecation path. You can replace them with\ndjango.contrib.auth.get_permission_codename('action', Model._meta) where\n'action' is 'add', 'change', or 'delete'.
get_query_set and similar methods renamed to get_querysetLink to this heading#Methods that return a QuerySet such as Manager.get_query_set or\nModelAdmin.queryset have been renamed to get_queryset.
If you are writing a library that implements, for example, a\nManager.get_query_set method, and you need to support old Django versions,\nyou should rename the method and conditionally add an alias with the old name:
class CustomManager(models.Manager):\n def get_queryset(self):\n pass # ...\n\n if django.VERSION < (1, 6):\n get_query_set = get_queryset\n\n # For Django >= 1.6, models.Manager provides a get_query_set fallback\n # that emits a warning when used.\nIf you are writing a library that needs to call the get_queryset method and\nmust support old Django versions, you should write:
get_queryset = (\n some_manager.get_query_set\n if hasattr(some_manager, "get_query_set")\n else some_manager.get_queryset\n)\nreturn get_queryset() # etc\nIn the general case of a custom manager that both implements its own\nget_queryset method and calls that method, and needs to work with older\nDjango versions, and libraries that have not been updated yet, it is useful to\ndefine a get_queryset_compat method as below and use it internally to your\nmanager:
class YourCustomManager(models.Manager):\n def get_queryset(self):\n return YourCustomQuerySet() # for example\n\n if django.VERSION < (1, 6):\n get_query_set = get_queryset\n\n def active(self): # for example\n return self.get_queryset_compat().filter(active=True)\n\n def get_queryset_compat(self):\n get_queryset = (\n self.get_query_set if hasattr(self, "get_query_set") else self.get_queryset\n )\n return get_queryset()\nThis helps to minimize the changes that are needed, but also works correctly in\nthe case of subclasses (such as RelatedManagers from Django 1.5) which\nmight override either get_query_set or get_queryset.
shortcut view and URLconfLink to this heading#The shortcut view was moved from django.views.defaults to\ndjango.contrib.contenttypes.views shortly after the 1.0 release, but the\nold location was never deprecated. This oversight was corrected in Django 1.6\nand you should now use the new location.
The URLconf django.conf.urls.shortcut was also deprecated. If you’re\nincluding it in an URLconf, simply replace:
(r"^prefix/", include("django.conf.urls.shortcut")),\nwith:
\n(\n r"^prefix/(?P<content_type_id>\\d+)/(?P<object_id>.*)/$",\n "django.contrib.contenttypes.views.shortcut",\n),\nModelForm without fields or excludeLink to this heading#Previously, if you wanted a ModelForm to use all fields\non the model, you could simply omit the Meta.fields attribute, and all\nfields would be used.
This can lead to security problems where fields are added to the model and,\nunintentionally, automatically become editable by end users. In some cases,\nparticular with boolean fields, it is possible for this problem to be\ncompletely invisible. This is a form of Mass assignment vulnerability.
\nFor this reason, this behavior is deprecated, and using the Meta.exclude\noption is strongly discouraged. Instead, all fields that are intended for\ninclusion 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\nshortcut to explicitly indicate that all fields should be used - use the\nspecial value "__all__" for the fields attribute:
class MyModelForm(ModelForm):\n class Meta:\n fields = "__all__"\n model = MyModel\nIf you have custom ModelForms that only need to be used in the admin, there\nis another option. The admin has its own methods for defining fields\n(fieldsets etc.), and so adding a list of fields to the ModelForm is\nredundant. Instead, simply omit the Meta inner class of the ModelForm,\nor omit the Meta.model attribute. Since the ModelAdmin subclass knows\nwhich model it is for, it can add the necessary attributes to derive a\nfunctioning ModelForm. This behavior also works for earlier Django\nversions.
UpdateView and CreateView without explicit fieldsLink to this heading#The generic views CreateView and\nUpdateView, and anything else derived from\nModelFormMixin, are vulnerable to the\nsecurity problem described in the section above, because they can automatically\ncreate a ModelForm that uses all fields for a model.
For this reason, if you use these views for editing models, you must also\nsupply the fields attribute (new in Django 1.6), which is a list of model\nfields and works in the same way as the ModelForm\nMeta.fields attribute. Alternatively, you can set the form_class\nattribute to a ModelForm that explicitly defines the fields to be used.\nDefining an UpdateView or CreateView subclass to be used with a model\nbut without an explicit list of fields is deprecated.
ManyToManyField fieldsLink to this heading#All special handling of the help_text attribute of ManyToManyField\nmodel fields performed by standard model or model form fields as described in\nHelp text of model form fields for ManyToManyField fields above is deprecated and will be removed in Django 1.8.
Help text of these fields will need to be handled either by applications,\ncustom form fields or widgets, just like happens with the rest of the model\nfield types.
\n