1.9.txt 39 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330331332333334335336337338339340341342343344345346347348349350351352353354355356357358359360361362363364365366367368369370371372373374375376377378379380381382383384385386387388389390391392393394395396397398399400401402403404405406407408409410411412413414415416417418419420421422423424425426427428429430431432433434435436437438439440441442443444445446447448449450451452453454455456457458459460461462463464465466467468469470471472473474475476477478479480481482483484485486487488489490491492493494495496497498499500501502503504505506507508509510511512513514515516517518519520521522523524525526527528529530531532533534535536537538539540541542543544545546547548549550551552553554555556557558559560561562563564565566567568569570571572573574575576577578579580581582583584585586587588589590591592593594595596597598599600601602603604605606607608609610611612613614615616617618619620621622623624625626627628629630631632633634635636637638639640641642643644645646647648649650651652653654655656657658659660661662663664665666667668669670671672673674675676677678679680681682683684685686687688689690691692693694695696697698699700701702703704705706707708709710711712713714715716717718719720721722723724725726727728729730731732733734735736737738739740741742743744745746747748749750751752753754755756757758759760761762763764765766767768769770771772773774775776777778779780781782783784785786787788789790791792793794795796797798799800801802803804805806807808809810811812813814815816817818819820821822823824825826827828829830831832833834835836837838839840841842843844845846847848849850851852853854855856857858859860861862863864865866867868869870871872873874875876877878879880881882883884885886887888889890891892893894895896897898899900901902903904905906907908909910911912913914915916917918919920921922923924925926927928929930931932933934935936937938939940941942943944945946947948949950951952953954955956957958959960961962963964965966967968969970971972973974975976977978979980981982983984
  1. ============================================
  2. Django 1.9 release notes - UNDER DEVELOPMENT
  3. ============================================
  4. Welcome to Django 1.9!
  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.8 or older versions. We've :ref:`dropped some features
  8. <deprecation-removed-in-1.9>` that have reached the end of their deprecation
  9. cycle, and we've `begun the deprecation process for some features`_.
  10. .. _`new features`: `What's new in Django 1.9`_
  11. .. _`backwards incompatible changes`: `Backwards incompatible changes in 1.9`_
  12. .. _`dropped some features`: `Features removed in 1.9`_
  13. .. _`begun the deprecation process for some features`: `Features deprecated in 1.9`_
  14. Python compatibility
  15. ====================
  16. Like Django 1.8, Django 1.9 requires Python 2.7 or above, though we
  17. **highly recommend** the latest minor release. We've dropped support for
  18. Python 3.2 and 3.3, and added support for Python 3.5.
  19. What's new in Django 1.9
  20. ========================
  21. Password validation
  22. ~~~~~~~~~~~~~~~~~~~
  23. Django now offers password validation to help prevent the usage of weak
  24. passwords by users. The validation is integrated in the included password
  25. change and reset forms and is simple to integrate in any other code.
  26. Validation is performed by one or more validators, configured in the new
  27. :setting:`AUTH_PASSWORD_VALIDATORS` setting.
  28. Four validators are included in Django, which can enforce a minimum length,
  29. compare the password to the user's attributes like their name, ensure
  30. passwords aren't entirely numeric, or check against an included list of common
  31. passwords. You can combine multiple validators, and some validators have
  32. custom configuration options. For example, you can choose to provide a custom
  33. list of common passwords. Each validator provides a help text to explain its
  34. requirements to the user.
  35. By default, no validation is performed and all passwords are accepted, so if
  36. you don't set :setting:`AUTH_PASSWORD_VALIDATORS`, you will not see any
  37. change. In new projects created with the default :djadmin:`startproject`
  38. template, a simple set of validators is enabled. To enable basic validation in
  39. the included auth forms for your project, you could set, for example::
  40. AUTH_PASSWORD_VALIDATORS = [
  41. {
  42. 'NAME': 'django.contrib.auth.password_validation.UserAttributeSimilarityValidator',
  43. },
  44. {
  45. 'NAME': 'django.contrib.auth.password_validation.MinimumLengthValidator',
  46. },
  47. {
  48. 'NAME': 'django.contrib.auth.password_validation.CommonPasswordValidator',
  49. },
  50. {
  51. 'NAME': 'django.contrib.auth.password_validation.NumericPasswordValidator',
  52. },
  53. ]
  54. See :ref:`password-validation` for more details.
  55. Permission mixins for class-based views
  56. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  57. Django now ships with the mixins
  58. :class:`~django.contrib.auth.mixins.AccessMixin`,
  59. :class:`~django.contrib.auth.mixins.LoginRequiredMixin`,
  60. :class:`~django.contrib.auth.mixins.PermissionRequiredMixin`, and
  61. :class:`~django.contrib.auth.mixins.UserPassesTestMixin` to provide the
  62. functionality of the ``django.contrib.auth.decorators`` for class-based views.
  63. These mixins have been taken from, or are at least inspired by, the
  64. `django-braces`_ project.
  65. There are a few differences between Django's and django-braces' implementation,
  66. though:
  67. * The :attr:`~django.contrib.auth.mixins.AccessMixin.raise_exception` attribute
  68. can only be ``True`` or ``False``. Custom exceptions or callables are not
  69. supported.
  70. * The :meth:`~django.contrib.auth.mixins.AccessMixin.handle_no_permission`
  71. method does not take a ``request`` argument. The current request is available
  72. in ``self.request``.
  73. * The custom ``test_func()`` of :class:`~django.contrib.auth.mixins.UserPassesTestMixin`
  74. does not take a ``user`` argument. The current user is available in
  75. ``self.request.user``.
  76. * The :attr:`permission_required <django.contrib.auth.mixins.PermissionRequiredMixin>`
  77. attribute supports a string (defining one permission) or a list/tuple of
  78. strings (defining multiple permissions) that need to be fulfilled to grant
  79. access.
  80. * The new :attr:`~django.contrib.auth.mixins.AccessMixin.permission_denied_message`
  81. attribute allows passing a message to the ``PermissionDenied`` exception.
  82. .. _django-braces: http://django-braces.readthedocs.org/en/latest/index.html
  83. Minor features
  84. ~~~~~~~~~~~~~~
  85. :mod:`django.contrib.admin`
  86. ^^^^^^^^^^^^^^^^^^^^^^^^^^^
  87. * Admin views now have ``model_admin`` or ``admin_site`` attributes.
  88. * The URL of the admin change view has been changed (was at
  89. ``/admin/<app>/<model>/<pk>/`` by default and is now at
  90. ``/admin/<app>/<model>/<pk>/change/``). This should not affect your
  91. application unless you have hardcoded admin URLs. In that case, replace those
  92. links by :ref:`reversing admin URLs <admin-reverse-urls>` instead. Note that
  93. the old URL still redirects to the new one for backwards compatibility, but
  94. it may be removed in a future version.
  95. * :meth:`ModelAdmin.get_list_select_related()
  96. <django.contrib.admin.ModelAdmin.get_list_select_related>` was added to allow
  97. changing the ``select_related()`` values used in the admin's changelist query
  98. based on the request.
  99. * The ``available_apps`` context variable, which lists the available
  100. applications for the current user, has been added to the
  101. :meth:`AdminSite.each_context() <django.contrib.admin.AdminSite.each_context>`
  102. method.
  103. * :attr:`AdminSite.empty_value_display
  104. <django.contrib.admin.AdminSite.empty_value_display>` and
  105. :attr:`ModelAdmin.empty_value_display
  106. <django.contrib.admin.ModelAdmin.empty_value_display>` were added to override
  107. the display of empty values in admin change list. You can also customize the
  108. value for each field.
  109. * The time picker widget includes a '6 p.m' option for consistency of having
  110. predefined options every 6 hours.
  111. :mod:`django.contrib.auth`
  112. ^^^^^^^^^^^^^^^^^^^^^^^^^^
  113. * The default iteration count for the PBKDF2 password hasher has been increased
  114. by 20%. This backwards compatible change will not affect users who have
  115. subclassed ``django.contrib.auth.hashers.PBKDF2PasswordHasher`` to change the
  116. default value.
  117. * The ``BCryptSHA256PasswordHasher`` will now update passwords if its
  118. ``rounds`` attribute is changed.
  119. * ``AbstractBaseUser`` and ``BaseUserManager`` were moved to a new
  120. ``django.contrib.auth.base_user`` module so that they can be imported without
  121. including ``django.contrib.auth`` in :setting:`INSTALLED_APPS` (this raised
  122. a deprecation warning in older versions and is no longer supported in
  123. Django 1.9).
  124. * The permission argument of
  125. :func:`~django.contrib.auth.decorators.permission_required()` accepts all
  126. kinds of iterables, not only list and tuples.
  127. :mod:`django.contrib.gis`
  128. ^^^^^^^^^^^^^^^^^^^^^^^^^^
  129. * All ``GeoQuerySet`` methods have been deprecated and replaced by
  130. :doc:`equivalent database functions </ref/contrib/gis/functions>`. As soon
  131. as the legacy methods have been replaced in your code, you should even be
  132. able to remove the special ``GeoManager`` from your GIS-enabled classes.
  133. * The GDAL interface now supports instantiating file-based and in-memory
  134. :ref:`GDALRaster objects <raster-data-source-objects>` from raw data.
  135. Setters for raster properties such as projection or pixel values have
  136. been added.
  137. * For PostGIS users, the new :class:`~django.contrib.gis.db.models.RasterField`
  138. allows :ref:`storing GDALRaster objects <creating-and-saving-raster-models>`.
  139. It supports automatic spatial index creation and reprojection when saving a
  140. model. It does not yet support spatial querying.
  141. * The new :meth:`GDALRaster.warp() <django.contrib.gis.gdal.GDALRaster.warp>`
  142. method allows warping a raster by specifying target raster properties such as
  143. origin, width, height, or pixel size (amongst others).
  144. * The new :meth:`GDALRaster.transform()
  145. <django.contrib.gis.gdal.GDALRaster.transform>` method allows transforming a
  146. raster into a different spatial reference system by specifying a target
  147. ``srid``.
  148. :mod:`django.contrib.messages`
  149. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  150. * ...
  151. :mod:`django.contrib.postgres`
  152. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  153. * Added support for the :lookup:`rangefield.contained_by` lookup for some built
  154. in fields which correspond to the range fields.
  155. * Added :class:`~django.contrib.postgres.fields.JSONField`.
  156. * Added :doc:`/ref/contrib/postgres/aggregates`.
  157. * Fixed serialization of
  158. :class:`~django.contrib.postgres.fields.DateRangeField` and
  159. :class:`~django.contrib.postgres.fields.DateTimeRangeField`.
  160. * Added the :class:`~django.contrib.postgres.functions.TransactionNow` database
  161. function.
  162. :mod:`django.contrib.redirects`
  163. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  164. * ...
  165. :mod:`django.contrib.sessions`
  166. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  167. * ...
  168. :mod:`django.contrib.sitemaps`
  169. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  170. * ...
  171. :mod:`django.contrib.sites`
  172. ^^^^^^^^^^^^^^^^^^^^^^^^^^^
  173. * :func:`~django.contrib.sites.shortcuts.get_current_site` now handles the case
  174. where ``request.get_host()`` returns ``domain:port``, e.g.
  175. ``example.com:80``. If the lookup fails because the host does not match a
  176. record in the database and the host has a port, the port is stripped and the
  177. lookup is retried with the domain part only.
  178. :mod:`django.contrib.staticfiles`
  179. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  180. * ...
  181. :mod:`django.contrib.syndication`
  182. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  183. * ...
  184. Cache
  185. ^^^^^
  186. * ``django.core.cache.backends.base.BaseCache`` now has a ``get_or_set()``
  187. method.
  188. * :func:`django.views.decorators.cache.never_cache` now sends more persuasive
  189. headers (added ``no-cache, no-store, must-revalidate`` to ``Cache-Control``)
  190. to better prevent caching.
  191. Email
  192. ^^^^^
  193. * ...
  194. File Storage
  195. ^^^^^^^^^^^^
  196. * :meth:`Storage.get_valid_name()
  197. <django.core.files.storage.Storage.get_valid_name>` is now called when
  198. the :attr:`~django.db.models.FileField.upload_to` is a callable.
  199. * :class:`~django.core.files.File` now has the ``seekable()`` method when using
  200. Python 3.
  201. File Uploads
  202. ^^^^^^^^^^^^
  203. * ...
  204. Forms
  205. ^^^^^
  206. * :class:`~django.forms.ModelForm` accepts the new ``Meta`` option
  207. ``field_classes`` to customize the type of the fields. See
  208. :ref:`modelforms-overriding-default-fields` for details.
  209. * You can now specify the order in which form fields are rendered with the
  210. :attr:`~django.forms.Form.field_order` attribute, the ``field_order``
  211. constructor argument , or the :meth:`~django.forms.Form.order_fields` method.
  212. * A form prefix can be specified inside a form class, not only when
  213. instantiating a form. See :ref:`form-prefix` for details.
  214. * You can now :ref:`specify keyword arguments <custom-formset-form-kwargs>`
  215. that you want to pass to the constructor of forms in a formset.
  216. Generic Views
  217. ^^^^^^^^^^^^^
  218. * Class based views generated using ``as_view()`` now have ``view_class``
  219. and ``view_initkwargs`` attributes.
  220. Internationalization
  221. ^^^^^^^^^^^^^^^^^^^^
  222. * The :func:`django.views.i18n.set_language` view now properly redirects to
  223. :ref:`translated URLs <url-internationalization>`, when available.
  224. * The :func:`django.views.i18n.javascript_catalog` view now works correctly
  225. if used multiple times with different configurations on the same page.
  226. * The :func:`django.utils.timezone.make_aware` function gained an ``is_dst``
  227. argument to help resolve ambiguous times during DST transitions.
  228. * You can now use locale variants supported by gettext. These are usually used
  229. for languages which can be written in different scripts, for example Latin
  230. and Cyrillic (e.g. ``be@latin``).
  231. * Added the ``name_translated`` attribute to the object returned by the
  232. :ttag:`get_language_info` template tag. Also added a corresponding template
  233. filter: :tfilter:`language_name_translated`.
  234. * You can now run :djadmin:`compilemessages` from the root directory of your
  235. project and it will find all the app message files that were created by
  236. :djadmin:`makemessages`.
  237. Management Commands
  238. ^^^^^^^^^^^^^^^^^^^
  239. * The new :djadmin:`sendtestemail` command lets you send a test email to
  240. easily confirm that email sending through Django is working.
  241. * To increase the readability of the SQL code generated by
  242. :djadmin:`sqlmigrate`, the SQL code generated for each migration operation is
  243. preceded by the operation's description.
  244. * The :djadmin:`dumpdata` command output is now deterministically ordered.
  245. * The :djadmin:`createcachetable` command now has a ``--dry-run`` flag to
  246. print out the SQL rather than execute it.
  247. * The :djadmin:`startapp` command creates an ``apps.py`` file and adds
  248. ``default_app_config`` in ``__init__.py``.
  249. Models
  250. ^^^^^^
  251. * Database configuration gained a :setting:`TIME_ZONE <DATABASE-TIME_ZONE>`
  252. option for interacting with databases that store datetimes in local time and
  253. don't support time zones when :setting:`USE_TZ` is ``True``.
  254. * Added the :meth:`RelatedManager.set()
  255. <django.db.models.fields.related.RelatedManager.set()>` method to the related
  256. managers created by ``ForeignKey``, ``GenericForeignKey``, and
  257. ``ManyToManyField``.
  258. * Added the ``keep_parents`` parameter to :meth:`Model.delete()
  259. <django.db.models.Model.delete>` to allow deleting only a child's data in a
  260. model that uses multi-table inheritance.
  261. * :meth:`Model.delete() <django.db.models.Model.delete>`
  262. and :meth:`QuerySet.delete() <django.db.models.query.QuerySet.delete>` return
  263. the number of objects deleted.
  264. * Added a system check to prevent defining both ``Meta.ordering`` and
  265. ``order_with_respect_to`` on the same model.
  266. * :lookup:`Date and time <year>` lookups can be chained with other lookups
  267. (such as :lookup:`exact`, :lookup:`gt`, :lookup:`lt`, etc.). For example:
  268. ``Entry.objects.filter(pub_date__month__gt=6)``.
  269. * Time lookups (hour, minute, second) are now supported by
  270. :class:`~django.db.models.TimeField` for all database backends. Support for
  271. backends other than SQLite was added but undocumented in Django 1.7.
  272. * You can specify the ``output_field`` parameter of the
  273. :class:`~django.db.models.Avg` aggregate in order to aggregate over
  274. non-numeric columns, such as ``DurationField``.
  275. * Added the :lookup:`date` lookup to :class:`~django.db.models.DateTimeField`
  276. to allow querying the field by only the date portion.
  277. * Added the :class:`~django.db.models.functions.Greatest` and
  278. :class:`~django.db.models.functions.Least` database functions.
  279. * Added the :class:`~django.db.models.functions.Now` database function, which
  280. returns the current date and time.
  281. CSRF
  282. ^^^^
  283. * The request header's name used for CSRF authentication can be customized
  284. with :setting:`CSRF_HEADER_NAME`.
  285. Signals
  286. ^^^^^^^
  287. * ...
  288. Templates
  289. ^^^^^^^^^
  290. * Template tags created with the :meth:`~django.template.Library.simple_tag`
  291. helper can now store results in a template variable by using the ``as``
  292. argument.
  293. * Added a :meth:`Context.setdefault() <django.template.Context.setdefault>`
  294. method.
  295. * A warning will now be logged for missing context variables. These messages
  296. will be logged to the :ref:`django.template <django-template-logger>` logger.
  297. * The :ttag:`firstof` template tag supports storing the output in a variable
  298. using 'as'.
  299. * :meth:`Context.update() <django.template.Context.update>` can now be used as
  300. a context manager.
  301. * Django template loaders can now extend templates recursively.
  302. * The debug page template postmortem now include output from each engine that
  303. is installed.
  304. * :ref:`Debug page integration <template-debug-integration>` for custom
  305. template engines was added.
  306. * The :class:`~django.template.backends.django.DjangoTemplates` backend gained
  307. the ability to register libraries and builtins explicitly through the
  308. template :setting:`OPTIONS <TEMPLATES-OPTIONS>`.
  309. * The ``timesince`` and ``timeuntil`` filters were improved to deal with leap
  310. years when given large time spans.
  311. * The ``include`` tag now caches parsed templates objects during template
  312. rendering, speeding up reuse in places such as for loops.
  313. Requests and Responses
  314. ^^^^^^^^^^^^^^^^^^^^^^
  315. * Unless :attr:`HttpResponse.reason_phrase
  316. <django.http.HttpResponse.reason_phrase>` is explicitly set, it now is
  317. determined by the current value of :attr:`HttpResponse.status_code
  318. <django.http.HttpResponse.status_code>`. Modifying the value of
  319. ``status_code`` outside of the constructor will also modify the value of
  320. ``reason_phrase``.
  321. * The debug view now shows details of chained exceptions on Python 3.
  322. * The default 40x error views now accept a second positional parameter, the
  323. exception that triggered the view.
  324. * View error handlers now support
  325. :class:`~django.template.response.TemplateResponse`, commonly used with
  326. class-based views.
  327. * Request middleware can now set :attr:`HttpRequest.urlconf
  328. <django.http.HttpRequest.urlconf>` to ``None`` to revert any changes made
  329. by previous middleware and return to using the :setting:`ROOT_URLCONF`.
  330. Tests
  331. ^^^^^
  332. * Added the :meth:`json() <django.test.Response.json>` method to test client
  333. responses to give access to the response body as JSON.
  334. URLs
  335. ^^^^
  336. * Regular expression lookaround assertions are now allowed in URL patterns.
  337. * The application namespace can now be set using an ``app_name`` attribute
  338. on the included module or object. It can also be set by passing a 2-tuple
  339. of (<list of patterns>, <application namespace>) as the first argument to
  340. :func:`~django.conf.urls.include`.
  341. Validators
  342. ^^^^^^^^^^
  343. * Added :func:`django.core.validators.int_list_validator` to generate
  344. validators of strings containing integers separated with a custom character.
  345. * :class:`~django.core.validators.EmailValidator` now limits the length of
  346. domain name labels to 63 characters per :rfc:`1034`.
  347. Backwards incompatible changes in 1.9
  348. =====================================
  349. .. warning::
  350. In addition to the changes outlined in this section, be sure to review the
  351. :doc:`deprecation timeline </internals/deprecation>` for any features that
  352. have been removed. If you haven't updated your code within the
  353. deprecation timeline for a given feature, its removal may appear as a
  354. backwards incompatible change.
  355. Database backend API
  356. ~~~~~~~~~~~~~~~~~~~~
  357. * A couple of new tests rely on the ability of the backend to introspect column
  358. defaults (returning the result as ``Field.default``). You can set the
  359. ``can_introspect_default`` database feature to ``False`` if your backend
  360. doesn't implement this. You may want to review the implementation on the
  361. backends that Django includes for reference (:ticket:`24245`).
  362. * Registering a global adapter or converter at the level of the DB-API module
  363. to handle time zone information of :class:`~datetime.datetime` values passed
  364. as query parameters or returned as query results on databases that don't
  365. support time zones is discouraged. It can conflict with other libraries.
  366. The recommended way to add a time zone to :class:`~datetime.datetime` values
  367. fetched from the database is to register a converter for ``DateTimeField``
  368. in ``DatabaseOperations.get_db_converters()``.
  369. The ``needs_datetime_string_cast`` database feature was removed. Database
  370. backends that set it must register a converter instead, as explained above.
  371. * The ``DatabaseOperations.value_to_db_<type>()`` methods were renamed to
  372. ``adapt_<type>field_value()`` to mirror the ``convert_<type>field_value()``
  373. methods.
  374. * To use the new ``date`` lookup, third-party database backends may need to
  375. implement the ``DatabaseOperations.datetime_cast_date_sql()`` method.
  376. * The ``DatabaseOperations.time_extract_sql()`` method was added. It calls the
  377. existing ``date_extract_sql()`` method. This method is overridden by the
  378. SQLite backend to add time lookups (hour, minute, second) to
  379. :class:`~django.db.models.TimeField`, and may be needed by third-party
  380. database backends.
  381. Default settings that were tuples are now lists
  382. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  383. The default settings in ``django.conf.global_settings`` were a combination of
  384. lists and tuples. All settings that were formerly tuples are now lists.
  385. ``is_usable`` attribute on template loaders is removed
  386. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  387. Django template loaders previously required an ``is_usable`` attribute to be
  388. defined. If a loader was configured in the template settings and this attribute
  389. was ``False``, the loader would be silently ignored. In practice, this was only
  390. used by the egg loader to detect if setuptools was installed. The ``is_usable``
  391. attribute is now removed and the egg loader instead fails at runtime if
  392. setuptools is not installed.
  393. Related set direct assignment
  394. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  395. :ref:`Direct assignment <direct-assignment>`) used to perform a ``clear()``
  396. followed by a call to ``add()``. This caused needlessly large data changes
  397. and prevented using the :data:`~django.db.models.signals.m2m_changed` signal
  398. to track individual changes in many-to-many relations.
  399. Direct assignment now relies on the the new
  400. :meth:`django.db.models.fields.related.RelatedManager.set()` method on
  401. related managers which by default only processes changes between the
  402. existing related set and the one that's newly assigned. The previous behavior
  403. can be restored by replacing direct assignment by a call to ``set()`` with
  404. the keyword argument ``clear=True``.
  405. ``ModelForm``, and therefore ``ModelAdmin``, internally rely on direct
  406. assignment for many-to-many relations and as a consequence now use the new
  407. behavior.
  408. Filesystem-based template loaders catch more specific exceptions
  409. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  410. When using the :class:`filesystem.Loader <django.template.loaders.filesystem.Loader>`
  411. or :class:`app_directories.Loader <django.template.loaders.app_directories.Loader>`
  412. template loaders, earlier versions of Django raised a
  413. :exc:`~django.template.TemplateDoesNotExist` error if a template source existed
  414. but was unreadable. This could happen under many circumstances, such as if
  415. Django didn't have permissions to open the file, or if the template source was
  416. a directory. Now, Django only silences the exception if the template source
  417. does not exist. All other situations result in the original ``IOError`` being
  418. raised.
  419. HTTP redirects no longer forced to absolute URIs
  420. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  421. Relative redirects are no longer converted to absolute URIs. :rfc:`2616`
  422. required the ``Location`` header in redirect responses to be an absolute URI,
  423. but it has been superseded by :rfc:`7231` which allows relative URIs in
  424. ``Location``, recognizing the actual practice of user agents, almost all of
  425. which support them.
  426. Consequently, the expected URLs passed to ``assertRedirects`` should generally
  427. no longer include the scheme and domain part of the URLs. For example,
  428. ``self.assertRedirects(response, 'http://testserver/some-url/')`` should be
  429. replaced by ``self.assertRedirects(response, '/some-url/')`` (unless the
  430. redirection specifically contained an absolute URL, of course).
  431. Dropped support for PostgreSQL 9.0
  432. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  433. Upstream support for PostgreSQL 9.0 ended in September 2015. As a consequence,
  434. Django 1.9 sets 9.1 as the minimum PostgreSQL version it officially supports.
  435. Template ``LoaderOrigin`` and ``StringOrigin`` are removed
  436. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  437. In previous versions of Django, when a template engine was initialized with
  438. debug as ``True``, an instance of ``django.template.loader.LoaderOrigin`` or
  439. ``django.template.base.StringOrigin`` was set as the origin attribute on the
  440. template object. These classes have been combined into
  441. :class:`~django.template.base.Origin` and is now always set regardless of the
  442. engine debug setting.
  443. .. _default-logging-changes-19:
  444. Changes to the default logging configuration
  445. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  446. To make it easier to write custom logging configurations, Django's default
  447. logging configuration no longer defines 'django.request' and 'django.security'
  448. loggers. Instead, it defines a single 'django' logger with two handlers:
  449. * 'console': filtered at the ``INFO`` level and only active if ``DEBUG=True``.
  450. * 'mail_admins': filtered at the ``ERROR`` level and only active if
  451. ``DEBUG=False``.
  452. If you aren't overriding Django's default logging, you should see minimal
  453. changes in behavior, but you might see some new logging to the ``runserver``
  454. console, for example.
  455. If you are overriding Django's default logging, you should check to see how
  456. your configuration merges with the new defaults.
  457. Removal of time zone aware global adapters and converters for datetimes
  458. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  459. Django no longer registers global adapters and converters for managing time
  460. zone information on :class:`~datetime.datetime` values sent to the database as
  461. query parameters or read from the database in query results. This change
  462. affects projects that meet all the following conditions:
  463. * The :setting:`USE_TZ` setting is ``True``.
  464. * The database is SQLite, MySQL, Oracle, or a third-party database that
  465. doesn't support time zones. In doubt, you can check the value of
  466. ``connection.features.supports_timezones``.
  467. * The code queries the database outside of the ORM, typically with
  468. ``cursor.execute(sql, params)``.
  469. If you're passing aware :class:`~datetime.datetime` parameters to such
  470. queries, you should turn them into naive datetimes in UTC::
  471. from django.utils import timezone
  472. param = timezone.make_naive(param, timezone.utc)
  473. If you fail to do so, Django 1.9 and 2.0 will perform the conversion like
  474. earlier versions but emit a deprecation warning. Django 2.0 won't perform any
  475. conversion, which may result in data corruption.
  476. If you're reading :class:`~datetime.datetime` values from the results, they
  477. will be naive instead of aware. You can compensate as follows::
  478. from django.utils import timezone
  479. value = timezone.make_aware(value, timezone.utc)
  480. You don't need any of this if you're querying the database through the ORM,
  481. even if you're using :meth:`raw() <django.db.models.query.QuerySet.raw>`
  482. queries. The ORM takes care of managing time zone information.
  483. Template tag modules are imported when templates are configured
  484. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  485. The :class:`~django.template.backends.django.DjangoTemplates` backend now
  486. performs discovery on installed template tag modules when instantiated. This
  487. update enables libraries to be provided explicitly via the ``'libraries'``
  488. key of :setting:`OPTIONS <TEMPLATES-OPTIONS>` when defining a
  489. :class:`~django.template.backends.django.DjangoTemplates` backend. Import
  490. or syntax errors in template tag modules now fail early at instantiation time
  491. rather than when a template with a :ttag:`{% load %}<load>` tag is first
  492. compiled.
  493. ``django.template.base.add_to_builtins()`` is removed
  494. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  495. Although it was a private API, projects commonly used ``add_to_builtins()`` to
  496. make template tags and filters available without using the
  497. :ttag:`{% load %}<load>` tag. This API has been formalized. Projects should now
  498. define built-in libraries via the ``'builtins'`` key of :setting:`OPTIONS
  499. <TEMPLATES-OPTIONS>` when defining a
  500. :class:`~django.template.backends.django.DjangoTemplates` backend.
  501. Miscellaneous
  502. ~~~~~~~~~~~~~
  503. * CSS and images in ``contrib.admin`` to support Internet Explorer 6 & 7 have
  504. been removed as these browsers have reached end-of-life.
  505. * The jQuery static files in ``contrib.admin`` have been moved into a
  506. ``vendor/jquery`` subdirectory.
  507. * The text displayed for null columns in the admin changelist ``list_display``
  508. cells has changed from ``(None)`` (or its translated equivalent) to ``-``.
  509. * ``django.http.responses.REASON_PHRASES`` and
  510. ``django.core.handlers.wsgi.STATUS_CODE_TEXT`` have been removed. Use
  511. Python's stdlib instead: :data:`http.client.responses` for Python 3 and
  512. `httplib.responses`_ for Python 2.
  513. .. _`httplib.responses`: https://docs.python.org/2/library/httplib.html#httplib.responses
  514. * ``ValuesQuerySet`` and ``ValuesListQuerySet`` have been removed.
  515. * The ``admin/base.html`` template no longer sets
  516. ``window.__admin_media_prefix__``. Image references in JavaScript that used
  517. that value to construct absolute URLs have been moved to CSS for easier
  518. customization.
  519. * ``CommaSeparatedIntegerField`` validation has been refined to forbid values
  520. like ``','``, ``',1'``, and ``'1,,2'``.
  521. * Form initialization was moved from the :meth:`ProcessFormView.get()
  522. <django.views.generic.edit.ProcessFormView.get>` method to the new
  523. :meth:`FormMixin.get_context_data()
  524. <django.views.generic.edit.FormMixin.get_context_data>` method. This may be
  525. backwards incompatible if you have overridden the ``get_context_data()``
  526. method without calling ``super()``.
  527. * Support for PostGIS 1.5 has been dropped.
  528. * The ``django.contrib.sites.models.Site.domain`` field was changed to be
  529. :attr:`~django.db.models.Field.unique`.
  530. * In order to enforce test isolation, database queries are not allowed
  531. by default in :class:`~django.test.SimpleTestCase` tests anymore. You
  532. can disable this behavior by setting the
  533. :attr:`~django.test.SimpleTestCase.allow_database_queries` class attribute
  534. to ``True`` on your test class.
  535. * :attr:`ResolverMatch.app_name
  536. <django.core.urlresolvers.ResolverMatch.app_name>` was changed to contain
  537. the full namespace path in the case of nested namespaces. For consistency
  538. with :attr:`ResolverMatch.namespace
  539. <django.core.urlresolvers.ResolverMatch.namespace>`, the empty value is now
  540. an empty string instead of ``None``.
  541. * For security hardening, session keys must be at least 8 characters.
  542. * Private function ``django.utils.functional.total_ordering()`` has been
  543. removed. It contained a workaround for a ``functools.total_ordering()`` bug
  544. in Python versions older than 2.7.3.
  545. * XML serialization (either through :djadmin:`dumpdata` or the syndication
  546. framework) used to output any characters it received. Now if the content to
  547. be serialized contains any control characters not allowed in the XML 1.0
  548. standard, the serialization will fail with a :exc:`ValueError`.
  549. .. _deprecated-features-1.9:
  550. Features deprecated in 1.9
  551. ==========================
  552. ``assignment_tag()``
  553. ~~~~~~~~~~~~~~~~~~~~
  554. Django 1.4 added the ``assignment_tag`` helper to ease the creation of
  555. template tags that store results in a template variable. The
  556. :meth:`~django.template.Library.simple_tag` helper has gained this same
  557. ability, making the ``assignment_tag`` obsolete. Tags that use
  558. ``assignment_tag`` should be updated to use ``simple_tag``.
  559. ``{% cycle %}`` syntax with comma-separated arguments
  560. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  561. The :ttag:`cycle` tag supports an inferior old syntax from previous Django
  562. versions:
  563. .. code-block:: html+django
  564. {% cycle row1,row2,row3 %}
  565. Its parsing caused bugs with the current syntax, so support for the old syntax
  566. will be removed in Django 2.0 following an accelerated deprecation.
  567. ``Field.rel`` changes
  568. ~~~~~~~~~~~~~~~~~~~~~
  569. ``Field.rel`` and its methods and attributes have changed to match the related
  570. fields API. The ``Field.rel`` attribute is renamed to ``remote_field`` and many
  571. of its methods and attributes are either changed or renamed.
  572. The aim of these changes is to provide a documented API for relation fields.
  573. ``GeoManager`` and ``GeoQuerySet`` custom methods
  574. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  575. All custom ``GeoQuerySet`` methods (``area()``, ``distance()``, ``gml()``, ...)
  576. have been replaced by equivalent geographic expressions in annotations (see in
  577. new features). Hence the need to set a custom ``GeoManager`` to GIS-enabled
  578. models is now obsolete. As soon as your code doesn't call any of the deprecated
  579. methods, you can simply remove the ``objects = GeoManager()`` lines from your
  580. models.
  581. Template loader APIs have changed
  582. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  583. Django template loaders have been updated to allow recursive template
  584. extending. This change necessitated a new template loader API. The old
  585. ``load_template()`` and ``load_template_sources()`` methods are now deprecated.
  586. Details about the new API can be found :ref:`in the template loader
  587. documentation <custom-template-loaders>`.
  588. Passing a 3-tuple or an ``app_name`` to :func:`~django.conf.urls.include()`
  589. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  590. The instance namespace part of passing a tuple as the first argument has been
  591. replaced by passing the ``namespace`` argument to ``include()``. The
  592. ``app_name`` argument to ``include()`` has been replaced by passing a 2-tuple,
  593. or passing an object or module with an ``app_name`` attribute.
  594. If the ``app_name`` is set in this new way, the ``namespace`` argument is no
  595. longer required. It will default to the value of ``app_name``.
  596. This change also means that the old way of including an ``AdminSite`` instance
  597. is deprecated. Instead, pass ``admin.site.urls`` directly to
  598. :func:`~django.conf.urls.url()`:
  599. .. snippet::
  600. :filename: urls.py
  601. from django.conf.urls import url
  602. from django.contrib import admin
  603. urlpatterns = [
  604. url(r'^admin/', admin.site.urls),
  605. ]
  606. URL application namespace required if setting an instance namespace
  607. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  608. In the past, an instance namespace without an application namespace
  609. would serve the same purpose as the application namespace, but it was
  610. impossible to reverse the patterns if there was an application namespace
  611. with the same name. Includes that specify an instance namespace require that
  612. the included URLconf sets an application namespace.
  613. Miscellaneous
  614. ~~~~~~~~~~~~~
  615. * The ``weak`` argument to ``django.dispatch.signals.Signal.disconnect()`` has
  616. been deprecated as it has no effect.
  617. * The ``check_aggregate_support()`` method of
  618. ``django.db.backends.base.BaseDatabaseOperations`` has been deprecated and
  619. will be removed in Django 2.0. The more general ``check_expression_support()``
  620. should be used instead.
  621. * ``django.forms.extras`` is deprecated. You can find
  622. :class:`~django.forms.SelectDateWidget` in ``django.forms.widgets``
  623. (or simply ``django.forms``) instead.
  624. * Private API ``django.db.models.fields.add_lazy_relation()`` is deprecated.
  625. * The ``django.contrib.auth.tests.utils.skipIfCustomUser()`` decorator is
  626. deprecated. With the test discovery changes in Django 1.6, the tests for
  627. ``django.contrib`` apps are no longer run as part of the user's project.
  628. Therefore, the ``@skipIfCustomUser`` decorator is no longer needed to
  629. decorate tests in ``django.contrib.auth``.
  630. * If you customized some :ref:`error handlers <error-views>`, the view
  631. signatures with only one request parameter are deprecated. The views should
  632. now also accept a second ``exception`` positional parameter.
  633. * The ``django.utils.feedgenerator.Atom1Feed.mime_type`` and
  634. ``django.utils.feedgenerator.RssFeed.mime_type`` attributes are deprecated in
  635. favor of ``content_type``.
  636. .. removed-features-1.9:
  637. Features removed in 1.9
  638. =======================
  639. These features have reached the end of their deprecation cycle and so have been
  640. removed in Django 1.9 (please see the :ref:`deprecation timeline
  641. <deprecation-removed-in-1.9>` for more details):
  642. * ``django.utils.dictconfig`` is removed.
  643. * ``django.utils.importlib`` is removed.
  644. * ``django.utils.tzinfo`` is removed.
  645. * ``django.utils.unittest`` is removed.
  646. * The ``syncdb`` command is removed.
  647. * ``django.db.models.signals.pre_syncdb`` and
  648. ``django.db.models.signals.post_syncdb`` is removed.
  649. * Support for ``allow_syncdb`` on database routers is removed.
  650. * The legacy method of syncing apps without migrations is removed,
  651. and migrations are compulsory for all apps. This includes automatic
  652. loading of ``initial_data`` fixtures and support for initial SQL data.
  653. * All models need to be defined inside an installed application or declare an
  654. explicit :attr:`~django.db.models.Options.app_label`. Furthermore, it isn't
  655. possible to import them before their application is loaded. In particular, it
  656. isn't possible to import models inside the root package of an application.
  657. * The model and form ``IPAddressField`` is removed. A stub field remains for
  658. compatibility with historical migrations.
  659. * ``AppCommand.handle_app()`` is no longer be supported.
  660. * ``RequestSite`` and ``get_current_site()`` are no longer importable from
  661. ``django.contrib.sites.models``.
  662. * FastCGI support via the ``runfcgi`` management command is removed.
  663. * ``django.utils.datastructures.SortedDict`` is removed.
  664. * ``ModelAdmin.declared_fieldsets`` is removed.
  665. * The ``util`` modules that provided backwards compatibility are removed:
  666. * ``django.contrib.admin.util``
  667. * ``django.contrib.gis.db.backends.util``
  668. * ``django.db.backends.util``
  669. * ``django.forms.util``
  670. * ``ModelAdmin.get_formsets`` is removed.
  671. * The backward compatible shims introduced to rename the
  672. ``BaseMemcachedCache._get_memcache_timeout()`` method to
  673. ``get_backend_timeout()`` is removed.
  674. * The ``--natural`` and ``-n`` options for :djadmin:`dumpdata` are removed.
  675. * The ``use_natural_keys`` argument for ``serializers.serialize()`` is removed.
  676. * Private API ``django.forms.forms.get_declared_fields()`` is removed.
  677. * The ability to use a ``SplitDateTimeWidget`` with ``DateTimeField`` is
  678. removed.
  679. * The ``WSGIRequest.REQUEST`` property is removed.
  680. * The class ``django.utils.datastructures.MergeDict`` is removed.
  681. * The ``zh-cn`` and ``zh-tw`` language codes are removed.
  682. * The internal ``django.utils.functional.memoize()`` is removed.
  683. * ``django.core.cache.get_cache`` is removed.
  684. * ``django.db.models.loading`` is removed.
  685. * Passing callable arguments to querysets is no longer possible.
  686. * ``BaseCommand.requires_model_validation`` is removed in favor of
  687. ``requires_system_checks``. Admin validators is replaced by admin checks.
  688. * The ``ModelAdmin.validator_class`` and ``default_validator_class`` attributes
  689. are removed.
  690. * ``ModelAdmin.validate()`` is removed.
  691. * ``django.db.backends.DatabaseValidation.validate_field`` is removed in
  692. favor of the ``check_field`` method.
  693. * The ``validate`` management command is removed.
  694. * ``django.utils.module_loading.import_by_path`` is removed in favor of
  695. ``django.utils.module_loading.import_string``.
  696. * ``ssi`` and ``url`` template tags are removed from the ``future`` template
  697. tag library.
  698. * ``django.utils.text.javascript_quote()`` is removed.
  699. * Database test settings as independent entries in the database settings,
  700. prefixed by ``TEST_``, are no longer supported.
  701. * The `cache_choices` option to :class:`~django.forms.ModelChoiceField` and
  702. :class:`~django.forms.ModelMultipleChoiceField` is removed.
  703. * The default value of the
  704. :attr:`RedirectView.permanent <django.views.generic.base.RedirectView.permanent>`
  705. attribute has changed from ``True`` to ``False``.
  706. * ``django.contrib.sitemaps.FlatPageSitemap`` is removed in favor of
  707. ``django.contrib.flatpages.sitemaps.FlatPageSitemap``.
  708. * Private API ``django.test.utils.TestTemplateLoader`` is removed.
  709. * The ``django.contrib.contenttypes.generic`` module is removed.