| 1 |
python-django (1.0~beta2-3) unstable; urgency=low
|
| 2 |
|
| 3 |
The transition from Django 0.96.2 to Django 1.0 means that your Django software
|
| 4 |
will probably have to be updated. A comprehensive list of changes since Django
|
| 5 |
0.96 is available at the Django Wiki[1]. If you are upgrading from 0.95
|
| 6 |
(Sarge), you should refer to this page[2] as well.
|
| 7 |
|
| 8 |
The Debian package now also includes the full Django documentation in HTML
|
| 9 |
format[3]
|
| 10 |
|
| 11 |
The following incomplete list of major changes is taken from the release notes
|
| 12 |
of 1.0alpha1[4], 1.0alpha2[5], 1.0beta1[6] ad 1.0beta2[7]. For more changes
|
| 13 |
see those release notes or [1].
|
| 14 |
|
| 15 |
Refactored admin application (newforms-admin)
|
| 16 |
The Django administrative interface (django.contrib.admin) has been
|
| 17 |
completely refactored; admin definitions are now completely decoupled from
|
| 18 |
model definitions (no more class Admin declaration in models!), rewritten
|
| 19 |
to use Django’s new form-handling library (introduced in the 0.96 release
|
| 20 |
as django.newforms, and now available as simply django.forms) and redesigned
|
| 21 |
with extensibility and customization in mind. Full documentation for the
|
| 22 |
admin application is available online in the official Django
|
| 23 |
documentation[8].
|
| 24 |
|
| 25 |
INSERT/UPDATE distinction
|
| 26 |
Although Django’s default behavior of having a model’s save() method
|
| 27 |
automatically determine whether to perform an INSERT or an UPDATE at
|
| 28 |
the SQL level is suitable for the majority of cases, there are occasional
|
| 29 |
situations where forcing one or the other is useful. As a result, models
|
| 30 |
can now support an additional parameter to save() which can force a specific
|
| 31 |
operation. Consult the database API documentation[9] for details and important
|
| 32 |
notes about appropriate use of this parameter.
|
| 33 |
|
| 34 |
Split CacheMiddleware
|
| 35 |
Django’s CacheMiddleware has been split into three classes: CacheMiddleware
|
| 36 |
itself still exists and retains all of its previous functionality, but it
|
| 37 |
is now built from two separate middleware classes which handle the two parts
|
| 38 |
of caching (inserting into and reading from the cache) separately, offering
|
| 39 |
additional flexibility for situations where combining these functions into a
|
| 40 |
single middleware posed problems. Full details, including updated notes on
|
| 41 |
appropriate use, are in the caching documentation[10].
|
| 42 |
|
| 43 |
Refactored django.contrib.comments
|
| 44 |
As part of a Google Summer of Code project, Thejaswi Puthraya carried out
|
| 45 |
a major rewrite and refactoring of Django’s bundled comment system, greatly
|
| 46 |
increasing its flexibility and customizability. Full documentation[11] is
|
| 47 |
available, as well as an upgrade guide[12] if you were using the previous
|
| 48 |
incarnation of the comments application.
|
| 49 |
|
| 50 |
[1] http://code.djangoproject.com/wiki/BackwardsIncompatibleChanges
|
| 51 |
[2] http://code.djangoproject.com/wiki/OlderBackwardsIncompatibleChanges
|
| 52 |
[3] /usr/share/doc/python-django/html/index.html
|
| 53 |
[4] http://docs.djangoproject.com/en/dev/releases/1.0-alpha-1/#releases-1-0-alpha-1
|
| 54 |
[5] http://docs.djangoproject.com/en/dev/releases/1.0-alpha-2/#releases-1-0-alpha-2
|
| 55 |
[6] http://docs.djangoproject.com/en/dev/releases/1.0-beta/#releases-1-0-beta
|
| 56 |
[7] http://docs.djangoproject.com/en/dev/releases/1.0-beta-2/
|
| 57 |
[8] /usr/share/doc/python-django/html/ref/contrib/admin.html
|
| 58 |
[9] /usr/share/doc/python-django/html/ref/models/index.html
|
| 59 |
[10] /usr/share/doc/python-django/html/topics/cache.html
|
| 60 |
[11] /usr/share/doc/python-django/html/ref/contrib/comments/index.html
|
| 61 |
[12] /usr/share/doc/python-django/html/ref/contrib/comments/upgrade.htm
|
| 62 |
|
| 63 |
-- David Spreen <netzwurm@debian.org> Fri, 28 Aug 2008 09:10:16 -0700
|
Parent Directory
| 
Revision Log