1 ===================================

     2 Django version 0.96.1 release notes

     3 ===================================

     4 

     5 Welcome to Django 0.96.1!

     6 

     7 The primary goal for 0.96 is a cleanup and stabilization of the features

     8 introduced in 0.95. There have been a few small `backwards-incompatible

     9 changes since 0.95`_, but the upgrade process should be fairly simple

    10 and should not require major changes to existing applications.

    11 

    12 However, we're also releasing 0.96 now because we have a set of

    13 backwards-incompatible changes scheduled for the near future. Once

    14 completed, they will involve some code changes for application

    15 developers, so we recommend that you stick with Django 0.96 until the

    16 next official release; then you'll be able to upgrade in one step

    17 instead of needing to make incremental changes to keep up with the

    18 development version of Django.

    19 

    20 Changes since the 0.96 release

    21 ==============================

    22 

    23 This release contains fixes for a security vulnerability discovered after the

    24 initial release of Django 0.96. A bug in the i18n framework could allow an

    25 attacker to send extremely large strings in the Accept-Language header and

    26 cause a denial of service by filling available memory.

    27 

    28 Because this problems wasn't discovered and fixed until after the 0.96

    29 release, it's recommended that you use this release rather than the original

    30 0.96.

    31 

    32 Backwards-incompatible changes since 0.95

    33 =========================================

    34 

    35 The following changes may require you to update your code when you switch from

    36 0.95 to 0.96:

    37 

    38 ``MySQLdb`` version requirement

    39 -------------------------------

    40 

    41 Due to a bug in older versions of the ``MySQLdb`` Python module (which

    42 Django uses to connect to MySQL databases), Django's MySQL backend now

    43 requires version 1.2.1p2 or higher of `MySQLdb`, and will raise

    44 exceptions if you attempt to use an older version.

    45 

    46 If you're currently unable to upgrade your copy of ``MySQLdb`` to meet

    47 this requirement, a separate, backwards-compatible backend, called

    48 "mysql_old", has been added to Django. To use this backend, change

    49 the ``DATABASE_ENGINE`` setting in your Django settings file from

    50 this::

    51 

    52     DATABASE_ENGINE = "mysql"

    53 

    54 to this::

    55 

    56     DATABASE_ENGINE = "mysql_old"

    57 

    58 However, we strongly encourage MySQL users to upgrade to a more recent

    59 version of `MySQLdb` as soon as possible, The "mysql_old" backend is

    60 provided only to ease this transition, and is considered deprecated;

    61 aside from any necessary security fixes, it will not be actively

    62 maintained, and it will be removed in a future release of Django.

    63 

    64 Also, note that some features, like the new ``DATABASE_OPTIONS``

    65 setting (see the `databases documentation`_ for details), are only

    66 available on the "mysql" backend, and will not be made available for

    67 "mysql_old".

    68 

    69 .. _databases documentation: ../databases/

    70 

    71 Database constraint names changed

    72 ---------------------------------

    73 

    74 The format of the constraint names Django generates for foreign key

    75 references have changed slightly. These names are generally only used

    76 when it is not possible to put the reference directly on the affected

    77 column, so they is not always visible.

    78 

    79 The effect of this change is that running ``manage.py reset`` and

    80 similar commands against an existing database may generate SQL with

    81 the new form of constraint name, while the database itself contains

    82 constraints named in the old form; this will cause the database server

    83 to raise an error message about modifying non-existent constraints.

    84 

    85 If you need to work around this, there are two methods available:

    86 

    87     1. Redirect the output of ``manage.py`` to a file, and edit the

    88        generated SQL to use the correct constraint names before

    89        executing it.

    90 

    91     2. Examine the output of ``manage.py sqlall`` to see the new-style

    92        constraint names, and use that as a guide to rename existing

    93        constraints in your database.

    94 

    95 Name changes in ``manage.py``

    96 -----------------------------

    97 

    98 A few of the options to ``manage.py`` have changed with the addition of fixture

    99 support:

   100 

   101     * There are new ``dumpdata`` and ``loaddata`` commands which, as

   102       you might expect, will dump and load data to/from the

   103       database. These commands can operate against any of Django's

   104       supported serialization formats.

   105 

   106     * The ``sqlinitialdata`` command has been renamed to ``sqlcustom`` to

   107       emphasize that ``loaddata`` should be used for data (and ``sqlcustom`` for

   108       other custom SQL -- views, stored procedures, etc.).

   109       

   110     * The vestigial ``install`` command has been removed. Use ``syncdb``.

   111 

   112 Backslash escaping changed

   113 --------------------------

   114 

   115 The Django database API now escapes backslashes given as query parameters. If

   116 you have any database API code that matches backslashes, and it was working before

   117 (despite the lack of escaping), you'll have to change your code to "unescape" the

   118 slashes one level.

   119 

   120 For example, this used to work::

   121 

   122     # Find text containing a single backslash

   123     MyModel.objects.filter(text__contains='\\\\')

   124 

   125 The above is now incorrect, and should be rewritten as::

   126 

   127     # Find text containing a single backslash

   128     MyModel.objects.filter(text__contains='\\')

   129 

   130 Removed ENABLE_PSYCO setting

   131 ----------------------------

   132 

   133 The ``ENABLE_PSYCO`` setting no longer exists. If your settings file includes

   134 ``ENABLE_PSYCO`` it will have no effect; to use Psyco_, we recommend

   135 writing a middleware class to activate it.

   136 

   137 .. _psyco: http://psyco.sourceforge.net/

   138 

   139 What's new in 0.96?

   140 ===================

   141 

   142 This revision represents over a thousand source commits and over four hundred

   143 bug fixes, so we can't possibly catalog all the changes. Here, we describe the

   144 most notable changes in this release.

   145 

   146 New forms library

   147 -----------------

   148 

   149 ``django.newforms`` is Django's new form-handling library. It's a

   150 replacement for ``django.forms``, the old form/manipulator/validation

   151 framework.  Both APIs are available in 0.96, but over the next two

   152 releases we plan to switch completely to the new forms system, and

   153 deprecate and remove the old system.

   154 

   155 There are three elements to this transition:

   156 

   157     * We've copied the current ``django.forms`` to

   158       ``django.oldforms``. This allows you to upgrade your code *now*

   159       rather than waiting for the backwards-incompatible change and

   160       rushing to fix your code after the fact.  Just change your

   161       import statements like this::

   162 

   163           from django import forms             # 0.95-style

   164           from django import oldforms as forms # 0.96-style

   165 

   166     * The next official release of Django will move the current

   167       ``django.newforms`` to ``django.forms``. This will be a

   168       backwards-incompatible change, and anyone still using the old

   169       version of ``django.forms`` at that time will need to change

   170       their import statements as described above.

   171 

   172     * The next release after that will completely remove

   173       ``django.oldforms``.

   174 

   175 Although the ``newforms`` library will continue to evolve, it's ready for use

   176 for most common cases. We recommend that anyone new to form handling skip the

   177 old forms system and start with the new.

   178 

   179 For more information about ``django.newforms``, read the `newforms

   180 documentation`_.

   181 

   182 .. _newforms documentation: ../newforms/

   183 

   184 URLconf improvements

   185 --------------------

   186 

   187 You can now use any callable as the callback in URLconfs (previously, only

   188 strings that referred to callables were allowed). This allows a much more

   189 natural use of URLconfs. For example, this URLconf::

   190 

   191     from django.conf.urls.defaults import *

   192     

   193     urlpatterns = patterns('', 

   194         ('^myview/$', 'mysite.myapp.views.myview')

   195     )

   196     

   197 can now be rewritten as::

   198 

   199     from django.conf.urls.defaults import *

   200     from mysite.myapp.views import myview

   201     

   202     urlpatterns = patterns('', 

   203         ('^myview/$', myview)

   204     )

   205         

   206 One useful application of this can be seen when using decorators; this

   207 change allows you to apply decorators to views *in your

   208 URLconf*. Thus, you can make a generic view require login very

   209 easily::

   210 

   211     from django.conf.urls.defaults import *

   212     from django.contrib.auth.decorators import login_required

   213     from django.views.generic.list_detail import object_list

   214     from mysite.myapp.models import MyModel

   215     

   216     info = {

   217         "queryset" : MyModel.objects.all(),

   218     }

   219     

   220     urlpatterns = patterns('', 

   221         ('^myview/$', login_required(object_list), info)

   222     )

   223 

   224 Note that both syntaxes (strings and callables) are valid, and will continue to

   225 be valid for the foreseeable future.  

   226 

   227 The test framework

   228 ------------------

   229 

   230 Django now includes a test framework so you can start transmuting fear into

   231 boredom (with apologies to Kent Beck). You can write tests based on doctest_

   232 or unittest_ and test your views with a simple test client.

   233 

   234 There is also new support for "fixtures" -- initial data, stored in any of the

   235 supported `serialization formats`_, that will be loaded into your database at the

   236 start of your tests. This makes testing with real data much easier.

   237 

   238 See `the testing documentation`_ for the full details.

   239 

   240 .. _doctest: http://docs.python.org/lib/module-doctest.html

   241 .. _unittest: http://docs.python.org/lib/module-unittest.html

   242 .. _the testing documentation: ../testing/

   243 .. _serialization formats: ../serialization/

   244 

   245 Improvements to the admin interface

   246 -----------------------------------

   247 

   248 A small change, but a very nice one: dedicated views for adding and

   249 updating users have been added to the admin interface, so you no

   250 longer need to worry about working with hashed passwords in the admin.

   251 

   252 Thanks

   253 ======

   254 

   255 Since 0.95, a number of people have stepped forward and taken a major

   256 new role in Django's development. We'd like to thank these people for

   257 all their hard work:

   258 

   259     * Russell Keith-Magee and Malcolm Tredinnick for their major code

   260       contributions. This release wouldn't have been possible without them.

   261       

   262     * Our new release manager, James Bennett, for his work in getting out

   263       0.95.1, 0.96, and (hopefully) future release.

   264       

   265     * Our ticket managers Chris Beaven (aka SmileyChris), Simon Greenhill,

   266       Michael Radziej, and Gary Wilson. They agreed to take on the monumental

   267       task of wrangling our tickets into nicely cataloged submission. Figuring

   268       out what to work on is now about a million times easier; thanks again,

   269       guys.

   270             

   271     * Everyone who submitted a bug report, patch or ticket comment. We can't

   272       possibly thank everyone by name -- over 200 developers submitted patches

   273       that went into 0.96 -- but everyone who's contributed to Django is listed

   274       in AUTHORS_.

   275       

   276 .. _AUTHORS: http://code.djangoproject.com/browser/django/trunk/AUTHORS