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.