Welcome to Django 0.96!
\nThe primary goal for 0.96 is a cleanup and stabilization of the features\nintroduced in 0.95. There have been a few small backwards-incompatible\nchanges since 0.95, but the upgrade process should be fairly simple\nand should not require major changes to existing applications.
\nHowever, we’re also releasing 0.96 now because we have a set of\nbackwards-incompatible changes scheduled for the near future. Once\ncompleted, they will involve some code changes for application\ndevelopers, so we recommend that you stick with Django 0.96 until the\nnext official release; then you’ll be able to upgrade in one step\ninstead of needing to make incremental changes to keep up with the\ndevelopment version of Django.
\nThe following changes may require you to update your code when you switch from\n0.95 to 0.96:
\nMySQLdb version requirementLink to this heading#Due to a bug in older versions of the MySQLdb Python module (which\nDjango uses to connect to MySQL databases), Django’s MySQL backend now\nrequires version 1.2.1p2 or higher of MySQLdb, and will raise\nexceptions if you attempt to use an older version.
If you’re currently unable to upgrade your copy of MySQLdb to meet\nthis requirement, a separate, backwards-compatible backend, called\n“mysql_old”, has been added to Django. To use this backend, change\nthe DATABASE_ENGINE setting in your Django settings file from this:
DATABASE_ENGINE = "mysql"\nto this:
\nDATABASE_ENGINE = "mysql_old"\nHowever, we strongly encourage MySQL users to upgrade to a more recent\nversion of MySQLdb as soon as possible, The “mysql_old” backend is\nprovided only to ease this transition, and is considered deprecated;\naside from any necessary security fixes, it will not be actively\nmaintained, and it will be removed in a future release of Django.
Also, note that some features, like the new DATABASE_OPTIONS\nsetting (see the databases documentation for details),\nare only available on the “mysql” backend, and will not be made available for\n“mysql_old”.
The format of the constraint names Django generates for foreign key\nreferences have changed slightly. These names are generally only used\nwhen it is not possible to put the reference directly on the affected\ncolumn, so they are not always visible.
\nThe effect of this change is that running manage.py reset and\nsimilar commands against an existing database may generate SQL with\nthe new form of constraint name, while the database itself contains\nconstraints named in the old form; this will cause the database server\nto raise an error message about modifying nonexistent constraints.
If you need to work around this, there are two methods available:
\nRedirect the output of manage.py to a file, and edit the\ngenerated SQL to use the correct constraint names before\nexecuting it.
Examine the output of manage.py sqlall to see the new-style\nconstraint names, and use that as a guide to rename existing\nconstraints in your database.
manage.pyLink to this heading#A few of the options to manage.py have changed with the addition of fixture\nsupport:
There are new dumpdata and loaddata commands which, as\nyou might expect, will dump and load data to/from the\ndatabase. These commands can operate against any of Django’s\nsupported serialization formats.
The sqlinitialdata command has been renamed to sqlcustom to\nemphasize that loaddata should be used for data (and sqlcustom for\nother custom SQL – views, stored procedures, etc.).
The vestigial install command has been removed. Use syncdb.
The Django database API now escapes backslashes given as query parameters. If\nyou have any database API code that matches backslashes, and it was working\nbefore (despite the lack of escaping), you’ll have to change your code to\n“unescape” the slashes one level.
\nFor example, this used to work:
\n# Find text containing a single backslash\nMyModel.objects.filter(text__contains="\\\\\\\\")\nThe above is now incorrect, and should be rewritten as:
\n# Find text containing a single backslash\nMyModel.objects.filter(text__contains="\\\\")\nThe ENABLE_PSYCO setting no longer exists. If your settings file includes\nENABLE_PSYCO it will have no effect; to use Psyco, we recommend\nwriting a middleware class to activate it.
This revision represents over a thousand source commits and over four hundred\nbug fixes, so we can’t possibly catalog all the changes. Here, we describe the\nmost notable changes in this release.
\ndjango.newforms is Django’s new form-handling library. It’s a\nreplacement for django.forms, the old form/manipulator/validation\nframework. Both APIs are available in 0.96, but over the next two\nreleases we plan to switch completely to the new forms system, and\ndeprecate and remove the old system.
There are three elements to this transition:
\nWe’ve copied the current django.forms to\ndjango.oldforms. This allows you to upgrade your code now\nrather than waiting for the backwards-incompatible change and\nrushing to fix your code after the fact. Just change your\nimport statements like this:
from django import forms # 0.95-style\nfrom django import oldforms as forms # 0.96-style\nThe next official release of Django will move the current\ndjango.newforms to django.forms. This will be a\nbackwards-incompatible change, and anyone still using the old\nversion of django.forms at that time will need to change\ntheir import statements as described above.
The next release after that will completely remove\ndjango.oldforms.
Although the newforms library will continue to evolve, it’s ready for use\nfor most common cases. We recommend that anyone new to form handling skip the\nold forms system and start with the new.
For more information about django.newforms, read the newforms\ndocumentation.
You can now use any callable as the callback in URLconfs (previously, only\nstrings that referred to callables were allowed). This allows a much more\nnatural use of URLconfs. For example, this URLconf:
\nfrom django.conf.urls.defaults import *\n\nurlpatterns = patterns("", ("^myview/$", "mysite.myapp.views.myview"))\ncan now be rewritten as:
\nfrom django.conf.urls.defaults import *\nfrom mysite.myapp.views import myview\n\nurlpatterns = patterns("", ("^myview/$", myview))\nOne useful application of this can be seen when using decorators; this\nchange allows you to apply decorators to views in your\nURLconf. Thus, you can make a generic view require login very\neasily:
\nfrom django.conf.urls.defaults import *\nfrom django.contrib.auth.decorators import login_required\nfrom django.views.generic.list_detail import object_list\nfrom mysite.myapp.models import MyModel\n\ninfo = {\n "queryset": MyModel.objects.all(),\n}\n\nurlpatterns = patterns("", ("^myview/$", login_required(object_list), info))\nNote that both syntaxes (strings and callables) are valid, and will continue to\nbe valid for the foreseeable future.
\nDjango now includes a test framework so you can start transmuting fear into\nboredom (with apologies to Kent Beck). You can write tests based on\ndoctest or unittest and test your views with a simple test\nclient.
There is also new support for “fixtures” – initial data, stored in any of the\nsupported serialization formats, that will be\nloaded into your database at the start of your tests. This makes testing with\nreal data much easier.
\nSee the testing documentation for the full\ndetails.
\nA small change, but a very nice one: dedicated views for adding and\nupdating users have been added to the admin interface, so you no\nlonger need to worry about working with hashed passwords in the admin.
\nSince 0.95, a number of people have stepped forward and taken a major\nnew role in Django’s development. We’d like to thank these people for\nall their hard work:
\nRussell Keith-Magee and Malcolm Tredinnick for their major code\ncontributions. This release wouldn’t have been possible without them.
Our new release manager, James Bennett, for his work in getting out\n0.95.1, 0.96, and (hopefully) future release.
Our ticket managers Chris Beaven (aka SmileyChris), Simon Greenhill,\nMichael Radziej, and Gary Wilson. They agreed to take on the monumental\ntask of wrangling our tickets into nicely cataloged submission. Figuring\nout what to work on is now about a million times easier; thanks again,\nguys.
Everyone who submitted a bug report, patch or ticket comment. We can’t\npossibly thank everyone by name – over 200 developers submitted patches\nthat went into 0.96 – but everyone who’s contributed to Django is listed\nin AUTHORS.