PageRenderTime 47ms CodeModel.GetById 22ms RepoModel.GetById 1ms app.codeStats 0ms

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