|
1 ======================== |
|
2 Django 1.0 release notes |
|
3 ======================== |
|
4 |
|
5 Welcome to Django 1.0! |
|
6 |
|
7 We've been looking forward to this moment for over three years, and it's finally |
|
8 here. Django 1.0 represents a the largest milestone in Django's development to |
|
9 date: a Web framework that a group of perfectionists can truly be proud of. |
|
10 |
|
11 Django 1.0 represents over three years of community development as an Open |
|
12 Source project. Django's received contributions from hundreds of developers, |
|
13 been translated into fifty languages, and today is used by developers on every |
|
14 continent and in every kind of job. |
|
15 |
|
16 An interesting historical note: when Django was first released in July 2005, the |
|
17 initial released version of Django came from an internal repository at revision |
|
18 number 8825. Django 1.0 represents revision 8961 of our public repository. It |
|
19 seems fitting that our 1.0 release comes at the moment where community |
|
20 contributions overtake those made privately. |
|
21 |
|
22 Stability and forwards-compatibility |
|
23 ==================================== |
|
24 |
|
25 :doc:`The release of Django 1.0 </releases/1.0>` comes with a promise of API |
|
26 stability and forwards-compatibility. In a nutshell, this means that code you |
|
27 develop against Django 1.0 will continue to work against 1.1 unchanged, and you |
|
28 should need to make only minor changes for any 1.X release. |
|
29 |
|
30 See the :doc:`API stability guide </misc/api-stability>` for full details. |
|
31 |
|
32 Backwards-incompatible changes |
|
33 ============================== |
|
34 |
|
35 Django 1.0 has a number of backwards-incompatible changes from Django 0.96. If |
|
36 you have apps written against Django 0.96 that you need to port, see our |
|
37 detailed porting guide: |
|
38 |
|
39 .. toctree:: |
|
40 :maxdepth: 1 |
|
41 |
|
42 1.0-porting-guide |
|
43 |
|
44 A complete list of backwards-incompatible changes can be found at |
|
45 http://code.djangoproject.com/wiki/BackwardsIncompatibleChanges. |
|
46 |
|
47 What's new in Django 1.0 |
|
48 ======================== |
|
49 |
|
50 A *lot*! |
|
51 |
|
52 Since Django 0.96, we've made over 4,000 code commits, fixed more than 2,000 |
|
53 bugs, and edited, added, or removed around 350,000 lines of code. We've also |
|
54 added 40,000 lines of new documentation, and greatly improved what was already |
|
55 there. |
|
56 |
|
57 In fact, new documentation is one of our favorite features of Django 1.0, so we |
|
58 might as well start there. First, there's a new documentation site: |
|
59 |
|
60 http://docs.djangoproject.com/ |
|
61 |
|
62 The documentation has been greatly improved, cleaned up, and generally made |
|
63 awesome. There's now dedicated search, indexes, and more. |
|
64 |
|
65 We can't possibly document everything that's new in 1.0, but the documentation |
|
66 will be your definitive guide. Anywhere you see something like: |
|
67 |
|
68 .. versionadded:: 1.0 |
|
69 This feature is new in Django 1.0 |
|
70 |
|
71 You'll know that you're looking at something new or changed. |
|
72 |
|
73 The other major highlights of Django 1.0 are: |
|
74 |
|
75 Re-factored admin application |
|
76 ----------------------------- |
|
77 |
|
78 The Django administrative interface (``django.contrib.admin``) has been |
|
79 completely refactored; admin definitions are now completely decoupled from model |
|
80 definitions (no more ``class Admin`` declaration in models!), rewritten to use |
|
81 Django's new form-handling library (introduced in the 0.96 release as |
|
82 ``django.newforms``, and now available as simply ``django.forms``) and |
|
83 redesigned with extensibility and customization in mind. Full documentation for |
|
84 the admin application is available online in the official Django documentation: |
|
85 |
|
86 See the :doc:`admin reference </ref/contrib/admin/index>` for details |
|
87 |
|
88 Improved Unicode handling |
|
89 ------------------------- |
|
90 |
|
91 Django's internals have been refactored to use Unicode throughout; this |
|
92 drastically simplifies the task of dealing with non-Western-European content and |
|
93 data in Django. Additionally, utility functions have been provided to ease |
|
94 interoperability with third-party libraries and systems which may or may not |
|
95 handle Unicode gracefully. Details are available in Django's Unicode-handling |
|
96 documentation. |
|
97 |
|
98 See :doc:`/ref/unicode`. |
|
99 |
|
100 An improved ORM |
|
101 --------------- |
|
102 |
|
103 Django's object-relational mapper -- the component which provides the mapping |
|
104 between Django model classes and your database, and which mediates your database |
|
105 queries -- has been dramatically improved by a massive refactoring. For most |
|
106 users of Django this is backwards-compatible; the public-facing API for database |
|
107 querying underwent a few minor changes, but most of the updates took place in |
|
108 the ORM's internals. A guide to the changes, including backwards-incompatible |
|
109 modifications and mentions of new features opened up by this refactoring, is |
|
110 `available on the Django wiki`__. |
|
111 |
|
112 __ http://code.djangoproject.com/wiki/QuerysetRefactorBranch |
|
113 |
|
114 Automatic escaping of template variables |
|
115 ---------------------------------------- |
|
116 |
|
117 To provide improved security against cross-site scripting (XSS) vulnerabilities, |
|
118 Django's template system now automatically escapes the output of variables. This |
|
119 behavior is configurable, and allows both variables and larger template |
|
120 constructs to be marked as safe (requiring no escaping) or unsafe (requiring |
|
121 escaping). A full guide to this feature is in the documentation for the |
|
122 :ttag:`autoescape` tag. |
|
123 |
|
124 ``django.contrib.gis`` (GeoDjango) |
|
125 ---------------------------------- |
|
126 |
|
127 A project over a year in the making, this adds world-class GIS (`Geographic |
|
128 Information Systems`_) support to Django, in the form of a ``contrib`` |
|
129 application. Its documentation is currently being maintained externally, and |
|
130 will be merged into the main Django documentation shortly. Huge thanks go to |
|
131 Justin Bronn, Jeremy Dunck, Brett Hoerner and Travis Pinney for their efforts in |
|
132 creating and completing this feature. |
|
133 |
|
134 See http://geodjango.org/ for details. |
|
135 |
|
136 .. _Geographic Information Systems: http://en.wikipedia.org/wiki/Geographic_information_system |
|
137 |
|
138 Pluggable file storage |
|
139 ---------------------- |
|
140 |
|
141 Django's built-in ``FileField`` and ``ImageField`` now can take advantage of |
|
142 pluggable file-storage backends, allowing extensive customization of where and |
|
143 how uploaded files get stored by Django. For details, see :doc:`the files |
|
144 documentation </topics/files>`; big thanks go to Marty Alchin for putting in the |
|
145 hard work to get this completed. |
|
146 |
|
147 Jython compatibility |
|
148 -------------------- |
|
149 |
|
150 Thanks to a lot of work from Leo Soto during a Google Summer of Code project, |
|
151 Django's codebase has been refactored to remove incompatibilities with |
|
152 `Jython`_, an implementation of Python written in Java, which runs Python code |
|
153 on the Java Virtual Machine. Django is now compatible with the forthcoming |
|
154 Jython 2.5 release. |
|
155 |
|
156 See :doc:`/howto/jython`. |
|
157 |
|
158 .. _Jython: http://www.jython.org/ |
|
159 |
|
160 Generic relations in forms and admin |
|
161 ------------------------------------ |
|
162 |
|
163 Classes are now included in ``django.contrib.contenttypes`` which can be used to |
|
164 support generic relations in both the admin interface and in end-user forms. See |
|
165 :ref:`the documentation for generic relations <generic-relations>` for details. |
|
166 |
|
167 ``INSERT``/``UPDATE`` distinction |
|
168 --------------------------------- |
|
169 |
|
170 Although Django's default behavior of having a model's ``save()`` method |
|
171 automatically determine whether to perform an ``INSERT`` or an ``UPDATE`` at the |
|
172 SQL level is suitable for the majority of cases, there are occasional situations |
|
173 where forcing one or the other is useful. As a result, models can now support an |
|
174 additional parameter to ``save()`` which can force a specific operation. |
|
175 |
|
176 See :ref:`ref-models-force-insert` for details. |
|
177 |
|
178 Split ``CacheMiddleware`` |
|
179 ------------------------- |
|
180 |
|
181 Django's ``CacheMiddleware`` has been split into three classes: |
|
182 ``CacheMiddleware`` itself still exists and retains all of its previous |
|
183 functionality, but it is now built from two separate middleware classes which |
|
184 handle the two parts of caching (inserting into and reading from the cache) |
|
185 separately, offering additional flexibility for situations where combining these |
|
186 functions into a single middleware posed problems. |
|
187 |
|
188 Full details, including updated notes on appropriate use, are in :doc:`the |
|
189 caching documentation </topics/cache>`. |
|
190 |
|
191 Refactored ``django.contrib.comments`` |
|
192 -------------------------------------- |
|
193 |
|
194 As part of a Google Summer of Code project, Thejaswi Puthraya carried out a |
|
195 major rewrite and refactoring of Django's bundled comment system, greatly |
|
196 increasing its flexibility and customizability. :doc:`Full documentation |
|
197 </ref/contrib/comments/index>` is available, as well as :doc:`an upgrade guide |
|
198 </ref/contrib/comments/upgrade>` if you were using the previous incarnation of |
|
199 the comments application. |
|
200 |
|
201 Removal of deprecated features |
|
202 ------------------------------ |
|
203 |
|
204 A number of features and methods which had previously been marked as deprecated, |
|
205 and which were scheduled for removal prior to the 1.0 release, are no longer |
|
206 present in Django. These include imports of the form library from |
|
207 ``django.newforms`` (now located simply at ``django.forms``), the |
|
208 ``form_for_model`` and ``form_for_instance`` helper functions (which have been |
|
209 replaced by ``ModelForm``) and a number of deprecated features which were |
|
210 replaced by the dispatcher, file-uploading and file-storage refactorings |
|
211 introduced in the Django 1.0 alpha releases. |
|
212 |
|
213 Known issues |
|
214 ============ |
|
215 |
|
216 We've done our best to make Django 1.0 as solid as possible, but unfortunately |
|
217 there are a couple of issues that we know about in the release. |
|
218 |
|
219 Multi-table model inheritance with ``to_field`` |
|
220 ----------------------------------------------- |
|
221 |
|
222 If you're using :ref:`multiple table model inheritance |
|
223 <multi-table-inheritance>`, be aware of this caveat: child models using a custom |
|
224 ``parent_link`` and ``to_field`` will cause database integrity errors. A set of |
|
225 models like the following are **not valid**:: |
|
226 |
|
227 class Parent(models.Model): |
|
228 name = models.CharField(max_length=10) |
|
229 other_value = models.IntegerField(unique=True) |
|
230 |
|
231 class Child(Parent): |
|
232 father = models.OneToOneField(Parent, primary_key=True, to_field="other_value", parent_link=True) |
|
233 value = models.IntegerField() |
|
234 |
|
235 This bug will be fixed in the next release of Django. |
|
236 |
|
237 Caveats with support of certain databases |
|
238 ----------------------------------------- |
|
239 |
|
240 Django attempts to support as many features as possible on all database |
|
241 backends. However, not all database backends are alike, and in particular many of the supported database differ greatly from version to version. It's a good idea to checkout our :doc:`notes on supported database </ref/databases>`: |
|
242 |
|
243 - :ref:`mysql-notes` |
|
244 - :ref:`sqlite-notes` |
|
245 - :ref:`oracle-notes` |
|
246 |