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