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