-
diff --git a/docs/howto/custom-management-commands.txt b/docs/howto/custom-management-commands.txt
a
|
b
|
|
2 | 2 | Writing custom django-admin commands |
3 | 3 | ==================================== |
4 | 4 | |
5 | | .. versionadded:: 1.0 |
6 | | |
7 | 5 | Applications can register their own actions with ``manage.py``. For example, |
8 | 6 | you might want to add a ``manage.py`` action for a Django app that you're |
9 | 7 | distributing. In this document, we will be building a custom ``closepoll`` |
-
diff --git a/docs/howto/custom-model-fields.txt b/docs/howto/custom-model-fields.txt
a
|
b
|
|
2 | 2 | Writing custom model fields |
3 | 3 | =========================== |
4 | 4 | |
5 | | .. versionadded:: 1.0 |
6 | 5 | .. currentmodule:: django.db.models |
7 | 6 | |
8 | 7 | Introduction |
-
diff --git a/docs/howto/custom-template-tags.txt b/docs/howto/custom-template-tags.txt
a
|
b
|
|
155 | 155 | Filters and auto-escaping |
156 | 156 | ~~~~~~~~~~~~~~~~~~~~~~~~~ |
157 | 157 | |
158 | | .. versionadded:: 1.0 |
159 | | |
160 | 158 | When writing a custom filter, give some thought to how the filter will interact |
161 | 159 | with Django's auto-escaping behavior. Note that three types of strings can be |
162 | 160 | passed around inside the template code: |
… |
… |
|
426 | 424 | Auto-escaping considerations |
427 | 425 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
428 | 426 | |
429 | | .. versionadded:: 1.0 |
430 | | |
431 | 427 | The output from template tags is **not** automatically run through the |
432 | 428 | auto-escaping filters. However, there are still a couple of things you should |
433 | 429 | keep in mind when writing a template tag. |
… |
… |
|
605 | 601 | raise template.TemplateSyntaxError, "%r tag's argument should be in quotes" % tag_name |
606 | 602 | return FormatTimeNode(date_to_be_formatted, format_string[1:-1]) |
607 | 603 | |
608 | | .. versionchanged:: 1.0 |
609 | | Variable resolution has changed in the 1.0 release of Django. ``template.resolve_variable()`` |
610 | | has been deprecated in favor of a new ``template.Variable`` class. |
611 | | |
612 | 604 | You also have to change the renderer to retrieve the actual contents of the |
613 | 605 | ``date_updated`` property of the ``blog_entry`` object. This can be |
614 | 606 | accomplished by using the ``Variable()`` class in ``django.template``. |
-
diff --git a/docs/howto/deployment/modpython.txt b/docs/howto/deployment/modpython.txt
a
|
b
|
|
56 | 56 | Django mod_python handler." It passes the value of :ref:`DJANGO_SETTINGS_MODULE |
57 | 57 | <django-settings-module>` so mod_python knows which settings to use. |
58 | 58 | |
59 | | .. versionadded:: 1.0 |
60 | | The ``PythonOption django.root ...`` is new in this version. |
61 | | |
62 | 59 | Because mod_python does not know we are serving this site from underneath the |
63 | 60 | ``/mysite/`` prefix, this value needs to be passed through to the mod_python |
64 | 61 | handler in Django, via the ``PythonOption django.root ...`` line. The value set |
-
diff --git a/docs/ref/contrib/flatpages.txt b/docs/ref/contrib/flatpages.txt
a
|
b
|
|
17 | 17 | A flatpage can use a custom template or a default, systemwide flatpage |
18 | 18 | template. It can be associated with one, or multiple, sites. |
19 | 19 | |
20 | | .. versionadded:: 1.0 |
21 | | |
22 | | The content field may optionally be left blank if you prefer to put your |
| 20 | The content field may optionally be left blank if you prefer to put your |
23 | 21 | content in a custom template. |
24 | 22 | |
25 | 23 | Here are some examples of flatpages on Django-powered sites: |
… |
… |
|
35 | 33 | 1. Install the :mod:`sites framework <django.contrib.sites>` by adding |
36 | 34 | ``'django.contrib.sites'`` to your :setting:`INSTALLED_APPS` setting, |
37 | 35 | if it's not already in there. |
38 | | |
| 36 | |
39 | 37 | Also make sure you've correctly set :setting:`SITE_ID` to the ID of the |
40 | 38 | site the settings file represents. This will usually be ``1`` (i.e. |
41 | 39 | ``SITE_ID = 1``, but if you're using the sites framework to manage |
42 | 40 | multiple sites, it could be the ID of a different site. |
43 | | |
| 41 | |
44 | 42 | 2. Add ``'django.contrib.flatpages'`` to your :setting:`INSTALLED_APPS` |
45 | 43 | setting. |
46 | | |
| 44 | |
47 | 45 | 3. Add ``'django.contrib.flatpages.middleware.FlatpageFallbackMiddleware'`` |
48 | 46 | to your :setting:`MIDDLEWARE_CLASSES` setting. |
49 | | |
| 47 | |
50 | 48 | 4. Run the command :djadmin:`manage.py syncdb <syncdb>`. |
51 | | |
| 49 | |
52 | 50 | How it works |
53 | 51 | ============ |
54 | 52 | |
… |
… |
|
67 | 65 | |
68 | 66 | * If the flatpage has a custom template, it loads that template. Otherwise, |
69 | 67 | it loads the template :file:`flatpages/default.html`. |
70 | | |
| 68 | |
71 | 69 | * It passes that template a single context variable, :data:`flatpage`, which |
72 | 70 | is the flatpage object. It uses |
73 | 71 | :class:`~django.template.context.RequestContext` in rendering the |
… |
… |
|
94 | 92 | </topics/http/middleware>`. |
95 | 93 | |
96 | 94 | .. admonition:: Ensure that your 404 template works |
97 | | |
| 95 | |
98 | 96 | Note that the |
99 | 97 | :class:`~django.contrib.flatpages.middleware.FlatpageFallbackMiddleware` |
100 | 98 | only steps in once another view has successfully produced a 404 response. |
-
diff --git a/docs/ref/contrib/formtools/form-wizard.txt b/docs/ref/contrib/formtools/form-wizard.txt
a
|
b
|
|
5 | 5 | .. module:: django.contrib.formtools.wizard |
6 | 6 | :synopsis: Splits forms across multiple Web pages. |
7 | 7 | |
8 | | .. versionadded:: 1.0 |
9 | | |
10 | 8 | Django comes with an optional "form wizard" application that splits |
11 | 9 | :doc:`forms </topics/forms/index>` across multiple Web pages. It maintains |
12 | 10 | state in hashed HTML :samp:`<input type="hidden">` fields, and the data isn't |
-
diff --git a/docs/ref/contrib/gis/index.txt b/docs/ref/contrib/gis/index.txt
a
|
b
|
|
4 | 4 | GeoDjango |
5 | 5 | ========= |
6 | 6 | |
7 | | .. versionadded:: 1.0 |
8 | | |
9 | 7 | .. module:: django.contrib.gis |
10 | 8 | :synopsis: Geographic Information System (GIS) extensions for Django |
11 | 9 | |
-
diff --git a/docs/ref/contrib/humanize.txt b/docs/ref/contrib/humanize.txt
a
|
b
|
|
72 | 72 | naturalday |
73 | 73 | ---------- |
74 | 74 | |
75 | | .. versionadded:: 1.0 |
76 | | |
77 | 75 | For dates that are the current day or within one day, return "today", |
78 | 76 | "tomorrow" or "yesterday", as appropriate. Otherwise, format the date using |
79 | 77 | the passed in format string. |
-
diff --git a/docs/ref/contrib/index.txt b/docs/ref/contrib/index.txt
a
|
b
|
|
60 | 60 | comments |
61 | 61 | ======== |
62 | 62 | |
63 | | .. versionchanged:: 1.0 |
64 | | The comments application has been rewriten. See :doc:`/ref/contrib/comments/upgrade` |
65 | | for information on howto upgrade. |
66 | | |
67 | 63 | A simple yet flexible comments system. See :doc:`/ref/contrib/comments/index`. |
68 | 64 | |
69 | 65 | contenttypes |
-
diff --git a/docs/ref/contrib/sitemaps.txt b/docs/ref/contrib/sitemaps.txt
a
|
b
|
|
340 | 340 | Pinging Google via `manage.py` |
341 | 341 | ------------------------------ |
342 | 342 | |
343 | | .. versionadded:: 1.0 |
344 | | |
345 | 343 | Once the sitemaps application is added to your project, you may also |
346 | 344 | ping the Google server's through the command line manage.py interface:: |
347 | 345 | |
-
diff --git a/docs/ref/contrib/sites.txt b/docs/ref/contrib/sites.txt
a
|
b
|
|
228 | 228 | Caching the current ``Site`` object |
229 | 229 | =================================== |
230 | 230 | |
231 | | .. versionadded:: 1.0 |
232 | | |
233 | 231 | As the current site is stored in the database, each call to |
234 | 232 | ``Site.objects.get_current()`` could result in a database query. But Django is a |
235 | 233 | little cleverer than that: on the first request, the current site is cached, and |
… |
… |
|
383 | 381 | |
384 | 382 | .. _requestsite-objects: |
385 | 383 | |
386 | | .. versionadded:: 1.0 |
387 | | |
388 | 384 | Some :doc:`django.contrib </ref/contrib/index>` applications take advantage of |
389 | 385 | the sites framework but are architected in a way that doesn't *require* the |
390 | 386 | sites framework to be installed in your database. (Some people don't want to, or |
-
diff --git a/docs/ref/databases.txt b/docs/ref/databases.txt
a
|
b
|
|
586 | 586 | field would also generate an index, but no tablespace for it is specified, so |
587 | 587 | it would be stored in the model tablespace ``tables`` by default. |
588 | 588 | |
589 | | .. versionadded:: 1.0 |
590 | | |
591 | 589 | Use the :setting:`DEFAULT_TABLESPACE` and :setting:`DEFAULT_INDEX_TABLESPACE` |
592 | 590 | settings to specify default values for the db_tablespace options. |
593 | 591 | These are useful for setting a tablespace for the built-in Django apps and |
-
diff --git a/docs/ref/django-admin.txt b/docs/ref/django-admin.txt
a
|
b
|
|
88 | 88 | |
89 | 89 | .. django-admin:: cleanup |
90 | 90 | |
91 | | .. versionadded:: 1.0 |
92 | | |
93 | 91 | Can be run as a cronjob or directly to clean out old data from the database |
94 | 92 | (only expired sessions at the moment). |
95 | 93 | |
… |
… |
|
98 | 96 | |
99 | 97 | .. django-admin:: compilemessages |
100 | 98 | |
101 | | .. versionchanged:: 1.0 |
102 | | Before 1.0 this was the "bin/compile-messages.py" command. |
103 | | |
104 | 99 | Compiles .po files created with ``makemessages`` to .mo files for use with |
105 | 100 | the builtin gettext support. See :doc:`/topics/i18n/index`. |
106 | 101 | |
… |
… |
|
129 | 124 | |
130 | 125 | .. django-admin:: createsuperuser |
131 | 126 | |
132 | | .. versionadded:: 1.0 |
133 | | |
134 | 127 | Creates a superuser account (a user who has all permissions). This is |
135 | 128 | useful if you need to create an initial superuser account but did not |
136 | 129 | do so during ``syncdb``, or if you need to programmatically generate |
… |
… |
|
220 | 213 | easy for humans to read, so you can use the ``--indent`` option to |
221 | 214 | pretty-print the output with a number of indentation spaces. |
222 | 215 | |
223 | | .. versionadded:: 1.0 |
224 | | |
225 | 216 | The :djadminopt:`--exclude` option may be provided to prevent specific |
226 | 217 | applications from being dumped. |
227 | 218 | |
… |
… |
|
426 | 417 | |
427 | 418 | .. django-admin:: makemessages |
428 | 419 | |
429 | | .. versionchanged:: 1.0 |
430 | | Before 1.0 this was the ``bin/make-messages.py`` command. |
431 | | |
432 | 420 | Runs over the entire source tree of the current directory and pulls out all |
433 | 421 | strings marked for translation. It creates (or updates) a message file in the |
434 | 422 | conf/locale (in the django tree) or locale (for project and application) |
… |
… |
|
831 | 819 | |
832 | 820 | .. django-admin:: testserver |
833 | 821 | |
834 | | .. versionadded:: 1.0 |
835 | | |
836 | 822 | Runs a Django development server (as in ``runserver``) using data from the |
837 | 823 | given fixture(s). |
838 | 824 | |
-
diff --git a/docs/ref/forms/api.txt b/docs/ref/forms/api.txt
a
|
b
|
|
195 | 195 | >>> f.cleaned_data |
196 | 196 | {'cc_myself': True, 'message': u'Hi there', 'sender': u'foo@example.com', 'subject': u'hello'} |
197 | 197 | |
198 | | .. versionchanged:: 1.0 |
199 | | The ``cleaned_data`` attribute was called ``clean_data`` in earlier releases. |
200 | | |
201 | 198 | Note that any text-based field -- such as ``CharField`` or ``EmailField`` -- |
202 | 199 | always cleans the input into a Unicode string. We'll cover the encoding |
203 | 200 | implications later in this document. |
… |
… |
|
667 | 664 | Binding uploaded files to a form |
668 | 665 | -------------------------------- |
669 | 666 | |
670 | | .. versionadded:: 1.0 |
671 | | |
672 | 667 | Dealing with forms that have ``FileField`` and ``ImageField`` fields |
673 | 668 | is a little more complicated than a normal form. |
674 | 669 | |
-
diff --git a/docs/ref/forms/fields.txt b/docs/ref/forms/fields.txt
a
|
b
|
|
230 | 230 | ``error_messages`` |
231 | 231 | ~~~~~~~~~~~~~~~~~~ |
232 | 232 | |
233 | | .. versionadded:: 1.0 |
234 | | |
235 | 233 | .. attribute:: Field.error_messages |
236 | 234 | |
237 | 235 | The ``error_messages`` argument lets you override the default messages that the |
… |
… |
|
303 | 301 | the field has ``required=True``. |
304 | 302 | * Error message keys: ``required`` |
305 | 303 | |
306 | | .. versionchanged:: 1.0 |
307 | | The empty value for a ``CheckboxInput`` (and hence the standard |
308 | | ``BooleanField``) has changed to return ``False`` instead of ``None`` in |
309 | | the Django 1.0. |
310 | | |
311 | 304 | .. note:: |
312 | 305 | |
313 | 306 | Since all ``Field`` subclasses have ``required=True`` by default, the |
… |
… |
|
443 | 436 | '%m/%d/%y %H:%M', # '10/25/06 14:30' |
444 | 437 | '%m/%d/%y', # '10/25/06' |
445 | 438 | |
446 | | .. versionchanged:: 1.0 |
447 | | The ``DateTimeField`` used to use a ``TextInput`` widget by default. This has now changed. |
448 | | |
449 | 439 | ``DecimalField`` |
450 | 440 | ~~~~~~~~~~~~~~~~ |
451 | 441 | |
452 | | .. versionadded:: 1.0 |
453 | | |
454 | 442 | .. class:: DecimalField(**kwargs) |
455 | 443 | |
456 | 444 | * Default widget: ``TextInput`` |
… |
… |
|
503 | 491 | ``FileField`` |
504 | 492 | ~~~~~~~~~~~~~ |
505 | 493 | |
506 | | .. versionadded:: 1.0 |
507 | | |
508 | 494 | .. class:: FileField(**kwargs) |
509 | 495 | |
510 | 496 | * Default widget: ``FileInput`` |
… |
… |
|
523 | 509 | ``FilePathField`` |
524 | 510 | ~~~~~~~~~~~~~~~~~ |
525 | 511 | |
526 | | .. versionadded:: 1.0 |
527 | | |
528 | 512 | .. class:: FilePathField(**kwargs) |
529 | 513 | |
530 | 514 | * Default widget: ``Select`` |
… |
… |
|
569 | 553 | ``ImageField`` |
570 | 554 | ~~~~~~~~~~~~~~ |
571 | 555 | |
572 | | .. versionadded:: 1.0 |
573 | | |
574 | 556 | .. class:: ImageField(**kwargs) |
575 | 557 | |
576 | 558 | * Default widget: ``FileInput`` |
-
diff --git a/docs/ref/forms/widgets.txt b/docs/ref/forms/widgets.txt
a
|
b
|
|
57 | 57 | |
58 | 58 | .. class:: DateTimeInput |
59 | 59 | |
60 | | .. versionadded:: 1.0 |
61 | | |
62 | 60 | Date/time input as a simple text box: ``<input type='text' ...>`` |
63 | 61 | |
64 | 62 | Takes one optional argument: |
-
diff --git a/docs/ref/generic-views.txt b/docs/ref/generic-views.txt
a
|
b
|
|
176 | 176 | specified in ``date_field`` is greater than the current date/time. By |
177 | 177 | default, this is ``False``. |
178 | 178 | |
179 | | .. versionadded:: 1.0 |
180 | | |
181 | 179 | * ``template_object_name``: Designates the name of the template variable |
182 | 180 | to use in the template context. By default, this is ``'latest'``. |
183 | 181 | |
… |
… |
|
202 | 200 | ordered in reverse. This is equivalent to |
203 | 201 | ``queryset.dates(date_field, 'year')[::-1]``. |
204 | 202 | |
205 | | .. versionchanged:: 1.0 |
206 | | The behaviour depending on ``template_object_name`` is new in this version. |
207 | | |
208 | 203 | * ``latest``: The ``num_latest`` objects in the system, ordered descending |
209 | 204 | by ``date_field``. For example, if ``num_latest`` is ``10``, then |
210 | 205 | ``latest`` will be a list of the latest 10 objects in ``queryset``. |
… |
… |
|
374 | 369 | |
375 | 370 | * ``date_list``: A list of ``datetime.date`` objects representing all |
376 | 371 | days that have objects available in the given month, according to |
377 | | ``queryset``, in ascending order. |
| 372 | ``queryset``, in ascending order. |
378 | 373 | |
379 | 374 | * ``month``: A ``datetime.date`` object representing the given month. |
380 | 375 | |
… |
… |
|
721 | 716 | |
722 | 717 | **Template context:** |
723 | 718 | |
724 | | .. versionadded:: 1.0 |
725 | | The ``paginator`` and ``page_obj`` context variables are new. |
726 | | |
727 | 719 | In addition to ``extra_context``, the template's context will be: |
728 | 720 | |
729 | 721 | * ``object_list``: The list of objects. This variable's name depends on the |
… |
… |
|
767 | 759 | For more on pagination, read the :doc:`pagination documentation |
768 | 760 | </topics/pagination>`. |
769 | 761 | |
770 | | .. versionadded:: 1.0 |
771 | | |
772 | 762 | As a special case, you are also permitted to use ``last`` as a value for |
773 | 763 | ``page``:: |
774 | 764 | |
… |
… |
|
853 | 843 | The ``django.views.generic.create_update`` module contains a set of functions |
854 | 844 | for creating, editing and deleting objects. |
855 | 845 | |
856 | | .. versionchanged:: 1.0 |
857 | | |
858 | 846 | ``django.views.generic.create_update.create_object`` and |
859 | 847 | ``django.views.generic.create_update.update_object`` now use the new :doc:`forms |
860 | 848 | library </topics/forms/index>` to build and display the form. |
-
diff --git a/docs/ref/middleware.txt b/docs/ref/middleware.txt
a
|
b
|
|
52 | 52 | you don't have a valid URL pattern for ``foo.com/bar`` but *do* have a |
53 | 53 | valid pattern for ``foo.com/bar/``. |
54 | 54 | |
55 | | .. versionchanged:: 1.0 |
56 | | The behavior of :setting:`APPEND_SLASH` has changed slightly in this |
57 | | version. It didn't used to check whether the pattern was matched in |
58 | | the URLconf. |
59 | | |
60 | 55 | If :setting:`PREPEND_WWW` is ``True``, URLs that lack a leading "www." |
61 | 56 | will be redirected to the same URL with a leading "www." |
62 | 57 | |
… |
… |
|
183 | 178 | |
184 | 179 | .. class:: django.middleware.csrf.CsrfMiddleware |
185 | 180 | |
186 | | .. versionadded:: 1.0 |
187 | | |
188 | 181 | Adds protection against Cross Site Request Forgeries by adding hidden form |
189 | 182 | fields to POST forms and checking requests for the correct value. See the |
190 | 183 | :doc:`Cross Site Request Forgery protection documentation </ref/contrib/csrf>`. |
-
diff --git a/docs/ref/models/fields.txt b/docs/ref/models/fields.txt
a
|
b
|
|
171 | 171 | |
172 | 172 | .. attribute:: Field.db_tablespace |
173 | 173 | |
174 | | .. versionadded:: 1.0 |
175 | | |
176 | 174 | The name of the database tablespace to use for this field's index, if this field |
177 | 175 | is indexed. The default is the project's :setting:`DEFAULT_INDEX_TABLESPACE` |
178 | 176 | setting, if set, or the :attr:`~Field.db_tablespace` of the model, if any. If |
… |
… |
|
425 | 423 | ``DecimalField`` |
426 | 424 | ---------------- |
427 | 425 | |
428 | | .. versionadded:: 1.0 |
429 | | |
430 | 426 | .. class:: DecimalField(max_digits=None, decimal_places=None, [**options]) |
431 | 427 | |
432 | 428 | A fixed-precision decimal number, represented in Python by a |
… |
… |
|
482 | 478 | date/time of the file upload (so that uploaded files don't fill up the given |
483 | 479 | directory). |
484 | 480 | |
485 | | .. versionchanged:: 1.0 |
486 | | |
487 | 481 | This may also be a callable, such as a function, which will be called to |
488 | 482 | obtain the upload path, including the filename. This callable must be able |
489 | 483 | to accept two arguments, and return a Unix-style path (with forward slashes) |
… |
… |
|
512 | 506 | |
513 | 507 | .. attribute:: FileField.storage |
514 | 508 | |
515 | | .. versionadded:: 1.0 |
516 | | |
517 | 509 | Optional. A storage object, which handles the storage and retrieval of your |
518 | 510 | files. See :doc:`/topics/files` for details on how to provide this object. |
519 | 511 | |
… |
… |
|
560 | 552 | root, then somebody could upload a CGI or PHP script and execute that script by |
561 | 553 | visiting its URL on your site. Don't allow that. |
562 | 554 | |
563 | | .. versionadded:: 1.0 |
564 | | The ``max_length`` argument was added in this version. |
565 | | |
566 | 555 | By default, :class:`FileField` instances are |
567 | 556 | created as ``varchar(100)`` columns in your database. As with other fields, you |
568 | 557 | can change the maximum length using the :attr:`~CharField.max_length` argument. |
… |
… |
|
645 | 634 | because the :attr:`~FilePathField.match` applies to the base filename |
646 | 635 | (``foo.gif`` and ``bar.gif``). |
647 | 636 | |
648 | | .. versionadded:: 1.0 |
649 | | The ``max_length`` argument was added in this version. |
650 | | |
651 | 637 | By default, :class:`FilePathField` instances are |
652 | 638 | created as ``varchar(100)`` columns in your database. As with other fields, you |
653 | 639 | can change the maximum length using the :attr:`~CharField.max_length` argument. |
… |
… |
|
657 | 643 | |
658 | 644 | .. class:: FloatField([**options]) |
659 | 645 | |
660 | | .. versionchanged:: 1.0 |
661 | | |
662 | 646 | A floating-point number represented in Python by a ``float`` instance. |
663 | 647 | |
664 | 648 | The admin represents this as an ``<input type="text">`` (a single-line input). |
… |
… |
|
692 | 676 | |
693 | 677 | .. _Python Imaging Library: http://www.pythonware.com/products/pil/ |
694 | 678 | |
695 | | .. versionadded:: 1.0 |
696 | | The ``max_length`` argument was added in this version. |
697 | | |
698 | 679 | By default, :class:`ImageField` instances are created as ``varchar(100)`` |
699 | 680 | columns in your database. As with other fields, you can change the maximum |
700 | 681 | length using the :attr:`~CharField.max_length` argument. |
… |
… |
|
867 | 848 | class Manufacturer(models.Model): |
868 | 849 | # ... |
869 | 850 | |
870 | | .. versionadded:: 1.0 |
871 | | |
872 | 851 | To refer to models defined in another application, you can explicitly specify |
873 | 852 | a model with the full application label. For example, if the ``Manufacturer`` |
874 | 853 | model above is defined in another application called ``production``, you'd |
-
diff --git a/docs/ref/models/instances.txt b/docs/ref/models/instances.txt
a
|
b
|
|
133 | 133 | |
134 | 134 | .. method:: Model.save([force_insert=False, force_update=False, using=DEFAULT_DB_ALIAS]) |
135 | 135 | |
136 | | .. versionadded:: 1.0 |
137 | | The ``force_insert`` and ``force_update`` arguments were added. |
138 | | |
139 | 136 | .. versionadded:: 1.2 |
140 | 137 | The ``using`` argument was added. |
141 | 138 | |
… |
… |
|
168 | 165 | The ``pk`` property |
169 | 166 | ~~~~~~~~~~~~~~~~~~~ |
170 | 167 | |
171 | | .. versionadded:: 1.0 |
172 | | |
173 | 168 | .. attribute:: Model.pk |
174 | 169 | |
175 | 170 | Regardless of whether you define a primary key field yourself, or let Django |
… |
… |
|
278 | 273 | Forcing an INSERT or UPDATE |
279 | 274 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
280 | 275 | |
281 | | .. versionadded:: 1.0 |
282 | | |
283 | 276 | In some rare circumstances, it's necessary to be able to force the ``save()`` |
284 | 277 | method to perform an SQL ``INSERT`` and not fall back to doing an ``UPDATE``. |
285 | 278 | Or vice-versa: update, if possible, but not insert a new row. In these cases |
-
diff --git a/docs/ref/models/options.txt b/docs/ref/models/options.txt
a
|
b
|
|
65 | 65 | |
66 | 66 | .. attribute:: Options.db_tablespace |
67 | 67 | |
68 | | .. versionadded:: 1.0 |
69 | | |
70 | 68 | The name of the database tablespace to use for the model. If the backend doesn't |
71 | 69 | support tablespaces, this option is ignored. |
72 | 70 | |
… |
… |
|
212 | 210 | appropriate ``UNIQUE`` statements are included in the ``CREATE TABLE`` |
213 | 211 | statement). |
214 | 212 | |
215 | | .. versionadded:: 1.0 |
216 | | |
217 | 213 | For convenience, unique_together can be a single list when dealing with a single |
218 | 214 | set of fields:: |
219 | 215 | |
-
diff --git a/docs/ref/models/querysets.txt b/docs/ref/models/querysets.txt
a
|
b
|
|
278 | 278 | ordering may well be exactly what you want to do. Use ordering on multi-valued |
279 | 279 | fields with care and make sure the results are what you expect. |
280 | 280 | |
281 | | .. versionadded:: 1.0 |
282 | | |
283 | 281 | If you don't want any ordering to be applied to a query, not even the default |
284 | 282 | ordering, call ``order_by()`` with no parameters. |
285 | 283 | |
286 | | .. versionadded:: 1.0 |
287 | | |
288 | | The syntax for ordering across related models has changed. See the `Django 0.96 |
289 | | documentation`_ for the old behaviour. |
290 | | |
291 | | .. _Django 0.96 documentation: http://www.djangoproject.com/documentation/0.96/model-api/#floatfield |
292 | | |
293 | 284 | There's no way to specify whether ordering should be case sensitive. With |
294 | 285 | respect to case-sensitivity, Django will order results however your database |
295 | 286 | backend normally orders them. |
… |
… |
|
305 | 296 | |
306 | 297 | .. method:: reverse() |
307 | 298 | |
308 | | .. versionadded:: 1.0 |
309 | | |
310 | 299 | Use the ``reverse()`` method to reverse the order in which a queryset's |
311 | 300 | elements are returned. Calling ``reverse()`` a second time restores the |
312 | 301 | ordering back to the normal direction. |
… |
… |
|
431 | 420 | if the ``extra()`` clause is used after the ``values()``, the |
432 | 421 | fields added by the select will be included automatically. |
433 | 422 | |
434 | | .. versionadded:: 1.0 |
435 | | |
436 | | Previously, it was not possible to pass ``blog_id`` to ``values()`` in the above |
437 | | example, only ``blog``. |
438 | | |
439 | 423 | A ``ValuesQuerySet`` is useful when you know you're only going to need values |
440 | 424 | from a small number of the available fields and you won't need the |
441 | 425 | functionality of a model instance object. It's more efficient to select only |
… |
… |
|
458 | 442 | |
459 | 443 | .. method:: values_list(*fields) |
460 | 444 | |
461 | | .. versionadded:: 1.0 |
462 | | |
463 | 445 | This is similar to ``values()`` except that instead of returning dictionaries, |
464 | 446 | it returns tuples when iterated over. Each tuple contains the value from the |
465 | 447 | respective field passed into the ``values_list()`` call -- so the first item is |
… |
… |
|
524 | 506 | |
525 | 507 | .. method:: none() |
526 | 508 | |
527 | | .. versionadded:: 1.0 |
528 | | |
529 | 509 | Returns an ``EmptyQuerySet`` -- a ``QuerySet`` that always evaluates to |
530 | 510 | an empty list. This can be used in cases where you know that you should |
531 | 511 | return an empty result set and your caller is expecting a ``QuerySet`` |
… |
… |
|
541 | 521 | |
542 | 522 | .. method:: all() |
543 | 523 | |
544 | | .. versionadded:: 1.0 |
545 | | |
546 | 524 | Returns a ''copy'' of the current ``QuerySet`` (or ``QuerySet`` subclass you |
547 | 525 | pass in). This can be useful in some situations where you might want to pass |
548 | 526 | in either a model manager or a ``QuerySet`` and do further filtering on the |
… |
… |
|
656 | 634 | parameter in the same ``select_related()`` call, since they are |
657 | 635 | conflicting options. |
658 | 636 | |
659 | | .. versionadded:: 1.0 |
660 | | |
661 | | Both the ``depth`` argument and the ability to specify field names in the call |
662 | | to ``select_related()`` are new in Django version 1.0. |
663 | | |
664 | 637 | .. versionchanged:: 1.2 |
665 | 638 | |
666 | 639 | You can also refer to the reverse direction of a ``OneToOneFields`` in |
… |
… |
|
733 | 706 | some database backends, such as some MySQL versions, don't support |
734 | 707 | subqueries. |
735 | 708 | |
736 | | .. versionadded:: 1.0 |
737 | | |
738 | 709 | In some rare cases, you might wish to pass parameters to the SQL fragments |
739 | 710 | in ``extra(select=...)``. For this purpose, use the ``select_params`` |
740 | 711 | parameter. Since ``select_params`` is a sequence and the ``select`` |
… |
… |
|
1250 | 1221 | SELECT ... WHERE id = 14; |
1251 | 1222 | SELECT ... WHERE id IS NULL; |
1252 | 1223 | |
1253 | | .. versionchanged:: 1.0 |
1254 | | The semantics of ``id__exact=None`` have changed in Django 1.0. Previously, |
1255 | | it was (intentionally) converted to ``WHERE id = NULL`` at the SQL level, |
1256 | | which would never match anything. It has now been changed to behave the |
1257 | | same as ``id__isnull=True``. |
1258 | | |
1259 | 1224 | .. admonition:: MySQL comparisons |
1260 | 1225 | |
1261 | 1226 | In MySQL, a database table's "collation" setting determines whether |
… |
… |
|
1663 | 1628 | regex |
1664 | 1629 | ~~~~~ |
1665 | 1630 | |
1666 | | .. versionadded:: 1.0 |
1667 | | |
1668 | 1631 | Case-sensitive regular expression match. |
1669 | 1632 | |
1670 | 1633 | The regular expression syntax is that of the database backend in use. |
… |
… |
|
1694 | 1657 | iregex |
1695 | 1658 | ~~~~~~ |
1696 | 1659 | |
1697 | | .. versionadded:: 1.0 |
1698 | | |
1699 | 1660 | Case-insensitive regular expression match. |
1700 | 1661 | |
1701 | 1662 | Example:: |
-
diff --git a/docs/ref/request-response.txt b/docs/ref/request-response.txt
a
|
b
|
|
47 | 47 | |
48 | 48 | .. attribute:: HttpRequest.encoding |
49 | 49 | |
50 | | .. versionadded:: 1.0 |
51 | | |
52 | 50 | A string representing the current encoding used to decode form submission |
53 | 51 | data (or ``None``, which means the ``DEFAULT_CHARSET`` setting is used). |
54 | 52 | You can write to this attribute to change the encoding used when accessing |
… |
… |
|
111 | 109 | ``enctype="multipart/form-data"``. Otherwise, ``FILES`` will be a blank |
112 | 110 | dictionary-like object. |
113 | 111 | |
114 | | .. versionchanged:: 1.0 |
115 | | |
116 | | In previous versions of Django, ``request.FILES`` contained simple ``dict`` |
117 | | objects representing uploaded files. This is no longer true -- files are |
118 | | represented by ``UploadedFile`` objects as described below. |
119 | | |
120 | 112 | These ``UploadedFile`` objects will emulate the old-style ``dict`` |
121 | 113 | interface, but this is deprecated and will be removed in the next release of |
122 | 114 | Django. |
… |
… |
|
189 | 181 | |
190 | 182 | .. method:: HttpRequest.get_host() |
191 | 183 | |
192 | | .. versionadded:: 1.0 |
193 | | |
194 | 184 | Returns the originating host of the request using information from the |
195 | 185 | ``HTTP_X_FORWARDED_HOST`` and ``HTTP_HOST`` headers (in that order). If |
196 | 186 | they don't provide a value, the method uses a combination of |
… |
… |
|
208 | 198 | |
209 | 199 | .. method:: HttpRequest.build_absolute_uri(location) |
210 | 200 | |
211 | | .. versionadded:: 1.0 |
212 | | |
213 | 201 | Returns the absolute URI form of ``location``. If no location is provided, |
214 | 202 | the location will be set to ``request.get_full_path()``. |
215 | 203 | |
… |
… |
|
226 | 214 | |
227 | 215 | .. method:: HttpRequest.is_ajax() |
228 | 216 | |
229 | | .. versionadded:: 1.0 |
230 | | |
231 | 217 | Returns ``True`` if the request was made via an ``XMLHttpRequest``, by |
232 | 218 | checking the ``HTTP_X_REQUESTED_WITH`` header for the string |
233 | 219 | ``'XMLHttpRequest'``. Most modern JavaScript libraries send this header. |
… |
… |
|
478 | 464 | |
479 | 465 | ``status`` is the `HTTP Status code`_ for the response. |
480 | 466 | |
481 | | .. versionadded:: 1.0 |
482 | | |
483 | 467 | ``content_type`` is an alias for ``mimetype``. Historically, this parameter |
484 | 468 | was only called ``mimetype``, but since this is actually the value included |
485 | 469 | in the HTTP ``Content-Type`` header, it can also include the character set |
… |
… |
|
576 | 560 | |
577 | 561 | .. class:: HttpResponseBadRequest |
578 | 562 | |
579 | | .. versionadded:: 1.0 |
580 | | |
581 | 563 | Acts just like :class:`HttpResponse` but uses a 400 status code. |
582 | 564 | |
583 | 565 | .. class:: HttpResponseNotFound |
-
diff --git a/docs/ref/settings.txt b/docs/ref/settings.txt
a
|
b
|
|
538 | 538 | DEBUG_PROPAGATE_EXCEPTIONS |
539 | 539 | -------------------------- |
540 | 540 | |
541 | | .. versionadded:: 1.0 |
542 | | |
543 | 541 | Default: ``False`` |
544 | 542 | |
545 | 543 | If set to True, Django's normal exception handling of view functions |
… |
… |
|
605 | 603 | DEFAULT_INDEX_TABLESPACE |
606 | 604 | ------------------------ |
607 | 605 | |
608 | | .. versionadded:: 1.0 |
609 | | |
610 | 606 | Default: ``''`` (Empty string) |
611 | 607 | |
612 | 608 | Default tablespace to use for indexes on fields that don't specify |
… |
… |
|
617 | 613 | DEFAULT_TABLESPACE |
618 | 614 | ------------------ |
619 | 615 | |
620 | | .. versionadded:: 1.0 |
621 | | |
622 | 616 | Default: ``''`` (Empty string) |
623 | 617 | |
624 | 618 | Default tablespace to use for models that don't specify one, if the |
… |
… |
|
721 | 715 | EMAIL_USE_TLS |
722 | 716 | ------------- |
723 | 717 | |
724 | | .. versionadded:: 1.0 |
725 | | |
726 | 718 | Default: ``False`` |
727 | 719 | |
728 | 720 | Whether to use a TLS (secure) connection when talking to the SMTP server. |
… |
… |
|
732 | 724 | FILE_CHARSET |
733 | 725 | ------------ |
734 | 726 | |
735 | | .. versionadded:: 1.0 |
736 | | |
737 | 727 | Default: ``'utf-8'`` |
738 | 728 | |
739 | 729 | The character encoding used to decode any files read from disk. This includes |
… |
… |
|
744 | 734 | FILE_UPLOAD_HANDLERS |
745 | 735 | -------------------- |
746 | 736 | |
747 | | .. versionadded:: 1.0 |
748 | | |
749 | 737 | Default:: |
750 | 738 | |
751 | 739 | ("django.core.files.uploadhandler.MemoryFileUploadHandler", |
… |
… |
|
758 | 746 | FILE_UPLOAD_MAX_MEMORY_SIZE |
759 | 747 | --------------------------- |
760 | 748 | |
761 | | .. versionadded:: 1.0 |
762 | | |
763 | 749 | Default: ``2621440`` (i.e. 2.5 MB). |
764 | 750 | |
765 | 751 | The maximum size (in bytes) that an upload will be before it gets streamed to |
… |
… |
|
798 | 784 | FILE_UPLOAD_TEMP_DIR |
799 | 785 | -------------------- |
800 | 786 | |
801 | | .. versionadded:: 1.0 |
802 | | |
803 | 787 | Default: ``None`` |
804 | 788 | |
805 | 789 | The directory to store data temporarily while uploading files. If ``None``, |
… |
… |
|
945 | 929 | LANGUAGE_COOKIE_NAME |
946 | 930 | -------------------- |
947 | 931 | |
948 | | .. versionadded:: 1.0 |
949 | | |
950 | 932 | Default: ``'django_language'`` |
951 | 933 | |
952 | 934 | The name of the cookie to use for the language cookie. This can be whatever you |
… |
… |
|
1011 | 993 | LOGIN_REDIRECT_URL |
1012 | 994 | ------------------ |
1013 | 995 | |
1014 | | .. versionadded:: 1.0 |
1015 | | |
1016 | 996 | Default: ``'/accounts/profile/'`` |
1017 | 997 | |
1018 | 998 | The URL where requests are redirected after login when the |
… |
… |
|
1026 | 1006 | LOGIN_URL |
1027 | 1007 | --------- |
1028 | 1008 | |
1029 | | .. versionadded:: 1.0 |
1030 | | |
1031 | 1009 | Default: ``'/accounts/login/'`` |
1032 | 1010 | |
1033 | 1011 | The URL where requests are redirected for login, especially when using the |
… |
… |
|
1038 | 1016 | LOGOUT_URL |
1039 | 1017 | ---------- |
1040 | 1018 | |
1041 | | .. versionadded:: 1.0 |
1042 | | |
1043 | 1019 | Default: ``'/accounts/logout/'`` |
1044 | 1020 | |
1045 | 1021 | LOGIN_URL counterpart. |
… |
… |
|
1304 | 1280 | SESSION_COOKIE_PATH |
1305 | 1281 | ------------------- |
1306 | 1282 | |
1307 | | .. versionadded:: 1.0 |
1308 | | |
1309 | 1283 | Default: ``'/'`` |
1310 | 1284 | |
1311 | 1285 | The path set on the session cookie. This should either match the URL path of your |
… |
… |
|
1332 | 1306 | SESSION_ENGINE |
1333 | 1307 | -------------- |
1334 | 1308 | |
1335 | | .. versionadded:: 1.0 |
1336 | | |
1337 | 1309 | .. versionchanged:: 1.1 |
1338 | 1310 | The ``cached_db`` backend was added |
1339 | 1311 | |
… |
… |
|
1363 | 1335 | SESSION_FILE_PATH |
1364 | 1336 | ----------------- |
1365 | 1337 | |
1366 | | .. versionadded:: 1.0 |
1367 | | |
1368 | 1338 | Default: ``None`` |
1369 | 1339 | |
1370 | 1340 | If you're using file-based session storage, this sets the directory in |
-
diff --git a/docs/ref/templates/api.txt b/docs/ref/templates/api.txt
a
|
b
|
|
426 | 426 | django.core.context_processors.media |
427 | 427 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
428 | 428 | |
429 | | .. versionadded:: 1.0 |
430 | | |
431 | 429 | If :setting:`TEMPLATE_CONTEXT_PROCESSORS` contains this processor, every |
432 | 430 | ``RequestContext`` will contain a variable ``MEDIA_URL``, providing the |
433 | 431 | value of the :setting:`MEDIA_URL` setting. |
-
diff --git a/docs/ref/templates/builtins.txt b/docs/ref/templates/builtins.txt
a
|
b
|
|
19 | 19 | autoescape |
20 | 20 | ~~~~~~~~~~ |
21 | 21 | |
22 | | .. versionadded:: 1.0 |
23 | | |
24 | 22 | Control the current auto-escaping behavior. This tag takes either ``on`` or |
25 | 23 | ``off`` as an argument and that determines whether auto-escaping is in effect |
26 | 24 | inside the block. The block is closed with an ``endautoescape`` ending tag. |
… |
… |
|
72 | 70 | cycle |
73 | 71 | ~~~~~ |
74 | 72 | |
75 | | .. versionchanged:: 1.0 |
76 | | Cycle among the given strings or variables each time this tag is encountered. |
| 73 | Cycle among the given strings or variables each time this tag is encountered. |
77 | 74 | |
78 | 75 | Within a loop, cycles among the given strings each time through the |
79 | 76 | loop:: |
… |
… |
|
239 | 236 | |
240 | 237 | You can loop over a list in reverse by using ``{% for obj in list reversed %}``. |
241 | 238 | |
242 | | .. versionadded:: 1.0 |
243 | | |
244 | 239 | If you need to loop over a list of lists, you can unpack the values |
245 | 240 | in each sub-list into individual variables. For example, if your context |
246 | 241 | contains a list of (x,y) coordinates called ``points``, you could use the |
… |
… |
|
953 | 948 | |
954 | 949 | The template tag will output the string ``/clients/client/123/``. |
955 | 950 | |
956 | | .. versionadded:: 1.0 |
957 | | |
958 | 951 | If you're using :ref:`named URL patterns <naming-url-patterns>`, you can |
959 | 952 | refer to the name of the pattern in the ``url`` tag instead of using the |
960 | 953 | path to the view. |
… |
… |
|
963 | 956 | :exc:`NoReverseMatch` exception raised, which will cause your site to display an |
964 | 957 | error page. |
965 | 958 | |
966 | | .. versionadded:: 1.0 |
967 | | |
968 | 959 | If you'd like to retrieve a URL without displaying it, you can use a slightly |
969 | 960 | different call:: |
970 | 961 | |
… |
… |
|
1026 | 1017 | with |
1027 | 1018 | ~~~~ |
1028 | 1019 | |
1029 | | .. versionadded:: 1.0 |
1030 | | |
1031 | 1020 | Caches a complex variable under a simpler name. This is useful when accessing |
1032 | 1021 | an "expensive" method (e.g., one that hits the database) multiple times. |
1033 | 1022 | |
… |
… |
|
1278 | 1267 | it is safe to use this function even in auto-escaping environments. If you want |
1279 | 1268 | multiple escaping passes to be applied, use the ``force_escape`` filter. |
1280 | 1269 | |
1281 | | .. versionchanged:: 1.0 |
1282 | | Due to auto-escaping, the behavior of this filter has changed slightly. |
1283 | | The replacements are only made once, after |
1284 | | all other filters are applied -- including filters before and after it. |
1285 | | |
1286 | 1270 | .. templatefilter:: escapejs |
1287 | 1271 | |
1288 | 1272 | escapejs |
1289 | 1273 | ~~~~~~~~ |
1290 | 1274 | |
1291 | | .. versionadded:: 1.0 |
1292 | | |
1293 | 1275 | Escapes characters for use in JavaScript strings. This does *not* make the |
1294 | 1276 | string safe for use in HTML, but does protect you from syntax errors when using |
1295 | 1277 | templates to generate JavaScript/JSON. |
… |
… |
|
1333 | 1315 | fix_ampersands |
1334 | 1316 | ~~~~~~~~~~~~~~ |
1335 | 1317 | |
1336 | | .. versionchanged:: 1.0 |
1337 | | This is rarely useful as ampersands are now automatically escaped. See escape_ for more information. |
| 1318 | ..note:: |
| 1319 | |
| 1320 | This is rarely useful as ampersands are automatically escaped. See escape_ for more information. |
1338 | 1321 | |
1339 | 1322 | Replaces ampersands with ``&`` entities. |
1340 | 1323 | |
… |
… |
|
1391 | 1374 | force_escape |
1392 | 1375 | ~~~~~~~~~~~~ |
1393 | 1376 | |
1394 | | .. versionadded:: 1.0 |
1395 | | |
1396 | 1377 | Applies HTML escaping to a string (see the ``escape`` filter for details). |
1397 | 1378 | This filter is applied *immediately* and returns a new, escaped string. This |
1398 | 1379 | is useful in the rare cases where you need multiple escaping or want to apply |
… |
… |
|
1452 | 1433 | last |
1453 | 1434 | ~~~~ |
1454 | 1435 | |
1455 | | .. versionadded:: 1.0 |
1456 | | |
1457 | 1436 | Returns the last item in a list. |
1458 | 1437 | |
1459 | 1438 | For example:: |
… |
… |
|
1918 | 1897 | Recursively takes a self-nested list and returns an HTML unordered list -- |
1919 | 1898 | WITHOUT opening and closing <ul> tags. |
1920 | 1899 | |
1921 | | .. versionchanged:: 1.0 |
1922 | | The format accepted by ``unordered_list`` has changed to be easier to understand. |
1923 | | |
1924 | 1900 | The list is assumed to be in the proper format. For example, if ``var`` contains |
1925 | 1901 | ``['States', ['Kansas', ['Lawrence', 'Topeka'], 'Illinois']]``, then |
1926 | 1902 | ``{{ var|unordered_list }}`` would return:: |
… |
… |
|
1937 | 1913 | </ul> |
1938 | 1914 | </li> |
1939 | 1915 | |
1940 | | Note: the previous more restrictive and verbose format is still supported: |
| 1916 | Note: An older, more restrictive and verbose input format is also supported: |
1941 | 1917 | ``['States', [['Kansas', [['Lawrence', []], ['Topeka', []]]], ['Illinois', []]]]``, |
1942 | 1918 | |
1943 | 1919 | .. templatefilter:: upper |
-
diff --git a/docs/ref/unicode.txt b/docs/ref/unicode.txt
a
|
b
|
|
2 | 2 | Unicode data |
3 | 3 | ============ |
4 | 4 | |
5 | | .. versionadded:: 1.0 |
6 | | |
7 | 5 | Django natively supports Unicode data everywhere. Providing your database can |
8 | 6 | somehow store the data, you can safely pass around Unicode strings to |
9 | 7 | templates, models and the database. |
-
diff --git a/docs/topics/auth.txt b/docs/topics/auth.txt
a
|
b
|
|
190 | 190 | |
191 | 191 | .. method:: models.User.set_unusable_password() |
192 | 192 | |
193 | | .. versionadded:: 1.0 |
194 | | |
195 | 193 | Marks the user as having no password set. This isn't the same as |
196 | 194 | having a blank string for a password. |
197 | 195 | :meth:`~django.contrib.auth.models.User.check_password()` for this user |
… |
… |
|
203 | 201 | |
204 | 202 | .. method:: models.User.has_usable_password() |
205 | 203 | |
206 | | .. versionadded:: 1.0 |
207 | | |
208 | 204 | Returns ``False`` if |
209 | 205 | :meth:`~django.contrib.auth.models.User.set_unusable_password()` has |
210 | 206 | been called for this user. |
… |
… |
|
395 | 391 | only supported on platforms that have the standard Python ``crypt`` module |
396 | 392 | available. |
397 | 393 | |
398 | | .. versionadded:: 1.0 |
399 | | Support for the ``crypt`` module is new in Django 1.0. |
400 | | |
401 | 394 | For example:: |
402 | 395 | |
403 | 396 | sha1$a1976$a36cc8cbf81742a8fb52e221aaeab48ed7f58ab4 |
… |
… |
|
450 | 443 | Creating superusers |
451 | 444 | ------------------- |
452 | 445 | |
453 | | .. versionadded:: 1.0 |
454 | | The ``manage.py createsuperuser`` command is new. |
455 | | |
456 | 446 | :djadmin:`manage.py syncdb <syncdb>` prompts you to create a superuser the |
457 | 447 | first time you run it after adding ``'django.contrib.auth'`` to your |
458 | 448 | :setting:`INSTALLED_APPS`. If you need to create a superuser at a later date, |
… |
… |
|
653 | 643 | Note that :func:`~django.contrib.auth.logout()` doesn't throw any errors if |
654 | 644 | the user wasn't logged in. |
655 | 645 | |
656 | | .. versionchanged:: 1.0 |
657 | | Calling ``logout()`` now cleans session data. |
658 | | |
659 | 646 | When you call :func:`~django.contrib.auth.logout()`, the session data for |
660 | 647 | the current request is completely cleaned out. All existing data is |
661 | 648 | removed. This is to prevent another person from using the same web browser |
-
diff --git a/docs/topics/cache.txt b/docs/topics/cache.txt
a
|
b
|
|
238 | 238 | Using a custom cache backend |
239 | 239 | ---------------------------- |
240 | 240 | |
241 | | .. versionadded:: 1.0 |
242 | | |
243 | 241 | While Django includes support for a number of cache backends out-of-the-box, |
244 | 242 | sometimes you might want to use a customized cache backend. To use an external |
245 | 243 | cache backend with Django, use a Python import path as the scheme portion (the |
… |
… |
|
291 | 289 | The per-site cache |
292 | 290 | ================== |
293 | 291 | |
294 | | .. versionchanged:: 1.0 |
295 | | (previous versions of Django only provided a single ``CacheMiddleware`` instead |
296 | | of the two pieces described below). |
297 | | |
298 | 292 | Once the cache is set up, the simplest way to use caching is to cache your |
299 | 293 | entire site. You'll need to add |
300 | 294 | ``'django.middleware.cache.UpdateCacheMiddleware'`` and |
… |
… |
|
344 | 338 | |
345 | 339 | See :doc:`/topics/http/middleware` for more on middleware. |
346 | 340 | |
347 | | .. versionadded:: 1.0 |
348 | | |
349 | 341 | If a view sets its own cache expiry time (i.e. it has a ``max-age`` section in |
350 | 342 | its ``Cache-Control`` header) then the page will be cached until the expiry |
351 | 343 | time, rather than ``CACHE_MIDDLEWARE_SECONDS``. Using the decorators in |
… |
… |
|
441 | 433 | Template fragment caching |
442 | 434 | ========================= |
443 | 435 | |
444 | | .. versionadded:: 1.0 |
445 | | |
446 | 436 | If you're after even more control, you can also cache template fragments using |
447 | 437 | the ``cache`` template tag. To give your template access to this tag, put |
448 | 438 | ``{% load cache %}`` near the top of your template. |
… |
… |
|
558 | 548 | >>> cache.get('my_key', 'has expired') |
559 | 549 | 'has expired' |
560 | 550 | |
561 | | .. versionadded:: 1.0 |
562 | | |
563 | 551 | To add a key only if it doesn't already exist, use the ``add()`` method. |
564 | 552 | It takes the same parameters as ``set()``, but it will not attempt to |
565 | 553 | update the cache if the key specified is already present:: |
-
diff --git a/docs/topics/db/models.txt b/docs/topics/db/models.txt
a
|
b
|
|
387 | 387 | Extra fields on many-to-many relationships |
388 | 388 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
389 | 389 | |
390 | | .. versionadded:: 1.0 |
391 | | |
392 | 390 | When you're only dealing with simple many-to-many relationships such as |
393 | 391 | mixing and matching pizzas and toppings, a standard :class:`~django.db.models.ManyToManyField` is all you need. However, sometimes |
394 | 392 | you may need to associate data with the relationship between two models. |
… |
… |
|
552 | 550 | |
553 | 551 | .. _One-to-one relationship model example: http://www.djangoproject.com/documentation/models/one_to_one/ |
554 | 552 | |
555 | | .. versionadded:: 1.0 |
556 | | |
557 | 553 | :class:`~django.db.models.OneToOneField` fields also accept one optional argument |
558 | 554 | described in the :ref:`model field reference <ref-onetoone>`. |
559 | 555 | |
… |
… |
|
605 | 601 | Custom field types |
606 | 602 | ------------------ |
607 | 603 | |
608 | | .. versionadded:: 1.0 |
609 | | |
610 | 604 | If one of the existing model fields cannot be used to fit your purposes, or if |
611 | 605 | you wish to take advantage of some less common database column types, you can |
612 | 606 | create your own field class. Full coverage of creating your own fields is |
… |
… |
|
768 | 762 | Model inheritance |
769 | 763 | ================= |
770 | 764 | |
771 | | .. versionadded:: 1.0 |
772 | | |
773 | 765 | Model inheritance in Django works almost identically to the way normal |
774 | 766 | class inheritance works in Python. The only decision you have to make |
775 | 767 | is whether you want the parent models to be models in their own right |
-
diff --git a/docs/topics/db/queries.txt b/docs/topics/db/queries.txt
a
|
b
|
|
437 | 437 | Spanning multi-valued relationships |
438 | 438 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
439 | 439 | |
440 | | .. versionadded:: 1.0 |
441 | | |
442 | 440 | When you are filtering an object based on a ``ManyToManyField`` or a reverse |
443 | 441 | ``ForeignKey``, there are two different sorts of filter you may be |
444 | 442 | interested in. Consider the ``Blog``/``Entry`` relationship (``Blog`` to |
… |
… |
|
766 | 764 | Updating multiple objects at once |
767 | 765 | ================================= |
768 | 766 | |
769 | | .. versionadded:: 1.0 |
770 | | |
771 | 767 | Sometimes you want to set a field to a particular value for all the objects in |
772 | 768 | a ``QuerySet``. You can do this with the ``update()`` method. For example:: |
773 | 769 | |
-
diff --git a/docs/topics/email.txt b/docs/topics/email.txt
a
|
b
|
|
196 | 196 | The EmailMessage class |
197 | 197 | ====================== |
198 | 198 | |
199 | | .. versionadded:: 1.0 |
200 | | |
201 | 199 | Django's :meth:`~django.core.mail.send_mail()` and |
202 | 200 | :meth:`~django.core.mail.send_mass_mail()` functions are actually thin |
203 | 201 | wrappers that make use of the :class:`~django.core.mail.EmailMessage` class. |
-
diff --git a/docs/topics/files.txt b/docs/topics/files.txt
a
|
b
|
|
2 | 2 | Managing files |
3 | 3 | ============== |
4 | 4 | |
5 | | .. versionadded:: 1.0 |
6 | | |
7 | 5 | This document describes Django's file access APIs. |
8 | 6 | |
9 | 7 | By default, Django stores files locally, using the :setting:`MEDIA_ROOT` and |
-
diff --git a/docs/topics/forms/index.txt b/docs/topics/forms/index.txt
a
|
b
|
|
113 | 113 | 3. If the form has been submitted but is invalid, the bound form instance is |
114 | 114 | passed on to the template. |
115 | 115 | |
116 | | .. versionchanged:: 1.0 |
117 | | The ``cleaned_data`` attribute was called ``clean_data`` in earlier releases. |
118 | | |
119 | 116 | The distinction between **bound** and **unbound** forms is important. An unbound |
120 | 117 | form does not have any data associated with it; when rendered to the user, it |
121 | 118 | will be empty or will contain default values. A bound form does have submitted |
-
diff --git a/docs/topics/forms/modelforms.txt b/docs/topics/forms/modelforms.txt
a
|
b
|
|
105 | 105 | ``widget=forms.Textarea`` |
106 | 106 | =============================== ======================================== |
107 | 107 | |
108 | | |
109 | | .. versionadded:: 1.0 |
110 | | The ``FloatField`` form field and ``DecimalField`` model and form fields |
111 | | are new in Django 1.0. |
112 | | |
113 | 108 | .. versionadded:: 1.2 |
114 | 109 | The ``BigIntegerField`` is new in Django 1.2. |
115 | 110 | |
-
diff --git a/docs/topics/http/file-uploads.txt b/docs/topics/http/file-uploads.txt
a
|
b
|
|
4 | 4 | |
5 | 5 | .. currentmodule:: django.core.files |
6 | 6 | |
7 | | .. versionadded:: 1.0 |
8 | | |
9 | 7 | When Django handles a file upload, the file data ends up placed in |
10 | 8 | :attr:`request.FILES <django.http.HttpRequest.FILES>` (for more on the |
11 | 9 | ``request`` object see the documentation for :doc:`request and response objects |
-
diff --git a/docs/topics/http/sessions.txt b/docs/topics/http/sessions.txt
a
|
b
|
|
29 | 29 | Configuring the session engine |
30 | 30 | ============================== |
31 | 31 | |
32 | | .. versionadded:: 1.0 |
33 | | |
34 | 32 | By default, Django stores sessions in your database (using the model |
35 | 33 | ``django.contrib.sessions.models.Session``). Though this is convenient, in |
36 | 34 | some setups it's faster to store session data elsewhere, so Django can be |
… |
… |
|
138 | 136 | |
139 | 137 | * ``clear()`` |
140 | 138 | |
141 | | .. versionadded:: 1.0 |
142 | | ``setdefault()`` and ``clear()`` are new in this version. |
143 | | |
144 | 139 | It also has these methods: |
145 | 140 | |
146 | 141 | * ``flush()`` |
147 | 142 | |
148 | | .. versionadded:: 1.0 |
149 | | |
150 | 143 | Delete the current session data from the session and regenerate the |
151 | 144 | session key value that is sent back to the user in the cookie. This is |
152 | 145 | used if you want to ensure that the previous session data can't be |
… |
… |
|
173 | 166 | |
174 | 167 | * ``set_expiry(value)`` |
175 | 168 | |
176 | | .. versionadded:: 1.0 |
177 | | |
178 | 169 | Sets the expiration time for the session. You can pass a number of |
179 | 170 | different values: |
180 | 171 | |
… |
… |
|
198 | 189 | |
199 | 190 | * ``get_expiry_age()`` |
200 | 191 | |
201 | | .. versionadded:: 1.0 |
202 | | |
203 | 192 | Returns the number of seconds until this session expires. For sessions |
204 | 193 | with no custom expiration (or those set to expire at browser close), this |
205 | 194 | will equal ``settings.SESSION_COOKIE_AGE``. |
206 | 195 | |
207 | 196 | * ``get_expiry_date()`` |
208 | 197 | |
209 | | .. versionadded:: 1.0 |
210 | | |
211 | 198 | Returns the date this session will expire. For sessions with no custom |
212 | 199 | expiration (or those set to expire at browser close), this will equal the |
213 | 200 | date ``settings.SESSION_COOKIE_AGE`` seconds from now. |
214 | 201 | |
215 | 202 | * ``get_expire_at_browser_close()`` |
216 | 203 | |
217 | | .. versionadded:: 1.0 |
218 | | |
219 | 204 | Returns either ``True`` or ``False``, depending on whether the user's |
220 | 205 | session cookie will expire when the user's Web browser is closed. |
221 | 206 | |
… |
… |
|
302 | 287 | Using sessions out of views |
303 | 288 | =========================== |
304 | 289 | |
305 | | .. versionadded:: 1.0 |
306 | | |
307 | 290 | An API is available to manipulate session data outside of a view:: |
308 | 291 | |
309 | 292 | >>> from django.contrib.sessions.backends.db import SessionStore |
… |
… |
|
384 | 367 | her browser. Use this if you want people to have to log in every time they open |
385 | 368 | a browser. |
386 | 369 | |
387 | | .. versionadded:: 1.0 |
388 | | |
389 | 370 | This setting is a global default and can be overwritten at a per-session level |
390 | 371 | by explicitly calling ``request.session.set_expiry()`` as described above in |
391 | 372 | `using sessions in views`_. |
… |
… |
|
415 | 396 | SESSION_ENGINE |
416 | 397 | -------------- |
417 | 398 | |
418 | | .. versionadded:: 1.0 |
419 | | |
420 | 399 | .. versionchanged:: 1.1 |
421 | 400 | The ``cached_db`` backend was added |
422 | 401 | |
… |
… |
|
434 | 413 | SESSION_FILE_PATH |
435 | 414 | ----------------- |
436 | 415 | |
437 | | .. versionadded:: 1.0 |
438 | | |
439 | 416 | Default: ``/tmp/`` |
440 | 417 | |
441 | 418 | If you're using file-based session storage, this sets the directory in |
… |
… |
|
467 | 444 | SESSION_COOKIE_PATH |
468 | 445 | ------------------- |
469 | 446 | |
470 | | .. versionadded:: 1.0 |
471 | | |
472 | 447 | Default: ``'/'`` |
473 | 448 | |
474 | 449 | The path set on the session cookie. This should either match the URL path of |
-
diff --git a/docs/topics/http/shortcuts.txt b/docs/topics/http/shortcuts.txt
a
|
b
|
|
48 | 48 | |
49 | 49 | ``mimetype`` |
50 | 50 | |
51 | | .. versionadded:: 1.0 |
52 | | |
53 | 51 | The MIME type to use for the resulting document. Defaults to the value of |
54 | 52 | the :setting:`DEFAULT_CONTENT_TYPE` setting. |
55 | 53 | |
-
diff --git a/docs/topics/http/urls.txt b/docs/topics/http/urls.txt
a
|
b
|
|
223 | 223 | url |
224 | 224 | --- |
225 | 225 | |
226 | | .. versionadded:: 1.0 |
227 | | |
228 | 226 | .. function:: url(regex, view, kwargs=None, name=None, prefix='') |
229 | 227 | |
230 | 228 | You can use the ``url()`` function, instead of a tuple, as an argument to |
… |
… |
|
634 | 632 | Naming URL patterns |
635 | 633 | =================== |
636 | 634 | |
637 | | .. versionadded:: 1.0 |
638 | | |
639 | 635 | It's fairly common to use the same view function in multiple URL patterns in |
640 | 636 | your URLconf. For example, these two URL patterns both point to the ``archive`` |
641 | 637 | view:: |
-
diff --git a/docs/topics/i18n/deployment.txt b/docs/topics/i18n/deployment.txt
a
|
b
|
|
81 | 81 | |
82 | 82 | * Failing that, it looks for a cookie. |
83 | 83 | |
84 | | .. versionchanged:: 1.0 |
85 | | |
86 | | In Django version 0.96 and before, the cookie's name is hard-coded to |
87 | | ``django_language``. In Django 1,0, The cookie name is set by the |
88 | | ``LANGUAGE_COOKIE_NAME`` setting. (The default name is |
89 | | ``django_language``.) |
| 84 | The name of the cookie used is set by the ``LANGUAGE_COOKIE_NAME`` |
| 85 | setting. (The default name is ``django_language``.) |
90 | 86 | |
91 | 87 | * Failing that, it looks at the ``Accept-Language`` HTTP header. This |
92 | 88 | header is sent by your browser and tells the server which language(s) you |
-
diff --git a/docs/topics/pagination.txt b/docs/topics/pagination.txt
a
|
b
|
|
5 | 5 | .. module:: django.core.paginator |
6 | 6 | :synopsis: Classes to help you easily manage paginated data. |
7 | 7 | |
8 | | .. versionchanged:: 1.0 |
9 | | Pagination facilities have been almost fully reworked. |
10 | | |
11 | 8 | Django provides a few classes that help you manage paginated data -- that is, |
12 | 9 | data that's split across several pages, with "Previous/Next" links. These |
13 | 10 | classes live in :file:`django/core/paginator.py`. |
-
diff --git a/docs/topics/templates.txt b/docs/topics/templates.txt
a
|
b
|
|
390 | 390 | Automatic HTML escaping |
391 | 391 | ======================= |
392 | 392 | |
393 | | .. versionadded:: 1.0 |
394 | | |
395 | 393 | When generating HTML from templates, there's always a risk that a variable will |
396 | 394 | include characters that affect the resulting HTML. For example, consider this |
397 | 395 | template fragment:: |
-
diff --git a/docs/topics/testing.txt b/docs/topics/testing.txt
a
|
b
|
|
256 | 256 | |
257 | 257 | Note that we used ``animals``, not ``myproject.animals``. |
258 | 258 | |
259 | | .. versionadded:: 1.0 |
260 | | You can now choose which test to run. |
261 | | |
262 | 259 | You can be even *more* specific by naming an individual test case. To |
263 | 260 | run a single test case in an application (for example, the |
264 | 261 | ``AnimalTestCase`` described in the "Writing unit tests" section), add |
… |
… |
|
352 | 349 | to make sure that the given user account has sufficient privileges to |
353 | 350 | create a new database on the system. |
354 | 351 | |
355 | | .. versionadded:: 1.0 |
356 | | |
357 | 352 | For fine-grained control over the character encoding of your test |
358 | 353 | database, use the :setting:`TEST_CHARSET` option. If you're using |
359 | 354 | MySQL, you can also use the :setting:`TEST_COLLATION` option to |
… |
… |
|
778 | 773 | |
779 | 774 | .. method:: Client.login(**credentials) |
780 | 775 | |
781 | | .. versionadded:: 1.0 |
782 | | |
783 | 776 | If your site uses Django's :doc:`authentication system</topics/auth>` |
784 | 777 | and you deal with logging in users, you can use the test client's |
785 | 778 | ``login()`` method to simulate the effect of a user logging into the |
… |
… |
|
824 | 817 | |
825 | 818 | .. method:: Client.logout() |
826 | 819 | |
827 | | .. versionadded:: 1.0 |
828 | | |
829 | 820 | If your site uses Django's :doc:`authentication system</topics/auth>`, |
830 | 821 | the ``logout()`` method can be used to simulate the effect of a user |
831 | 822 | logging out of your site. |
… |
… |
|
1037 | 1028 | Default test client |
1038 | 1029 | ~~~~~~~~~~~~~~~~~~~ |
1039 | 1030 | |
1040 | | .. versionadded:: 1.0 |
1041 | | |
1042 | 1031 | .. attribute:: TestCase.client |
1043 | 1032 | |
1044 | 1033 | Every test case in a ``django.test.TestCase`` instance has access to an |
… |
… |
|
1143 | 1132 | URLconf configuration |
1144 | 1133 | ~~~~~~~~~~~~~~~~~~~~~ |
1145 | 1134 | |
1146 | | .. versionadded:: 1.0 |
1147 | | |
1148 | 1135 | .. attribute:: TestCase.urls |
1149 | 1136 | |
1150 | 1137 | If your application provides views, you may want to include tests that use the |
… |
… |
|
1212 | 1199 | Emptying the test outbox |
1213 | 1200 | ~~~~~~~~~~~~~~~~~~~~~~~~ |
1214 | 1201 | |
1215 | | .. versionadded:: 1.0 |
1216 | | |
1217 | 1202 | If you use Django's custom ``TestCase`` class, the test runner will clear the |
1218 | 1203 | contents of the test e-mail outbox at the start of each test case. |
1219 | 1204 | |
… |
… |
|
1222 | 1207 | Assertions |
1223 | 1208 | ~~~~~~~~~~ |
1224 | 1209 | |
1225 | | .. versionadded:: 1.0 |
1226 | | |
1227 | 1210 | .. versionchanged:: 1.2 |
1228 | 1211 | Addded ``msg_prefix`` argument. |
1229 | 1212 | |
… |
… |
|
1293 | 1276 | E-mail services |
1294 | 1277 | --------------- |
1295 | 1278 | |
1296 | | .. versionadded:: 1.0 |
1297 | | |
1298 | 1279 | If any of your Django views send e-mail using :doc:`Django's e-mail |
1299 | 1280 | functionality </topics/email>`, you probably don't want to send e-mail each time |
1300 | 1281 | you run a test using that view. For this reason, Django's test runner |
… |
… |
|
1543 | 1524 | :setting:`NAME` in :setting:`DATABASES` to match the name of the test |
1544 | 1525 | database. |
1545 | 1526 | |
1546 | | .. versionchanged:: 1.0 |
1547 | | ``create_test_db()`` now returns the name of the test database. |
1548 | | |
1549 | 1527 | .. function:: destroy_test_db(old_database_name, verbosity=1) |
1550 | 1528 | |
1551 | 1529 | Destroys the database whose name is in stored in :setting:`NAME` in the |