0.96.txt 10 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266
  1. .. _releases-0.96:
  2. =================================
  3. Django version 0.96 release notes
  4. =================================
  5. Welcome to Django 0.96!
  6. The primary goal for 0.96 is a cleanup and stabilization of the features
  7. introduced in 0.95. There have been a few small `backwards-incompatible
  8. changes`_ since 0.95, but the upgrade process should be fairly simple
  9. and should not require major changes to existing applications.
  10. However, we're also releasing 0.96 now because we have a set of
  11. backwards-incompatible changes scheduled for the near future. Once
  12. completed, they will involve some code changes for application
  13. developers, so we recommend that you stick with Django 0.96 until the
  14. next official release; then you'll be able to upgrade in one step
  15. instead of needing to make incremental changes to keep up with the
  16. development version of Django.
  17. Backwards-incompatible changes
  18. ==============================
  19. The following changes may require you to update your code when you switch from
  20. 0.95 to 0.96:
  21. ``MySQLdb`` version requirement
  22. -------------------------------
  23. Due to a bug in older versions of the ``MySQLdb`` Python module (which
  24. Django uses to connect to MySQL databases), Django's MySQL backend now
  25. requires version 1.2.1p2 or higher of ``MySQLdb``, and will raise
  26. exceptions if you attempt to use an older version.
  27. If you're currently unable to upgrade your copy of ``MySQLdb`` to meet
  28. this requirement, a separate, backwards-compatible backend, called
  29. "mysql_old", has been added to Django. To use this backend, change
  30. the :setting:`DATABASE_ENGINE` setting in your Django settings file from
  31. this::
  32. DATABASE_ENGINE = "mysql"
  33. to this::
  34. DATABASE_ENGINE = "mysql_old"
  35. However, we strongly encourage MySQL users to upgrade to a more recent
  36. version of ``MySQLdb`` as soon as possible, The "mysql_old" backend is
  37. provided only to ease this transition, and is considered deprecated;
  38. aside from any necessary security fixes, it will not be actively
  39. maintained, and it will be removed in a future release of Django.
  40. Also, note that some features, like the new :setting:`DATABASE_OPTIONS`
  41. setting (see the `databases documentation`_ for details), are only
  42. available on the "mysql" backend, and will not be made available for
  43. "mysql_old".
  44. .. _databases documentation: http://www.djangoproject.com/documentation/0.96/databases/
  45. Database constraint names changed
  46. ---------------------------------
  47. The format of the constraint names Django generates for foreign key
  48. references have changed slightly. These names are generally only used
  49. when it is not possible to put the reference directly on the affected
  50. column, so they are not always visible.
  51. The effect of this change is that running ``manage.py reset`` and
  52. similar commands against an existing database may generate SQL with
  53. the new form of constraint name, while the database itself contains
  54. constraints named in the old form; this will cause the database server
  55. to raise an error message about modifying non-existent constraints.
  56. If you need to work around this, there are two methods available:
  57. 1. Redirect the output of ``manage.py`` to a file, and edit the
  58. generated SQL to use the correct constraint names before
  59. executing it.
  60. 2. Examine the output of ``manage.py sqlall`` to see the new-style
  61. constraint names, and use that as a guide to rename existing
  62. constraints in your database.
  63. Name changes in ``manage.py``
  64. -----------------------------
  65. A few of the options to ``manage.py`` have changed with the addition of fixture
  66. support:
  67. * There are new ``dumpdata`` and ``loaddata`` commands which, as
  68. you might expect, will dump and load data to/from the
  69. database. These commands can operate against any of Django's
  70. supported serialization formats.
  71. * The ``sqlinitialdata`` command has been renamed to ``sqlcustom`` to
  72. emphasize that ``loaddata`` should be used for data (and ``sqlcustom`` for
  73. other custom SQL -- views, stored procedures, etc.).
  74. * The vestigial ``install`` command has been removed. Use ``syncdb``.
  75. Backslash escaping changed
  76. --------------------------
  77. The Django database API now escapes backslashes given as query parameters. If
  78. you have any database API code that matches backslashes, and it was working before
  79. (despite the lack of escaping), you'll have to change your code to "unescape" the
  80. slashes one level.
  81. For example, this used to work::
  82. # Find text containing a single backslash
  83. MyModel.objects.filter(text__contains='\\\\')
  84. The above is now incorrect, and should be rewritten as::
  85. # Find text containing a single backslash
  86. MyModel.objects.filter(text__contains='\\')
  87. Removed ENABLE_PSYCO setting
  88. ----------------------------
  89. The ``ENABLE_PSYCO`` setting no longer exists. If your settings file includes
  90. ``ENABLE_PSYCO`` it will have no effect; to use Psyco_, we recommend
  91. writing a middleware class to activate it.
  92. .. _psyco: http://psyco.sourceforge.net/
  93. What's new in 0.96?
  94. ===================
  95. This revision represents over a thousand source commits and over four hundred
  96. bug fixes, so we can't possibly catalog all the changes. Here, we describe the
  97. most notable changes in this release.
  98. New forms library
  99. -----------------
  100. ``django.newforms`` is Django's new form-handling library. It's a
  101. replacement for ``django.forms``, the old form/manipulator/validation
  102. framework. Both APIs are available in 0.96, but over the next two
  103. releases we plan to switch completely to the new forms system, and
  104. deprecate and remove the old system.
  105. There are three elements to this transition:
  106. * We've copied the current ``django.forms`` to
  107. ``django.oldforms``. This allows you to upgrade your code *now*
  108. rather than waiting for the backwards-incompatible change and
  109. rushing to fix your code after the fact. Just change your
  110. import statements like this::
  111. from django import forms # 0.95-style
  112. from django import oldforms as forms # 0.96-style
  113. * The next official release of Django will move the current
  114. ``django.newforms`` to ``django.forms``. This will be a
  115. backwards-incompatible change, and anyone still using the old
  116. version of ``django.forms`` at that time will need to change
  117. their import statements as described above.
  118. * The next release after that will completely remove
  119. ``django.oldforms``.
  120. Although the ``newforms`` library will continue to evolve, it's ready for use
  121. for most common cases. We recommend that anyone new to form handling skip the
  122. old forms system and start with the new.
  123. For more information about ``django.newforms``, read the `newforms
  124. documentation`_.
  125. .. _newforms documentation: http://www.djangoproject.com/documentation/0.96/newforms/
  126. URLconf improvements
  127. --------------------
  128. You can now use any callable as the callback in URLconfs (previously, only
  129. strings that referred to callables were allowed). This allows a much more
  130. natural use of URLconfs. For example, this URLconf::
  131. from django.conf.urls.defaults import *
  132. urlpatterns = patterns('',
  133. ('^myview/$', 'mysite.myapp.views.myview')
  134. )
  135. can now be rewritten as::
  136. from django.conf.urls.defaults import *
  137. from mysite.myapp.views import myview
  138. urlpatterns = patterns('',
  139. ('^myview/$', myview)
  140. )
  141. One useful application of this can be seen when using decorators; this
  142. change allows you to apply decorators to views *in your
  143. URLconf*. Thus, you can make a generic view require login very
  144. easily::
  145. from django.conf.urls.defaults import *
  146. from django.contrib.auth.decorators import login_required
  147. from django.views.generic.list_detail import object_list
  148. from mysite.myapp.models import MyModel
  149. info = {
  150. "queryset" : MyModel.objects.all(),
  151. }
  152. urlpatterns = patterns('',
  153. ('^myview/$', login_required(object_list), info)
  154. )
  155. Note that both syntaxes (strings and callables) are valid, and will continue to
  156. be valid for the foreseeable future.
  157. The test framework
  158. ------------------
  159. Django now includes a test framework so you can start transmuting fear into
  160. boredom (with apologies to Kent Beck). You can write tests based on doctest_
  161. or unittest_ and test your views with a simple test client.
  162. There is also new support for "fixtures" -- initial data, stored in any of the
  163. supported `serialization formats`_, that will be loaded into your database at the
  164. start of your tests. This makes testing with real data much easier.
  165. See `the testing documentation`_ for the full details.
  166. .. _doctest: http://docs.python.org/library/doctest.html
  167. .. _unittest: http://docs.python.org/library/unittest.html
  168. .. _the testing documentation: http://www.djangoproject.com/documentation/0.96/testing/
  169. .. _serialization formats: http://www.djangoproject.com/documentation/0.96/serialization/
  170. Improvements to the admin interface
  171. -----------------------------------
  172. A small change, but a very nice one: dedicated views for adding and
  173. updating users have been added to the admin interface, so you no
  174. longer need to worry about working with hashed passwords in the admin.
  175. Thanks
  176. ======
  177. Since 0.95, a number of people have stepped forward and taken a major
  178. new role in Django's development. We'd like to thank these people for
  179. all their hard work:
  180. * Russell Keith-Magee and Malcolm Tredinnick for their major code
  181. contributions. This release wouldn't have been possible without them.
  182. * Our new release manager, James Bennett, for his work in getting out
  183. 0.95.1, 0.96, and (hopefully) future release.
  184. * Our ticket managers Chris Beaven (aka SmileyChris), Simon Greenhill,
  185. Michael Radziej, and Gary Wilson. They agreed to take on the monumental
  186. task of wrangling our tickets into nicely cataloged submission. Figuring
  187. out what to work on is now about a million times easier; thanks again,
  188. guys.
  189. * Everyone who submitted a bug report, patch or ticket comment. We can't
  190. possibly thank everyone by name -- over 200 developers submitted patches
  191. that went into 0.96 -- but everyone who's contributed to Django is listed
  192. in AUTHORS_.
  193. .. _AUTHORS: http://code.djangoproject.com/browser/django/trunk/AUTHORS