| =================================== |
| Django version 0.96.1 release notes |
| =================================== |
| |
| Welcome to Django 0.96.1! |
| |
| The primary goal for 0.96 is a cleanup and stabilization of the features |
| introduced in 0.95. There have been a few small `backwards-incompatible |
| changes since 0.95`_, but the upgrade process should be fairly simple |
| and should not require major changes to existing applications. |
| |
| However, we're also releasing 0.96 now because we have a set of |
| backwards-incompatible changes scheduled for the near future. Once |
| completed, they will involve some code changes for application |
| developers, so we recommend that you stick with Django 0.96 until the |
| next official release; then you'll be able to upgrade in one step |
| instead of needing to make incremental changes to keep up with the |
| development version of Django. |
| |
| Changes since the 0.96 release |
| ============================== |
| |
| This release contains fixes for a security vulnerability discovered after the |
| initial release of Django 0.96. A bug in the i18n framework could allow an |
| attacker to send extremely large strings in the Accept-Language header and |
| cause a denial of service by filling available memory. |
| |
| Because this problems wasn't discovered and fixed until after the 0.96 |
| release, it's recommended that you use this release rather than the original |
| 0.96. |
| |
| Backwards-incompatible changes since 0.95 |
| ========================================= |
| |
| The following changes may require you to update your code when you switch from |
| 0.95 to 0.96: |
| |
| ``MySQLdb`` version requirement |
| ------------------------------- |
| |
| Due to a bug in older versions of the ``MySQLdb`` Python module (which |
| Django uses to connect to MySQL databases), Django's MySQL backend now |
| requires version 1.2.1p2 or higher of `MySQLdb`, and will raise |
| exceptions if you attempt to use an older version. |
| |
| If you're currently unable to upgrade your copy of ``MySQLdb`` to meet |
| this requirement, a separate, backwards-compatible backend, called |
| "mysql_old", has been added to Django. To use this backend, change |
| the ``DATABASE_ENGINE`` setting in your Django settings file from |
| this:: |
| |
| DATABASE_ENGINE = "mysql" |
| |
| to this:: |
| |
| DATABASE_ENGINE = "mysql_old" |
| |
| However, we strongly encourage MySQL users to upgrade to a more recent |
| version of `MySQLdb` as soon as possible, The "mysql_old" backend is |
| provided only to ease this transition, and is considered deprecated; |
| aside from any necessary security fixes, it will not be actively |
| maintained, and it will be removed in a future release of Django. |
| |
| Also, note that some features, like the new ``DATABASE_OPTIONS`` |
| setting (see the `databases documentation`_ for details), are only |
| available on the "mysql" backend, and will not be made available for |
| "mysql_old". |
| |
| .. _databases documentation: ../databases/ |
| |
| Database constraint names changed |
| --------------------------------- |
| |
| The format of the constraint names Django generates for foreign key |
| references have changed slightly. These names are generally only used |
| when it is not possible to put the reference directly on the affected |
| column, so they is not always visible. |
| |
| The effect of this change is that running ``manage.py reset`` and |
| similar commands against an existing database may generate SQL with |
| the new form of constraint name, while the database itself contains |
| constraints named in the old form; this will cause the database server |
| to raise an error message about modifying non-existent constraints. |
| |
| If you need to work around this, there are two methods available: |
| |
| 1. Redirect the output of ``manage.py`` to a file, and edit the |
| generated SQL to use the correct constraint names before |
| executing it. |
| |
| 2. Examine the output of ``manage.py sqlall`` to see the new-style |
| constraint names, and use that as a guide to rename existing |
| constraints in your database. |
| |
| Name changes in ``manage.py`` |
| ----------------------------- |
| |
| A few of the options to ``manage.py`` have changed with the addition of fixture |
| support: |
| |
| * There are new ``dumpdata`` and ``loaddata`` commands which, as |
| you might expect, will dump and load data to/from the |
| database. These commands can operate against any of Django's |
| supported serialization formats. |
| |
| * The ``sqlinitialdata`` command has been renamed to ``sqlcustom`` to |
| emphasize that ``loaddata`` should be used for data (and ``sqlcustom`` for |
| other custom SQL -- views, stored procedures, etc.). |
| |
| * The vestigial ``install`` command has been removed. Use ``syncdb``. |
| |
| Backslash escaping changed |
| -------------------------- |
| |
| The Django database API now escapes backslashes given as query parameters. If |
| you have any database API code that matches backslashes, and it was working before |
| (despite the lack of escaping), you'll have to change your code to "unescape" the |
| slashes one level. |
| |
| For example, this used to work:: |
| |
| # Find text containing a single backslash |
| MyModel.objects.filter(text__contains='\\\\') |
| |
| The above is now incorrect, and should be rewritten as:: |
| |
| # Find text containing a single backslash |
| MyModel.objects.filter(text__contains='\\') |
| |
| Removed ENABLE_PSYCO setting |
| ---------------------------- |
| |
| The ``ENABLE_PSYCO`` setting no longer exists. If your settings file includes |
| ``ENABLE_PSYCO`` it will have no effect; to use Psyco_, we recommend |
| writing a middleware class to activate it. |
| |
| .. _psyco: http://psyco.sourceforge.net/ |
| |
| What's new in 0.96? |
| =================== |
| |
| This revision represents over a thousand source commits and over four hundred |
| bug fixes, so we can't possibly catalog all the changes. Here, we describe the |
| most notable changes in this release. |
| |
| New forms library |
| ----------------- |
| |
| ``django.newforms`` is Django's new form-handling library. It's a |
| replacement for ``django.forms``, the old form/manipulator/validation |
| framework. Both APIs are available in 0.96, but over the next two |
| releases we plan to switch completely to the new forms system, and |
| deprecate and remove the old system. |
| |
| There are three elements to this transition: |
| |
| * We've copied the current ``django.forms`` to |
| ``django.oldforms``. This allows you to upgrade your code *now* |
| rather than waiting for the backwards-incompatible change and |
| rushing to fix your code after the fact. Just change your |
| import statements like this:: |
| |
| from django import forms # 0.95-style |
| from django import oldforms as forms # 0.96-style |
| |
| * The next official release of Django will move the current |
| ``django.newforms`` to ``django.forms``. This will be a |
| backwards-incompatible change, and anyone still using the old |
| version of ``django.forms`` at that time will need to change |
| their import statements as described above. |
| |
| * The next release after that will completely remove |
| ``django.oldforms``. |
| |
| Although the ``newforms`` library will continue to evolve, it's ready for use |
| for most common cases. We recommend that anyone new to form handling skip the |
| old forms system and start with the new. |
| |
| For more information about ``django.newforms``, read the `newforms |
| documentation`_. |
| |
| .. _newforms documentation: ../newforms/ |
| |
| URLconf improvements |
| -------------------- |
| |
| You can now use any callable as the callback in URLconfs (previously, only |
| strings that referred to callables were allowed). This allows a much more |
| natural use of URLconfs. For example, this URLconf:: |
| |
| from django.conf.urls.defaults import * |
| |
| urlpatterns = patterns('', |
| ('^myview/$', 'mysite.myapp.views.myview') |
| ) |
| |
| can now be rewritten as:: |
| |
| from django.conf.urls.defaults import * |
| from mysite.myapp.views import myview |
| |
| urlpatterns = patterns('', |
| ('^myview/$', myview) |
| ) |
| |
| One useful application of this can be seen when using decorators; this |
| change allows you to apply decorators to views *in your |
| URLconf*. Thus, you can make a generic view require login very |
| easily:: |
| |
| from django.conf.urls.defaults import * |
| from django.contrib.auth.decorators import login_required |
| from django.views.generic.list_detail import object_list |
| from mysite.myapp.models import MyModel |
| |
| info = { |
| "queryset" : MyModel.objects.all(), |
| } |
| |
| urlpatterns = patterns('', |
| ('^myview/$', login_required(object_list), info) |
| ) |
| |
| Note that both syntaxes (strings and callables) are valid, and will continue to |
| be valid for the foreseeable future. |
| |
| The test framework |
| ------------------ |
| |
| Django now includes a test framework so you can start transmuting fear into |
| boredom (with apologies to Kent Beck). You can write tests based on doctest_ |
| or unittest_ and test your views with a simple test client. |
| |
| There is also new support for "fixtures" -- initial data, stored in any of the |
| supported `serialization formats`_, that will be loaded into your database at the |
| start of your tests. This makes testing with real data much easier. |
| |
| See `the testing documentation`_ for the full details. |
| |
| .. _doctest: http://docs.python.org/lib/module-doctest.html |
| .. _unittest: http://docs.python.org/lib/module-unittest.html |
| .. _the testing documentation: ../testing/ |
| .. _serialization formats: ../serialization/ |
| |
| Improvements to the admin interface |
| ----------------------------------- |
| |
| A small change, but a very nice one: dedicated views for adding and |
| updating users have been added to the admin interface, so you no |
| longer need to worry about working with hashed passwords in the admin. |
| |
| Thanks |
| ====== |
| |
| Since 0.95, a number of people have stepped forward and taken a major |
| new role in Django's development. We'd like to thank these people for |
| all their hard work: |
| |
| * Russell Keith-Magee and Malcolm Tredinnick for their major code |
| contributions. This release wouldn't have been possible without them. |
| |
| * Our new release manager, James Bennett, for his work in getting out |
| 0.95.1, 0.96, and (hopefully) future release. |
| |
| * Our ticket managers Chris Beaven (aka SmileyChris), Simon Greenhill, |
| Michael Radziej, and Gary Wilson. They agreed to take on the monumental |
| task of wrangling our tickets into nicely cataloged submission. Figuring |
| out what to work on is now about a million times easier; thanks again, |
| guys. |
| |
| * Everyone who submitted a bug report, patch or ticket comment. We can't |
| possibly thank everyone by name -- over 200 developers submitted patches |
| that went into 0.96 -- but everyone who's contributed to Django is listed |
| in AUTHORS_. |
| |
| .. _AUTHORS: http://code.djangoproject.com/browser/django/trunk/AUTHORS |