1.7.txt 29 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330331332333334335336337338339340341342343344345346347348349350351352353354355356357358359360361362363364365366367368369370371372373374375376377378379380381382383384385386387388389390391392393394395396397398399400401402403404405406407408409410411412413414415416417418419420421422423424425426427428429430431432433434435436437438439440441442443444445446447448449450451452453454455456457458459460461462463464465466467468469470471472473474475476477478479480481482483484485486487488489490491492493494495496497498499500501502503504505506507508509510511512513514515516517518519520521522523524525526527528529530531532533534535536537538539540541542543544545546547548549550551552553554555556557558559560561562563564565566567568569570571572573574575576577578579580581582583584585586587588589590591592593594595596597598599600601602603604605606607608609610611612613614615616617618619620621622623624625626627628629630631632633634635636637638639640641642643644645646647648649650651652653654655656657658659660661662663664665666667668669670671672673674675676677678679680681682
  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.pre_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. Using a custom manager when traversing reverse relations
  72. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  73. It is now possible to :ref:`specify a custom manager
  74. <using-custom-reverse-manager>` when traversing a reverse relationship.
  75. Admin shortcuts support time zones
  76. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  77. The "today" and "now" shortcuts next to date and time input widgets in the
  78. admin are now operating in the :ref:`current time zone
  79. <default-current-time-zone>`. Previously, they used the browser time zone,
  80. which could result in saving the wrong value when it didn't match the current
  81. time zone on the server.
  82. In addition, the widgets now display a help message when the browser and
  83. server time zone are different, to clarify how the value inserted in the field
  84. will be interpreted.
  85. Using database cursors as context managers
  86. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  87. Prior to Python 2.7, database cursors could be used as a context manager. The
  88. specific backend's cursor defined the behavior of the context manager. The
  89. behavior of magic method lookups was changed with Python 2.7 and cursors were
  90. no longer usable as context managers.
  91. Django 1.7 allows a cursor to be used as a context manager that is a shortcut
  92. for the following, instead of backend specific behavior.
  93. .. code-block:: python
  94. c = connection.cursor()
  95. try:
  96. c.execute(...)
  97. finally:
  98. c.close()
  99. Minor features
  100. ~~~~~~~~~~~~~~
  101. :mod:`django.contrib.admin`
  102. ^^^^^^^^^^^^^^^^^^^^^^^^^^^
  103. * You can now implement :attr:`~django.contrib.admin.AdminSite.site_header`,
  104. :attr:`~django.contrib.admin.AdminSite.site_title`, and
  105. :attr:`~django.contrib.admin.AdminSite.index_title` attributes on a custom
  106. :class:`~django.contrib.admin.AdminSite` in order to easily change the admin
  107. site's page title and header text. No more needing to override templates!
  108. * Buttons in :mod:`django.contrib.admin` now use the ``border-radius`` CSS
  109. property for rounded corners rather than GIF background images.
  110. * Some admin templates now have ``app-<app_name>`` and ``model-<model_name>``
  111. classes in their ``<body>`` tag to allow customizing the CSS per app or per
  112. model.
  113. * The admin changelist cells now have a ``field-<field_name>`` class in the
  114. HTML to enable style customizations.
  115. * The admin's search fields can now be customized per-request thanks to the new
  116. :meth:`django.contrib.admin.ModelAdmin.get_search_fields` method.
  117. * The :meth:`ModelAdmin.get_fields()
  118. <django.contrib.admin.ModelAdmin.get_fields>` method may be overridden to
  119. customize the value of :attr:`ModelAdmin.fields
  120. <django.contrib.admin.ModelAdmin.fields>`.
  121. * In addition to the existing ``admin.site.register`` syntax, you can use the
  122. new :func:`~django.contrib.admin.register` decorator to register a
  123. :class:`~django.contrib.admin.ModelAdmin`.
  124. * You may specify :meth:`ModelAdmin.list_display_links
  125. <django.contrib.admin.ModelAdmin.list_display_links>` ``= None`` to disable
  126. links on the change list page grid.
  127. :mod:`django.contrib.auth`
  128. ^^^^^^^^^^^^^^^^^^^^^^^^^^
  129. * Any ``**kwargs`` passed to
  130. :meth:`~django.contrib.auth.models.User.email_user()` are passed to the
  131. underlying :meth:`~django.core.mail.send_mail()` call.
  132. * The :func:`~django.contrib.auth.decorators.permission_required` decorator can
  133. take a list of permissions as well as a single permission.
  134. * You can override the new :meth:`AuthenticationForm.confirm_login_allowed()
  135. <django.contrib.auth.forms.AuthenticationForm.confirm_login_allowed>` method
  136. to more easily customize the login policy.
  137. * :func:`django.contrib.auth.views.password_reset` takes an optional
  138. ``html_email_template_name`` parameter used to send a multipart HTML email
  139. for password resets.
  140. :mod:`django.contrib.gis`
  141. ^^^^^^^^^^^^^^^^^^^^^^^^^^
  142. * The default OpenLayers library version included in widgets has been updated
  143. from 2.11 to 2.13.
  144. :mod:`django.contrib.messages`
  145. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  146. * The backends for :mod:`django.contrib.messages` that use cookies, will now
  147. follow the :setting:`SESSION_COOKIE_SECURE` and
  148. :setting:`SESSION_COOKIE_HTTPONLY` settings.
  149. :mod:`django.contrib.redirects`
  150. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  151. * :class:`~django.contrib.redirects.middleware.RedirectFallbackMiddleware`
  152. has two new attributes
  153. (:attr:`~django.contrib.redirects.middleware.RedirectFallbackMiddleware.response_gone_class`
  154. and
  155. :attr:`~django.contrib.redirects.middleware.RedirectFallbackMiddleware.response_redirect_class`)
  156. that specify the types of :class:`~django.http.HttpResponse` instances the
  157. middleware returns.
  158. :mod:`django.contrib.sessions`
  159. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  160. * The ``"django.contrib.sessions.backends.cached_db"`` session backend now
  161. respects :setting:`SESSION_CACHE_ALIAS`. In previous versions, it always used
  162. the `default` cache.
  163. :mod:`django.contrib.sitemaps`
  164. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  165. * The :mod:`sitemap framework<django.contrib.sitemaps>` now makes use of
  166. :attr:`~django.contrib.sitemaps.Sitemap.lastmod` to set a ``Last-Modified``
  167. header in the response. This makes it possible for the
  168. :class:`~django.middleware.http.ConditionalGetMiddleware` to handle
  169. conditional ``GET`` requests for sitemaps which set ``lastmod``.
  170. :mod:`django.contrib.staticfiles`
  171. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  172. * The :ref:`static files storage classes <staticfiles-storages>` may be
  173. subclassed to override the permissions that collected static files receive by
  174. setting the
  175. :attr:`~django.core.files.storage.FileSystemStorage.file_permissions_mode`
  176. parameter. See :djadmin:`collectstatic` for example usage.
  177. :mod:`django.contrib.syndication`
  178. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  179. * The :class:`~django.utils.feedgenerator.Atom1Feed` syndication feed's
  180. ``updated`` element now utilizes ``updateddate`` instead of ``pubdate``,
  181. allowing the ``published`` element to be included in the feed (which
  182. relies on ``pubdate``).
  183. Email
  184. ^^^^^
  185. * :func:`~django.core.mail.send_mail` now accepts an ``html_message``
  186. parameter for sending a multipart ``text/plain`` and ``text/html`` email.
  187. * The SMTP :class:`~django.core.mail.backends.smtp.EmailBackend` now accepts a
  188. :attr:`~django.core.mail.backends.smtp.EmailBackend.timeout` parameter.
  189. File Uploads
  190. ^^^^^^^^^^^^
  191. * The new :attr:`UploadedFile.content_type_extra
  192. <django.core.files.uploadedfile.UploadedFile.content_type_extra>` attribute
  193. contains extra parameters passed to the ``content-type`` header on a file
  194. upload.
  195. * The new :setting:`FILE_UPLOAD_DIRECTORY_PERMISSIONS` setting controls
  196. the file system permissions of directories created during file upload, like
  197. :setting:`FILE_UPLOAD_PERMISSIONS` does for the files themselves.
  198. * The :attr:`FileField.upload_to <django.db.models.FileField.upload_to>`
  199. attribute is now optional. If it is omitted or given ``None`` or an empty
  200. string, a subdirectory won't be used for storing the uploaded files.
  201. Forms
  202. ^^^^^
  203. * The ``<label>`` and ``<input>`` tags rendered by
  204. :class:`~django.forms.RadioSelect` and
  205. :class:`~django.forms.CheckboxSelectMultiple` when looping over the radio
  206. buttons or checkboxes now include ``for`` and ``id`` attributes, respectively.
  207. Each radio button or checkbox includes an ``id_for_label`` attribute to
  208. output the element's ID.
  209. * :attr:`Field.choices<django.db.models.Field.choices>` now allows you to
  210. customize the "empty choice" label by including a tuple with an empty string
  211. or ``None`` for the key and the custom label as the value. The default blank
  212. option ``"----------"`` will be omitted in this case.
  213. * :class:`~django.forms.MultiValueField` allows optional subfields by setting
  214. the ``require_all_fields`` argument to ``False``. The ``required`` attribute
  215. for each individual field will be respected, and a new ``incomplete``
  216. validation error will be raised when any required fields are empty.
  217. * The :meth:`~django.forms.Form.clean` method on a form no longer needs to
  218. return ``self.cleaned_data``. If it does return a changed dictionary then
  219. that will still be used.
  220. * :attr:`SelectDateWidget.months
  221. <django.forms.extras.widgets.SelectDateWidget.months>` can be used to
  222. customize the wording of the months displayed in the select widget.
  223. * The ``min_num`` and ``validate_min`` parameters were added to
  224. :func:`~django.forms.formsets.formset_factory` to allow validating
  225. a minimum number of submitted forms.
  226. * The metaclasses used by ``Form`` and ``ModelForm`` have been reworked to
  227. support more inheritance scenarios. The previous limitation that prevented
  228. inheriting from both ``Form`` and ``ModelForm`` simultaneously have been
  229. removed as long as ``ModelForm`` appears first in the MRO.
  230. * It's now possible to opt-out from a ``Form`` field declared in a parent class
  231. by shadowing it with a non-``Field`` value.
  232. Internationalization
  233. ^^^^^^^^^^^^^^^^^^^^
  234. * The :attr:`django.middleware.locale.LocaleMiddleware.response_redirect_class`
  235. attribute allows you to customize the redirects issued by the middleware.
  236. * The :class:`~django.middleware.locale.LocaleMiddleware` now stores the user's
  237. selected language with the session key ``_language``. Previously it was
  238. stored with the key ``django_language``, but keys reserved for Django should
  239. start with an underscore. For backwards compatibility ``django_language`` is
  240. still read from in 1.7. Sessions will be migrated to the new ``_language``
  241. key as they are written.
  242. Management Commands
  243. ^^^^^^^^^^^^^^^^^^^
  244. * The :djadminopt:`--no-color` option for ``django-admin.py`` allows you to
  245. disable the colorization of management command output.
  246. * The new :djadminopt:`--natural-foreign` and :djadminopt:`--natural-primary`
  247. options for :djadmin:`dumpdata`, and the new ``use_natural_foreign_keys`` and
  248. ``use_natural_primary_keys`` arguments for ``serializers.serialize()``, allow
  249. the use of natural primary keys when serializing.
  250. * It is no longer necessary to provide the cache table name or the
  251. :djadminopt:`--database` option for the :djadmin:`createcachetable` command.
  252. Django takes this information from your settings file. If you have configured
  253. multiple caches or multiple databases, all cache tables are created.
  254. Models
  255. ^^^^^^
  256. * The :meth:`QuerySet.update_or_create()
  257. <django.db.models.query.QuerySet.update_or_create>` method was added.
  258. * The new :attr:`~django.db.models.Options.default_permissions` model
  259. ``Meta`` option allows you to customize (or disable) creation of the default
  260. add, change, and delete permissions.
  261. * :attr:`~django.db.models.Options.app_label` is no longer required for models
  262. that are defined in a ``models`` package within an app.
  263. * Explicit :class:`~django.db.models.OneToOneField` for
  264. :ref:`multi-table-inheritance` are now discovered in abstract classes.
  265. * Is it now possible to avoid creating a backward relation for
  266. :class:`~django.db.models.OneToOneField` by setting its
  267. :attr:`~django.db.models.ForeignKey.related_name` to
  268. `'+'` or ending it with `'+'`.
  269. * :class:`F expressions <django.db.models.F>` support the power operator
  270. (``**``).
  271. Signals
  272. ^^^^^^^
  273. * The ``enter`` argument was added to the
  274. :data:`~django.test.signals.setting_changed` signal.
  275. Templates
  276. ^^^^^^^^^
  277. * The :meth:`Context.push() <django.template.Context.push>` method now returns
  278. a context manager which automatically calls :meth:`pop()
  279. <django.template.Context.pop>` upon exiting the ``with`` statement.
  280. Additionally, :meth:`push() <django.template.Context.push>` now accepts
  281. parameters that are passed to the ``dict`` constructor used to build the new
  282. context level.
  283. * The :ttag:`widthratio` template tag now accepts an "as" parameter to capture
  284. the result in a variable.
  285. * The :ttag:`include` template tag will now also accept anything with a
  286. ``render()`` method (such as a ``Template``) as an argument. String
  287. arguments will be looked up using
  288. :func:`~django.template.loader.get_template` as always.
  289. * It is now possible to :ttag:`include` templates recursively.
  290. * Template objects now have an origin attribute set when
  291. :setting:`TEMPLATE_DEBUG` is ``True``. This allows template origins to be
  292. inspected and logged outside of the ``django.template`` infrastructure.
  293. * ``TypeError`` exceptions are no longer silenced when raised during the
  294. rendering of a template.
  295. * The following functions now accept a ``dirs`` parameter which is a list or
  296. tuple to override :setting:`TEMPLATE_DIRS`:
  297. * :func:`django.template.loader.get_template()`
  298. * :func:`django.template.loader.select_template()`
  299. * :func:`django.shortcuts.render()`
  300. * :func:`django.shortcuts.render_to_response()`
  301. * The :tfilter:`time` filter now accepts timzone-related :ref:`format
  302. specifiers <date-and-time-formatting-specifiers>` ``'e'``, ``'O'`` , ``'T'``
  303. and ``'Z'`` and is able to digest :ref:`time-zone-aware
  304. <naive_vs_aware_datetimes>` ``datetime`` instances performing the expected
  305. rendering.
  306. * The :ttag:`cache` tag will now try to use the cache called
  307. "template_fragments" if it exists and fall back to using the default cache
  308. otherwise. It also now accepts an optional ``using`` keyword argument to
  309. control which cache it uses.
  310. Requests
  311. ^^^^^^^^
  312. * The new :attr:`HttpRequest.scheme <django.http.HttpRequest.scheme>` attribute
  313. specifies the scheme of the request (``http`` or ``https`` normally).
  314. Tests
  315. ^^^^^
  316. * :class:`~django.test.runner.DiscoverRunner` has two new attributes,
  317. :attr:`~django.test.runner.DiscoverRunner.test_suite` and
  318. :attr:`~django.test.runner.DiscoverRunner.test_runner`, which facilitate
  319. overriding the way tests are collected and run.
  320. * The ``fetch_redirect_response`` argument was added to
  321. :meth:`~django.test.SimpleTestCase.assertRedirects`. Since the test
  322. client can't fetch externals URLs, this allows you to use ``assertRedirects``
  323. with redirects that aren't part of your Django app.
  324. Backwards incompatible changes in 1.7
  325. =====================================
  326. .. warning::
  327. In addition to the changes outlined in this section, be sure to review the
  328. :doc:`deprecation plan </internals/deprecation>` for any features that
  329. have been removed. If you haven't updated your code within the
  330. deprecation timeline for a given feature, its removal may appear as a
  331. backwards incompatible change.
  332. allow_syncdb/allow_migrate
  333. ~~~~~~~~~~~~~~~~~~~~~~~~~~
  334. While Django will still look at ``allow_syncdb`` methods even though they
  335. should be renamed to ``allow_migrate``, there is a subtle difference in which
  336. models get passed to these methods.
  337. For apps with migrations, ``allow_migrate`` will now get passed
  338. :ref:`historical models <historical-models>`, which are special versioned models
  339. without custom attributes, methods or managers. Make sure your ``allow_migrate``
  340. methods are only referring to fields or other items in ``model._meta``.
  341. Passing ``None`` to ``Manager.db_manager()``
  342. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  343. In previous versions of Django, it was possible to use
  344. ``db_manager(using=None)`` on a model manager instance to obtain a manager
  345. instance using default routing behavior, overriding any manually specified
  346. database routing. In Django 1.7, a value of ``None`` passed to db_manager will
  347. produce a router that *retains* any manually assigned database routing -- the
  348. manager will *not* be reset. This was necessary to resolve an inconsistency in
  349. the way routing information cascaded over joins. See `Ticket #13724`_ for more
  350. details.
  351. .. _Ticket #13724: https://code.djangoproject.com/ticket/13724
  352. pytz may be required
  353. ~~~~~~~~~~~~~~~~~~~~
  354. If your project handles datetimes before 1970 or after 2037 and Django raises
  355. a :exc:`~exceptions.ValueError` when encountering them, you will have to
  356. install pytz_. You may be affected by this problem if you use Django's time
  357. zone-related date formats or :mod:`django.contrib.syndication`.
  358. .. _pytz: https://pypi.python.org/pypi/pytz/
  359. Miscellaneous
  360. ~~~~~~~~~~~~~
  361. * The :meth:`django.core.files.uploadhandler.FileUploadHandler.new_file()`
  362. method is now passed an additional ``content_type_extra`` parameter. If you
  363. have a custom :class:`~django.core.files.uploadhandler.FileUploadHandler`
  364. that implements ``new_file()``, be sure it accepts this new parameter.
  365. * :class:`ModelFormSet<django.forms.models.BaseModelFormSet>`’s no longer
  366. delete instances when ``save(commit=False)`` is called. See
  367. :attr:`~django.forms.formsets.BaseFormSet.can_delete` for instructions on how
  368. to manually delete objects from deleted forms.
  369. * Loading empty fixtures emits a ``RuntimeWarning`` rather than raising
  370. :class:`~django.core.management.CommandError`.
  371. * :func:`django.contrib.staticfiles.views.serve` will now raise an
  372. :exc:`~django.http.Http404` exception instead of
  373. :exc:`~django.core.exceptions.ImproperlyConfigured` when :setting:`DEBUG`
  374. is ``False``. This change removes the need to conditionally add the view to
  375. your root URLconf, which in turn makes it safe to reverse by name. It also
  376. removes the ability for visitors to generate spurious HTTP 500 errors by
  377. requesting static files that don't exist or haven't been collected yet.
  378. * The :meth:`django.db.models.Model.__eq__` method is now defined in a
  379. way where instances of a proxy model and its base model are considered
  380. equal when primary keys match. Previously only instances of exact same
  381. class were considered equal on primary key match.
  382. * The :meth:`django.db.models.Model.__eq__` method has changed such that
  383. two ``Model`` instances without primary key values won't be considered
  384. equal (unless they are the same instance).
  385. * The :meth:`django.db.models.Model.__hash__` will now raise ``TypeError``
  386. when called on an instance without a primary key value. This is done to
  387. avoid mutable ``__hash__`` values in containers.
  388. * :class:`~django.db.models.AutoField` columns in SQLite databases will now be
  389. created using the ``AUTOINCREMENT`` option, which guarantees monotonic
  390. increments. This will cause primary key numbering behavior to change on
  391. SQLite, becoming consistent with most other SQL databases. This will only
  392. apply to newly created tables. If you have a database created with an older
  393. version of Django, you will need to migrate it to take advantage of this
  394. feature. For example, you could do the following:
  395. #) Use :djadmin:`dumpdata` to save your data.
  396. #) Rename the existing database file (keep it as a backup).
  397. #) Run :djadmin:`migrate` to create the updated schema.
  398. #) Use :djadmin:`loaddata` to import the fixtures you exported in (1).
  399. * ``django.contrib.auth.models.AbstractUser`` no longer defines a
  400. :meth:`~django.db.models.Model.get_absolute_url()` method. The old definition
  401. returned ``"/users/%s/" % urlquote(self.username)`` which was arbitrary
  402. since applications may or may not define such a url in ``urlpatterns``.
  403. Define a ``get_absolute_url()`` method on your own custom user object or use
  404. :setting:`ABSOLUTE_URL_OVERRIDES` if you want a URL for your user.
  405. * The static asset-serving functionality of the
  406. :class:`django.test.LiveServerTestCase` class has been simplified: Now it's
  407. only able to serve content already present in :setting:`STATIC_ROOT` when
  408. tests are run. The ability to transparently serve all the static assets
  409. (similarly to what one gets with :setting:`DEBUG = True <DEBUG>` at
  410. development-time) has been moved to a new class that lives in the
  411. ``staticfiles`` application (the one actually in charge of such feature):
  412. :class:`django.contrib.staticfiles.testing.StaticLiveServerCase`. In other
  413. words, ``LiveServerTestCase`` itself is less powerful but at the same time
  414. has less magic.
  415. Rationale behind this is removal of dependency of non-contrib code on
  416. contrib applications.
  417. * The old cache URI syntax (e.g. ``"locmem://"``) is no longer supported. It
  418. still worked, even though it was not documented or officially supported. If
  419. you're still using it, please update to the current :setting:`CACHES` syntax.
  420. * The default ordering of ``Form`` fields in case of inheritance has changed to
  421. follow normal Python MRO. Fields are now discovered by iterating through the
  422. MRO in reverse with the topmost class coming last. This only affects you if
  423. you relied on the default field ordering while having fields defined on both
  424. the current class *and* on a parent ``Form``.
  425. * :meth:`~django.db.models.query.QuerySet.select_related` now chains in the
  426. same way as other similar calls like ``prefetch_related``. That is,
  427. ``select_related('foo', 'bar')`` is equivalent to
  428. ``select_related('foo').select_related('bar')``. Previously the latter would
  429. have been equivalent to ``select_related('bar')``.
  430. Features deprecated in 1.7
  431. ==========================
  432. ``django.utils.dictconfig``/``django.utils.importlib``
  433. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  434. ``django.utils.dictconfig`` and ``django.utils.importlib`` were copies of
  435. respectively :mod:`logging.config` and :mod:`importlib` provided for Python
  436. versions prior to 2.7. They have been deprecated.
  437. ``django.utils.tzinfo``
  438. ~~~~~~~~~~~~~~~~~~~~~~~
  439. ``django.utils.tzinfo`` provided two :class:`~datetime.tzinfo` subclasses,
  440. ``LocalTimezone`` and ``FixedOffset``. They've been deprecated in favor of
  441. more correct alternatives provided by :mod:`django.utils.timezone`,
  442. :func:`django.utils.timezone.get_default_timezone` and
  443. :func:`django.utils.timezone.get_fixed_timezone`.
  444. ``django.utils.unittest``
  445. ~~~~~~~~~~~~~~~~~~~~~~~~~
  446. ``django.utils.unittest`` provided uniform access to the ``unittest2`` library
  447. on all Python versions. Since ``unittest2`` became the standard library's
  448. :mod:`unittest` module in Python 2.7, and Django 1.7 drops support for older
  449. Python versions, this module isn't useful anymore. It has been deprecated. Use
  450. :mod:`unittest` instead.
  451. ``django.utils.datastructures.SortedDict``
  452. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  453. As :class:`~collections.OrderedDict` was added to the standard library in
  454. Python 2.7, :class:`~django.utils.datastructures.SortedDict` is no longer
  455. needed and has been deprecated.
  456. Custom SQL location for models package
  457. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  458. Previously, if models were organized in a package (``myapp/models/``) rather
  459. than simply ``myapp/models.py``, Django would look for :ref:`initial SQL data
  460. <initial-sql>` in ``myapp/models/sql/``. This bug has been fixed so that Django
  461. will search ``myapp/sql/`` as documented. The old location will continue to
  462. work until Django 1.9.
  463. ``declared_fieldsets`` attribute on ``ModelAdmin``
  464. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  465. ``ModelAdmin.declared_fieldsets`` has been deprecated. Despite being a private
  466. API, it will go through a regular deprecation path. This attribute was mostly
  467. used by methods that bypassed ``ModelAdmin.get_fieldsets()`` but this was
  468. considered a bug and has been addressed.
  469. ``syncdb``
  470. ~~~~~~~~~~
  471. The ``syncdb`` command has been deprecated in favour of the new ``migrate``
  472. command. ``migrate`` takes the same arguments as ``syncdb`` used to plus a few
  473. more, so it's safe to just change the name you're calling and nothing else.
  474. ``util`` modules renamed to ``utils``
  475. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  476. The following instances of ``util.py`` in the Django codebase have been renamed
  477. to ``utils.py`` in an effort to unify all util and utils references:
  478. * ``django.contrib.admin.util``
  479. * ``django.contrib.gis.db.backends.util``
  480. * ``django.db.backends.util``
  481. * ``django.forms.util``
  482. ``get_formsets`` method on ``ModelAdmin``
  483. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  484. ``ModelAdmin.get_formsets`` has been deprecated in favor of the new
  485. :meth:`~django.contrib.admin.ModelAdmin.get_formsets_with_inlines`, in order to
  486. better handle the case of selecting showing inlines on a ``ModelAdmin``.
  487. ``IPAddressField``
  488. ~~~~~~~~~~~~~~~~~~
  489. The :class:`django.db.models.IPAddressField` and
  490. :class:`django.forms.IPAddressField` fields have been deprecated in favor of
  491. :class:`django.db.models.GenericIPAddressField` and
  492. :class:`django.forms.GenericIPAddressField`.
  493. ``BaseMemcachedCache._get_memcache_timeout`` method
  494. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  495. The ``BaseMemcachedCache._get_memcache_timeout()`` method has been renamed to
  496. ``get_backend_timeout()``. Despite being a private API, it will go through the
  497. normal deprecation.
  498. Natural key serialization options
  499. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  500. The ``--natural`` and ``-n`` options for :djadmin:`dumpdata` have been
  501. deprecated. Use :djadminopt:`--natural-foreign` instead.
  502. Similarly, the ``use_natural_keys`` argument for ``serializers.serialize()``
  503. has been deprecated. Use ``use_natural_foreign_keys`` instead.
  504. Merging of ``POST`` and ``GET`` arguments into ``WSGIRequest.REQUEST``
  505. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  506. It was already strongly suggested that you use ``GET`` and ``POST`` instead of
  507. ``REQUEST``, because the former are more explicit. The property ``REQUEST`` is
  508. deprecated and will be removed in Django 1.9.
  509. ``django.utils.datastructures.MergeDict`` class
  510. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  511. ``MergeDict`` exists primarily to support merging ``POST`` and ``GET``
  512. arguments into a ``REQUEST`` property on ``WSGIRequest``. To merge
  513. dictionaries, use ``dict.update()`` instead. The class ``MergeDict`` is
  514. deprecated and will be removed in Django 1.9.