1.7.txt 15 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325
  1. ============================================
  2. Django 1.7 release notes - UNDER DEVELOPMENT
  3. ============================================
  4. Welcome to Django 1.7!
  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. :doc:`our deprecation plan </internals/deprecation>`, and we've `begun the
  9. deprecation process for some features`_.
  10. .. _`new features`: `What's new in Django 1.7`_
  11. .. _`backwards incompatible changes`: `Backwards incompatible changes in 1.7`_
  12. .. _`begun the deprecation process for some features`: `Features deprecated in 1.7`_
  13. Python compatibility
  14. ====================
  15. Django 1.7 requires Python 2.7 or above, though we **highly recommend**
  16. the latest minor release. Support for Python 2.6 has been dropped.
  17. This change should affect only a small number of Django users, as most
  18. operating-system vendors today are shipping Python 2.7 or newer as their default
  19. version. If you're still using Python 2.6, however, you'll need to stick to
  20. Django 1.6 until you can upgrade your Python version. Per :doc:`our support
  21. policy </internals/release-process>`, Django 1.6 will continue to receive
  22. security support until the release of Django 1.8.
  23. What's new in Django 1.7
  24. ========================
  25. Schema migrations
  26. ~~~~~~~~~~~~~~~~~
  27. Django now has built-in support for schema migrations. It allows models
  28. to be updated, changed, and deleted by creating migration files that represent
  29. the model changes and which can be run on any development, staging or production
  30. database.
  31. Migrations are covered in :doc:`their own documentation</topics/migrations>`,
  32. but a few of the key features are:
  33. * ``syncdb`` has been deprecated and replaced by ``migrate``. Don't worry -
  34. calls to ``syncdb`` will still work as before.
  35. * A new ``makemigrations`` command provides an easy way to autodetect changes
  36. to your models and make migrations for them.
  37. * :data:`~django.db.models.signals.post_syncdb` and
  38. :data:`~django.db.models.signals.post_syncdb` have been renamed to
  39. :data:`~django.db.models.signals.pre_migrate` and
  40. :data:`~django.db.models.signals.post_migrate` respectively. The
  41. ``create_models``/``created_models`` argument has also been deprecated.
  42. * The ``allow_syncdb`` method on database routers is now called ``allow_migrate``,
  43. but still performs the same function. Routers with ``allow_syncdb`` methods
  44. will still work, but that method name is deprecated and you should change
  45. it as soon as possible (nothing more than renaming is required).
  46. New method on Field subclasses
  47. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  48. To help power both schema migrations and composite keys, the :class:`~django.db.models.Field` API now
  49. has a new required method: ``deconstruct()``.
  50. This method takes no arguments, and returns a tuple of four items:
  51. * ``name``: The field's attribute name on its parent model, or None if it is not part of a model
  52. * ``path``: A dotted, Python path to the class of this field, including the class name.
  53. * ``args``: Positional arguments, as a list
  54. * ``kwargs``: Keyword arguments, as a dict
  55. These four values allow any field to be serialized into a file, as well as
  56. allowing the field to be copied safely, both essential parts of these new features.
  57. This change should not affect you unless you write custom Field subclasses;
  58. if you do, you may need to reimplement the ``deconstruct()`` method if your
  59. subclass changes the method signature of ``__init__`` in any way. If your
  60. field just inherits from a built-in Django field and doesn't override ``__init__``,
  61. no changes are necessary.
  62. If you do need to override ``deconstruct()``, a good place to start is the
  63. built-in Django fields (``django/db/models/fields/__init__.py``) as several
  64. fields, including ``DecimalField`` and ``DateField``, override it and show how
  65. to call the method on the superclass and simply add or remove extra arguments.
  66. Calling custom ``QuerySet`` methods from the ``Manager``
  67. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  68. The :meth:`QuerySet.as_manager() <django.db.models.query.QuerySet.as_manager>`
  69. class method has been added to :ref:`create Manager with QuerySet methods
  70. <create-manager-with-queryset-methods>`.
  71. Admin shortcuts support time zones
  72. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  73. The "today" and "now" shortcuts next to date and time input widgets in the
  74. admin are now operating in the :ref:`current time zone
  75. <default-current-time-zone>`. Previously, they used the browser time zone,
  76. which could result in saving the wrong value when it didn't match the current
  77. time zone on the server.
  78. In addition, the widgets now display a help message when the browser and
  79. server time zone are different, to clarify how the value inserted in the field
  80. will be interpreted.
  81. Minor features
  82. ~~~~~~~~~~~~~~
  83. * The new :attr:`UploadedFile.content_type_extra
  84. <django.core.files.uploadedfile.UploadedFile.content_type_extra>` attribute
  85. contains extra parameters passed to the ``content-type`` header on a file
  86. upload.
  87. * The ``enter`` argument was added to the
  88. :data:`~django.test.signals.setting_changed` signal.
  89. * The :meth:`QuerySet.update_or_create()
  90. <django.db.models.query.QuerySet.update_or_create>` method was added.
  91. * :attr:`~django.db.models.Options.app_label` is no longer required for models
  92. that are defined in a ``models`` package within an app.
  93. * The :meth:`Context.push() <django.template.Context.push>` method now returns
  94. a context manager which automatically calls :meth:`pop()
  95. <django.template.Context.pop>` upon exiting the ``with`` statement.
  96. Additionally, :meth:`push() <django.template.Context.push>` now accepts
  97. parameters that are passed to the ``dict`` constructor used to build the new
  98. context level.
  99. * The :class:`~django.utils.feedgenerator.Atom1Feed` syndication feed's
  100. ``updated`` element now utilizes ``updateddate`` instead of ``pubdate``,
  101. allowing the ``published`` element to be included in the feed (which
  102. relies on ``pubdate``).
  103. * Buttons in :mod:`django.contrib.admin` now use the ``border-radius`` CSS
  104. property for rounded corners rather than GIF background images.
  105. * Some admin templates now have ``app-<app_name>`` and ``model-<model_name>``
  106. classes in their ``<body>`` tag to allow customizing the CSS per app or per
  107. model.
  108. * The admin changelist cells now have a ``field-<field_name>`` class in the
  109. HTML to enable style customizations.
  110. * :func:`~django.core.mail.send_mail` now accepts an ``html_message``
  111. parameter for sending a multipart ``text/plain`` and ``text/html`` email.
  112. * The :djadminopt:`--no-color` option for ``django-admin.py`` allows you to
  113. disable the colorization of management command output.
  114. * The :mod:`sitemap framework<django.contrib.sitemaps>` now makes use of
  115. :attr:`~django.contrib.sitemaps.Sitemap.lastmod` to set a ``Last-Modified``
  116. header in the response. This makes it possible for the
  117. :class:`~django.middleware.http.ConditionalGetMiddleware` to handle
  118. conditional ``GET`` requests for sitemaps which set ``lastmod``.
  119. * You can override the new :meth:`AuthenticationForm.confirm_login_allowed()
  120. <django.contrib.auth.forms.AuthenticationForm.confirm_login_allowed>` method
  121. to more easily customize the login policy.
  122. * :attr:`Field.choices<django.db.models.Field.choices>` now allows you to
  123. customize the "empty choice" label by including a tuple with an empty string
  124. or ``None`` for the key and the custom label as the value. The default blank
  125. option ``"----------"`` will be omitted in this case.
  126. * The admin's search fields can now be customized per-request thanks to the new
  127. :meth:`django.contrib.admin.ModelAdmin.get_search_fields` method.
  128. * The :meth:`ModelAdmin.get_fields()
  129. <django.contrib.admin.ModelAdmin.get_fields>` method may be overridden to
  130. customize the value of :attr:`ModelAdmin.fields
  131. <django.contrib.admin.ModelAdmin.fields>`.
  132. * :func:`django.contrib.auth.views.password_reset` takes an optional
  133. ``html_email_template_name`` parameter used to send a multipart HTML email
  134. for password resets.
  135. * :class:`~django.forms.MultiValueField` allows optional subfields by setting
  136. the ``require_all_fields`` argument to ``False``. The ``required`` attribute
  137. for each individual field will be respected, and a new ``incomplete``
  138. validation error will be raised when any required fields are empty.
  139. * The :meth:`~django.forms.Form.clean` method on a form no longer needs to
  140. return ``self.cleaned_data``. If it does return a changed dictionary then
  141. that will still be used.
  142. * The new :attr:`~django.db.models.Options.default_permissions` model
  143. ``Meta`` option allows you to customize (or disable) creation of the default
  144. add, change, and delete permissions.
  145. * The :func:`~django.contrib.auth.decorators.permission_required` decorator can
  146. take a list of permissions as well as a single permission.
  147. * The new :setting:`FILE_UPLOAD_DIRECTORY_PERMISSIONS` setting controls
  148. the file system permissions of directories created during file upload, like
  149. :setting:`FILE_UPLOAD_PERMISSIONS` does for the files themselves.
  150. * Explicit :class:`~django.db.models.OneToOneField` for
  151. :ref:`multi-table-inheritance` are now discovered in abstract classes.
  152. * The ``<label>`` and ``<input>`` tags rendered by
  153. :class:`~django.forms.RadioSelect` and
  154. :class:`~django.forms.CheckboxSelectMultiple` when looping over the radio
  155. buttons or checkboxes now include ``for`` and ``id`` attributes, respectively.
  156. Each radio button or checkbox includes an ``id_for_label`` attribute to
  157. output the element's ID.
  158. * Any ``**kwargs`` passed to
  159. :meth:`~django.contrib.auth.models.User.email_user()` are passed to the
  160. underlying :meth:`~django.core.mail.send_mail()` call.
  161. * The :ttag:`widthratio` template tag now accepts an "as" parameter to capture
  162. the result in a variable.
  163. Backwards incompatible changes in 1.7
  164. =====================================
  165. .. warning::
  166. In addition to the changes outlined in this section, be sure to review the
  167. :doc:`deprecation plan </internals/deprecation>` for any features that
  168. have been removed. If you haven't updated your code within the
  169. deprecation timeline for a given feature, its removal may appear as a
  170. backwards incompatible change.
  171. allow_syncdb/allow_migrate
  172. ~~~~~~~~~~~~~~~~~~~~~~~~~~
  173. While Django will still look at ``allow_syncdb`` methods even though they
  174. should be renamed to ``allow_migrate``, there is a subtle difference in which
  175. models get passed to these methods.
  176. For apps with migrations, ``allow_migrate`` will now get passed
  177. :ref:`historical models <historical-models>`, which are special versioned models
  178. without custom attributes, methods or managers. Make sure your ``allow_migrate``
  179. methods are only referring to fields or other items in ``model._meta``.
  180. Miscellaneous
  181. ~~~~~~~~~~~~~
  182. * The :meth:`django.core.files.uploadhandler.FileUploadHandler.new_file()`
  183. method is now passed an additional ``content_type_extra`` parameter. If you
  184. have a custom :class:`~django.core.files.uploadhandler.FileUploadHandler`
  185. that implements ``new_file()``, be sure it accepts this new parameter.
  186. * :class:`ModelFormSet<django.forms.models.BaseModelFormSet>`’s no longer
  187. delete instances when ``save(commit=False)`` is called. See
  188. :attr:`~django.forms.formsets.BaseFormSet.can_delete` for instructions on how
  189. to manually delete objects from deleted forms.
  190. * Loading empty fixtures emits a ``RuntimeWarning`` rather than raising
  191. :class:`~django.core.management.CommandError`.
  192. * :func:`django.contrib.staticfiles.views.serve` will now raise an
  193. :exc:`~django.http.Http404` exception instead of
  194. :exc:`~django.core.exceptions.ImproperlyConfigured` when :setting:`DEBUG`
  195. is ``False``. This change removes the need to conditionally add the view to
  196. your root URLconf, which in turn makes it safe to reverse by name. It also
  197. removes the ability for visitors to generate spurious HTTP 500 errors by
  198. requesting static files that don't exist or haven't been collected yet.
  199. * The :meth:`django.db.models.Model.__eq__` method is now defined in a
  200. way where instances of a proxy model and its base model are considered
  201. equal when primary keys match. Previously only instances of exact same
  202. class were considered equal on primary key match.
  203. * The :meth:`django.db.models.Model.__eq__` method has changed such that
  204. two ``Model`` instances without primary key values won't be considered
  205. equal (unless they are the same instance).
  206. * The :meth:`django.db.models.Model.__hash__` will now raise ``TypeError``
  207. when called on an instance without a primary key value. This is done to
  208. avoid mutable ``__hash__`` values in containers.
  209. Features deprecated in 1.7
  210. ==========================
  211. ``django.utils.dictconfig``/``django.utils.importlib``
  212. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  213. ``django.utils.dictconfig`` and ``django.utils.importlib`` were copies of
  214. respectively :mod:`logging.config` and :mod:`importlib` provided for Python
  215. versions prior to 2.7. They have been deprecated.
  216. ``django.utils.unittest``
  217. ~~~~~~~~~~~~~~~~~~~~~~~~~
  218. ``django.utils.unittest`` provided uniform access to the ``unittest2`` library
  219. on all Python versions. Since ``unittest2`` became the standard library's
  220. :mod:`unittest` module in Python 2.7, and Django 1.7 drops support for older
  221. Python versions, this module isn't useful anymore. It has been deprecated. Use
  222. :mod:`unittest` instead.
  223. ``django.utils.datastructures.SortedDict``
  224. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  225. As :class:`~collections.OrderedDict` was added to the standard library in
  226. Python 2.7, :class:`~django.utils.datastructures.SortedDict` is no longer
  227. needed and has been deprecated.
  228. Custom SQL location for models package
  229. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  230. Previously, if models were organized in a package (``myapp/models/``) rather
  231. than simply ``myapp/models.py``, Django would look for :ref:`initial SQL data
  232. <initial-sql>` in ``myapp/models/sql/``. This bug has been fixed so that Django
  233. will search ``myapp/sql/`` as documented. The old location will continue to
  234. work until Django 1.9.
  235. ``declared_fieldsets`` attribute on ``ModelAdmin.``
  236. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  237. ``ModelAdmin.declared_fieldsets`` was deprecated. Despite being a private API,
  238. it will go through a regular deprecation path. This attribute was mostly used
  239. by methods that bypassed ``ModelAdmin.get_fieldsets()`` but this was considered
  240. a bug and has been addressed.
  241. ``syncdb``
  242. ~~~~~~~~~~
  243. The ``syncdb`` command has been deprecated in favour of the new ``migrate``
  244. command. ``migrate`` takes the same arguments as ``syncdb`` used to plus a few
  245. more, so it's safe to just change the name you're calling and nothing else.