July 29, 2009
\nWelcome to Django 1.1!
\nDjango 1.1 includes a number of nifty new features, lots\nof bug fixes, and an easy upgrade path from Django 1.0.
\nDjango has a policy of API stability. This means\nthat, in general, code you develop against Django 1.0 should continue to work\nagainst 1.1 unchanged. However, we do sometimes make backwards-incompatible\nchanges if they’re necessary to resolve bugs, and there are a handful of such\n(minor) changes between Django 1.0 and Django 1.1.
\nBefore upgrading to Django 1.1 you should double-check that the following\nchanges don’t impact you, and upgrade your code if they do.
\nDjango 1.1 modifies the method used to generate database constraint names so\nthat names are consistent regardless of machine word size. This change is\nbackwards incompatible for some users.
\nIf you are using a 32-bit platform, you’re off the hook; you’ll observe no\ndifferences as a result of this change.
\nHowever, users on 64-bit platforms may experience some problems using the\nreset management command. Prior to this change, 64-bit platforms\nwould generate a 64-bit, 16 character digest in the constraint name; for\nexample:
ALTER TABLE myapp_sometable ADD CONSTRAINT object_id_refs_id_5e8f10c132091d1e FOREIGN KEY ...\nFollowing this change, all platforms, regardless of word size, will generate a\n32-bit, 8 character digest in the constraint name; for example:
\nALTER TABLE myapp_sometable ADD CONSTRAINT object_id_refs_id_32091d1e FOREIGN KEY ...\nAs a result of this change, you will not be able to use the reset\nmanagement command on any table made by a 64-bit machine. This is because the\nnew generated name will not match the historically generated name; as a\nresult, the SQL constructed by the reset command will be invalid.
If you need to reset an application that was created with 64-bit constraints,\nyou will need to manually drop the old constraint prior to invoking\nreset.
Django 1.1 runs tests inside a transaction, allowing better test performance\n(see test performance improvements for details).
\nThis change is slightly backwards incompatible if existing tests need to test\ntransactional behavior, if they rely on invalid assumptions about the test\nenvironment, or if they require a specific test case ordering.
\nFor these cases, TransactionTestCase can be used instead.\nThis is a just a quick fix to get around test case errors revealed by the new\nrollback approach; in the long-term tests should be rewritten to correct the\ntest case.
SetRemoteAddrFromForwardedFor middlewareLink to this heading#For convenience, Django 1.0 included an optional middleware class –\ndjango.middleware.http.SetRemoteAddrFromForwardedFor – which updated the\nvalue of REMOTE_ADDR based on the HTTP X-Forwarded-For header commonly\nset by some proxy configurations.
It has been demonstrated that this mechanism cannot be made reliable enough for\ngeneral-purpose use, and that (despite documentation to the contrary) its\ninclusion in Django may lead application developers to assume that the value of\nREMOTE_ADDR is “safe” or in some way reliable as a source of\nauthentication.
While not directly a security issue, we’ve decided to remove this middleware\nwith the Django 1.1 release. It has been replaced with a class that does\nnothing other than raise a DeprecationWarning.
If you’ve been relying on this middleware, the easiest upgrade path is:
\nVerify that it works correctly with your upstream proxy, modifying\nit to support your particular proxy (if necessary).
Introduce your modified version of SetRemoteAddrFromForwardedFor as a\npiece of middleware in your own project.
In Django 1.0, files uploaded and stored in a model’s FileField were\nsaved to disk before the model was saved to the database. This meant that the\nactual file name assigned to the file was available before saving. For example,\nit was available in a model’s pre-save signal handler.
In Django 1.1 the file is saved as part of saving the model in the database, so\nthe actual file name used on disk cannot be relied on until after the model\nhas been saved.
\nIn Django 1.1, BaseModelFormSet now calls\nModelForm.save().
This is backwards-incompatible if you were modifying self.initial in a\nmodel formset’s __init__, or if you relied on the internal\n_total_form_count or _initial_form_count attributes of BaseFormSet.\nThose attributes are now public methods.
join filter’s escaping behaviorLink to this heading#The join filter no longer escapes the literal value that is\npassed in for the connector.
This is backwards incompatible for the special situation of the literal string\ncontaining one of the five special HTML characters. Thus, if you were writing\n{{ foo|join:"&" }}, you now have to write {{ foo|join:"&" }}.
The previous behavior was a bug and contrary to what was documented\nand expected.
\nredirect_to() generic viewLink to this heading#Django 1.1 adds a permanent argument to the\ndjango.views.generic.simple.redirect_to() view. This is technically\nbackwards-incompatible if you were using the redirect_to view with a\nformat-string key called ‘permanent’, which is highly unlikely.
One feature has been marked as deprecated in Django 1.1:
\nYou should no longer use AdminSite.root() to register that admin\nviews. That is, if your URLconf contains the line:
(r"^admin/(.*)", admin.site.root),\nYou should change it to read:
\n(r"^admin/", include(admin.site.urls)),\nYou should begin to remove use of this feature from your code immediately.
\nAdminSite.root will raise a PendingDeprecationWarning if used in\nDjango 1.1. This warning is hidden by default. In Django 1.2, this warning will\nbe upgraded to a DeprecationWarning, which will be displayed loudly. Django\n1.3 will remove AdminSite.root() entirely.
For more details on our deprecation policies and strategy, see\nDjango’s release process.
\nQuite a bit: since Django 1.0, we’ve made 1,290 code commits, fixed 1,206 bugs,\nand added roughly 10,000 lines of documentation.
\nThe major new features in Django 1.1 are:
\nTwo major enhancements have been added to Django’s object-relational mapper\n(ORM): aggregate support, and query expressions.
\nIt’s now possible to run SQL aggregate queries (i.e. COUNT(), MAX(),\nMIN(), etc.) from within Django’s ORM. You can choose to either return the\nresults of the aggregate directly, or else annotate the objects in a\nQuerySet with the results of the aggregate\nquery.
This feature is available as new\naggregate() and\nannotate() methods, and is covered in\ndetail in the ORM aggregation documentation.
Queries can now refer to another field on the query and can traverse\nrelationships to refer to fields on related models. This is implemented in the\nnew F object; for full details, including examples,\nconsult the F expressions documentation.
A number of features have been added to Django’s model layer:
\nYou can now control whether or not Django manages the life-cycle of the\ndatabase tables for a model using the managed model option.\nThis defaults to True, meaning that Django will create the appropriate\ndatabase tables in syncdb and remove them as part of the reset command.\nThat is, Django manages the database table’s lifecycle.
If you set this to False, however, no database table creating or deletion\nwill be automatically performed for this model. This is useful if the model\nrepresents an existing table or a database view that has been created by some\nother means.
For more details, see the documentation for the managed\noption.
You can now create proxy models: subclasses of existing\nmodels that only add Python-level (rather than database-level) behavior and\naren’t represented by a new table. That is, the new model is a proxy for some\nunderlying model, which stores all the real data.
\nAll the details can be found in the proxy models documentation. This feature is similar on the surface to unmanaged models,\nso the documentation has an explanation of how proxy models differ from\nunmanaged models.
\nIn some complex situations, your models might contain fields which could\ncontain a lot of data (for example, large text fields), or require expensive\nprocessing to convert them to Python objects. If you know you don’t need those\nparticular fields, you can now tell Django not to retrieve them from the\ndatabase.
\nYou’ll do this with the new queryset methods\ndefer() and\nonly().
A few notable improvements have been made to the testing framework.
\nTests written using Django’s testing framework\nnow run dramatically faster (as much as 10 times faster in many cases).
\nThis was accomplished through the introduction of transaction-based tests: when\nusing django.test.TestCase, your tests will now be run in a\ntransaction which is rolled back when finished, instead of by flushing and\nre-populating the database. This results in an immense speedup for most types\nof unit tests. See the documentation for TestCase and\nTransactionTestCase for a full description, and some important notes\non database support.
A couple of small – but highly useful – improvements have been made to the\ntest client:
\nThe test Client now can automatically follow redirects with the\nfollow argument to Client.get() and Client.post(). This\nmakes testing views that issue redirects simpler.
It’s now easier to get at the template context in the response returned\nthe test client: you’ll simply access the context as\nrequest.context[key]. The old way, which treats request.context as\na list of contexts, one for each rendered template in the inheritance\nchain, is still available if you need it.
Django 1.1 adds a couple of nifty new features to Django’s admin interface:
\nYou can now make fields editable on the admin list views via the new\nlist_editable admin option. These fields will show\nup as form widgets on the list pages, and can be edited and saved in bulk.
\nYou can now define admin actions that can\nperform some action to a group of models in bulk. Users will be able to select\nobjects on the change list page and then apply these bulk actions to all\nselected objects.
\nDjango ships with one pre-defined admin action to delete a group of objects in\none fell swoop.
\nDjango now has much better support for conditional view processing using the standard ETag and\nLast-Modified HTTP headers. This means you can now easily short-circuit\nview processing by testing less-expensive conditions. For many views this can\nlead to a serious improvement in speed and reduction in bandwidth.
Django 1.1 improves named URL patterns with the\nintroduction of URL “namespaces.”
\nIn short, this feature allows the same group of URLs, from the same\napplication, to be included in a Django URLConf multiple times, with varying\n(and potentially nested) named prefixes which will be used when performing\nreverse resolution. In other words, reusable applications like Django’s admin\ninterface may be registered multiple times without URL conflicts.
\nFor full details, see the documentation on defining URL namespaces.
\nIn Django 1.1, GeoDjango (i.e.\ndjango.contrib.gis) has several new features:
Support for SpatiaLite – a spatial database for SQLite – as a spatial\nbackend.
Geographic aggregates (Collect, Extent, MakeLine, Union)\nand F expressions.
New GeoQuerySet methods: collect, geojson, and\nsnap_to_grid.
A new list interface methods for GEOSGeometry objects.
For more details, see the GeoDjango documentation.
\nOther new features and changes introduced since Django 1.0 include:
\nThe CSRF protection middleware has been split into\ntwo classes – CsrfViewMiddleware checks incoming requests, and\nCsrfResponseMiddleware processes outgoing responses. The combined\nCsrfMiddleware class (which does both) remains for\nbackwards-compatibility, but using the split classes is now recommended in\norder to allow fine-grained control of when and where the CSRF processing\ntakes place.
reverse() and code which uses it (e.g., the {% url %} template tag)\nnow works with URLs in Django’s administrative site, provided that the admin\nURLs are set up via include(admin.site.urls) (sending admin requests to\nthe admin.site.root view still works, but URLs in the admin will not be\n“reversible” when configured this way).
The include() function in Django URLconf modules can now accept sequences\nof URL patterns (generated by patterns()) in addition to module names.
Instances of Django forms (see the forms overview) now have two additional methods, hidden_fields()\nand visible_fields(), which return the list of hidden – i.e.,\n<input type="hidden"> – and visible fields on the form, respectively.
The redirect_to generic view\nnow accepts an additional keyword argument permanent. If permanent is\nTrue, the view will emit an HTTP permanent redirect (status code 301). If\nFalse, the view will emit an HTTP temporary redirect (status code 302).
A new database lookup type – week_day – has been added for\nDateField and DateTimeField. This type of lookup accepts a number\nbetween 1 (Sunday) and 7 (Saturday), and returns objects where the field\nvalue matches that day of the week. See the full list of lookup types for details.
The {% for %} tag in Django’s template language now accepts an optional\n{% empty %} clause, to be displayed when {% for %} is asked to loop\nover an empty sequence. See the list of built-in template tags for examples of this.
The dumpdata management command now accepts individual\nmodel names as arguments, allowing you to export the data just from\nparticular models.
There’s a new safeseq template filter which works just like\nsafe for lists, marking each item in the list as safe.
Cache backends now support incr() and\ndecr() commands to increment and decrement the value of a cache key.\nOn cache backends that support atomic increment/decrement – most\nnotably, the memcached backend – these operations will be atomic, and\nquite fast.
Django now can easily delegate authentication to the web server via a new authentication backend that supports\nthe standard REMOTE_USER environment variable used for this purpose.
There’s a new django.shortcuts.redirect() function that makes it\neasier to issue redirects given an object, a view name, or a URL.
The postgresql_psycopg2 backend now supports native PostgreSQL\nautocommit. This is an advanced, PostgreSQL-specific\nfeature, that can make certain read-heavy applications a good deal\nfaster.
We’ll take a short break, and then work on Django 1.2 will begin – no rest for\nthe weary! If you’d like to help, discussion of Django development, including\nprogress toward the 1.2 release, takes place daily on the django-developers\nmailing list and in the #django-dev IRC channel on irc.libera.chat.\nFeel free to join the discussions!
Django’s online documentation also includes pointers on how to contribute to\nDjango:
\n\nContributions on any level – developing code, writing documentation or simply\ntriaging tickets and helping to test proposed bugfixes – are always welcome\nand appreciated.
\nAnd that’s the way it is.
\n