1.8.txt 36 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330331332333334335336337338339340341342343344345346347348349350351352353354355356357358359360361362363364365366367368369370371372373374375376377378379380381382383384385386387388389390391392393394395396397398399400401402403404405406407408409410411412413414415416417418419420421422423424425426427428429430431432433434435436437438439440441442443444445446447448449450451452453454455456457458459460461462463464465466467468469470471472473474475476477478479480481482483484485486487488489490491492493494495496497498499500501502503504505506507508509510511512513514515516517518519520521522523524525526527528529530531532533534535536537538539540541542543544545546547548549550551552553554555556557558559560561562563564565566567568569570571572573574575576577578579580581582583584585586587588589590591592593594595596597598599600601602603604605606607608609610611612613614615616617618619620621622623624625626627628629630631632633634635636637638639640641642643644645646647648649650651652653654655656657658659660661662663664665666667668669670671672673674675676677678679680681682683684685686687688689690691692693694695696697698699700701702703704705706707708709710711712713714715716717718719720721722723724725726727728729730731732733734735736737738739740741742743744745746747748749750751752753754755756757758759760761762763764765766767768769770771772773774775776777778779780781782783784785786787788789790791792793794795796797798799800801802803804805806807808809810811812813814815816817818819820821822823824825826827828829830831832833834835836837838839840841842843844845846847848849850851852853854855856857858859860861862863864865866867868869870871872873874875876877878879880881882883884885886887
  1. ============================================
  2. Django 1.8 release notes - UNDER DEVELOPMENT
  3. ============================================
  4. Welcome to Django 1.8!
  5. These release notes cover the `new features`_, as well as some `backwards
  6. incompatible changes`_ you'll want to be aware of when upgrading from Django
  7. 1.6 or older versions. We've also dropped some features, which are detailed in
  8. :ref:`our deprecation plan <deprecation-removed-in-1.8>`, and we've `begun the
  9. deprecation process for some features`_.
  10. .. _`new features`: `What's new in Django 1.8`_
  11. .. _`backwards incompatible changes`: `Backwards incompatible changes in 1.8`_
  12. .. _`begun the deprecation process for some features`: `Features deprecated in 1.8`_
  13. Python compatibility
  14. ====================
  15. Like Django 1.7, Django 1.8 requires Python 2.7 or above, though we
  16. **highly recommend** the latest minor release.
  17. What's new in Django 1.8
  18. ========================
  19. Security enhancements
  20. ~~~~~~~~~~~~~~~~~~~~~
  21. Several features of the django-secure_ third-party library have been
  22. integrated into Django. :class:`django.middleware.security.SecurityMiddleware`
  23. provides several security enhancements to the request/response cycle. The new
  24. :djadminopt:`--deploy` option of the :djadmin:`check` command allows you to
  25. check your production settings file for ways to increase the security of your
  26. site.
  27. .. _django-secure: https://pypi.python.org/pypi/django-secure
  28. New data types
  29. ~~~~~~~~~~~~~~
  30. * Django now has a :class:`~django.db.models.UUIDField` for storing
  31. universally unique identifiers. There is a corresponding :class:`form field
  32. <django.forms.UUIDField>`. It is stored as the native ``uuid`` data type on
  33. PostgreSQL and as a fixed length character field on other backends.
  34. Minor features
  35. ~~~~~~~~~~~~~~
  36. :mod:`django.contrib.admin`
  37. ^^^^^^^^^^^^^^^^^^^^^^^^^^^
  38. * :class:`~django.contrib.admin.ModelAdmin` now has a
  39. :meth:`~django.contrib.admin.ModelAdmin.has_module_permission`
  40. method to allow limiting access to the module on the admin index page.
  41. * :class:`~django.contrib.admin.InlineModelAdmin` now has an attribute
  42. :attr:`~django.contrib.admin.InlineModelAdmin.show_change_link` that
  43. supports showing a link to an inline object's change form.
  44. * Use the new ``django.contrib.admin.RelatedOnlyFieldListFilter`` in
  45. :attr:`ModelAdmin.list_filter <django.contrib.admin.ModelAdmin.list_filter>`
  46. to limit the ``list_filter`` choices to foreign objects which are attached to
  47. those from the ``ModelAdmin``.
  48. * The :meth:`ModelAdmin.delete_view()
  49. <django.contrib.admin.ModelAdmin.delete_view>` displays a summary of objects
  50. to be deleted on the deletion confirmation page.
  51. * The jQuery library embedded in the admin has been upgraded to version 1.11.1.
  52. * You can now specify :attr:`AdminSite.site_url
  53. <django.contrib.admin.AdminSite.site_url>` in order to display a link to the
  54. front-end site.
  55. * You can now specify :attr:`ModelAdmin.show_full_result_count
  56. <django.contrib.admin.ModelAdmin.show_full_result_count>` to control whether
  57. or not the full count of objects should be displayed on a filtered admin page.
  58. :mod:`django.contrib.auth`
  59. ^^^^^^^^^^^^^^^^^^^^^^^^^^
  60. * Authorization backends can now raise
  61. :class:`~django.core.exceptions.PermissionDenied` in
  62. :meth:`~django.contrib.auth.models.User.has_perm`
  63. and :meth:`~django.contrib.auth.models.User.has_module_perms`
  64. to short-circuit permission checking.
  65. * :class:`~django.contrib.auth.forms.PasswordResetForm` now
  66. has a method :meth:`~django.contrib.auth.forms.PasswordResetForm.send_email`
  67. that can be overridden to customize the mail to be sent.
  68. * The ``max_length`` of :attr:`Permission.name
  69. <django.contrib.auth.models.Permission.name>` has been increased from 50 to
  70. 255 characters. Please run the database migration.
  71. * :attr:`~django.contrib.auth.models.CustomUser.USERNAME_FIELD` and
  72. :attr:`~django.contrib.auth.models.CustomUser.REQUIRED_FIELDS` now supports
  73. :class:`~django.db.models.ForeignKey`\s.
  74. :mod:`django.contrib.formtools`
  75. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  76. * A :doc:`form wizard </ref/contrib/formtools/form-wizard>` using the
  77. :class:`~django.contrib.formtools.wizard.views.CookieWizardView` will now ignore
  78. an invalid cookie, and the wizard will restart from the first step. An invalid
  79. cookie can occur in cases of intentional manipulation, but also after a secret
  80. key change. Previously, this would raise ``WizardViewCookieModified``, a
  81. ``SuspiciousOperation``, causing an exception for any user with an invalid cookie
  82. upon every request to the wizard, until the cookie is removed.
  83. :mod:`django.contrib.gis`
  84. ^^^^^^^^^^^^^^^^^^^^^^^^^^
  85. * Compatibility shims for ``SpatialRefSys`` and ``GeometryColumns`` changed in
  86. Django 1.2 have been removed.
  87. * The Spatialite backend now supports ``Collect`` and ``Extent`` aggregates
  88. when the database version is 3.0 or later.
  89. :mod:`django.contrib.messages`
  90. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  91. * ...
  92. :mod:`django.contrib.redirects`
  93. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  94. * ...
  95. :mod:`django.contrib.sessions`
  96. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  97. * Session cookie is now deleted after
  98. :meth:`~django.contrib.sessions.backends.base.SessionBase.flush()` is called.
  99. :mod:`django.contrib.sitemaps`
  100. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  101. * The new :attr:`Sitemap.i18n <django.contrib.sitemaps.Sitemap.i18n>` attribute
  102. allows you to generate a sitemap based on the :setting:`LANGUAGES` setting.
  103. :mod:`django.contrib.sites`
  104. ^^^^^^^^^^^^^^^^^^^^^^^^^^^
  105. * :func:`~django.contrib.sites.shortcuts.get_current_site` will now lookup
  106. the current site based on :meth:`request.get_host()
  107. <django.http.HttpRequest.get_host>` if the :setting:`SITE_ID` setting is not
  108. defined.
  109. :mod:`django.contrib.staticfiles`
  110. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  111. * ...
  112. :mod:`django.contrib.syndication`
  113. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  114. * ...
  115. Cache
  116. ^^^^^
  117. * The ``incr()`` method of the
  118. ``django.core.cache.backends.locmem.LocMemCache`` backend is now thread-safe.
  119. Database backends
  120. ^^^^^^^^^^^^^^^^^
  121. * The MySQL backend no longer strips microseconds from ``datetime`` values as
  122. MySQL 5.6.4 and up supports fractional seconds depending on the declaration
  123. of the datetime field (when ``DATETIME`` includes fractional precision greater
  124. than 0). New datetime database columns created with Django 1.8 and MySQL 5.6.4
  125. and up will support microseconds. See the :ref:`MySQL database notes
  126. <mysql-fractional-seconds>` for more details.
  127. Email
  128. ^^^^^
  129. * :ref:`Email backends <topic-email-backends>` now support the context manager
  130. protocol for opening and closing connections.
  131. * The SMTP email backend now supports ``keyfile`` and ``certfile``
  132. authentication with the :setting:`EMAIL_SSL_CERTFILE` and
  133. :setting:`EMAIL_SSL_KEYFILE` settings.
  134. * The SMTP :class:`~django.core.mail.backends.smtp.EmailBackend` now supports
  135. setting the ``timeout`` parameter with the :setting:`EMAIL_TIMEOUT` setting.
  136. File Storage
  137. ^^^^^^^^^^^^
  138. * ...
  139. File Uploads
  140. ^^^^^^^^^^^^
  141. * ...
  142. Forms
  143. ^^^^^
  144. * Form widgets now render attributes with a value of ``True`` or ``False``
  145. as HTML5 boolean attributes.
  146. * The new :meth:`~django.forms.Form.has_error()` method allows checking
  147. if a specific error has happened.
  148. * If :attr:`~django.forms.Form.required_css_class` is defined on a form, then
  149. the ``<label>`` tags for required fields will have this class present in its
  150. attributes.
  151. * The rendering of non-field errors in unordered lists (``<ul>``) now includes
  152. ``nonfield`` in its list of classes to distinguish them from field-specific
  153. errors.
  154. * :class:`~django.forms.Field` now accepts a
  155. :attr:`~django.forms.Field.label_suffix` argument, which will override the
  156. form's :attr:`~django.forms.Form.label_suffix`. This enables customizing the
  157. suffix on a per-field basis — previously it wasn't possible to override
  158. a form's :attr:`~django.forms.Form.label_suffix` while using shortcuts such
  159. as ``{{ form.as_p }}`` in templates.
  160. * :class:`~django.forms.extras.widgets.SelectDateWidget` now accepts an
  161. :attr:`~django.forms.extras.widgets.SelectDateWidget.empty_label` argument, which will
  162. override the top list choice label when :class:`~django.forms.DateField` is not required.
  163. * After an :class:`~django.forms.ImageField` has been cleaned and validated, the
  164. ``UploadedFile`` object will have an additional ``image`` attribute containing
  165. the Pillow ``Image`` instance used to check if the file was a valid image. It
  166. will also update ``UploadedFile.content_type`` with the image's content type
  167. as determined by Pillow.
  168. Generic Views
  169. ^^^^^^^^^^^^^
  170. * Generic views that use :class:`~django.views.generic.list.MultipleObjectMixin`
  171. may now specify the ordering applied to the
  172. :attr:`~django.views.generic.list.MultipleObjectMixin.queryset` by setting
  173. :attr:`~django.views.generic.list.MultipleObjectMixin.ordering` or overriding
  174. :meth:`~django.views.generic.list.MultipleObjectMixin.get_ordering()`.
  175. * The new :attr:`SingleObjectMixin.query_pk_and_slug
  176. <django.views.generic.detail.SingleObjectMixin.query_pk_and_slug>`
  177. attribute allows changing the behavior of
  178. :meth:`~django.views.generic.detail.SingleObjectMixin.get_object()`
  179. so that it'll perform its lookup using both the primary key and the slug.
  180. Internationalization
  181. ^^^^^^^^^^^^^^^^^^^^
  182. * :setting:`FORMAT_MODULE_PATH` can now be a list of strings representing
  183. module paths. This allows importing several format modules from different
  184. reusable apps. It also allows overriding those custom formats in your main
  185. Django project.
  186. Management Commands
  187. ^^^^^^^^^^^^^^^^^^^
  188. * :djadmin:`dumpdata` now has the option :djadminopt:`--output` which allows
  189. specifying the file to which the serialized data is written.
  190. * :djadmin:`makemessages` and :djadmin:`compilemessages` now have the option
  191. :djadminopt:`--exclude` which allows exclusion of specific locales from
  192. processing.
  193. * The :djadminopt:`--ignorenonexistent` option of the :djadmin:`loaddata`
  194. management command now ignores data for models that no longer exist.
  195. * :djadmin:`runserver` now uses daemon threads for faster reloading.
  196. * :djadmin:`inspectdb` now outputs ``Meta.unique_together``.
  197. * When calling management commands from code through :ref:`call_command
  198. <call-command>` and passing options, the option name can match the command
  199. line option name (without the initial dashes) or the final option destination
  200. variable name, but in either case, the resulting option received by the
  201. command is now always the ``dest`` name specified in the command option
  202. definition (as long as the command uses the new :py:mod:`argparse` module).
  203. * The :djadmin:`dbshell` command now supports MySQL's optional SSL certificate
  204. authority setting (``--ssl-ca``).
  205. * The :djadminopt:`--name` option for :djadmin:`makemigrations` allows you to
  206. to give the migration(s) a custom name instead of a generated one.
  207. Migrations
  208. ^^^^^^^^^^
  209. * The :class:`~django.db.migrations.operations.RunSQL` operation can now handle
  210. parameters passed to the SQL statements.
  211. * It is now possible to have migrations (most probably :ref:`data migrations
  212. <data-migrations>`) for applications without models.
  213. Models
  214. ^^^^^^
  215. * Django now logs at most 9000 queries in ``connections.queries``, in order
  216. to prevent excessive memory usage in long-running processes in debug mode.
  217. * There is now a model ``Meta`` option to define a
  218. :attr:`default related name <django.db.models.Options.default_related_name>`
  219. for all relational fields of a model.
  220. * Pickling models and querysets across different versions of Django isn't
  221. officially supported (it may work, but there's no guarantee). An extra
  222. variable that specifies the current Django version is now added to the
  223. pickled state of models and querysets, and Django raises a ``RuntimeWarning``
  224. when these objects are unpickled in a different version than the one in
  225. which they were pickled.
  226. * Added :meth:`Model.from_db() <django.db.models.Model.from_db()>` which
  227. Django uses whenever objects are loaded using the ORM. The method allows
  228. customizing model loading behavior.
  229. * ``extra(select={...})`` now allows you to escape a literal ``%s`` sequence
  230. using ``%%s``.
  231. * :doc:`Custom Lookups</howto/custom-lookups>` can now be registered using
  232. a decorator pattern.
  233. * The new :attr:`Transform.bilateral <django.db.models.Transform.bilateral>`
  234. attribute allows creating bilateral transformations. These transformations
  235. are applied to both ``lhs`` and ``rhs`` when used in a lookup expression,
  236. providing opportunities for more sophisticated lookups.
  237. Signals
  238. ^^^^^^^
  239. * Exceptions from the ``(receiver, exception)`` tuples returned by
  240. :meth:`Signal.send_robust() <django.dispatch.Signal.send_robust>` now have
  241. their traceback attached as a ``__traceback__`` attribute.
  242. * The ``environ`` argument, which contains the WSGI environment structure from
  243. the request, was added to the :data:`~django.core.signals.request_started`
  244. signal.
  245. Templates
  246. ^^^^^^^^^
  247. * :tfilter:`urlize` now supports domain-only links that include characters after
  248. the top-level domain (e.g. ``djangoproject.com/`` and
  249. ``djangoproject.com/download/``).
  250. Requests and Responses
  251. ^^^^^^^^^^^^^^^^^^^^^^
  252. * ``WSGIRequest`` now respects paths starting with ``//``.
  253. * The :meth:`HttpRequest.build_absolute_uri()
  254. <django.http.HttpRequest.build_absolute_uri>` method now handles paths
  255. starting with ``//`` correctly.
  256. * If :setting:`DEBUG` is ``True`` and a request raises a
  257. :exc:`~django.core.exceptions.SuspiciousOperation`, the response will be
  258. rendered with a detailed error page.
  259. * The ``query_string`` argument of :class:`~django.http.QueryDict` is now
  260. optional, defaulting to ``None``, so a blank ``QueryDict`` can now be
  261. instantiated with ``QueryDict()`` instead of ``QueryDict(None)`` or
  262. ``QueryDict('')``.
  263. * The ``GET`` and ``POST`` attributes of an :class:`~django.http.HttpRequest`
  264. object are now :class:`~django.http.QueryDict`\s rather than dictionaries,
  265. and the ``FILES`` attribute is now a ``MultiValueDict``.
  266. This brings this class into line with the documentation and with
  267. ``WSGIRequest``.
  268. * The :attr:`HttpResponse.charset <django.http.HttpResponse.charset>` attribute
  269. was added.
  270. * ``WSGIRequestHandler`` now follows RFC in converting URI to IRI, using
  271. ``uri_to_iri()``.
  272. Tests
  273. ^^^^^
  274. * The :class:`RequestFactory.trace() <django.test.RequestFactory>`
  275. and :class:`Client.trace() <django.test.Client.trace>` methods were
  276. implemented, allowing you to create ``TRACE`` requests in your tests.
  277. * The ``count`` argument was added to
  278. :meth:`~django.test.SimpleTestCase.assertTemplateUsed`. This allows you to
  279. assert that a template was rendered a specific number of times.
  280. * The new :meth:`~django.test.SimpleTestCase.assertJSONNotEqual` assertion
  281. allows you to test that two JSON fragments are not equal.
  282. * Added the ability to preserve the test database by adding the
  283. :djadminopt:`--keepdb` flag.
  284. * Added the :attr:`~django.test.Response.resolver_match` attribute to test
  285. client responses.
  286. * Added several settings that allow customization of test tablespace parameters
  287. for Oracle: :setting:`DATAFILE`, :setting:`DATAFILE_TMP`,
  288. :setting:`DATAFILE_MAXSIZE` and :setting:`DATAFILE_TMP_MAXSIZE`.
  289. Validators
  290. ^^^^^^^^^^
  291. * ...
  292. Backwards incompatible changes in 1.8
  293. =====================================
  294. .. warning::
  295. In addition to the changes outlined in this section, be sure to review the
  296. :ref:`deprecation plan <deprecation-removed-in-1.8>` for any features that
  297. have been removed. If you haven't updated your code within the
  298. deprecation timeline for a given feature, its removal may appear as a
  299. backwards incompatible change.
  300. Related object operations are run in a transaction
  301. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  302. Some operations on related objects such as
  303. :meth:`~django.db.models.fields.related.RelatedManager.add()` or
  304. :ref:`direct assignment<direct-assignment>` ran multiple data modifying
  305. queries without wrapping them in transactions. To reduce the risk of data
  306. corruption, all data modifying methods that affect multiple related objects
  307. (i.e. ``add()``, ``remove()``, ``clear()``, and :ref:`direct assignment
  308. <direct-assignment>`) now perform their data modifying queries from within a
  309. transaction, provided your database supports transactions.
  310. This has one backwards incompatible side effect, signal handlers triggered from
  311. these methods are now executed within the method's transaction and any
  312. exception in a signal handler will prevent the whole operation.
  313. Assigning unsaved objects to relations raises an error
  314. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  315. Assigning unsaved objects to a :class:`~django.db.models.ForeignKey`,
  316. :class:`~django.contrib.contenttypes.fields.GenericForeignKey`, and
  317. :class:`~django.db.models.OneToOneField` now raises a :exc:`ValueError`.
  318. Previously, the assignment of an unsaved object would be silently ignored.
  319. For example::
  320. >>> book = Book.objects.create(name="Django")
  321. >>> book.author = Author(name="John")
  322. >>> book.author.save()
  323. >>> book.save()
  324. >>> Book.objects.get(name="Django")
  325. >>> book.author
  326. >>>
  327. Now, an error will be raised to prevent data loss::
  328. >>> book.author = Author(name="john")
  329. Traceback (most recent call last):
  330. ...
  331. ValueError: Cannot assign "<Author: John>": "Author" instance isn't saved in the database.
  332. Management commands that only accept positional arguments
  333. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  334. If you have written a custom management command that only accepts positional
  335. arguments and you didn't specify the
  336. :attr:`~django.core.management.BaseCommand.args` command variable, you might
  337. get an error like ``Error: unrecognized arguments: ...``, as variable parsing
  338. is now based on :py:mod:`argparse` which doesn't implicitly accept positional
  339. arguments. You can make your command backwards compatible by simply setting the
  340. :attr:`~django.core.management.BaseCommand.args` class variable. However, if
  341. you don't have to keep compatibility with older Django versions, it's better to
  342. implement the new :meth:`~django.core.management.BaseCommand.add_arguments`
  343. method as described in :doc:`/howto/custom-management-commands`.
  344. Custom test management command arguments through test runner
  345. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  346. The method to add custom arguments to the `test` management command through the
  347. test runner has changed. Previously, you could provide an `option_list` class
  348. variable on the test runner to add more arguments (à la :py:mod:`optparse`).
  349. Now to implement the same behavior, you have to create an
  350. ``add_arguments(cls, parser)`` class method on the test runner and call
  351. ``parser.add_argument`` to add any custom arguments, as parser is now an
  352. :py:class:`argparse.ArgumentParser` instance.
  353. Model check ensures auto-generated column names are within limits specified by database
  354. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  355. A field name that's longer than the column name length supported by a database
  356. can create problems. For example, with MySQL you'll get an exception trying to
  357. create the column, and with PostgreSQL the column name is truncated by the
  358. database (you may see a warning in the PostgreSQL logs).
  359. A model check has been introduced to better alert users to this scenario before
  360. the actual creation of database tables.
  361. If you have an existing model where this check seems to be a false positive,
  362. for example on PostgreSQL where the name was already being truncated, simply
  363. use :attr:`~django.db.models.Field.db_column` to specify the name that's being
  364. used.
  365. The check also applies to the columns generated in an implicit
  366. ``ManyToManyField.through`` model. If you run into an issue there, use
  367. :attr:`~django.db.models.ManyToManyField.through` to create an explicit model
  368. and then specify :attr:`~django.db.models.Field.db_column` on its column(s)
  369. as needed.
  370. Query relation lookups now check object types
  371. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  372. Querying for model lookups now checks if the object passed is of correct type
  373. and raises a :exc:`ValueError` if not. Previously, Django didn't care if the
  374. object was of correct type; it just used the object's related field attribute
  375. (e.g. ``id``) for the lookup. Now, an error is raised to prevent incorrect
  376. lookups::
  377. >>> book = Book.objects.create(name="Django")
  378. >>> book = Book.objects.filter(author=book)
  379. Traceback (most recent call last):
  380. ...
  381. ValueError: Cannot query "<Book: Django>": Must be "Author" instance.
  382. Default ``EmailField.max_length`` increased to 254
  383. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  384. The old default 75 character ``max_length`` was not capable of storing all
  385. possible RFC3696/5321-compliant email addresses. In order to store all
  386. possible valid email addresses, the ``max_length`` has been increased to 254
  387. characters. You will need to generate and apply database migrations for your
  388. affected models (or add ``max_length=75`` if you wish to keep the length on
  389. your current fields). A migration for
  390. :attr:`django.contrib.auth.models.User.email` is included.
  391. Support for PostgreSQL versions older than 9.0
  392. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  393. The end of upstream support periods was reached in July 2014 for PostgreSQL 8.4.
  394. As a consequence, Django 1.8 sets 9.0 as the minimum PostgreSQL version it
  395. officially supports.
  396. This also includes dropping support for PostGIS 1.3 and 1.4 as these versions
  397. are not supported on versions of PostgreSQL later than 8.4.
  398. Django also now requires the use of Psycopg2 version 2.0.9 or higher.
  399. Support for MySQL versions older than 5.5
  400. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  401. The end of upstream support periods was reached in January 2012 for MySQL 5.0
  402. and December 2013 for MySQL 5.1. As a consequence, Django 1.8 sets 5.5 as the
  403. minimum MySQL version it officially supports.
  404. Support for Oracle versions older than 11.1
  405. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  406. The end of upstream support periods was reached in July 2010 for Oracle 9.2,
  407. January 2012 for Oracle 10.1, and July 2013 for Oracle 10.2. As a consequence,
  408. Django 1.8 sets 11.1 as the minimum Oracle version it officially supports.
  409. Specific privileges used instead of roles for tests on Oracle
  410. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  411. Earlier versions of Django granted the CONNECT and RESOURCE roles to the test
  412. user on Oracle. These roles have been deprecated, so Django 1.8 uses the
  413. specific underlying privileges instead. This changes the privileges required
  414. of the main user for running tests (unless the project is configured to avoid
  415. creating a test user). The exact privileges required now are detailed in
  416. :ref:`Oracle notes <oracle-notes>`.
  417. ``AbstractUser.last_login`` allows null values
  418. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  419. The :attr:`AbstractUser.last_login <django.contrib.auth.models.User.last_login>`
  420. field now allows null values. Previously, it defaulted to the time when the user
  421. was created which was misleading if the user never logged in. Please run the
  422. database migration. If your custom user inherits from ``AbstractUser`` and you
  423. wish to set ``last_login`` to ``NULL`` for users who haven't logged in, you can
  424. run this query::
  425. from django.db import models
  426. from django.contrib.auth import get_user_model
  427. from django.contrib.auth.models import AbstractBaseUser
  428. UserModel = get_user_model()
  429. if issubclass(UserModel, AbstractBaseUser):
  430. UserModel._default_manager.filter(
  431. last_login=models.F('date_joined')
  432. ).update(last_login=None)
  433. :mod:`django.contrib.gis`
  434. ~~~~~~~~~~~~~~~~~~~~~~~~~
  435. * Support for GEOS 3.1 and GDAL 1.6 has been dropped.
  436. * Support for SpatiaLite < 2.4 has been dropped.
  437. * GIS-specific lookups have been refactored to use the
  438. :class:`django.db.models.Lookup` API.
  439. * The default ``str`` representation of
  440. :class:`~django.contrib.gis.geos.GEOSGeometry` objects has been changed from
  441. WKT to EWKT format (including the SRID). As this representation is used in
  442. the serialization framework, that means that ``dumpdata`` output will now
  443. contain the SRID value of geometry objects.
  444. Miscellaneous
  445. ~~~~~~~~~~~~~
  446. * ``connections.queries`` is now a read-only attribute.
  447. * Database connections are considered equal only if they're the same object.
  448. They aren't hashable any more.
  449. * :class:`~django.middleware.gzip.GZipMiddleware` used to disable compression
  450. for some content types when the request is from Internet Explorer, in order
  451. to work around a bug in IE6 and earlier. This behavior could affect
  452. performance on IE7 and later. It was removed.
  453. * ``URLField.to_python`` no longer adds a trailing slash to pathless URLs.
  454. * The :tfilter:`length` template filter now returns ``0`` for an undefined
  455. variable, rather than an empty string.
  456. * ``ForeignKey.default_error_message['invalid']`` has been changed from
  457. ``'%(model)s instance with pk %(pk)r does not exist.'`` to
  458. ``'%(model)s instance with %(field)s %(value)r does not exist.'`` If you are
  459. using this message in your own code, please update the list of interpolated
  460. parameters. Internally, Django will continue to provide the
  461. ``pk`` parameter in ``params`` for backwards compatibility.
  462. * ``UserCreationForm.errors_messages['duplicate_username']`` is no longer used.
  463. If you wish to customize that error message, :ref:`override it on the form
  464. <modelforms-overriding-default-fields>` using the ``'unique'`` key in
  465. ``Meta.errors_messages['username']`` or, if you have a custom form field for
  466. ``'username'``, using the the ``'unique'`` key in its
  467. :attr:`~django.forms.Field.error_messages` argument.
  468. * ``AdminSite`` no longer takes an ``app_name`` argument and its ``app_name``
  469. attribute has been removed. The application name is always ``admin`` (as
  470. opposed to the instance name which you can still customize using
  471. ``AdminSite(name="...")``.
  472. * Internal changes were made to the :class:`~django.forms.ClearableFileInput`
  473. widget to allow more customization. The undocumented ``url_markup_template``
  474. attribute was removed in favor of ``template_with_initial``.
  475. * For consistency with other major vendors, the ``en_GB`` locale now has Monday
  476. as the first day of the week.
  477. * Seconds have been removed from any locales that had them in ``TIME_FORMAT``,
  478. ``DATETIME_FORMAT``, or ``SHORT_DATETIME_FORMAT``.
  479. * The default max size of the Oracle test tablespace has increased from 200M
  480. to 500M.
  481. * :func:`~django.core.urlresolvers.reverse` and
  482. :func:`~django.core.urlresolvers.reverse_lazy` now return Unicode strings
  483. instead of byte strings.
  484. * The ``CacheClass`` shim has been removed from all cache backends.
  485. These aliases were provided for backwards compatibility with Django 1.3.
  486. If you are still using them, please update your project to use the real
  487. class name found in the :setting:`BACKEND <CACHES-BACKEND>` key of the
  488. :setting:`CACHES` setting.
  489. * By default, :ref:`call_command <call-command>` now always skips the check
  490. framework (unless you pass it ``skip_checks=False``).
  491. .. _deprecated-features-1.8:
  492. Features deprecated in 1.8
  493. ==========================
  494. Loading ``cycle`` and ``firstof`` template tags from ``future`` library
  495. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  496. Django 1.6 introduced ``{% load cycle from future %}`` and
  497. ``{% load firstof from future %}`` syntax for forward compatibility of the
  498. :ttag:`cycle` and :ttag:`firstof` template tags. This syntax is now deprecated
  499. and will be removed in Django 2.0. You can simply remove the
  500. ``{% load ... from future %}`` tags.
  501. ``django.conf.urls.patterns()``
  502. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  503. In the olden days of Django, it was encouraged to reference views as strings
  504. in ``urlpatterns``::
  505. urlpatterns = patterns('',
  506. url('^$', 'myapp.views.myview'),
  507. )
  508. and Django would magically import ``myapp.views.myview`` internally and turn
  509. the string into a real function reference. In order to reduce repetition when
  510. referencing many views from the same module, the ``patterns()`` function takes
  511. a required initial ``prefix`` argument which is prepended to all
  512. views-as-strings in that set of ``urlpatterns``::
  513. urlpatterns = patterns('myapp.views',
  514. url('^$', 'myview'),
  515. url('^other/$', 'otherview'),
  516. )
  517. In the modern era, we have updated the tutorial to instead recommend importing
  518. your views module and referencing your view functions (or classes) directly.
  519. This has a number of advantages, all deriving from the fact that we are using
  520. normal Python in place of "Django String Magic": the errors when you mistype a
  521. view name are less obscure, IDEs can help with autocompletion of view names,
  522. etc.
  523. So these days, the above use of the ``prefix`` arg is much more likely to be
  524. written (and is better written) as::
  525. from myapp import views
  526. urlpatterns = patterns('',
  527. url('^$', views.myview),
  528. url('^other/$', views.otherview),
  529. )
  530. Thus ``patterns()`` serves little purpose and is a burden when teaching new users
  531. (answering the newbie's question "why do I need this empty string as the first
  532. argument to ``patterns()``?"). For these reasons, we are deprecating it.
  533. Updating your code is as simple as ensuring that ``urlpatterns`` is a list of
  534. :func:`django.conf.urls.url` instances. For example::
  535. from django.conf.urls import url
  536. from myapp import views
  537. urlpatterns = [
  538. url('^$', views.myview),
  539. url('^other/$', views.otherview),
  540. ]
  541. Passing a string as ``view`` to :func:`~django.conf.urls.url`
  542. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  543. Related to the previous item, referencing views as strings in the ``url()``
  544. function is deprecated. Pass the callable view as described in the previous
  545. section instead.
  546. ``django.test.SimpleTestCase.urls``
  547. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  548. The attribute :attr:`SimpleTestCase.urls <django.test.SimpleTestCase.urls>`
  549. for specifying URLconf configuration in tests has been deprecated and will be
  550. removed in Django 2.0. Use :func:`@override_settings(ROOT_URLCONF=...)
  551. <django.test.override_settings>` instead.
  552. ``prefix`` argument to :func:`~django.conf.urls.i18n.i18n_patterns`
  553. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  554. Related to the previous item, the ``prefix`` argument to
  555. :func:`django.conf.urls.i18n.i18n_patterns` has been deprecated. Simply pass a
  556. list of :func:`django.conf.urls.url` instances instead.
  557. Using an incorrect count of unpacked values in the :ttag:`for` template tag
  558. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  559. Using an incorrect count of unpacked values in :ttag:`for` tag will raise an
  560. exception rather than fail silently in Django 2.0.
  561. Passing a dotted path to :func:`~django.core.urlresolvers.reverse()` and :ttag:`url`
  562. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  563. Reversing URLs by Python path is an expensive operation as it causes the
  564. path being reversed to be imported. This behavior has also resulted in a
  565. `security issue`_. Use :ref:`named URL patterns <naming-url-patterns>`
  566. for reversing instead.
  567. If you are using :mod:`django.contrib.sitemaps`, add the ``name`` argument to
  568. the ``url`` that references :func:`django.contrib.sitemaps.views.sitemap`::
  569. from django.contrib.sitemaps.views import sitemap
  570. url(r'^sitemap\.xml$', sitemap, {'sitemaps': sitemaps},
  571. name='django.contrib.sitemaps.views.sitemap')
  572. to ensure compatibility when reversing by Python path is removed in Django 2.0.
  573. Similarly for GIS sitemaps, add ``name='django.contrib.gis.sitemaps.views.kml'``
  574. or ``name='django.contrib.gis.sitemaps.views.kmz'``.
  575. .. _security issue: https://www.djangoproject.com/weblog/2014/apr/21/security/#s-issue-unexpected-code-execution-using-reverse
  576. Extending management command arguments through ``Command.option_list``
  577. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  578. Management commands now use :py:mod:`argparse` instead of :py:mod:`optparse` to
  579. parse command-line arguments passed to commands. This also means that the way
  580. to add custom arguments to commands has changed: instead of extending the
  581. ``option_list`` class list, you should now override the
  582. :meth:`~django.core.management.BaseCommand.add_arguments` method and add
  583. arguments through ``argparse.add_argument()``. See
  584. :ref:`this example <custom-commands-options>` for more details.
  585. ``django.core.management.NoArgsCommand``
  586. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  587. The class :class:`~django.core.management.NoArgsCommand` is now deprecated and
  588. will be removed in Django 2.0. Use :class:`~django.core.management.BaseCommand`
  589. instead, which takes no arguments by default.
  590. ``cache_choices`` option of ``ModelChoiceField`` and ``ModelMultipleChoiceField``
  591. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  592. :class:`~django.forms.ModelChoiceField` and
  593. :class:`~django.forms.ModelMultipleChoiceField` took an undocumented, untested
  594. option ``cache_choices``. This cached querysets between multiple renderings of
  595. the same ``Form`` object. This option is subject to an accelerated deprecation
  596. and will be removed in Django 1.9.
  597. ``django.template.resolve_variable()``
  598. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  599. The function has been informally marked as "Deprecated" for some time. Replace
  600. ``resolve_variable(path, context)`` with
  601. ``django.template.Variable(path).resolve(context)``.
  602. ``django.contrib.webdesign``
  603. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  604. It provided the :ttag:`lorem` template tag which is now included in the
  605. built-in tags. Simply remove ``'django.contrib.webdesign'`` from
  606. :setting:`INSTALLED_APPS` and ``{% load webdesign %}`` from your templates.
  607. ``error_message`` argument to ``django.forms.RegexField``
  608. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  609. It provided backwards compatibility for pre-1.0 code, but its functionality is
  610. redundant. Use ``Field.error_messages['invalid']`` instead.
  611. Old :tfilter:`unordered_list` syntax
  612. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  613. An older (pre-1.0), more restrictive and verbose input format for the
  614. :tfilter:`unordered_list` template filter has been deprecated::
  615. ``['States', [['Kansas', [['Lawrence', []], ['Topeka', []]]], ['Illinois', []]]]``
  616. Using the new syntax, this becomes::
  617. ``['States', ['Kansas', ['Lawrence', 'Topeka'], 'Illinois']]``
  618. ``django.forms.Field._has_changed()``
  619. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  620. Rename this method to :meth:`~django.forms.Field.has_changed` by removing the
  621. leading underscore. The old name will still work until Django 2.0.
  622. ``django.utils.html.remove_tags()`` and ``removetags`` template filter
  623. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  624. ``django.utils.html.remove_tags()`` as well as the template filter
  625. ``removetags`` have been deprecated as they cannot guarantee safe output. Their
  626. existence is likely to lead to their use in security-sensitive contexts where
  627. they are not actually safe.
  628. The unused and undocumented ``django.utils.html.strip_entities()`` function has
  629. also been deprecated.
  630. ``is_admin_site`` argument to ``django.contrib.auth.views.password_reset()``
  631. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  632. It's a legacy option that should no longer be necessary.
  633. ``SubfieldBase``
  634. ~~~~~~~~~~~~~~~~
  635. ``django.db.models.fields.subclassing.SubfieldBase`` has been deprecated and
  636. will be removed in Django 2.0. Historically, it was used to handle fields where
  637. type conversion was needed when loading from the database, but it was not used
  638. in ``.values()`` calls or in aggregates. It has been replaced with
  639. :meth:`~django.db.models.Field.from_db_value`. Note that the new approach does
  640. not call the :meth:`~django.db.models.Field.to_python` method on assignment
  641. as was the case with ``SubfieldBase``.
  642. ``django.utils.checksums``
  643. ~~~~~~~~~~~~~~~~~~~~~~~~~~
  644. The ``django.utils.checksums`` module has been deprecated and will be removed
  645. in Django 2.0. The functionality it provided (validating checksum using the
  646. Luhn algorithm) was undocumented and not used in Django. The module has been
  647. moved to the `django-localflavor`_ package (version 1.1+).
  648. .. _django-localflavor: https://pypi.python.org/pypi/django-localflavor
  649. ``django.contrib.admin.helpers.InlineAdminForm.original_content_type_id``
  650. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  651. The ``original_content_type_id`` attribute on ``InlineAdminForm`` has been
  652. deprecated and will be removed in Django 2.0. Historically, it was used
  653. to construct the "view on site" URL. This URL is now accessible using the
  654. ``absolute_url`` attribute of the form.