-
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
|
|
63 | 63 | Django mod_python handler." It passes the value of :ref:`DJANGO_SETTINGS_MODULE |
64 | 64 | <django-settings-module>` so mod_python knows which settings to use. |
65 | 65 | |
66 | | .. versionadded:: 1.0 |
67 | | The ``PythonOption django.root ...`` is new in this version. |
68 | | |
69 | 66 | Because mod_python does not know we are serving this site from underneath the |
70 | 67 | ``/mysite/`` prefix, this value needs to be passed through to the mod_python |
71 | 68 | handler in Django, via the ``PythonOption django.root ...`` line. The value set |
-
diff --git a/docs/intro/tutorial02.txt b/docs/intro/tutorial02.txt
a
|
b
|
|
38 | 38 | need to know is that it maps URL roots to applications. In the end, you |
39 | 39 | should have a ``urls.py`` file that looks like this: |
40 | 40 | |
41 | | .. versionchanged:: 1.1 |
42 | | The method for adding admin urls has changed in Django 1.1. |
43 | | |
44 | 41 | .. parsed-literal:: |
45 | 42 | |
46 | 43 | from django.conf.urls.defaults import * |
-
diff --git a/docs/ref/authbackends.txt b/docs/ref/authbackends.txt
a
|
b
|
|
26 | 26 | |
27 | 27 | .. class:: RemoteUserBackend |
28 | 28 | |
29 | | .. versionadded:: 1.1 |
30 | | |
31 | 29 | Use this backend to take advantage of external-to-Django-handled |
32 | 30 | authentication. It authenticates using usernames passed in |
33 | 31 | :attr:`request.META['REMOTE_USER'] <django.http.HttpRequest.META>`. See |
-
diff --git a/docs/ref/contrib/admin/actions.txt b/docs/ref/contrib/admin/actions.txt
a
|
b
|
|
2 | 2 | Admin actions |
3 | 3 | ============= |
4 | 4 | |
5 | | .. versionadded:: 1.1 |
6 | | |
7 | 5 | .. currentmodule:: django.contrib.admin |
8 | 6 | |
9 | 7 | The basic workflow of Django's admin is, in a nutshell, "select an object, |
-
diff --git a/docs/ref/contrib/admin/index.txt b/docs/ref/contrib/admin/index.txt
a
|
b
|
|
423 | 423 | |
424 | 424 | .. attribute:: ModelAdmin.list_editable |
425 | 425 | |
426 | | .. versionadded:: 1.1 |
427 | | |
428 | 426 | Set ``list_editable`` to a list of field names on the model which will allow |
429 | 427 | editing on the change list page. That is, fields listed in ``list_editable`` |
430 | 428 | will be displayed as form widgets on the change list page, allowing users to |
… |
… |
|
647 | 645 | |
648 | 646 | .. attribute:: ModelAdmin.formfield_overrides |
649 | 647 | |
650 | | .. versionadded:: 1.1 |
651 | | |
652 | 648 | This provides a quick-and-dirty way to override some of the |
653 | 649 | :class:`~django.forms.Field` options for use in the admin. |
654 | 650 | ``formfield_overrides`` is a dictionary mapping a field class to a dict of |
… |
… |
|
689 | 685 | |
690 | 686 | .. attribute:: ModelAdmin.actions |
691 | 687 | |
692 | | .. versionadded:: 1.1 |
693 | | |
694 | 688 | A list of actions to make available on the change list page. See |
695 | 689 | :doc:`/ref/contrib/admin/actions` for details. |
696 | 690 | |
697 | 691 | .. attribute:: ModelAdmin.actions_on_top |
698 | 692 | .. attribute:: ModelAdmin.actions_on_bottom |
699 | 693 | |
700 | | .. versionadded:: 1.1 |
701 | | |
702 | 694 | Controls where on the page the actions bar appears. By default, the admin |
703 | 695 | changelist displays actions at the top of the page (``actions_on_top = True; |
704 | 696 | actions_on_bottom = False``). |
… |
… |
|
797 | 789 | |
798 | 790 | .. method:: ModelAdmin.get_urls(self) |
799 | 791 | |
800 | | .. versionadded:: 1.1 |
801 | | |
802 | 792 | The ``get_urls`` method on a ``ModelAdmin`` returns the URLs to be used for |
803 | 793 | that ModelAdmin in the same way as a URLconf. Therefore you can extend them as |
804 | 794 | documented in :doc:`/topics/http/urls`:: |
… |
… |
|
855 | 845 | |
856 | 846 | .. method:: ModelAdmin.formfield_for_foreignkey(self, db_field, request, **kwargs) |
857 | 847 | |
858 | | .. versionadded:: 1.1 |
859 | | |
860 | 848 | The ``formfield_for_foreignkey`` method on a ``ModelAdmin`` allows you to |
861 | 849 | override the default formfield for a foreign key field. For example, to |
862 | 850 | return a subset of objects for this foreign key field based on the user:: |
… |
… |
|
872 | 860 | |
873 | 861 | .. method:: ModelAdmin.formfield_for_manytomany(self, db_field, request, **kwargs) |
874 | 862 | |
875 | | .. versionadded:: 1.1 |
876 | | |
877 | 863 | Like the ``formfield_for_foreignkey`` method, the ``formfield_for_manytomany`` |
878 | 864 | method can be overridden to change the default formfield for a many to many |
879 | 865 | field. For example, if an owner can own multiple cars and cars can belong |
… |
… |
|
1418 | 1404 | Python class), and register your models and ``ModelAdmin`` subclasses |
1419 | 1405 | with it instead of using the default. |
1420 | 1406 | |
1421 | | .. versionadded:: 1.1 |
1422 | | |
1423 | 1407 | When constructing an instance of an ``AdminSite``, you are able to provide |
1424 | 1408 | a unique instance name using the ``name`` argument to the constructor. This |
1425 | 1409 | instance name is used to identify the instance, especially when |
… |
… |
|
1505 | 1489 | Django-powered Web site. Just create multiple instances of ``AdminSite`` and |
1506 | 1490 | root each one at a different URL. |
1507 | 1491 | |
1508 | | .. versionchanged:: 1.1 |
1509 | | The method for hooking ``AdminSite`` instances into urls has changed in |
1510 | | Django 1.1. |
1511 | | |
1512 | 1492 | In this example, the URLs ``/basic-admin/`` and ``/advanced-admin/`` feature |
1513 | 1493 | separate versions of the admin site -- using the ``AdminSite`` instances |
1514 | 1494 | ``myproject.admin.basic_site`` and ``myproject.admin.advanced_site``, |
… |
… |
|
1531 | 1511 | Adding views to admin sites |
1532 | 1512 | --------------------------- |
1533 | 1513 | |
1534 | | .. versionadded:: 1.1 |
1535 | | |
1536 | 1514 | Just like :class:`ModelAdmin`, :class:`AdminSite` provides a |
1537 | 1515 | :meth:`~django.contrib.admin.ModelAdmin.get_urls()` method |
1538 | 1516 | that can be overridden to define additional views for the site. To add |
… |
… |
|
1552 | 1530 | Reversing Admin URLs |
1553 | 1531 | ==================== |
1554 | 1532 | |
1555 | | .. versionadded:: 1.1 |
1556 | | |
1557 | 1533 | When an :class:`AdminSite` is deployed, the views provided by that site are |
1558 | 1534 | accessible using Django's :ref:`URL reversing system <naming-url-patterns>`. |
1559 | 1535 | |
-
diff --git a/docs/ref/contrib/csrf.txt b/docs/ref/contrib/csrf.txt
a
|
b
|
|
241 | 241 | Exceptions |
242 | 242 | ---------- |
243 | 243 | |
244 | | .. versionadded:: 1.1 |
245 | 244 | .. versionchanged:: 1.2 |
246 | 245 | Import paths for the decorators below were changed. |
247 | 246 | |
-
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 | 20 | The content field may optionally be left blank if you prefer to put your |
23 | 21 | content in a custom template. |
24 | 22 | |
-
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/gdal.txt b/docs/ref/contrib/gis/gdal.txt
a
|
b
|
|
459 | 459 | |
460 | 460 | .. classmethod:: from_bbox(bbox) |
461 | 461 | |
462 | | .. versionadded:: 1.1 |
463 | | |
464 | 462 | Constructs a :class:`Polygon` from the given bounding-box (a 4-tuple). |
465 | 463 | |
466 | 464 | .. method:: __len__ |
… |
… |
|
601 | 599 | |
602 | 600 | .. attribute:: kml |
603 | 601 | |
604 | | .. versionadded:: 1.1 |
605 | | |
606 | 602 | Returns a string representation of this geometry in KML format. |
607 | 603 | |
608 | 604 | .. attribute:: wkb_size |
… |
… |
|
889 | 885 | |
890 | 886 | .. method:: expand_to_include(self, *args) |
891 | 887 | |
892 | | .. versionadded:: 1.1 |
893 | | |
894 | 888 | Coordinate System Objects |
895 | 889 | ========================= |
896 | 890 | |
… |
… |
|
992 | 986 | Import spatial reference from PROJ.4 string. |
993 | 987 | |
994 | 988 | .. method:: import_user_input(user_input) |
995 | | |
996 | | .. versionadded:: 1.1 |
997 | 989 | |
998 | 990 | .. method:: import_wkt(wkt) |
999 | 991 | |
-
diff --git a/docs/ref/contrib/gis/geoquerysets.txt b/docs/ref/contrib/gis/geoquerysets.txt
a
|
b
|
|
835 | 835 | |
836 | 836 | .. method:: GeoQuerySet.snap_to_grid(*args, **kwargs) |
837 | 837 | |
838 | | .. versionadded:: 1.1 |
839 | | |
840 | 838 | Snap all points of the input geometry to the grid. How the |
841 | 839 | geometry is snapped to the grid depends on how many numeric |
842 | 840 | (either float, integer, or long) arguments are given. |
… |
… |
|
957 | 955 | |
958 | 956 | .. method:: GeoQuerySet.geojson(**kwargs) |
959 | 957 | |
960 | | .. versionadded:: 1.1 |
961 | | |
962 | 958 | *Availability*: PostGIS |
963 | 959 | |
964 | 960 | Attaches a ``geojson`` attribute to every model in the queryset that contains the |
… |
… |
|
1102 | 1098 | |
1103 | 1099 | Spatial Aggregates |
1104 | 1100 | ================== |
1105 | | .. versionadded:: 1.1 |
1106 | 1101 | |
1107 | 1102 | Aggregate Methods |
1108 | 1103 | ----------------- |
… |
… |
|
1112 | 1107 | |
1113 | 1108 | .. method:: GeoQuerySet.collect(**kwargs) |
1114 | 1109 | |
1115 | | .. versionadded:: 1.1 |
1116 | | |
1117 | 1110 | *Availability*: PostGIS |
1118 | 1111 | |
1119 | 1112 | Returns a ``GEOMETRYCOLLECTION`` or a ``MULTI`` geometry object from the geometry |
-
diff --git a/docs/ref/contrib/gis/geos.txt b/docs/ref/contrib/gis/geos.txt
a
|
b
|
|
497 | 497 | |
498 | 498 | .. attribute:: GEOSGeometry.prepared |
499 | 499 | |
500 | | .. versionadded:: 1.1 |
501 | | |
502 | 500 | .. note:: |
503 | 501 | |
504 | 502 | Support for prepared geometries requires GEOS 3.1. |
… |
… |
|
593 | 591 | |
594 | 592 | .. classmethod:: from_bbox(bbox) |
595 | 593 | |
596 | | .. versionadded:: 1.1 |
597 | | |
598 | 594 | Returns a polygon object from the given bounding-box, a 4-tuple |
599 | 595 | comprising (xmin, ymin, xmax, ymax). |
600 | 596 | |
… |
… |
|
633 | 629 | |
634 | 630 | .. attribute:: merged |
635 | 631 | |
636 | | .. versionadded:: 1.1 |
637 | | |
638 | 632 | Returns a :class:`LineString` representing the line merge of |
639 | 633 | all the components in this ``MultiLineString``. |
640 | 634 | |
… |
… |
|
655 | 649 | |
656 | 650 | .. attribute:: cascaded_union |
657 | 651 | |
658 | | .. versionadded:: 1.1 |
659 | | |
660 | 652 | Returns a :class:`Polygon` that is the union of all of the component |
661 | 653 | polygons in this collection. The algorithm employed is significantly |
662 | 654 | more efficient (faster) than trying to union the geometries together |
-
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/gis/install.txt b/docs/ref/contrib/gis/install.txt
a
|
b
|
|
356 | 356 | |
357 | 357 | SpatiaLite |
358 | 358 | ---------- |
359 | | .. versionadded:: 1.1 |
360 | 359 | |
361 | 360 | .. note:: |
362 | 361 | |
-
diff --git a/docs/ref/contrib/gis/testing.txt b/docs/ref/contrib/gis/testing.txt
a
|
b
|
|
33 | 33 | ``POSTGIS_TEMPLATE`` |
34 | 34 | ^^^^^^^^^^^^^^^^^^^^ |
35 | 35 | |
36 | | .. versionadded:: 1.1 |
37 | | |
38 | 36 | .. versionchanged:: 1.2 |
39 | 37 | |
40 | 38 | This setting may be used to customize the name of the PostGIS template |
… |
… |
|
53 | 51 | |
54 | 52 | ``POSTGIS_VERSION`` |
55 | 53 | ^^^^^^^^^^^^^^^^^^^ |
56 | | .. versionadded:: 1.1 |
57 | 54 | |
58 | 55 | When GeoDjango's spatial backend initializes on PostGIS, it has to perform |
59 | 56 | a SQL query to determine the version. Setting the version manually |
… |
… |
|
123 | 120 | SpatiaLite |
124 | 121 | ========== |
125 | 122 | |
126 | | .. versionadded:: 1.1 |
127 | | |
128 | 123 | You will need to download the `initialization SQL`__ script for SpatiaLite:: |
129 | 124 | |
130 | 125 | $ wget http://www.gaia-gis.it/spatialite/init_spatialite-2.3.zip |
… |
… |
|
142 | 137 | |
143 | 138 | ``SPATIALITE_SQL`` |
144 | 139 | ^^^^^^^^^^^^^^^^^^ |
145 | | .. versionadded:: 1.1 |
146 | 140 | |
147 | 141 | By default, the GeoDjango test runner looks for the SpatiaLite SQL in the |
148 | 142 | same directory where it was invoked (by default the same directory where |
-
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
|
|
230 | 230 | Caching the current ``Site`` object |
231 | 231 | =================================== |
232 | 232 | |
233 | | .. versionadded:: 1.0 |
234 | | |
235 | 233 | As the current site is stored in the database, each call to |
236 | 234 | ``Site.objects.get_current()`` could result in a database query. But Django is a |
237 | 235 | little cleverer than that: on the first request, the current site is cached, and |
… |
… |
|
385 | 383 | |
386 | 384 | .. _requestsite-objects: |
387 | 385 | |
388 | | .. versionadded:: 1.0 |
389 | | |
390 | 386 | Some :doc:`django.contrib </ref/contrib/index>` applications take advantage of |
391 | 387 | the sites framework but are architected in a way that doesn't *require* the |
392 | 388 | 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
|
|
58 | 58 | Autocommit mode |
59 | 59 | ~~~~~~~~~~~~~~~ |
60 | 60 | |
61 | | .. versionadded:: 1.1 |
62 | | |
63 | 61 | If your application is particularly read-heavy and doesn't make many |
64 | 62 | database writes, the overhead of a constantly open transaction can |
65 | 63 | sometimes be noticeable. For those situations, if you're using the |
… |
… |
|
101 | 99 | Indexes for ``varchar`` and ``text`` columns |
102 | 100 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
103 | 101 | |
104 | | .. versionadded:: 1.1.2 |
105 | | |
106 | 102 | When specifying ``db_index=True`` on your model fields, Django typically |
107 | 103 | outputs a single ``CREATE INDEX`` statement. However, if the database type |
108 | 104 | for the field is either ``varchar`` or ``text`` (e.g., used by ``CharField``, |
… |
… |
|
452 | 448 | Using newer versions of the SQLite DB-API 2.0 driver |
453 | 449 | ---------------------------------------------------- |
454 | 450 | |
455 | | .. versionadded:: 1.1 |
456 | | |
457 | 451 | For versions of Python 2.5 or newer that include ``sqlite3`` in the standard |
458 | 452 | library Django will now use a ``pysqlite2`` interface in preference to |
459 | 453 | ``sqlite3`` if it finds one is available. |
… |
… |
|
605 | 599 | field would also generate an index, but no tablespace for it is specified, so |
606 | 600 | it would be stored in the model tablespace ``tables`` by default. |
607 | 601 | |
608 | | .. versionadded:: 1.0 |
609 | | |
610 | 602 | Use the :setting:`DEFAULT_TABLESPACE` and :setting:`DEFAULT_INDEX_TABLESPACE` |
611 | 603 | settings to specify default values for the db_tablespace options. |
612 | 604 | 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 |
… |
… |
|
226 | 219 | easy for humans to read, so you can use the ``--indent`` option to |
227 | 220 | pretty-print the output with a number of indentation spaces. |
228 | 221 | |
229 | | .. versionadded:: 1.0 |
230 | | |
231 | 222 | The :djadminopt:`--exclude` option may be provided to prevent specific |
232 | 223 | applications from being dumped. |
233 | 224 | |
… |
… |
|
236 | 227 | The :djadminopt:`--exclude` option may also be provided to prevent specific |
237 | 228 | models (specified as in the form of ``appname.ModelName``) from being dumped. |
238 | 229 | |
239 | | .. versionadded:: 1.1 |
240 | | |
241 | 230 | In addition to specifying application names, you can provide a list of |
242 | 231 | individual models, in the form of ``appname.Model``. If you specify a model |
243 | 232 | name to ``dumpdata``, the dumped output will be restricted to that model, |
… |
… |
|
436 | 425 | |
437 | 426 | .. django-admin:: makemessages |
438 | 427 | |
439 | | .. versionchanged:: 1.0 |
440 | | Before 1.0 this was the ``bin/make-messages.py`` command. |
441 | | |
442 | 428 | Runs over the entire source tree of the current directory and pulls out all |
443 | 429 | strings marked for translation. It creates (or updates) a message file in the |
444 | 430 | conf/locale (in the django tree) or locale (for project and application) |
… |
… |
|
839 | 825 | |
840 | 826 | .. django-admin:: testserver |
841 | 827 | |
842 | | .. versionadded:: 1.0 |
843 | | |
844 | 828 | Runs a Django development server (as in ``runserver``) using data from the |
845 | 829 | given fixture(s). |
846 | 830 | |
-
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 |
… |
… |
|
408 | 401 | '%B %d %Y', '%B %d, %Y', # 'October 25 2006', 'October 25, 2006' |
409 | 402 | '%d %B %Y', '%d %B, %Y', # '25 October 2006', '25 October, 2006' |
410 | 403 | |
411 | | .. versionchanged:: 1.1 |
412 | | The ``DateField`` previously used a ``TextInput`` widget by default. It now |
413 | | uses a ``DateInput`` widget. |
414 | | |
415 | 404 | ``DateTimeField`` |
416 | 405 | ~~~~~~~~~~~~~~~~~ |
417 | 406 | |
… |
… |
|
443 | 432 | '%m/%d/%y %H:%M', # '10/25/06 14:30' |
444 | 433 | '%m/%d/%y', # '10/25/06' |
445 | 434 | |
446 | | .. versionchanged:: 1.0 |
447 | | The ``DateTimeField`` used to use a ``TextInput`` widget by default. This has now changed. |
448 | | |
449 | 435 | ``DecimalField`` |
450 | 436 | ~~~~~~~~~~~~~~~~ |
451 | 437 | |
452 | | .. versionadded:: 1.0 |
453 | | |
454 | 438 | .. class:: DecimalField(**kwargs) |
455 | 439 | |
456 | 440 | * Default widget: ``TextInput`` |
… |
… |
|
503 | 487 | ``FileField`` |
504 | 488 | ~~~~~~~~~~~~~ |
505 | 489 | |
506 | | .. versionadded:: 1.0 |
507 | | |
508 | 490 | .. class:: FileField(**kwargs) |
509 | 491 | |
510 | 492 | * Default widget: ``FileInput`` |
… |
… |
|
523 | 505 | ``FilePathField`` |
524 | 506 | ~~~~~~~~~~~~~~~~~ |
525 | 507 | |
526 | | .. versionadded:: 1.0 |
527 | | |
528 | 508 | .. class:: FilePathField(**kwargs) |
529 | 509 | |
530 | 510 | * Default widget: ``Select`` |
… |
… |
|
569 | 549 | ``ImageField`` |
570 | 550 | ~~~~~~~~~~~~~~ |
571 | 551 | |
572 | | .. versionadded:: 1.0 |
573 | | |
574 | 552 | .. class:: ImageField(**kwargs) |
575 | 553 | |
576 | 554 | * Default widget: ``FileInput`` |
… |
… |
|
834 | 812 | If no ``input_time_formats`` argument is provided, the default input formats |
835 | 813 | for ``TimeField`` are used. |
836 | 814 | |
837 | | .. versionchanged:: 1.1 |
838 | | The ``SplitDateTimeField`` previously used two ``TextInput`` widgets by |
839 | | default. The ``input_date_formats`` and ``input_time_formats`` arguments |
840 | | are also new. |
841 | | |
842 | 815 | Fields which handle relationships |
843 | 816 | --------------------------------- |
844 | 817 | |
-
diff --git a/docs/ref/forms/widgets.txt b/docs/ref/forms/widgets.txt
a
|
b
|
|
48 | 48 | |
49 | 49 | .. class:: DateInput |
50 | 50 | |
51 | | .. versionadded:: 1.1 |
52 | | |
53 | 51 | Date input as a simple text box: ``<input type='text' ...>`` |
54 | 52 | |
55 | 53 | Takes one optional argument: |
… |
… |
|
62 | 60 | |
63 | 61 | .. class:: DateTimeInput |
64 | 62 | |
65 | | .. versionadded:: 1.0 |
66 | | |
67 | 63 | Date/time input as a simple text box: ``<input type='text' ...>`` |
68 | 64 | |
69 | 65 | Takes one optional argument: |
… |
… |
|
87 | 83 | |
88 | 84 | If no ``format`` argument is provided, the default format is ``'%H:%M:%S'``. |
89 | 85 | |
90 | | .. versionchanged:: 1.1 |
91 | | The ``format`` argument was not supported in Django 1.0. |
92 | | |
93 | 86 | .. class:: Textarea |
94 | 87 | |
95 | 88 | Text area: ``<textarea>...</textarea>`` |
… |
… |
|
159 | 152 | Takes two optional arguments, ``date_format`` and ``time_format``, which |
160 | 153 | work just like the ``format`` argument for ``DateInput`` and ``TimeInput``. |
161 | 154 | |
162 | | .. versionchanged:: 1.1 |
163 | | The ``date_format`` and ``time_format`` arguments were not supported in Django 1.0. |
164 | | |
165 | 155 | .. class:: SelectDateWidget |
166 | 156 | |
167 | 157 | Wrapper around three select widgets: one each for month, day, and year. |
-
diff --git a/docs/ref/generic-views.txt b/docs/ref/generic-views.txt
a
|
b
|
|
93 | 93 | to the URL. If ``False``, then the query string is discarded. By |
94 | 94 | default, ``query_string`` is ``False``. |
95 | 95 | |
96 | | .. versionadded:: 1.1 |
97 | | The ``permanent`` keyword argument is new in Django 1.1. |
98 | | |
99 | | |
100 | 96 | **Example:** |
101 | 97 | |
102 | 98 | This example issues a permanent redirect (HTTP status code 301) from |
… |
… |
|
182 | 178 | specified in ``date_field`` is greater than the current date/time. By |
183 | 179 | default, this is ``False``. |
184 | 180 | |
185 | | .. versionadded:: 1.0 |
186 | | |
187 | 181 | * ``template_object_name``: Designates the name of the template variable |
188 | 182 | to use in the template context. By default, this is ``'latest'``. |
189 | 183 | |
… |
… |
|
208 | 202 | ordered in reverse. This is equivalent to |
209 | 203 | ``queryset.dates(date_field, 'year')[::-1]``. |
210 | 204 | |
211 | | .. versionchanged:: 1.0 |
212 | | The behaviour depending on ``template_object_name`` is new in this version. |
213 | | |
214 | 205 | * ``latest``: The ``num_latest`` objects in the system, ordered descending |
215 | 206 | by ``date_field``. For example, if ``num_latest`` is ``10``, then |
216 | 207 | ``latest`` will be a list of the latest 10 objects in ``queryset``. |
… |
… |
|
380 | 371 | |
381 | 372 | * ``date_list``: A list of ``datetime.date`` objects representing all |
382 | 373 | days that have objects available in the given month, according to |
383 | | ``queryset``, in ascending order. |
| 374 | ``queryset``, in ascending order. |
384 | 375 | |
385 | 376 | * ``month``: A ``datetime.date`` object representing the given month. |
386 | 377 | |
… |
… |
|
727 | 718 | |
728 | 719 | **Template context:** |
729 | 720 | |
730 | | .. versionadded:: 1.0 |
731 | | The ``paginator`` and ``page_obj`` context variables are new. |
732 | | |
733 | 721 | In addition to ``extra_context``, the template's context will be: |
734 | 722 | |
735 | 723 | * ``object_list``: The list of objects. This variable's name depends on the |
… |
… |
|
773 | 761 | For more on pagination, read the :doc:`pagination documentation |
774 | 762 | </topics/pagination>`. |
775 | 763 | |
776 | | .. versionadded:: 1.0 |
777 | | |
778 | 764 | As a special case, you are also permitted to use ``last`` as a value for |
779 | 765 | ``page``:: |
780 | 766 | |
… |
… |
|
859 | 845 | The ``django.views.generic.create_update`` module contains a set of functions |
860 | 846 | for creating, editing and deleting objects. |
861 | 847 | |
862 | | .. versionchanged:: 1.0 |
863 | | |
864 | 848 | ``django.views.generic.create_update.create_object`` and |
865 | 849 | ``django.views.generic.create_update.update_object`` now use the new :doc:`forms |
866 | 850 | 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 | |
… |
… |
|
120 | 115 | |
121 | 116 | .. class:: django.middleware.http.SetRemoteAddrFromForwardedFor |
122 | 117 | |
123 | | .. versionchanged:: 1.1 |
124 | | |
125 | 118 | This middleware was removed in Django 1.1. See :ref:`the release notes |
126 | 119 | <removed-setremoteaddrfromforwardedfor-middleware>` for details. |
127 | 120 | |
… |
… |
|
183 | 176 | |
184 | 177 | .. class:: django.middleware.csrf.CsrfMiddleware |
185 | 178 | |
186 | | .. versionadded:: 1.0 |
187 | | |
188 | 179 | Adds protection against Cross Site Request Forgeries by adding hidden form |
189 | 180 | fields to POST forms and checking requests for the correct value. See the |
190 | 181 | :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 | |
… |
… |
|
90 | 88 | |
91 | 89 | .. attribute:: Options.managed |
92 | 90 | |
93 | | .. versionadded:: 1.1 |
94 | | |
95 | 91 | Defaults to ``True``, meaning Django will create the appropriate database |
96 | 92 | tables in :djadmin:`syncdb` and remove them as part of a :djadmin:`reset` |
97 | 93 | management command. That is, Django *manages* the database tables' lifecycles. |
… |
… |
|
193 | 189 | |
194 | 190 | .. attribute:: Options.proxy |
195 | 191 | |
196 | | .. versionadded:: 1.1 |
197 | | |
198 | 192 | If set to ``True``, a model which subclasses another model will be treated as |
199 | 193 | a :ref:`proxy model <proxy-models>`. |
200 | 194 | |
… |
… |
|
212 | 206 | appropriate ``UNIQUE`` statements are included in the ``CREATE TABLE`` |
213 | 207 | statement). |
214 | 208 | |
215 | | .. versionadded:: 1.0 |
216 | | |
217 | 209 | For convenience, unique_together can be a single list when dealing with a single |
218 | 210 | set of fields:: |
219 | 211 | |
-
diff --git a/docs/ref/models/querysets.txt b/docs/ref/models/querysets.txt
a
|
b
|
|
185 | 185 | |
186 | 186 | .. method:: annotate(*args, **kwargs) |
187 | 187 | |
188 | | .. versionadded:: 1.1 |
189 | | |
190 | 188 | Annotates each object in the ``QuerySet`` with the provided list of |
191 | 189 | aggregate values (averages, sums, etc) that have been computed over |
192 | 190 | the objects that are related to the objects in the ``QuerySet``. |
… |
… |
|
278 | 276 | ordering may well be exactly what you want to do. Use ordering on multi-valued |
279 | 277 | fields with care and make sure the results are what you expect. |
280 | 278 | |
281 | | .. versionadded:: 1.0 |
282 | | |
283 | 279 | If you don't want any ordering to be applied to a query, not even the default |
284 | 280 | ordering, call ``order_by()`` with no parameters. |
285 | 281 | |
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 | 282 | There's no way to specify whether ordering should be case sensitive. With |
294 | 283 | respect to case-sensitivity, Django will order results however your database |
295 | 284 | backend normally orders them. |
296 | 285 | |
297 | | .. versionadded:: 1.1 |
298 | | |
299 | 286 | You can tell if a query is ordered or not by checking the |
300 | 287 | :attr:`QuerySet.ordered` attribute, which will be ``True`` if the |
301 | 288 | ``QuerySet`` has been ordered in any way. |
… |
… |
|
305 | 292 | |
306 | 293 | .. method:: reverse() |
307 | 294 | |
308 | | .. versionadded:: 1.0 |
309 | | |
310 | 295 | Use the ``reverse()`` method to reverse the order in which a queryset's |
311 | 296 | elements are returned. Calling ``reverse()`` a second time restores the |
312 | 297 | ordering back to the normal direction. |
… |
… |
|
431 | 416 | if the ``extra()`` clause is used after the ``values()``, the |
432 | 417 | fields added by the select will be included automatically. |
433 | 418 | |
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 | 419 | A ``ValuesQuerySet`` is useful when you know you're only going to need values |
440 | 420 | from a small number of the available fields and you won't need the |
441 | 421 | functionality of a model instance object. It's more efficient to select only |
… |
… |
|
458 | 438 | |
459 | 439 | .. method:: values_list(*fields) |
460 | 440 | |
461 | | .. versionadded:: 1.0 |
462 | | |
463 | 441 | This is similar to ``values()`` except that instead of returning dictionaries, |
464 | 442 | it returns tuples when iterated over. Each tuple contains the value from the |
465 | 443 | respective field passed into the ``values_list()`` call -- so the first item is |
… |
… |
|
524 | 502 | |
525 | 503 | .. method:: none() |
526 | 504 | |
527 | | .. versionadded:: 1.0 |
528 | | |
529 | 505 | Returns an ``EmptyQuerySet`` -- a ``QuerySet`` that always evaluates to |
530 | 506 | an empty list. This can be used in cases where you know that you should |
531 | 507 | return an empty result set and your caller is expecting a ``QuerySet`` |
… |
… |
|
541 | 517 | |
542 | 518 | .. method:: all() |
543 | 519 | |
544 | | .. versionadded:: 1.0 |
545 | | |
546 | 520 | Returns a ''copy'' of the current ``QuerySet`` (or ``QuerySet`` subclass you |
547 | 521 | pass in). This can be useful in some situations where you might want to pass |
548 | 522 | in either a model manager or a ``QuerySet`` and do further filtering on the |
… |
… |
|
656 | 630 | parameter in the same ``select_related()`` call, since they are |
657 | 631 | conflicting options. |
658 | 632 | |
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 | 633 | .. versionchanged:: 1.2 |
665 | 634 | |
666 | 635 | You can also refer to the reverse direction of a ``OneToOneFields`` in |
… |
… |
|
733 | 702 | some database backends, such as some MySQL versions, don't support |
734 | 703 | subqueries. |
735 | 704 | |
736 | | .. versionadded:: 1.0 |
737 | | |
738 | 705 | In some rare cases, you might wish to pass parameters to the SQL fragments |
739 | 706 | in ``extra(select=...)``. For this purpose, use the ``select_params`` |
740 | 707 | parameter. Since ``select_params`` is a sequence and the ``select`` |
… |
… |
|
840 | 807 | |
841 | 808 | .. method:: defer(*fields) |
842 | 809 | |
843 | | .. versionadded:: 1.1 |
844 | | |
845 | 810 | In some complex data-modeling situations, your models might contain a lot of |
846 | 811 | fields, some of which could contain a lot of data (for example, text fields), |
847 | 812 | or require expensive processing to convert them to Python objects. If you are |
… |
… |
|
900 | 865 | |
901 | 866 | .. method:: only(*fields) |
902 | 867 | |
903 | | .. versionadded:: 1.1 |
904 | | |
905 | 868 | The ``only()`` method is more or less the opposite of ``defer()``. You |
906 | 869 | call it with the fields that should *not* be deferred when retrieving a model. |
907 | 870 | If you have a model where almost all the fields need to be deferred, using |
… |
… |
|
1176 | 1139 | |
1177 | 1140 | .. method:: aggregate(*args, **kwargs) |
1178 | 1141 | |
1179 | | .. versionadded:: 1.1 |
1180 | | |
1181 | 1142 | Returns a dictionary of aggregate values (averages, sums, etc) calculated |
1182 | 1143 | over the ``QuerySet``. Each argument to ``aggregate()`` specifies |
1183 | 1144 | a value that will be included in the dictionary that is returned. |
… |
… |
|
1250 | 1211 | SELECT ... WHERE id = 14; |
1251 | 1212 | SELECT ... WHERE id IS NULL; |
1252 | 1213 | |
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 | 1214 | .. admonition:: MySQL comparisons |
1260 | 1215 | |
1261 | 1216 | In MySQL, a database table's "collation" setting determines whether |
… |
… |
|
1362 | 1317 | inner_q = Blog.objects.filter(name__contains='Cheddar').values('pk').query |
1363 | 1318 | entries = Entry.objects.filter(blog__in=inner_q) |
1364 | 1319 | |
1365 | | |
1366 | | .. versionchanged:: 1.1 |
1367 | | In Django 1.0, only the latter piece of code is valid. |
1368 | | |
1369 | 1320 | This second form is a bit less readable and unnatural to write, since it |
1370 | 1321 | accesses the internal ``query`` attribute and requires a ``ValuesQuerySet``. |
1371 | 1322 | If your code doesn't require compatibility with Django 1.0, use the first |
… |
… |
|
1603 | 1554 | week_day |
1604 | 1555 | ~~~~~~~~ |
1605 | 1556 | |
1606 | | .. versionadded:: 1.1 |
1607 | | |
1608 | 1557 | For date/datetime fields, a 'day of the week' match. |
1609 | 1558 | |
1610 | 1559 | Takes an integer value representing the day of week from 1 (Sunday) to 7 |
… |
… |
|
1663 | 1612 | regex |
1664 | 1613 | ~~~~~ |
1665 | 1614 | |
1666 | | .. versionadded:: 1.0 |
1667 | | |
1668 | 1615 | Case-sensitive regular expression match. |
1669 | 1616 | |
1670 | 1617 | The regular expression syntax is that of the database backend in use. |
… |
… |
|
1694 | 1641 | iregex |
1695 | 1642 | ~~~~~~ |
1696 | 1643 | |
1697 | | .. versionadded:: 1.0 |
1698 | | |
1699 | 1644 | Case-insensitive regular expression match. |
1700 | 1645 | |
1701 | 1646 | Example:: |
… |
… |
|
1717 | 1662 | Aggregation Functions |
1718 | 1663 | --------------------- |
1719 | 1664 | |
1720 | | .. versionadded:: 1.1 |
1721 | | |
1722 | 1665 | Django provides the following aggregation functions in the |
1723 | 1666 | ``django.db.models`` module. For details on how to use these |
1724 | 1667 | aggregate functions, see |
-
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. |
… |
… |
|
434 | 420 | >>> response = HttpResponse() |
435 | 421 | >>> response['Cache-Control'] = 'no-cache' |
436 | 422 | |
437 | | .. versionadded:: 1.1 |
438 | | |
439 | 423 | HTTP headers cannot contain newlines. An attempt to set a header containing a |
440 | 424 | newline character (CR or LF) will raise ``BadHeaderError`` |
441 | 425 | |
… |
… |
|
478 | 462 | |
479 | 463 | ``status`` is the `HTTP Status code`_ for the response. |
480 | 464 | |
481 | | .. versionadded:: 1.0 |
482 | | |
483 | 465 | ``content_type`` is an alias for ``mimetype``. Historically, this parameter |
484 | 466 | was only called ``mimetype``, but since this is actually the value included |
485 | 467 | in the HTTP ``Content-Type`` header, it can also include the character set |
… |
… |
|
576 | 558 | |
577 | 559 | .. class:: HttpResponseBadRequest |
578 | 560 | |
579 | | .. versionadded:: 1.0 |
580 | | |
581 | 561 | Acts just like :class:`HttpResponse` but uses a 400 status code. |
582 | 562 | |
583 | 563 | .. 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 | | .. versionchanged:: 1.1 |
1338 | | The ``cached_db`` backend was added |
1339 | | |
1340 | 1309 | Default: ``django.contrib.sessions.backends.db`` |
1341 | 1310 | |
1342 | 1311 | Controls where Django stores session data. Valid values are: |
… |
… |
|
1363 | 1332 | SESSION_FILE_PATH |
1364 | 1333 | ----------------- |
1365 | 1334 | |
1366 | | .. versionadded:: 1.0 |
1367 | | |
1368 | 1335 | Default: ``None`` |
1369 | 1336 | |
1370 | 1337 | If you're using file-based session storage, this sets the directory in |
-
diff --git a/docs/ref/signals.txt b/docs/ref/signals.txt
a
|
b
|
|
470 | 470 | .. data:: django.db.backends.signals.connection_created |
471 | 471 | :module: |
472 | 472 | |
473 | | .. versionadded:: 1.1 |
474 | | |
475 | 473 | .. versionchanged:: 1.2 |
476 | 474 | The connection argument was added |
477 | 475 | |
-
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 |
… |
… |
|
278 | 273 | for ... empty |
279 | 274 | ^^^^^^^^^^^^^ |
280 | 275 | |
281 | | .. versionadded:: 1.1 |
282 | | |
283 | 276 | The ``for`` tag can take an optional ``{% empty %}`` clause that will be |
284 | 277 | displayed if the given array is empty or could not be found:: |
285 | 278 | |
… |
… |
|
953 | 946 | |
954 | 947 | The template tag will output the string ``/clients/client/123/``. |
955 | 948 | |
956 | | .. versionadded:: 1.0 |
957 | | |
958 | 949 | If you're using :ref:`named URL patterns <naming-url-patterns>`, you can |
959 | 950 | refer to the name of the pattern in the ``url`` tag instead of using the |
960 | 951 | path to the view. |
… |
… |
|
963 | 954 | :exc:`NoReverseMatch` exception raised, which will cause your site to display an |
964 | 955 | error page. |
965 | 956 | |
966 | | .. versionadded:: 1.0 |
967 | | |
968 | 957 | If you'd like to retrieve a URL without displaying it, you can use a slightly |
969 | 958 | different call:: |
970 | 959 | |
… |
… |
|
981 | 970 | <a href="{{ the_url }}">Link to optional stuff</a> |
982 | 971 | {% endif %} |
983 | 972 | |
984 | | .. versionadded:: 1.1 |
985 | | |
986 | 973 | If you'd like to retrieve a namespaced URL, specify the fully qualified name:: |
987 | 974 | |
988 | 975 | {% url myapp:view-name %} |
… |
… |
|
1026 | 1013 | with |
1027 | 1014 | ~~~~ |
1028 | 1015 | |
1029 | | .. versionadded:: 1.0 |
1030 | | |
1031 | 1016 | Caches a complex variable under a simpler name. This is useful when accessing |
1032 | 1017 | an "expensive" method (e.g., one that hits the database) multiple times. |
1033 | 1018 | |
… |
… |
|
1278 | 1263 | it is safe to use this function even in auto-escaping environments. If you want |
1279 | 1264 | multiple escaping passes to be applied, use the ``force_escape`` filter. |
1280 | 1265 | |
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 | 1266 | .. templatefilter:: escapejs |
1287 | 1267 | |
1288 | 1268 | escapejs |
1289 | 1269 | ~~~~~~~~ |
1290 | 1270 | |
1291 | | .. versionadded:: 1.0 |
1292 | | |
1293 | 1271 | Escapes characters for use in JavaScript strings. This does *not* make the |
1294 | 1272 | string safe for use in HTML, but does protect you from syntax errors when using |
1295 | 1273 | templates to generate JavaScript/JSON. |
… |
… |
|
1333 | 1311 | fix_ampersands |
1334 | 1312 | ~~~~~~~~~~~~~~ |
1335 | 1313 | |
1336 | | .. versionchanged:: 1.0 |
1337 | | This is rarely useful as ampersands are now automatically escaped. See escape_ for more information. |
| 1314 | ..note:: |
| 1315 | |
| 1316 | This is rarely useful as ampersands are automatically escaped. See escape_ for more information. |
1338 | 1317 | |
1339 | 1318 | Replaces ampersands with ``&`` entities. |
1340 | 1319 | |
… |
… |
|
1391 | 1370 | force_escape |
1392 | 1371 | ~~~~~~~~~~~~ |
1393 | 1372 | |
1394 | | .. versionadded:: 1.0 |
1395 | | |
1396 | 1373 | Applies HTML escaping to a string (see the ``escape`` filter for details). |
1397 | 1374 | This filter is applied *immediately* and returns a new, escaped string. This |
1398 | 1375 | is useful in the rare cases where you need multiple escaping or want to apply |
… |
… |
|
1452 | 1429 | last |
1453 | 1430 | ~~~~ |
1454 | 1431 | |
1455 | | .. versionadded:: 1.0 |
1456 | | |
1457 | 1432 | Returns the last item in a list. |
1458 | 1433 | |
1459 | 1434 | For example:: |
… |
… |
|
1918 | 1893 | Recursively takes a self-nested list and returns an HTML unordered list -- |
1919 | 1894 | WITHOUT opening and closing <ul> tags. |
1920 | 1895 | |
1921 | | .. versionchanged:: 1.0 |
1922 | | The format accepted by ``unordered_list`` has changed to be easier to understand. |
1923 | | |
1924 | 1896 | The list is assumed to be in the proper format. For example, if ``var`` contains |
1925 | 1897 | ``['States', ['Kansas', ['Lawrence', 'Topeka'], 'Illinois']]``, then |
1926 | 1898 | ``{{ var|unordered_list }}`` would return:: |
… |
… |
|
1937 | 1909 | </ul> |
1938 | 1910 | </li> |
1939 | 1911 | |
1940 | | Note: the previous more restrictive and verbose format is still supported: |
| 1912 | Note: An older, more restrictive and verbose input format is also supported: |
1941 | 1913 | ``['States', [['Kansas', [['Lawrence', []], ['Topeka', []]]], ['Illinois', []]]]``, |
1942 | 1914 | |
1943 | 1915 | .. 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:: |
… |
… |
|
614 | 602 | |
615 | 603 | >>> cache.clear() |
616 | 604 | |
617 | | .. versionadded:: 1.1 |
618 | | |
619 | 605 | You can also increment or decrement a key that already exists using the |
620 | 606 | ``incr()`` or ``decr()`` methods, respectively. By default, the existing cache |
621 | 607 | value will incremented or decremented by 1. Other increment/decrement values |
-
diff --git a/docs/topics/conditional-view-processing.txt b/docs/topics/conditional-view-processing.txt
a
|
b
|
|
2 | 2 | Conditional View Processing |
3 | 3 | =========================== |
4 | 4 | |
5 | | .. versionadded:: 1.1 |
6 | | |
7 | 5 | HTTP clients can send a number of headers to tell the server about copies of a |
8 | 6 | resource that they have already seen. This is commonly used when retrieving a |
9 | 7 | web page (using an HTTP ``GET`` request) to avoid sending all the data for |
-
diff --git a/docs/topics/db/aggregation.txt b/docs/topics/db/aggregation.txt
a
|
b
|
|
2 | 2 | Aggregation |
3 | 3 | =========== |
4 | 4 | |
5 | | .. versionadded:: 1.1 |
6 | | |
7 | 5 | .. currentmodule:: django.db.models |
8 | 6 | |
9 | 7 | The topic guide on :doc:`Django's database-abstraction API </topics/db/queries>` |
-
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 |
… |
… |
|
1025 | 1017 | Proxy models |
1026 | 1018 | ------------ |
1027 | 1019 | |
1028 | | .. versionadded:: 1.1 |
1029 | | |
1030 | 1020 | When using :ref:`multi-table inheritance <multi-table-inheritance>`, a new |
1031 | 1021 | database table is created for each subclass of a model. This is usually the |
1032 | 1022 | desired behavior, since the subclass needs a place to store any additional |
-
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 |
… |
… |
|
494 | 492 | Filters can reference fields on the model |
495 | 493 | ----------------------------------------- |
496 | 494 | |
497 | | .. versionadded:: 1.1 |
498 | | |
499 | 495 | In the examples given so far, we have constructed filters that compare |
500 | 496 | the value of a model field with a constant. But what if you want to compare |
501 | 497 | the value of a model field with another field on the same model? |
… |
… |
|
766 | 762 | Updating multiple objects at once |
767 | 763 | ================================= |
768 | 764 | |
769 | | .. versionadded:: 1.0 |
770 | | |
771 | 765 | Sometimes you want to set a field to a particular value for all the objects in |
772 | 766 | a ``QuerySet``. You can do this with the ``update()`` method. For example:: |
773 | 767 | |
… |
… |
|
806 | 800 | for item in my_queryset: |
807 | 801 | item.save() |
808 | 802 | |
809 | | .. versionadded:: 1.1 |
810 | | |
811 | 803 | Calls to update can also use :ref:`F() objects <query-expressions>` to update |
812 | 804 | one field based on the value of another field in the model. This is especially |
813 | 805 | useful for incrementing counters based upon their current value. For example, to |
-
diff --git a/docs/topics/db/transactions.txt b/docs/topics/db/transactions.txt
a
|
b
|
|
301 | 301 | Database-level autocommit |
302 | 302 | ------------------------- |
303 | 303 | |
304 | | .. versionadded:: 1.1 |
305 | | |
306 | 304 | With PostgreSQL 8.2 or later, there is an advanced option to run PostgreSQL |
307 | 305 | with :doc:`database-level autocommit </ref/databases>`. If you use this option, |
308 | 306 | there is no constantly open transaction, so it is always possible to continue |
-
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/formsets.txt b/docs/topics/forms/formsets.txt
a
|
b
|
|
157 | 157 | the management data by rendering ``{{ my_formset.management_form }}`` |
158 | 158 | (substituting the name of your formset as appropriate). |
159 | 159 | |
160 | | .. versionadded:: 1.1 |
161 | | |
162 | 160 | ``total_form_count`` and ``initial_form_count`` |
163 | 161 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
164 | 162 | |
-
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 |
… |
… |
|
343 | 340 | interaction won't alter them. However, you could easily insert some error |
344 | 341 | displays for those form errors, as well. |
345 | 342 | |
346 | | .. versionadded:: 1.1 |
347 | | The ``hidden_fields`` and ``visible_fields`` methods are new in Django |
348 | | 1.1. |
349 | | |
350 | 343 | Reusable form templates |
351 | 344 | ----------------------- |
352 | 345 | |
-
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 | |
… |
… |
|
305 | 300 | |
306 | 301 | 2. Use the ``fields`` attribute of the ``ModelForm``'s inner ``Meta`` |
307 | 302 | class. This attribute, if given, should be a list of field names |
308 | | to include in the form. |
309 | | |
310 | | .. versionchanged:: 1.1 |
311 | | |
312 | | The form will render the fields in the same order they are specified in the |
313 | | ``fields`` attribute. |
| 303 | to include in the form. The order in which the fields names are specified |
| 304 | in that list is respected when the form renders them. |
314 | 305 | |
315 | 306 | 3. Use the ``exclude`` attribute of the ``ModelForm``'s inner ``Meta`` |
316 | 307 | class. This attribute, if given, should be a list of field names |
… |
… |
|
450 | 441 | Changing the order of fields |
451 | 442 | ---------------------------- |
452 | 443 | |
453 | | .. versionadded:: 1.1 |
454 | | |
455 | 444 | By default, a ``ModelForm`` will render fields in the same order that they are |
456 | 445 | defined on the model, with ``ManyToManyField`` instances appearing last. If |
457 | 446 | you want to change the order in which fields are rendered, you can use the |
-
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 |
… |
… |
|
50 | 48 | |
51 | 49 | For better performance, you may want to use a cache-based session backend. |
52 | 50 | |
53 | | .. versionchanged:: 1.1 |
54 | | Django 1.0 did not include the ``cached_db`` session backend. |
55 | | |
56 | 51 | To store session data using Django's cache system, you'll first need to make |
57 | 52 | sure you've configured your cache; see the :doc:`cache documentation |
58 | 53 | </topics/cache>` for details. |
… |
… |
|
138 | 133 | |
139 | 134 | * ``clear()`` |
140 | 135 | |
141 | | .. versionadded:: 1.0 |
142 | | ``setdefault()`` and ``clear()`` are new in this version. |
143 | | |
144 | 136 | It also has these methods: |
145 | 137 | |
146 | 138 | * ``flush()`` |
147 | 139 | |
148 | | .. versionadded:: 1.0 |
149 | | |
150 | 140 | Delete the current session data from the session and regenerate the |
151 | 141 | session key value that is sent back to the user in the cookie. This is |
152 | 142 | used if you want to ensure that the previous session data can't be |
… |
… |
|
173 | 163 | |
174 | 164 | * ``set_expiry(value)`` |
175 | 165 | |
176 | | .. versionadded:: 1.0 |
177 | | |
178 | 166 | Sets the expiration time for the session. You can pass a number of |
179 | 167 | different values: |
180 | 168 | |
… |
… |
|
198 | 186 | |
199 | 187 | * ``get_expiry_age()`` |
200 | 188 | |
201 | | .. versionadded:: 1.0 |
202 | | |
203 | 189 | Returns the number of seconds until this session expires. For sessions |
204 | 190 | with no custom expiration (or those set to expire at browser close), this |
205 | 191 | will equal ``settings.SESSION_COOKIE_AGE``. |
206 | 192 | |
207 | 193 | * ``get_expiry_date()`` |
208 | 194 | |
209 | | .. versionadded:: 1.0 |
210 | | |
211 | 195 | Returns the date this session will expire. For sessions with no custom |
212 | 196 | expiration (or those set to expire at browser close), this will equal the |
213 | 197 | date ``settings.SESSION_COOKIE_AGE`` seconds from now. |
214 | 198 | |
215 | 199 | * ``get_expire_at_browser_close()`` |
216 | 200 | |
217 | | .. versionadded:: 1.0 |
218 | | |
219 | 201 | Returns either ``True`` or ``False``, depending on whether the user's |
220 | 202 | session cookie will expire when the user's Web browser is closed. |
221 | 203 | |
… |
… |
|
302 | 284 | Using sessions out of views |
303 | 285 | =========================== |
304 | 286 | |
305 | | .. versionadded:: 1.0 |
306 | | |
307 | 287 | An API is available to manipulate session data outside of a view:: |
308 | 288 | |
309 | 289 | >>> from django.contrib.sessions.backends.db import SessionStore |
… |
… |
|
384 | 364 | her browser. Use this if you want people to have to log in every time they open |
385 | 365 | a browser. |
386 | 366 | |
387 | | .. versionadded:: 1.0 |
388 | | |
389 | 367 | This setting is a global default and can be overwritten at a per-session level |
390 | 368 | by explicitly calling ``request.session.set_expiry()`` as described above in |
391 | 369 | `using sessions in views`_. |
… |
… |
|
415 | 393 | SESSION_ENGINE |
416 | 394 | -------------- |
417 | 395 | |
418 | | .. versionadded:: 1.0 |
419 | | |
420 | | .. versionchanged:: 1.1 |
421 | | The ``cached_db`` backend was added |
422 | | |
423 | 396 | Default: ``django.contrib.sessions.backends.db`` |
424 | 397 | |
425 | 398 | Controls where Django stores session data. Valid values are: |
… |
… |
|
434 | 407 | SESSION_FILE_PATH |
435 | 408 | ----------------- |
436 | 409 | |
437 | | .. versionadded:: 1.0 |
438 | | |
439 | 410 | Default: ``/tmp/`` |
440 | 411 | |
441 | 412 | If you're using file-based session storage, this sets the directory in |
… |
… |
|
467 | 438 | SESSION_COOKIE_PATH |
468 | 439 | ------------------- |
469 | 440 | |
470 | | .. versionadded:: 1.0 |
471 | | |
472 | 441 | Default: ``'/'`` |
473 | 442 | |
474 | 443 | 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 | |
… |
… |
|
83 | 81 | |
84 | 82 | .. function:: redirect(to[, permanent=False], *args, **kwargs) |
85 | 83 | |
86 | | .. versionadded:: 1.1 |
87 | | |
88 | 84 | Returns an HttpResponseRedirect to the apropriate URL for the arguments |
89 | 85 | passed. |
90 | 86 | |
-
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 |
… |
… |
|
283 | 281 | A function that takes a full Python import path to another URLconf module that |
284 | 282 | should be "included" in this place. |
285 | 283 | |
286 | | .. versionadded:: 1.1 |
287 | | |
288 | 284 | :func:`include` also accepts as an argument an iterable that returns URL |
289 | 285 | patterns. |
290 | 286 | |
… |
… |
|
415 | 411 | up to that point and sends the remaining string to the included URLconf for |
416 | 412 | further processing. |
417 | 413 | |
418 | | .. versionadded:: 1.1 |
419 | | |
420 | 414 | Another possibility is to include additional URL patterns not by specifying the |
421 | 415 | URLconf Python module defining them as the `include`_ argument but by using |
422 | 416 | directly the pattern list as returned by `patterns`_ instead. For example:: |
… |
… |
|
634 | 628 | Naming URL patterns |
635 | 629 | =================== |
636 | 630 | |
637 | | .. versionadded:: 1.0 |
638 | | |
639 | 631 | It's fairly common to use the same view function in multiple URL patterns in |
640 | 632 | your URLconf. For example, these two URL patterns both point to the ``archive`` |
641 | 633 | view:: |
… |
… |
|
694 | 686 | URL namespaces |
695 | 687 | -------------- |
696 | 688 | |
697 | | .. versionadded:: 1.1 |
698 | | |
699 | 689 | Namespaced URLs are specified using the ``:`` operator. For example, the main |
700 | 690 | index page of the admin application is referenced using ``admin:index``. This |
701 | 691 | indicates a namespace of ``admin``, and a named URL of ``index``. |
… |
… |
|
801 | 791 | matching against incoming URLs and sending them off to views, but you cannot |
802 | 792 | reverse such patterns. |
803 | 793 | |
804 | | .. versionadded:: 1.1 |
805 | | |
806 | 794 | The ``current_app`` argument allows you to provide a hint to the resolver |
807 | 795 | indicating the application to which the currently executing view belongs. |
808 | 796 | This ``current_app`` argument is used as a hint to resolve application |
-
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 |
… |
… |
|
626 | 621 | details view, which is a good way to test code paths that use the |
627 | 622 | :meth:`django.http.HttpRequest.is_ajax()` method. |
628 | 623 | |
629 | | .. versionadded:: 1.1 |
630 | | |
631 | 624 | If you already have the GET arguments in URL-encoded form, you can |
632 | 625 | use that encoding instead of using the data argument. For example, |
633 | 626 | the previous GET request could also be posed as:: |
… |
… |
|
710 | 703 | |
711 | 704 | The ``extra`` argument acts the same as for :meth:`Client.get`. |
712 | 705 | |
713 | | .. versionchanged:: 1.1 |
714 | | |
715 | 706 | If the URL you request with a POST contains encoded parameters, these |
716 | 707 | parameters will be made available in the request.GET data. For example, |
717 | 708 | if you were to make the request:: |
… |
… |
|
728 | 719 | |
729 | 720 | .. method:: Client.head(path, data={}, follow=False, **extra) |
730 | 721 | |
731 | | .. versionadded:: 1.1 |
732 | | |
733 | 722 | Makes a HEAD request on the provided ``path`` and returns a ``Response`` |
734 | 723 | object. Useful for testing RESTful interfaces. Acts just like |
735 | 724 | :meth:`Client.get` except it does not return a message body. |
… |
… |
|
740 | 729 | |
741 | 730 | .. method:: Client.options(path, data={}, follow=False, **extra) |
742 | 731 | |
743 | | .. versionadded:: 1.1 |
744 | | |
745 | 732 | Makes an OPTIONS request on the provided ``path`` and returns a |
746 | 733 | ``Response`` object. Useful for testing RESTful interfaces. |
747 | 734 | |
… |
… |
|
753 | 740 | |
754 | 741 | .. method:: Client.put(path, data={}, content_type=MULTIPART_CONTENT, follow=False, **extra) |
755 | 742 | |
756 | | .. versionadded:: 1.1 |
757 | | |
758 | 743 | Makes a PUT request on the provided ``path`` and returns a |
759 | 744 | ``Response`` object. Useful for testing RESTful interfaces. Acts just |
760 | 745 | like :meth:`Client.post` except with the PUT request method. |
… |
… |
|
765 | 750 | |
766 | 751 | .. method:: Client.delete(path, follow=False, **extra) |
767 | 752 | |
768 | | .. versionadded:: 1.1 |
769 | | |
770 | 753 | Makes an DELETE request on the provided ``path`` and returns a |
771 | 754 | ``Response`` object. Useful for testing RESTful interfaces. |
772 | 755 | |
… |
… |
|
778 | 761 | |
779 | 762 | .. method:: Client.login(**credentials) |
780 | 763 | |
781 | | .. versionadded:: 1.0 |
782 | | |
783 | 764 | If your site uses Django's :doc:`authentication system</topics/auth>` |
784 | 765 | and you deal with logging in users, you can use the test client's |
785 | 766 | ``login()`` method to simulate the effect of a user logging into the |
… |
… |
|
824 | 805 | |
825 | 806 | .. method:: Client.logout() |
826 | 807 | |
827 | | .. versionadded:: 1.0 |
828 | | |
829 | 808 | If your site uses Django's :doc:`authentication system</topics/auth>`, |
830 | 809 | the ``logout()`` method can be used to simulate the effect of a user |
831 | 810 | logging out of your site. |
… |
… |
|
864 | 843 | If the rendered page used multiple templates, then ``context`` will be a |
865 | 844 | list of ``Context`` objects, in the order in which they were rendered. |
866 | 845 | |
867 | | .. versionadded:: 1.1 |
868 | | |
869 | 846 | Regardless of the number of templates used during rendering, you can |
870 | 847 | retrieve context values using the ``[]`` operator. For example, the |
871 | 848 | context variable ``name`` could be retrieved using:: |
… |
… |
|
988 | 965 | will continue to be available, but it will be augmented with some useful |
989 | 966 | additions. |
990 | 967 | |
991 | | .. versionadded:: 1.1 |
992 | | |
993 | 968 | .. class:: TransactionTestCase() |
994 | 969 | |
995 | 970 | Django ``TestCase`` classes make use of database transaction facilities, if |
… |
… |
|
1037 | 1012 | Default test client |
1038 | 1013 | ~~~~~~~~~~~~~~~~~~~ |
1039 | 1014 | |
1040 | | .. versionadded:: 1.0 |
1041 | | |
1042 | 1015 | .. attribute:: TestCase.client |
1043 | 1016 | |
1044 | 1017 | Every test case in a ``django.test.TestCase`` instance has access to an |
… |
… |
|
1143 | 1116 | URLconf configuration |
1144 | 1117 | ~~~~~~~~~~~~~~~~~~~~~ |
1145 | 1118 | |
1146 | | .. versionadded:: 1.0 |
1147 | | |
1148 | 1119 | .. attribute:: TestCase.urls |
1149 | 1120 | |
1150 | 1121 | If your application provides views, you may want to include tests that use the |
… |
… |
|
1212 | 1183 | Emptying the test outbox |
1213 | 1184 | ~~~~~~~~~~~~~~~~~~~~~~~~ |
1214 | 1185 | |
1215 | | .. versionadded:: 1.0 |
1216 | | |
1217 | 1186 | If you use Django's custom ``TestCase`` class, the test runner will clear the |
1218 | 1187 | contents of the test e-mail outbox at the start of each test case. |
1219 | 1188 | |
… |
… |
|
1222 | 1191 | Assertions |
1223 | 1192 | ~~~~~~~~~~ |
1224 | 1193 | |
1225 | | .. versionadded:: 1.0 |
1226 | | |
1227 | 1194 | .. versionchanged:: 1.2 |
1228 | 1195 | Addded ``msg_prefix`` argument. |
1229 | 1196 | |
… |
… |
|
1282 | 1249 | redirected to ``expected_url`` (including any GET data), and the final |
1283 | 1250 | page was received with ``target_status_code``. |
1284 | 1251 | |
1285 | | .. versionadded:: 1.1 |
1286 | | |
1287 | 1252 | If your request used the ``follow`` argument, the ``expected_url`` and |
1288 | 1253 | ``target_status_code`` will be the url and status code for the final |
1289 | 1254 | point of the redirect chain. |
… |
… |
|
1308 | 1273 | E-mail services |
1309 | 1274 | --------------- |
1310 | 1275 | |
1311 | | .. versionadded:: 1.0 |
1312 | | |
1313 | 1276 | If any of your Django views send e-mail using :doc:`Django's e-mail |
1314 | 1277 | functionality </topics/email>`, you probably don't want to send e-mail each time |
1315 | 1278 | you run a test using that view. For this reason, Django's test runner |
… |
… |
|
1558 | 1521 | :setting:`NAME` in :setting:`DATABASES` to match the name of the test |
1559 | 1522 | database. |
1560 | 1523 | |
1561 | | .. versionchanged:: 1.0 |
1562 | | ``create_test_db()`` now returns the name of the test database. |
1563 | | |
1564 | 1524 | .. function:: destroy_test_db(old_database_name, verbosity=1) |
1565 | 1525 | |
1566 | 1526 | Destroys the database whose name is in stored in :setting:`NAME` in the |