1.1-beta-1.txt 8.0 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210
  1. .. _releases-1.1-beta-1:
  2. ===============================
  3. Django 1.1 beta 1 release notes
  4. ===============================
  5. March 23, 2009
  6. Welcome to Django 1.1 beta 1!
  7. This is the second in a series of preview/development releases leading up to
  8. the eventual release of Django 1.1, currently scheduled to take place in April
  9. 2009. This release is primarily targeted at developers who are interested in
  10. trying out new features and testing the Django codebase to help identify and
  11. resolve bugs prior to the final 1.1 release.
  12. As such, this release is *not* intended for production use, and any such use
  13. is discouraged.
  14. What's new in Django 1.1 beta 1
  15. ===============================
  16. .. seealso::
  17. The :ref:`1.1 alpha release notes <releases-1.1-alpha-1>`, which has a
  18. list of everything new between Django 1.0 and Django 1.1 alpha.
  19. Model improvements
  20. ------------------
  21. .. currentmodule:: django.db.models
  22. A number of features have been added to Django's model layer:
  23. "Unmanaged" models
  24. ~~~~~~~~~~~~~~~~~~
  25. You can now control whether or not Django creates database tables for a model
  26. using the :attr:`~Options.managed` model option. This defaults to ``True``,
  27. meaning that Django will create the appropriate database tables in
  28. :djadmin:`syncdb` and remove them as part of :djadmin:`reset` command. That
  29. is, Django *manages* the database table's lifecycle.
  30. If you set this to ``False``, however, no database table creating or deletion
  31. will be automatically performed for this model. This is useful if the model
  32. represents an existing table or a database view that has been created by some
  33. other means.
  34. For more details, see the documentation for the :attr:`~Options.managed`
  35. option.
  36. Proxy models
  37. ~~~~~~~~~~~~
  38. You can now create :ref:`proxy models <proxy-models>`: subclasses of existing
  39. models that only add Python behavior and aren't represented by a new table.
  40. That is, the new model is a *proxy* for some underlying model, which stores
  41. all the real data.
  42. All the details can be found in the :ref:`proxy models documentation
  43. <proxy-models>`. This feature is similar on the surface to unmanaged models,
  44. so the documentation has an explanation of :ref:`how proxy models differ from
  45. unmanaged models <proxy-vs-unmanaged-models>`.
  46. Deferred fields
  47. ~~~~~~~~~~~~~~~
  48. In some complex situations, your models might contain fields which could
  49. contain a lot of data (for example, large text fields), or require expensive
  50. processing to convert them to Python objects. If you know you don't need those
  51. particular fields, you can now tell Django not to retrieve them from the
  52. database.
  53. You'll do this with the new queryset methods
  54. :meth:`~django.db.models.QuerySet.defer` and
  55. :meth:`~django.db.models.QuerySet.only`.
  56. New admin features
  57. ------------------
  58. Since 1.1 alpha, a couple of new features have been added to Django's admin
  59. application:
  60. Editable fields on the change list
  61. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  62. You can now make fields editable on the admin list views via the new
  63. :ref:`list_editable <admin-list-editable>` admin option. These fields will show
  64. up as form widgets on the list pages, and can be edited and saved in bulk.
  65. Admin "actions"
  66. ~~~~~~~~~~~~~~~
  67. You can now define :ref:`admin actions <ref-contrib-admin-actions>` that can perform
  68. some action to a group of models in bulk. Users will be able to select objects on
  69. the change list page and then apply these bulk actions to all selected objects.
  70. Django ships with one pre-defined admin action to delete a group of objects in
  71. one fell swoop.
  72. Testing improvements
  73. --------------------
  74. .. currentmodule:: django.test.client
  75. A couple of small but very useful improvements have been made to the
  76. :ref:`testing framework <topics-testing>`:
  77. * The test :class:`Client` now can automatically follow redirects with the
  78. ``follow`` argument to :meth:`Client.get` and :meth:`Client.post`. This
  79. makes testing views that issue redirects simpler.
  80. * It's now easier to get at the template context in the response returned
  81. the test client: you'll simply access the context as
  82. ``request.context[key]``. The old way, which treats ``request.context``
  83. as a list of contexts, one for each rendered template, is still
  84. available if you need it.
  85. Conditional view processing
  86. ---------------------------
  87. Django now has much better support for :ref:`conditional view processing
  88. <topics-conditional-processing>` using the standard ``ETag`` and
  89. ``Last-Modified`` HTTP headers. This means you can now easily short-circuit
  90. view processing by testing less-expensive conditions. For many views this can
  91. lead to a serious improvement in speed and reduction in bandwidth.
  92. Other improvements
  93. ------------------
  94. Finally, a grab-bag of other neat features made their way into this beta
  95. release, including:
  96. * The :djadmin:`dumpdata` management command now accepts individual
  97. model names as arguments, allowing you to export the data just from
  98. particular models.
  99. * There's a new :tfilter:`safeseq` template filter which works just like
  100. :tfilter:`safe` for lists, marking each item in the list as safe.
  101. * :ref:`Cache backends <topics-cache>` now support ``incr()`` and
  102. ``decr()`` commands to increment and decrement the value of a cache key.
  103. On cache backends that support atomic increment/decrement -- most
  104. notably, the memcached backend -- these operations will be atomic, and
  105. quite fast.
  106. * Django now can :ref:`easily delegate authentication to the web server
  107. <howto-auth-remote-user>` via a new authentication backend that supports
  108. the standard ``REMOTE_USER`` environment variable used for this purpose.
  109. * There's a new :func:`django.shortcuts.redirect` function that makes it
  110. easier to issue redirects given an object, a view name, or a URL.
  111. * The ``postgresql_psycopg2`` backend now supports :ref:`native PostgreSQL
  112. autocommit <postgresql-notes>`. This is an advanced, PostgreSQL-specific
  113. feature, that can make certain read-heavy applications a good deal
  114. faster.
  115. The Django 1.1 roadmap
  116. ======================
  117. Before Django 1.1 goes final, at least one other preview/development release
  118. will be made available. The current schedule consists of at least the
  119. following:
  120. * Week of *April 2, 2009:* Django 1.1 release candidate. At this point all
  121. strings marked for translation must freeze to allow translations to
  122. be submitted in advance of the final release.
  123. * Week of *April 13, 2009:* Django 1.1 final.
  124. If deemed necessary, additional beta or release candidate packages will be
  125. issued prior to the final 1.1 release.
  126. What you can do to help
  127. =======================
  128. In order to provide a high-quality 1.1 release, we need your help. Although this
  129. beta release is, again, *not* intended for production use, you can help the
  130. Django team by trying out the beta codebase in a safe test environment and
  131. reporting any bugs or issues you encounter. The Django ticket tracker is the
  132. central place to search for open issues:
  133. * http://code.djangoproject.com/timeline
  134. Please open new tickets if no existing ticket corresponds to a problem you're
  135. running into.
  136. Additionally, discussion of Django development, including progress toward the
  137. 1.1 release, takes place daily on the django-developers mailing list:
  138. * http://groups.google.com/group/django-developers
  139. ... and in the ``#django-dev`` IRC channel on ``irc.freenode.net``. If you're
  140. interested in helping out with Django's development, feel free to join the
  141. discussions there.
  142. Django's online documentation also includes pointers on how to contribute to
  143. Django:
  144. * :ref:`How to contribute to Django <internals-contributing>`
  145. Contributions on any level -- developing code, writing documentation or simply
  146. triaging tickets and helping to test proposed bugfixes -- are always welcome and
  147. appreciated.
  148. Development sprints for Django 1.1 will also be taking place at PyCon US 2009,
  149. on the dedicated sprint days (March 30 through April 2), and anyone who wants to
  150. help out is welcome to join in, either in person at PyCon or virtually in the
  151. IRC channel or on the mailing list.