2
0

1.1-alpha-1.txt 6.8 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165
  1. ================================
  2. Django 1.1 alpha 1 release notes
  3. ================================
  4. February 23, 2009
  5. Welcome to Django 1.1 alpha 1!
  6. This is the first in a series of preview/development releases leading up to the
  7. eventual release of Django 1.1, currently scheduled to take place in April 2009.
  8. This release is primarily targeted at developers who are interested in trying
  9. out new features and testing the Django codebase to help identify and resolve
  10. bugs prior to the final 1.1 release.
  11. As such, this release is *not* intended for production use, and any such use is
  12. discouraged.
  13. What's new in Django 1.1 alpha 1
  14. ================================
  15. ORM improvements
  16. ----------------
  17. Two major enhancements have been added to Django's object-relational mapper
  18. (ORM):
  19. Aggregate support
  20. ~~~~~~~~~~~~~~~~~
  21. .. currentmodule:: django.db.models
  22. It's now possible to run SQL aggregate queries (i.e. ``COUNT()``, ``MAX()``,
  23. ``MIN()``, etc.) from within Django's ORM. You can choose to either return the
  24. results of the aggregate directly, or else annotate the objects in a
  25. :class:`~django.db.models.query.QuerySet` with the results of the aggregate
  26. query.
  27. This feature is available as new
  28. :meth:`~django.db.models.query.QuerySet.aggregate` and
  29. :meth:`~django.db.models.query.QuerySet.annotate` methods, and is covered in
  30. detail in :doc:`the ORM aggregation documentation </topics/db/aggregation>`.
  31. Query expressions
  32. ~~~~~~~~~~~~~~~~~
  33. Queries can now refer to a another field on the query and can traverse
  34. relationships to refer to fields on related models. This is implemented in the
  35. new :class:`F` object; for full details, including examples, consult the
  36. :class:`F expressions documentation <django.db.models.F>`.
  37. Performance improvements
  38. ------------------------
  39. .. currentmodule:: django.test
  40. Tests written using Django's :doc:`testing framework </topics/testing/index>`
  41. now run dramatically faster (as much as 10 times faster in many cases).
  42. This was accomplished through the introduction of transaction-based tests: when
  43. using :class:`django.test.TestCase`, your tests will now be run in a transaction
  44. which is rolled back when finished, instead of by flushing and re-populating the
  45. database. This results in an immense speedup for most types of unit tests. See
  46. the documentation for :class:`TestCase` and :class:`TransactionTestCase` for a
  47. full description, and some important notes on database support.
  48. Other improvements
  49. ------------------
  50. Other new features and changes introduced since Django 1.0 include:
  51. * The :doc:`CSRF protection middleware </ref/contrib/csrf>` has been split into
  52. two classes -- ``CsrfViewMiddleware`` checks incoming requests, and
  53. ``CsrfResponseMiddleware`` processes outgoing responses. The combined
  54. ``CsrfMiddleware`` class (which does both) remains for
  55. backwards-compatibility, but using the split classes is now recommended in
  56. order to allow fine-grained control of when and where the CSRF processing
  57. takes place.
  58. * :func:`~django.core.urlresolvers.reverse` and code which uses it (e.g., the
  59. ``{% url %}`` template tag) now works with URLs in Django's administrative
  60. site, provided that the admin URLs are set up via ``include(admin.site.urls)``
  61. (sending admin requests to the ``admin.site.root`` view still works, but URLs
  62. in the admin will not be "reversible" when configured this way).
  63. * The ``include()`` function in Django URLconf modules can now accept sequences
  64. of URL patterns (generated by ``patterns()``) in addition to module names.
  65. * Instances of Django forms (see :doc:`the forms overview </topics/forms/index>`)
  66. now have two additional methods, ``hidden_fields()`` and ``visible_fields()``,
  67. which return the list of hidden -- i.e., ``<input type="hidden">`` -- and
  68. visible fields on the form, respectively.
  69. * The ``redirect_to`` generic view
  70. now accepts an additional keyword argument
  71. ``permanent``. If ``permanent`` is ``True``, the view will emit an HTTP
  72. permanent redirect (status code 301). If ``False``, the view will emit an HTTP
  73. temporary redirect (status code 302).
  74. * A new database lookup type -- ``week_day`` -- has been added for ``DateField``
  75. and ``DateTimeField``. This type of lookup accepts a number between 1 (Sunday)
  76. and 7 (Saturday), and returns objects where the field value matches that day
  77. of the week. See :ref:`the full list of lookup types <field-lookups>` for
  78. details.
  79. * The ``{% for %}`` tag in Django's template language now accepts an optional
  80. ``{% empty %}`` clause, to be displayed when ``{% for %}`` is asked to loop
  81. over an empty sequence. See :doc:`the list of built-in template tags
  82. </ref/templates/builtins>` for examples of this.
  83. The Django 1.1 roadmap
  84. ======================
  85. Before Django 1.1 goes final, several other preview/development releases will be
  86. made available. The current schedule consists of at least the following:
  87. * Week of *March 20, 2009:* Django 1.1 beta 1, at which point Django 1.1 will
  88. be in "feature freeze": no new features will be implemented for 1.1
  89. past that point, and all new feature work will be deferred to
  90. Django 1.2.
  91. * Week of *April 2, 2009:* Django 1.1 release candidate. At this point all
  92. strings marked for translation must freeze to allow translations to
  93. be submitted in advance of the final release.
  94. * Week of *April 13, 2009:* Django 1.1 final.
  95. If deemed necessary, additional alpha, beta or release candidate packages will
  96. be issued prior to the final 1.1 release.
  97. What you can do to help
  98. =======================
  99. In order to provide a high-quality 1.1 release, we need your help. Although this
  100. alpha release is, again, *not* intended for production use, you can help the
  101. Django team by trying out the alpha codebase in a safe test environment and
  102. reporting any bugs or issues you encounter. The Django ticket tracker is the
  103. central place to search for open issues:
  104. * https://code.djangoproject.com/timeline
  105. Please open new tickets if no existing ticket corresponds to a problem you're
  106. running into.
  107. Additionally, discussion of Django development, including progress toward the
  108. 1.1 release, takes place daily on the django-developers mailing list:
  109. * http://groups.google.com/group/django-developers
  110. ... and in the ``#django-dev`` IRC channel on ``irc.freenode.net``. If you're
  111. interested in helping out with Django's development, feel free to join the
  112. discussions there.
  113. Django's online documentation also includes pointers on how to contribute to
  114. Django:
  115. * :doc:`How to contribute to Django </internals/contributing/index>`
  116. Contributions on any level -- developing code, writing documentation or simply
  117. triaging tickets and helping to test proposed bugfixes -- are always welcome and
  118. appreciated.
  119. Development sprints for Django 1.1 will also be taking place at PyCon US 2009,
  120. on the dedicated sprint days (March 30 through April 2), and anyone who wants to
  121. help out is welcome to join in, either in person at PyCon or virtually in the
  122. IRC channel or on the mailing list.