PageRenderTime 111ms CodeModel.GetById 106ms app.highlight 2ms RepoModel.GetById 1ms app.codeStats 0ms

/docs/releases/1.1-beta-1.txt

https://code.google.com/p/mango-py/
Plain Text | 208 lines | 150 code | 58 blank | 0 comment | 0 complexity | afca708b4ce31757fa173ecc142ce625 MD5 | raw file
  1===============================
  2Django 1.1 beta 1 release notes
  3===============================
  4
  5March 23, 2009
  6
  7Welcome to Django 1.1 beta 1!
  8
  9This is the second in a series of preview/development releases leading up to
 10the eventual release of Django 1.1, currently scheduled to take place in April
 112009. This release is primarily targeted at developers who are interested in
 12trying out new features and testing the Django codebase to help identify and
 13resolve bugs prior to the final 1.1 release.
 14
 15As such, this release is *not* intended for production use, and any such use
 16is discouraged.
 17
 18What'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
 26Model improvements
 27------------------
 28
 29.. currentmodule:: django.db.models
 30
 31A number of features have been added to Django's model layer:
 32
 33"Unmanaged" models
 34~~~~~~~~~~~~~~~~~~
 35
 36You can now control whether or not Django creates database tables for a model
 37using the :attr:`~Options.managed` model option. This defaults to ``True``,
 38meaning that Django will create the appropriate database tables in
 39:djadmin:`syncdb` and remove them as part of :djadmin:`reset` command. That
 40is, Django *manages* the database table's lifecycle.
 41
 42If you set this to ``False``, however, no database table creating or deletion
 43will be automatically performed for this model. This is useful if the model
 44represents an existing table or a database view that has been created by some
 45other means.
 46
 47For more details, see the documentation for the :attr:`~Options.managed`
 48option.
 49
 50Proxy models
 51~~~~~~~~~~~~
 52
 53You can now create :ref:`proxy models <proxy-models>`: subclasses of existing
 54models that only add Python behavior and aren't represented by a new table.
 55That is, the new model is a *proxy* for some underlying model, which stores
 56all the real data.
 57
 58All the details can be found in the :ref:`proxy models documentation
 59<proxy-models>`. This feature is similar on the surface to unmanaged models,
 60so the documentation has an explanation of :ref:`how proxy models differ from
 61unmanaged models <proxy-vs-unmanaged-models>`.
 62
 63Deferred fields
 64~~~~~~~~~~~~~~~
 65
 66In some complex situations, your models might contain fields which could
 67contain a lot of data (for example, large text fields), or require expensive
 68processing to convert them to Python objects. If you know you don't need those
 69particular fields, you can now tell Django not to retrieve them from the
 70database.
 71
 72You'll do this with the new queryset methods
 73:meth:`~django.db.models.QuerySet.defer` and
 74:meth:`~django.db.models.QuerySet.only`.
 75
 76New admin features
 77------------------
 78
 79Since 1.1 alpha, a couple of new features have been added to Django's admin
 80application:
 81
 82Editable fields on the change list
 83~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 84
 85You 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
 87up as form widgets on the list pages, and can be edited and saved in bulk.
 88
 89Admin "actions"
 90~~~~~~~~~~~~~~~
 91
 92You can now define :doc:`admin actions </ref/contrib/admin/actions>` that can perform
 93some action to a group of models in bulk. Users will be able to select objects on
 94the change list page and then apply these bulk actions to all selected objects.
 95
 96Django ships with one pre-defined admin action to delete a group of objects in
 97one fell swoop.
 98
 99Testing improvements
100--------------------
101
102.. currentmodule:: django.test.client
103
104A 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
117Conditional view processing
118---------------------------
119
120Django 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
123view processing by testing less-expensive conditions. For many views this can
124lead to a serious improvement in speed and reduction in bandwidth.
125
126Other improvements
127------------------
128
129Finally, a grab-bag of other neat features made their way into this beta
130release, 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
157The Django 1.1 roadmap
158======================
159
160Before Django 1.1 goes final, at least one other preview/development release
161will be made available. The current schedule consists of at least the
162following:
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
170If deemed necessary, additional beta or release candidate packages will be
171issued prior to the final 1.1 release.
172
173What you can do to help
174=======================
175
176In order to provide a high-quality 1.1 release, we need your help. Although this
177beta release is, again, *not* intended for production use, you can help the
178Django team by trying out the beta codebase in a safe test environment and
179reporting any bugs or issues you encounter. The Django ticket tracker is the
180central place to search for open issues:
181
182    * http://code.djangoproject.com/timeline
183
184Please open new tickets if no existing ticket corresponds to a problem you're
185running into.
186
187Additionally, discussion of Django development, including progress toward the
1881.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
193interested in helping out with Django's development, feel free to join the
194discussions there.
195
196Django's online documentation also includes pointers on how to contribute to
197Django:
198
199    * :doc:`How to contribute to Django </internals/contributing>`
200
201Contributions on any level -- developing code, writing documentation or simply
202triaging tickets and helping to test proposed bugfixes -- are always welcome and
203appreciated.
204
205Development sprints for Django 1.1 will also be taking place at PyCon US 2009,
206on the dedicated sprint days (March 30 through April 2), and anyone who wants to
207help out is welcome to join in, either in person at PyCon or virtually in the
208IRC channel or on the mailing list.