mirror of
				https://github.com/django/django.git
				synced 2025-11-01 00:17:31 +03:00 
			
		
		
		
	Removed references to changes made in 1.2.
Thanks Florian Apolloner for the patch.
This commit is contained in:
		
							parent
							
								
									6492e8e5e6
								
							
						
					
					
						commit
						c28e700c7e
					
				|  | @ -26,8 +26,6 @@ SELECTs, etc. Each time your app hits the database, the query will be recorded. | |||
| Note that the SQL recorded here may be :ref:`incorrectly quoted under SQLite | ||||
| <sqlite-connection-queries>`. | ||||
| 
 | ||||
| .. versionadded:: 1.2 | ||||
| 
 | ||||
| If you are using :doc:`multiple databases</topics/db/multi-db>`, you can use the | ||||
| same interface on each member of the ``connections`` dictionary:: | ||||
| 
 | ||||
|  |  | |||
|  | @ -313,9 +313,6 @@ Custom database types | |||
| 
 | ||||
| .. method:: Field.db_type(self, connection) | ||||
| 
 | ||||
| .. versionadded:: 1.2 | ||||
|    The ``connection`` argument was added to support multiple databases. | ||||
| 
 | ||||
| Returns the database column data type for the :class:`~django.db.models.Field`, | ||||
| taking into account the connection object, and the settings associated with it. | ||||
| 
 | ||||
|  | @ -452,9 +449,6 @@ Converting Python objects to query values | |||
| 
 | ||||
| .. method:: Field.get_prep_value(self, value) | ||||
| 
 | ||||
| .. versionadded:: 1.2 | ||||
|    This method was factored out of ``get_db_prep_value()`` | ||||
| 
 | ||||
| This is the reverse of :meth:`.to_python` when working with the | ||||
| database backends (as opposed to serialization). The ``value`` | ||||
| parameter is the current value of the model's attribute (a field has | ||||
|  | @ -480,9 +474,6 @@ Converting query values to database values | |||
| 
 | ||||
| .. method:: Field.get_db_prep_value(self, value, connection, prepared=False) | ||||
| 
 | ||||
| .. versionadded:: 1.2 | ||||
|    The ``connection`` and ``prepared`` arguments were added to support multiple databases. | ||||
| 
 | ||||
| Some data types (for example, dates) need to be in a specific format | ||||
| before they can be used by a database backend. | ||||
| :meth:`.get_db_prep_value` is the method where those conversions should | ||||
|  | @ -499,9 +490,6 @@ processing. | |||
| 
 | ||||
| .. method:: Field.get_db_prep_save(self, value, connection) | ||||
| 
 | ||||
| .. versionadded:: 1.2 | ||||
|    The ``connection`` argument was added to support multiple databases. | ||||
| 
 | ||||
| Same as the above, but called when the Field value must be *saved* to | ||||
| the database. As the default implementation just calls | ||||
| :meth:`.get_db_prep_value`, you shouldn't need to implement this method | ||||
|  | @ -540,9 +528,6 @@ two phase process. | |||
| 
 | ||||
| .. method:: Field.get_prep_lookup(self, lookup_type, value) | ||||
| 
 | ||||
| .. versionadded:: 1.2 | ||||
|    This method was factored out of ``get_db_prep_lookup()`` | ||||
| 
 | ||||
| :meth:`.get_prep_lookup` performs the first phase of lookup preparation, | ||||
| performing generic data validity checks | ||||
| 
 | ||||
|  | @ -591,9 +576,6 @@ accepted lookup types to ``exact`` and ``in``:: | |||
| 
 | ||||
| .. method:: Field.get_db_prep_lookup(self, lookup_type, value, connection, prepared=False) | ||||
| 
 | ||||
| .. versionadded:: 1.2 | ||||
|    The ``connection`` and ``prepared`` arguments were added to support multiple databases. | ||||
| 
 | ||||
| Performs any database-specific data conversions required by a lookup. | ||||
| As with :meth:`.get_db_prep_value`, the specific connection that will | ||||
| be used for the query is passed as the ``connection`` parameter. | ||||
|  |  | |||
|  | @ -540,8 +540,6 @@ tag is used inside a :ttag:`{% autoescape off %}<autoescape>` block. | |||
| Thread-safety considerations | ||||
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | ||||
| 
 | ||||
| .. versionadded:: 1.2 | ||||
| 
 | ||||
| Once a node is parsed, its ``render`` method may be called any number of times. | ||||
| Since Django is sometimes run in multi-threaded environments, a single node may | ||||
| be simultaneously rendering with different contexts in response to two separate | ||||
|  |  | |||
|  | @ -127,8 +127,6 @@ should be considered non-trivial, just ask. | |||
| Javascript patches | ||||
| ------------------ | ||||
| 
 | ||||
| .. versionadded:: 1.2 | ||||
| 
 | ||||
| Django's admin system leverages the jQuery framework to increase the | ||||
| capabilities of the admin interface. In conjunction, there is an emphasis on | ||||
| admin javascript performance and minimizing overall admin media file size. | ||||
|  |  | |||
|  | @ -115,8 +115,6 @@ subclass:: | |||
| 
 | ||||
| .. attribute:: ModelAdmin.actions_selection_counter | ||||
| 
 | ||||
|     .. versionadded:: 1.2 | ||||
| 
 | ||||
|     Controls whether a selection counter is display next to the action dropdown. | ||||
|     By default, the admin changelist will display it | ||||
|     (``actions_selection_counter = True``). | ||||
|  | @ -177,12 +175,9 @@ subclass:: | |||
|             fields = ('url', 'title', 'content') | ||||
| 
 | ||||
|     In the above example, only the fields ``url``, ``title`` and ``content`` | ||||
|     will be displayed, sequentially, in the form. | ||||
| 
 | ||||
|     .. versionadded:: 1.2 | ||||
| 
 | ||||
|     ``fields`` can contain values defined in :attr:`ModelAdmin.readonly_fields` | ||||
|     to be displayed as read-only. | ||||
|     will be displayed, sequentially, in the form. ``fields`` can contain | ||||
|     values defined in :attr:`ModelAdmin.readonly_fields` to be displayed as | ||||
|     read-only. | ||||
| 
 | ||||
|     .. versionadded:: 1.4 | ||||
| 
 | ||||
|  | @ -262,8 +257,6 @@ subclass:: | |||
|             'fields': (('first_name', 'last_name'), 'address', 'city', 'state'), | ||||
|             } | ||||
| 
 | ||||
|         .. versionadded:: 1.2 | ||||
| 
 | ||||
|         ``fields`` can contain values defined in | ||||
|         :attr:`~ModelAdmin.readonly_fields` to be displayed as read-only. | ||||
| 
 | ||||
|  | @ -380,8 +373,6 @@ subclass:: | |||
| 
 | ||||
| .. attribute:: ModelAdmin.get_changelist | ||||
| 
 | ||||
|     .. versionchanged:: 1.2 | ||||
| 
 | ||||
|     Returns the Changelist class to be used for listing. By default, | ||||
|     ``django.contrib.admin.views.main.ChangeList`` is used. By inheriting this | ||||
|     class you can change the behavior of the listing. | ||||
|  | @ -819,8 +810,6 @@ subclass:: | |||
| 
 | ||||
| .. attribute:: ModelAdmin.readonly_fields | ||||
| 
 | ||||
|     .. versionadded:: 1.2 | ||||
| 
 | ||||
|     By default the admin shows all fields as editable. Any fields in this | ||||
|     option (which should be a ``list`` or ``tuple``) will display its data | ||||
|     as-is and non-editable. This option behaves nearly identical to | ||||
|  | @ -928,8 +917,6 @@ templates used by the :class:`ModelAdmin` views: | |||
| 
 | ||||
| .. attribute:: ModelAdmin.add_form_template | ||||
| 
 | ||||
|     .. versionadded:: 1.2 | ||||
| 
 | ||||
|     Path to a custom template, used by :meth:`add_view`. | ||||
| 
 | ||||
| .. attribute:: ModelAdmin.change_form_template | ||||
|  | @ -947,8 +934,6 @@ templates used by the :class:`ModelAdmin` views: | |||
| 
 | ||||
| .. attribute:: ModelAdmin.delete_selected_confirmation_template | ||||
| 
 | ||||
|     .. versionadded:: 1.2 | ||||
| 
 | ||||
|     Path to a custom template, used by the :meth:`delete_selected` | ||||
|     action method for displaying a confirmation page when deleting one | ||||
|     or more objects. See the :doc:`actions | ||||
|  | @ -1035,8 +1020,6 @@ templates used by the :class:`ModelAdmin` views: | |||
| 
 | ||||
| .. method:: ModelAdmin.get_readonly_fields(self, request, obj=None) | ||||
| 
 | ||||
|     .. versionadded:: 1.2 | ||||
| 
 | ||||
|     The ``get_readonly_fields`` method is given the ``HttpRequest`` and the | ||||
|     ``obj`` being edited (or ``None`` on an add form) and is expected to return | ||||
|     a ``list`` or ``tuple`` of field names that will be displayed as read-only, | ||||
|  | @ -1405,20 +1388,17 @@ adds some of its own (the shared features are actually defined in the | |||
| - :attr:`~InlineModelAdmin.form` | ||||
| - :attr:`~ModelAdmin.fieldsets` | ||||
| - :attr:`~ModelAdmin.fields` | ||||
| - :attr:`~ModelAdmin.formfield_overrides` | ||||
| - :attr:`~ModelAdmin.exclude` | ||||
| - :attr:`~ModelAdmin.filter_horizontal` | ||||
| - :attr:`~ModelAdmin.filter_vertical` | ||||
| - :attr:`~ModelAdmin.prepopulated_fields` | ||||
| - :attr:`~ModelAdmin.radio_fields` | ||||
| - :attr:`~ModelAdmin.readonly_fields` | ||||
| - :attr:`~InlineModelAdmin.raw_id_fields` | ||||
| - :meth:`~ModelAdmin.formfield_for_foreignkey` | ||||
| - :meth:`~ModelAdmin.formfield_for_manytomany` | ||||
| 
 | ||||
| .. versionadded:: 1.2 | ||||
| 
 | ||||
| - :attr:`~ModelAdmin.readonly_fields` | ||||
| - :attr:`~ModelAdmin.formfield_overrides` | ||||
| 
 | ||||
| .. versionadded:: 1.3 | ||||
| 
 | ||||
| - :attr:`~ModelAdmin.ordering` | ||||
|  | @ -1463,8 +1443,6 @@ The ``InlineModelAdmin`` class adds: | |||
|     :doc:`formsets documentation </topics/forms/formsets>` for more | ||||
|     information. | ||||
| 
 | ||||
|     .. versionadded:: 1.2 | ||||
| 
 | ||||
|     For users with JavaScript-enabled browsers, an "Add another" link is | ||||
|     provided to enable any number of additional inlines to be added in addition | ||||
|     to those provided as a result of the ``extra`` argument. | ||||
|  | @ -1541,8 +1519,6 @@ automatically:: | |||
| Working with many-to-many models | ||||
| -------------------------------- | ||||
| 
 | ||||
| .. versionadded:: 1.2 | ||||
| 
 | ||||
| By default, admin widgets for many-to-many relations will be displayed | ||||
| on whichever model contains the actual reference to the | ||||
| :class:`~django.db.models.ManyToManyField`. Depending on your ``ModelAdmin`` | ||||
|  | @ -1842,21 +1818,15 @@ Templates can override or extend base admin templates as described in | |||
| 
 | ||||
| .. attribute:: AdminSite.logout_template | ||||
| 
 | ||||
|     .. versionadded:: 1.2 | ||||
| 
 | ||||
|     Path to a custom template that will be used by the admin site logout view. | ||||
| 
 | ||||
| .. attribute:: AdminSite.password_change_template | ||||
| 
 | ||||
|     .. versionadded:: 1.2 | ||||
| 
 | ||||
|     Path to a custom template that will be used by the admin site password | ||||
|     change view. | ||||
| 
 | ||||
| .. attribute:: AdminSite.password_change_done_template | ||||
| 
 | ||||
|     .. versionadded:: 1.2 | ||||
| 
 | ||||
|     Path to a custom template that will be used by the admin site password | ||||
|     change done view. | ||||
| 
 | ||||
|  |  | |||
|  | @ -37,8 +37,6 @@ available in the context, then you can refer to it directly:: | |||
|    {% get_comment_count for entry as comment_count %} | ||||
|    <p>{{ comment_count }} comments have been posted.</p> | ||||
| 
 | ||||
| .. versionadded:: 1.2 | ||||
| 
 | ||||
| Next, we can use the :ttag:`render_comment_list` tag, to render all comments | ||||
| to the given instance (``entry``) by using the ``comments/list.html`` template:: | ||||
| 
 | ||||
|  |  | |||
|  | @ -130,8 +130,6 @@ details. | |||
| Linking to comments | ||||
| ------------------- | ||||
| 
 | ||||
| .. versionadded:: 1.2 | ||||
| 
 | ||||
| To provide a permalink to a specific comment, use :ttag:`get_comment_permalink`:: | ||||
| 
 | ||||
|     {% get_comment_permalink comment_obj [format_string] %} | ||||
|  |  | |||
|  | @ -434,8 +434,6 @@ A number of settings can be used to control Django's CSRF behavior. | |||
| CSRF_COOKIE_DOMAIN | ||||
| ------------------ | ||||
| 
 | ||||
| .. versionadded:: 1.2 | ||||
| 
 | ||||
| Default: ``None`` | ||||
| 
 | ||||
| The domain to be used when setting the CSRF cookie.  This can be useful for | ||||
|  | @ -450,8 +448,6 @@ mechanism is not safe against cross-subdomain attacks -- see `Limitations`_. | |||
| CSRF_COOKIE_NAME | ||||
| ---------------- | ||||
| 
 | ||||
| .. versionadded:: 1.2 | ||||
| 
 | ||||
| Default: ``'csrftoken'`` | ||||
| 
 | ||||
| The name of the cookie to use for the CSRF authentication token. This can be | ||||
|  | @ -485,8 +481,6 @@ cookie is only sent under an HTTPS connection. | |||
| CSRF_FAILURE_VIEW | ||||
| ----------------- | ||||
| 
 | ||||
| .. versionadded:: 1.2 | ||||
| 
 | ||||
| Default: ``'django.views.csrf.csrf_failure'`` | ||||
| 
 | ||||
| A dotted path to the view function to be used when an incoming request | ||||
|  |  | |||
|  | @ -110,8 +110,6 @@ default templates. | |||
| Advanced ``FormPreview`` methods | ||||
| ================================ | ||||
| 
 | ||||
| .. versionadded:: 1.2 | ||||
| 
 | ||||
| .. method:: FormPreview.process_preview | ||||
| 
 | ||||
|     Given a validated form, performs any extra processing before displaying the | ||||
|  |  | |||
|  | @ -12,11 +12,7 @@ GeoDjango Database API | |||
| Spatial Backends | ||||
| ================ | ||||
| 
 | ||||
| .. versionadded:: 1.2 | ||||
| 
 | ||||
| In Django 1.2, support for :doc:`multiple databases </topics/db/multi-db>` was | ||||
| introduced.  In order to support multiple databases, GeoDjango has segregated | ||||
| its functionality into full-fledged spatial database backends: | ||||
| GeoDjango currently provides the following spatial database backends: | ||||
| 
 | ||||
| * :mod:`django.contrib.gis.db.backends.postgis` | ||||
| * :mod:`django.contrib.gis.db.backends.mysql` | ||||
|  |  | |||
|  | @ -212,8 +212,6 @@ __ http://www.gdal.org/ogr/ogr_formats.html | |||
| 
 | ||||
|    .. attribute:: spatial_filter | ||||
| 
 | ||||
|    .. versionadded:: 1.2 | ||||
| 
 | ||||
|    Property that may be used to retrieve or set a spatial filter for this | ||||
|    layer.  A spatial filter can only be set with an :class:`OGRGeometry` | ||||
|    instance, a 4-tuple extent, or ``None``.  When set with something  | ||||
|  | @ -490,15 +488,9 @@ systems and coordinate transformation:: | |||
| 
 | ||||
|    .. attribute:: coord_dim | ||||
| 
 | ||||
|    .. versionchanged:: 1.2 | ||||
| 
 | ||||
|    Returns or sets the coordinate dimension of this geometry.  For | ||||
|    example, the value would be 2 for two-dimensional geometries. | ||||
| 
 | ||||
|    .. note:: | ||||
| 
 | ||||
|       Setting this property is only available in versions 1.2 and above. | ||||
| 
 | ||||
|    .. attribute:: geom_count | ||||
| 
 | ||||
|    Returns the number of elements in this geometry:: | ||||
|  | @ -619,8 +611,6 @@ systems and coordinate transformation:: | |||
| 
 | ||||
|    .. attribute:: ewkt | ||||
| 
 | ||||
|    .. versionadded:: 1.2 | ||||
| 
 | ||||
|    Returns the EWKT representation of this geometry. | ||||
| 
 | ||||
|    .. method:: clone() | ||||
|  |  | |||
|  | @ -117,8 +117,6 @@ SpatiaLite  ``Contains(poly, geom)`` | |||
| contains_properly | ||||
| ----------------- | ||||
| 
 | ||||
| .. versionadded:: 1.2 | ||||
| 
 | ||||
| *Availability*: PostGIS | ||||
| 
 | ||||
| Returns true if the lookup geometry intersects the interior of the | ||||
|  | @ -803,8 +801,6 @@ Geometry Editors | |||
| 
 | ||||
| .. method:: GeoQuerySet.force_rhr(**kwargs) | ||||
| 
 | ||||
| .. versionadded:: 1.2 | ||||
| 
 | ||||
| *Availability*: PostGIS | ||||
| 
 | ||||
| Returns a modified version of the polygon/multipolygon in which all | ||||
|  | @ -816,8 +812,6 @@ of the vertices follow the Right-Hand-Rule, and attaches as a | |||
| 
 | ||||
| .. method:: GeoQuerySet.reverse_geom(**kwargs) | ||||
| 
 | ||||
| .. versionadded:: 1.2 | ||||
| 
 | ||||
| *Availability*: PostGIS, Oracle | ||||
| 
 | ||||
| Reverse the coordinate order of the geometry field, and attaches as a | ||||
|  | @ -943,8 +937,6 @@ of the geometry field in each model converted to the requested output format. | |||
| 
 | ||||
| .. method:: GeoQuerySet.geohash(precision=20, **kwargs) | ||||
| 
 | ||||
| .. versionadded:: 1.2 | ||||
| 
 | ||||
| Attaches a ``geohash`` attribute to every model the queryset | ||||
| containing the `GeoHash`__ representation of the geometry. | ||||
| 
 | ||||
|  | @ -1136,8 +1128,6 @@ Example:: | |||
| 
 | ||||
| .. method:: GeoQuerySet.extent3d(**kwargs) | ||||
| 
 | ||||
| .. versionadded:: 1.2 | ||||
| 
 | ||||
| *Availability*: PostGIS | ||||
| 
 | ||||
| Returns the 3D extent of the ``GeoQuerySet`` as a six-tuple, comprising | ||||
|  | @ -1224,8 +1214,6 @@ Returns the same as the :meth:`GeoQuerySet.extent` aggregate method. | |||
| 
 | ||||
| .. class:: Extent3D(geo_field) | ||||
| 
 | ||||
| .. versionadded:: 1.2 | ||||
| 
 | ||||
| Returns the same as the :meth:`GeoQuerySet.extent3d` aggregate method. | ||||
| 
 | ||||
| ``MakeLine`` | ||||
|  |  | |||
|  | @ -265,8 +265,6 @@ because it is not a part of the OGC specification (use the | |||
| 
 | ||||
| .. attribute:: GEOSGeometry.hexewkb | ||||
| 
 | ||||
| .. versionadded:: 1.2 | ||||
| 
 | ||||
| Returns the EWKB of this Geometry in hexadecimal form.  This is an | ||||
| extension of the WKB specification that includes SRID and Z values | ||||
| that are a part of this geometry. | ||||
|  | @ -314,8 +312,6 @@ as a Python buffer.  SRID and Z values are not included, use the | |||
| 
 | ||||
| .. attribute:: GEOSGeometry.ewkb | ||||
| 
 | ||||
| .. versionadded:: 1.2 | ||||
| 
 | ||||
| Return the EWKB representation of this Geometry as a Python buffer. | ||||
| This is an extension of the WKB specification that includes any SRID | ||||
| and Z values that are a part of this geometry. | ||||
|  |  | |||
|  | @ -624,8 +624,6 @@ features such as the geographic admin or KML sitemaps will not function properly | |||
| Add Google projection to ``spatial_ref_sys`` table | ||||
| -------------------------------------------------- | ||||
| 
 | ||||
| .. versionchanged:: 1.2 | ||||
| 
 | ||||
| .. note:: | ||||
| 
 | ||||
|     If you're running PostGIS 1.4 or above, you can skip this step. The entry | ||||
|  |  | |||
|  | @ -163,8 +163,6 @@ field. | |||
| ``dim`` | ||||
| ------- | ||||
| 
 | ||||
| .. versionadded:: 1.2 | ||||
| 
 | ||||
| .. attribute:: GeometryField.dim | ||||
| 
 | ||||
| This option may be used for customizing the coordinate dimension of the | ||||
|  | @ -180,8 +178,6 @@ three-dimensonal support. | |||
| ``geography`` | ||||
| ------------- | ||||
| 
 | ||||
| .. versionadded:: 1.2 | ||||
| 
 | ||||
| .. attribute:: GeometryField.geography | ||||
| 
 | ||||
| If set to ``True``, this option will create a database column of | ||||
|  |  | |||
|  | @ -2,12 +2,6 @@ | |||
| Testing GeoDjango apps | ||||
| ====================== | ||||
| 
 | ||||
| .. versionchanged:: 1.2 | ||||
| 
 | ||||
| In Django 1.2, the addition of :ref:`spatial-backends` simplified the | ||||
| process of testing GeoDjango applications. The process is now the | ||||
| same as :doc:`/topics/testing`. | ||||
| 
 | ||||
| Included in this documentation are some additional notes and settings | ||||
| for :ref:`testing-postgis` and :ref:`testing-spatialite` users. | ||||
| 
 | ||||
|  | @ -28,11 +22,9 @@ Settings | |||
| ``POSTGIS_TEMPLATE`` | ||||
| ^^^^^^^^^^^^^^^^^^^^ | ||||
| 
 | ||||
| .. versionchanged:: 1.2 | ||||
| 
 | ||||
| This setting may be used to customize the name of the PostGIS template | ||||
| database to use. In Django versions 1.2 and above, it automatically | ||||
| defaults to ``'template_postgis'`` (the same name used in the | ||||
| database to use. It automatically defaults to ``'template_postgis'`` | ||||
| (the same name used in the | ||||
| :ref:`installation documentation <spatialdb_template>`). | ||||
| 
 | ||||
| .. setting:: POSTGIS_VERSION | ||||
|  |  | |||
|  | @ -142,9 +142,6 @@ See the :doc:`markup documentation </ref/contrib/markup>`. | |||
| messages | ||||
| ======== | ||||
| 
 | ||||
| .. versionchanged:: 1.2 | ||||
|     The messages framework was added. | ||||
| 
 | ||||
| A framework for storing and retrieving temporary cookie- or session-based | ||||
| messages | ||||
| 
 | ||||
|  |  | |||
|  | @ -12,9 +12,6 @@ in a subsequent request (usually the next one). Every message is tagged | |||
| with a specific ``level`` that determines its priority (e.g., ``info``, | ||||
| ``warning``, or ``error``). | ||||
| 
 | ||||
| .. versionadded:: 1.2 | ||||
|    The messages framework was added. | ||||
| 
 | ||||
| Enabling messages | ||||
| ================= | ||||
| 
 | ||||
|  |  | |||
|  | @ -22,10 +22,6 @@ lower-level way. | |||
| The high-level framework | ||||
| ======================== | ||||
| 
 | ||||
| .. versionchanged:: 1.2 | ||||
|    The high-level feeds framework was refactored in Django 1.2. The | ||||
|    pre-1.2 interface has been removed in Django 1.4. | ||||
| 
 | ||||
| Overview | ||||
| -------- | ||||
| 
 | ||||
|  | @ -176,9 +172,6 @@ These can be matched with a :doc:`URLconf </topics/http/urls>` line such as:: | |||
| Like a view, the arguments in the URL are passed to the ``get_object()`` | ||||
| method along with the request object. | ||||
| 
 | ||||
| .. versionchanged:: 1.2 | ||||
|    Prior to version 1.2, ``get_object()`` only accepted a ``bits`` argument. | ||||
| 
 | ||||
| Here's the code for these beat-specific feeds:: | ||||
| 
 | ||||
|     from django.contrib.syndication.views import FeedDoesNotExist | ||||
|  |  | |||
|  | @ -373,15 +373,6 @@ these methods in no-op's based in the results of such detection. | |||
| Notes on specific fields | ||||
| ------------------------ | ||||
| 
 | ||||
| Boolean fields | ||||
| ~~~~~~~~~~~~~~ | ||||
| 
 | ||||
| .. versionchanged:: 1.2 | ||||
| 
 | ||||
| In previous versions of Django when running under MySQL ``BooleanFields`` would | ||||
| return their data as ``ints``, instead of true ``bools``.  See the release | ||||
| notes for a complete description of the change. | ||||
| 
 | ||||
| Character fields | ||||
| ~~~~~~~~~~~~~~~~ | ||||
| 
 | ||||
|  |  | |||
|  | @ -119,8 +119,6 @@ createcachetable | |||
| Creates a cache table named ``tablename`` for use with the database cache | ||||
| backend. See :doc:`/topics/cache` for more information. | ||||
| 
 | ||||
| .. versionadded:: 1.2 | ||||
| 
 | ||||
| The :djadminopt:`--database` option can be used to specify the database | ||||
| onto which the cachetable will be installed. | ||||
| 
 | ||||
|  | @ -142,8 +140,6 @@ the program name (``psql``, ``mysql``, ``sqlite3``) will find the program in | |||
| the right place. There's no way to specify the location of the program | ||||
| manually. | ||||
| 
 | ||||
| .. versionadded:: 1.2 | ||||
| 
 | ||||
| The :djadminopt:`--database` option can be used to specify the database | ||||
| onto which to open a shell. | ||||
| 
 | ||||
|  | @ -212,15 +208,11 @@ name to ``dumpdata``, the dumped output will be restricted to that model, | |||
| rather than the entire application. You can also mix application names and | ||||
| model names. | ||||
| 
 | ||||
| .. versionadded:: 1.2 | ||||
| 
 | ||||
| The :djadminopt:`--database` option can be used to specify the database | ||||
| from which data will be dumped. | ||||
| 
 | ||||
| .. django-admin-option:: --natural | ||||
| 
 | ||||
| .. versionadded:: 1.2 | ||||
| 
 | ||||
| Use :ref:`natural keys <topics-serialization-natural-keys>` to represent | ||||
| any foreign key and many-to-many relationship with a model that provides | ||||
| a natural key definition. If you are dumping ``contrib.auth`` ``Permission`` | ||||
|  | @ -240,8 +232,6 @@ fixture will be re-installed. | |||
| The :djadminopt:`--noinput` option may be provided to suppress all user | ||||
| prompts. | ||||
| 
 | ||||
| .. versionadded:: 1.2 | ||||
| 
 | ||||
| The :djadminopt:`--database` option may be used to specify the database | ||||
| to flush. | ||||
| 
 | ||||
|  | @ -296,8 +286,6 @@ needed. | |||
| ``inspectdb`` works with PostgreSQL, MySQL and SQLite. Foreign-key detection | ||||
| only works in PostgreSQL and with certain types of MySQL tables. | ||||
| 
 | ||||
| .. versionadded:: 1.2 | ||||
| 
 | ||||
| The :djadminopt:`--database` option may be used to specify the | ||||
| database to introspect. | ||||
| 
 | ||||
|  | @ -308,8 +296,6 @@ loaddata <fixture fixture ...> | |||
| 
 | ||||
| Searches for and loads the contents of the named fixture into the database. | ||||
| 
 | ||||
| .. versionadded:: 1.2 | ||||
| 
 | ||||
| The :djadminopt:`--database` option can be used to specify the database | ||||
| onto which the data will be loaded. | ||||
| 
 | ||||
|  | @ -452,8 +438,6 @@ Currently supported: | |||
| 
 | ||||
| .. django-admin-option:: --symlinks | ||||
| 
 | ||||
| .. versionadded:: 1.2 | ||||
| 
 | ||||
| Use the ``--symlinks`` or ``-s`` option to follow symlinks to directories when | ||||
| looking for new translation strings. | ||||
| 
 | ||||
|  | @ -768,8 +752,6 @@ sql <appname appname ...> | |||
| 
 | ||||
| Prints the CREATE TABLE SQL statements for the given app name(s). | ||||
| 
 | ||||
| .. versionadded:: 1.2 | ||||
| 
 | ||||
| The :djadminopt:`--database` option can be used to specify the database for | ||||
| which to print the SQL. | ||||
| 
 | ||||
|  | @ -783,8 +765,6 @@ Prints the CREATE TABLE and initial-data SQL statements for the given app name(s | |||
| Refer to the description of ``sqlcustom`` for an explanation of how to | ||||
| specify initial data. | ||||
| 
 | ||||
| .. versionadded:: 1.2 | ||||
| 
 | ||||
| The :djadminopt:`--database` option can be used to specify the database for | ||||
| which to print the SQL. | ||||
| 
 | ||||
|  | @ -795,8 +775,6 @@ sqlclear <appname appname ...> | |||
| 
 | ||||
| Prints the DROP TABLE SQL statements for the given app name(s). | ||||
| 
 | ||||
| .. versionadded:: 1.2 | ||||
| 
 | ||||
| The :djadminopt:`--database` option can be used to specify the database for | ||||
| which to print the SQL. | ||||
| 
 | ||||
|  | @ -821,8 +799,6 @@ table modifications, or insert any SQL functions into the database. | |||
| 
 | ||||
| Note that the order in which the SQL files are processed is undefined. | ||||
| 
 | ||||
| .. versionadded:: 1.2 | ||||
| 
 | ||||
| The :djadminopt:`--database` option can be used to specify the database for | ||||
| which to print the SQL. | ||||
| 
 | ||||
|  | @ -834,8 +810,6 @@ sqlflush | |||
| Prints the SQL statements that would be executed for the :djadmin:`flush` | ||||
| command. | ||||
| 
 | ||||
| .. versionadded:: 1.2 | ||||
| 
 | ||||
| The :djadminopt:`--database` option can be used to specify the database for | ||||
| which to print the SQL. | ||||
| 
 | ||||
|  | @ -846,8 +820,6 @@ sqlindexes <appname appname ...> | |||
| 
 | ||||
| Prints the CREATE INDEX SQL statements for the given app name(s). | ||||
| 
 | ||||
| .. versionadded:: 1.2 | ||||
| 
 | ||||
| The :djadminopt:`--database` option can be used to specify the database for | ||||
| which to print the SQL. | ||||
| 
 | ||||
|  | @ -864,8 +836,6 @@ number for automatically incremented fields. | |||
| Use this command to generate SQL which will fix cases where a sequence is out | ||||
| of sync with its automatically incremented field data. | ||||
| 
 | ||||
| .. versionadded:: 1.2 | ||||
| 
 | ||||
| The :djadminopt:`--database` option can be used to specify the database for | ||||
| which to print the SQL. | ||||
| 
 | ||||
|  | @ -1027,8 +997,6 @@ data files. | |||
| The :djadminopt:`--noinput` option may be provided to suppress all user | ||||
| prompts. | ||||
| 
 | ||||
| .. versionadded:: 1.2 | ||||
| 
 | ||||
| The :djadminopt:`--database` option can be used to specify the database to | ||||
| synchronize. | ||||
| 
 | ||||
|  | @ -1047,7 +1015,6 @@ test <app or test identifier> | |||
| Runs tests for all installed models. See :doc:`/topics/testing` for more | ||||
| information. | ||||
| 
 | ||||
| .. versionadded:: 1.2 | ||||
| .. django-admin-option:: --failfast | ||||
| 
 | ||||
| The ``--failfast`` option can be used to stop running tests and report the | ||||
|  | @ -1155,8 +1122,6 @@ changepassword | |||
| 
 | ||||
| .. django-admin:: changepassword | ||||
| 
 | ||||
| .. versionadded:: 1.2 | ||||
| 
 | ||||
| This command is only available if Django's :doc:`authentication system | ||||
| </topics/auth>` (``django.contrib.auth``) is installed. | ||||
| 
 | ||||
|  | @ -1317,8 +1282,6 @@ to a number of commands. | |||
| 
 | ||||
| .. django-admin-option:: --database | ||||
| 
 | ||||
| .. versionadded:: 1.2 | ||||
| 
 | ||||
| Used to specify the database on which a command will operate. If not | ||||
| specified, this option will default to an alias of ``default``. | ||||
| 
 | ||||
|  |  | |||
|  | @ -377,8 +377,6 @@ a form object, and each rendering method returns a Unicode object. | |||
| Styling required or erroneous form rows | ||||
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | ||||
| 
 | ||||
| .. versionadded:: 1.2 | ||||
| 
 | ||||
| It's pretty common to style form rows and fields that are required or have | ||||
| errors. For example, you might want to present required form rows in bold and | ||||
| highlight errors in red. | ||||
|  | @ -638,8 +636,6 @@ For a field's list of errors, access the field's ``errors`` attribute. | |||
| 
 | ||||
| .. method:: BoundField.css_classes() | ||||
| 
 | ||||
|    .. versionadded:: 1.2 | ||||
| 
 | ||||
| When you use Django's rendering shortcuts, CSS classes are used to | ||||
| indicate required form fields or fields that contain errors. If you're | ||||
| manually rendering a form, you can access these CSS classes using the | ||||
|  |  | |||
|  | @ -256,8 +256,6 @@ error message keys it uses. | |||
| ``validators`` | ||||
| ~~~~~~~~~~~~~~ | ||||
| 
 | ||||
| .. versionadded:: 1.2 | ||||
| 
 | ||||
| .. attribute:: Field.validators | ||||
| 
 | ||||
| The ``validators`` argument lets you provide a list of validation functions | ||||
|  | @ -268,8 +266,6 @@ See the :doc:`validators documentation </ref/validators>` for more information. | |||
| ``localize`` | ||||
| ~~~~~~~~~~~~ | ||||
| 
 | ||||
| .. versionadded:: 1.2 | ||||
| 
 | ||||
| .. attribute:: Field.localize | ||||
| 
 | ||||
| The ``localize`` argument enables the localization of form data, input as well | ||||
|  | @ -492,11 +488,6 @@ For each field, we describe the default widget used if you don't specify | |||
|     If provided, these arguments ensure that the string is at most or at least the | ||||
|     given length. | ||||
| 
 | ||||
| .. versionchanged:: 1.2 | ||||
|    The EmailField previously did not recognize email addresses as valid that | ||||
|    contained an IDN (Internationalized Domain Name; a domain containing | ||||
|    unicode characters) domain part. This has now been corrected. | ||||
| 
 | ||||
| ``FileField`` | ||||
| ~~~~~~~~~~~~~ | ||||
| 
 | ||||
|  | @ -815,11 +806,6 @@ For each field, we describe the default widget used if you don't specify | |||
| 
 | ||||
|     These are the same as ``CharField.max_length`` and ``CharField.min_length``. | ||||
| 
 | ||||
| .. versionchanged:: 1.2 | ||||
|    The URLField previously did not recognize URLs as valid that contained an IDN | ||||
|    (Internationalized Domain Name; a domain name containing unicode characters) | ||||
|    domain name. This has now been corrected. | ||||
| 
 | ||||
| 
 | ||||
| Slightly complex built-in ``Field`` classes | ||||
| ------------------------------------------- | ||||
|  |  | |||
|  | @ -1,8 +1,6 @@ | |||
| Form and field validation | ||||
| ========================= | ||||
| 
 | ||||
| .. versionchanged:: 1.2 | ||||
| 
 | ||||
| Form validation happens when the data is cleaned. If you want to customize | ||||
| this process, there are various places you can change, each one serving a | ||||
| different purpose. Three types of cleaning methods are run during form | ||||
|  | @ -175,7 +173,6 @@ previous features. | |||
| 
 | ||||
| Using validators | ||||
| ~~~~~~~~~~~~~~~~ | ||||
| .. versionadded:: 1.2 | ||||
| 
 | ||||
| Django's form (and model) fields support use of simple utility functions and | ||||
| classes known as validators. These can be passed to a field's constructor, via | ||||
|  |  | |||
|  | @ -156,9 +156,6 @@ Message middleware | |||
| 
 | ||||
| .. class:: MessageMiddleware | ||||
| 
 | ||||
| .. versionadded:: 1.2 | ||||
|    ``MessageMiddleware`` was added. | ||||
| 
 | ||||
| Enables cookie- and session-based message support. See the | ||||
| :doc:`messages documentation </ref/contrib/messages>`. | ||||
| 
 | ||||
|  |  | |||
|  | @ -208,8 +208,6 @@ automatically generated from the model class. Default is ``True``. | |||
| ``error_messages`` | ||||
| ------------------ | ||||
| 
 | ||||
| .. versionadded:: 1.2 | ||||
| 
 | ||||
| .. attribute:: Field.error_messages | ||||
| 
 | ||||
| The ``error_messages`` argument lets you override the default messages that the | ||||
|  | @ -309,8 +307,6 @@ underscores to spaces. See :ref:`Verbose field names <verbose-field-names>`. | |||
| ``validators`` | ||||
| ------------------- | ||||
| 
 | ||||
| .. versionadded:: 1.2 | ||||
| 
 | ||||
| .. attribute:: Field.validators | ||||
| 
 | ||||
| A list of validators to run for this field. See the :doc:`validators | ||||
|  | @ -336,8 +332,6 @@ otherwise. See :ref:`automatic-primary-key-fields`. | |||
| ``BigIntegerField`` | ||||
| ------------------- | ||||
| 
 | ||||
| .. versionadded:: 1.2 | ||||
| 
 | ||||
| .. class:: BigIntegerField([**options]) | ||||
| 
 | ||||
| A 64 bit integer, much like an :class:`IntegerField` except that it is | ||||
|  | @ -357,11 +351,6 @@ The admin represents this as a checkbox. | |||
| If you need to accept :attr:`~Field.null` values then use | ||||
| :class:`NullBooleanField` instead. | ||||
| 
 | ||||
| .. versionchanged:: 1.2 | ||||
|     In previous versions of Django when running under MySQL ``BooleanFields`` | ||||
|     would return their data as ``ints``, instead of true ``bools``.  See the | ||||
|     release notes for a complete description of the change. | ||||
| 
 | ||||
| ``CharField`` | ||||
| ------------- | ||||
| 
 | ||||
|  |  | |||
|  | @ -30,8 +30,6 @@ that, you need to :meth:`~Model.save()`. | |||
| Validating objects | ||||
| ================== | ||||
| 
 | ||||
| .. versionadded:: 1.2 | ||||
| 
 | ||||
| There are three steps involved in validating a model: | ||||
| 
 | ||||
| 1. Validate the model fields | ||||
|  | @ -137,9 +135,6 @@ To save an object back to the database, call ``save()``: | |||
| 
 | ||||
| .. method:: Model.save([force_insert=False, force_update=False, using=DEFAULT_DB_ALIAS, update_fields=None]) | ||||
| 
 | ||||
| .. versionadded:: 1.2 | ||||
|    The ``using`` argument was added. | ||||
| 
 | ||||
| If you want customized saving behavior, you can override this ``save()`` | ||||
| method. See :ref:`overriding-model-methods` for more details. | ||||
| 
 | ||||
|  | @ -361,9 +356,6 @@ Deleting objects | |||
| 
 | ||||
| .. method:: Model.delete([using=DEFAULT_DB_ALIAS]) | ||||
| 
 | ||||
| .. versionadded:: 1.2 | ||||
|    The ``using`` argument was added. | ||||
| 
 | ||||
| Issues a SQL ``DELETE`` for the object. This only deletes the object in the | ||||
| database; the Python instance will still exist and will still have data in | ||||
| its fields. | ||||
|  |  | |||
|  | @ -727,8 +727,6 @@ passed to ``select_related()``. This includes foreign keys that have | |||
| It's an error to use both a list of fields and the ``depth`` parameter in the | ||||
| same ``select_related()`` call; they are conflicting options. | ||||
| 
 | ||||
| .. versionchanged:: 1.2 | ||||
| 
 | ||||
| You can also refer to the reverse direction of a | ||||
| :class:`~django.db.models.OneToOneField` in the list of fields passed to | ||||
| ``select_related`` — that is, you can traverse a | ||||
|  | @ -1156,8 +1154,6 @@ using | |||
| 
 | ||||
| .. method:: using(alias) | ||||
| 
 | ||||
| .. versionadded:: 1.2 | ||||
| 
 | ||||
| This method is for controlling which database the ``QuerySet`` will be | ||||
| evaluated against if you are using more than one database.  The only argument | ||||
| this method takes is the alias of a database, as defined in | ||||
|  | @ -1512,8 +1508,6 @@ exists | |||
| 
 | ||||
| .. method:: exists() | ||||
| 
 | ||||
| .. versionadded:: 1.2 | ||||
| 
 | ||||
| Returns ``True`` if the :class:`.QuerySet` contains any results, and ``False`` | ||||
| if not. This tries to perform the query in the simplest and fastest way | ||||
| possible, but it *does* execute nearly the same query. This means that calling | ||||
|  |  | |||
|  | @ -307,8 +307,6 @@ See :doc:`/topics/cache`. | |||
| CSRF_COOKIE_DOMAIN | ||||
| ------------------ | ||||
| 
 | ||||
| .. versionadded:: 1.2 | ||||
| 
 | ||||
| Default: ``None`` | ||||
| 
 | ||||
| The domain to be used when setting the CSRF cookie.  This can be useful for | ||||
|  | @ -326,8 +324,6 @@ protection is safe from cross-subdomain attacks by default - please see the | |||
| CSRF_COOKIE_NAME | ||||
| ---------------- | ||||
| 
 | ||||
| .. versionadded:: 1.2 | ||||
| 
 | ||||
| Default: ``'csrftoken'`` | ||||
| 
 | ||||
| The name of the cookie to use for the CSRF authentication token. This can be whatever you | ||||
|  | @ -367,8 +363,6 @@ cookie is only sent under an HTTPS connection. | |||
| CSRF_FAILURE_VIEW | ||||
| ----------------- | ||||
| 
 | ||||
| .. versionadded:: 1.2 | ||||
| 
 | ||||
| Default: ``'django.views.csrf.csrf_failure'`` | ||||
| 
 | ||||
| A dotted path to the view function to be used when an incoming request | ||||
|  | @ -386,8 +380,6 @@ end users) indicating the reason the request was rejected.  See | |||
| DATABASES | ||||
| --------- | ||||
| 
 | ||||
| .. versionadded:: 1.2 | ||||
| 
 | ||||
| Default: ``{}`` (Empty dictionary) | ||||
| 
 | ||||
| A dictionary containing the settings for all databases to be used with | ||||
|  | @ -430,12 +422,6 @@ You can use a database backend that doesn't ship with Django by setting | |||
| scratch is left as an exercise to the reader; see the other backends for | ||||
| examples. | ||||
| 
 | ||||
| .. note:: | ||||
|     Prior to Django 1.2, you could use a short version of the backend name | ||||
|     to reference the built-in database backends (e.g., you could use | ||||
|     ``'sqlite3'`` to refer to the SQLite backend). This format has been | ||||
|     deprecated, and will be removed in Django 1.4. | ||||
| 
 | ||||
| .. setting:: HOST | ||||
| 
 | ||||
| HOST | ||||
|  | @ -664,8 +650,6 @@ not provided, Django will use ``'test_' + NAME + '_temp'``. | |||
| DATABASE_ROUTERS | ||||
| ---------------- | ||||
| 
 | ||||
| .. versionadded:: 1.2 | ||||
| 
 | ||||
| Default: ``[]`` (Empty list) | ||||
| 
 | ||||
| The list of routers that will be used to determine which database | ||||
|  | @ -686,9 +670,6 @@ system. Note that if :setting:`USE_L10N` is set to ``True``, then the | |||
| locale-dictated format has higher precedence and will be applied instead. See | ||||
| :tfilter:`allowed date format strings <date>`. | ||||
| 
 | ||||
| .. versionchanged:: 1.2 | ||||
|     This setting can now be overriden by setting :setting:`USE_L10N` to ``True``. | ||||
| 
 | ||||
| See also :setting:`DATETIME_FORMAT`, :setting:`TIME_FORMAT` and :setting:`SHORT_DATE_FORMAT`. | ||||
| 
 | ||||
| .. setting:: DATE_INPUT_FORMATS | ||||
|  | @ -696,8 +677,6 @@ See also :setting:`DATETIME_FORMAT`, :setting:`TIME_FORMAT` and :setting:`SHORT_ | |||
| DATE_INPUT_FORMATS | ||||
| ------------------ | ||||
| 
 | ||||
| .. versionadded:: 1.2 | ||||
| 
 | ||||
| Default:: | ||||
| 
 | ||||
|     ('%Y-%m-%d', '%m/%d/%Y', '%m/%d/%y', '%b %d %Y', | ||||
|  | @ -728,9 +707,6 @@ system. Note that if :setting:`USE_L10N` is set to ``True``, then the | |||
| locale-dictated format has higher precedence and will be applied instead. See | ||||
| :tfilter:`allowed date format strings <date>`. | ||||
| 
 | ||||
| .. versionchanged:: 1.2 | ||||
|     This setting can now be overriden by setting :setting:`USE_L10N` to ``True``. | ||||
| 
 | ||||
| See also :setting:`DATE_FORMAT`, :setting:`TIME_FORMAT` and :setting:`SHORT_DATETIME_FORMAT`. | ||||
| 
 | ||||
| .. setting:: DATETIME_INPUT_FORMATS | ||||
|  | @ -738,8 +714,6 @@ See also :setting:`DATE_FORMAT`, :setting:`TIME_FORMAT` and :setting:`SHORT_DATE | |||
| DATETIME_INPUT_FORMATS | ||||
| ---------------------- | ||||
| 
 | ||||
| .. versionadded:: 1.2 | ||||
| 
 | ||||
| Default:: | ||||
| 
 | ||||
|     ('%Y-%m-%d %H:%M:%S', '%Y-%m-%d %H:%M', '%Y-%m-%d', | ||||
|  | @ -823,8 +797,6 @@ site. | |||
| DECIMAL_SEPARATOR | ||||
| ----------------- | ||||
| 
 | ||||
| .. versionadded:: 1.2 | ||||
| 
 | ||||
| Default: ``'.'`` (Dot) | ||||
| 
 | ||||
| Default decimal separator used when formatting decimal numbers. | ||||
|  | @ -926,8 +898,6 @@ This is only used if ``CommonMiddleware`` is installed (see | |||
| EMAIL_BACKEND | ||||
| ------------- | ||||
| 
 | ||||
| .. versionadded:: 1.2 | ||||
| 
 | ||||
| Default: ``'django.core.mail.backends.smtp.EmailBackend'`` | ||||
| 
 | ||||
| The backend to use for sending emails. For the list of available backends see | ||||
|  | @ -938,8 +908,6 @@ The backend to use for sending emails. For the list of available backends see | |||
| EMAIL_FILE_PATH | ||||
| --------------- | ||||
| 
 | ||||
| .. versionadded:: 1.2 | ||||
| 
 | ||||
| Default: Not defined | ||||
| 
 | ||||
| The directory used by the ``file`` email backend to store output files. | ||||
|  | @ -1086,8 +1054,6 @@ See :doc:`/topics/files` for details. | |||
| FIRST_DAY_OF_WEEK | ||||
| ----------------- | ||||
| 
 | ||||
| .. versionadded:: 1.2 | ||||
| 
 | ||||
| Default: ``0`` (Sunday) | ||||
| 
 | ||||
| Number representing the first day of the week. This is especially useful | ||||
|  | @ -1127,8 +1093,6 @@ of the preferred value or not supplied at all. | |||
| FORMAT_MODULE_PATH | ||||
| ------------------ | ||||
| 
 | ||||
| .. versionadded:: 1.2 | ||||
| 
 | ||||
| Default: ``None`` | ||||
| 
 | ||||
| A full Python path to a Python package that contains format definitions for | ||||
|  | @ -1426,8 +1390,6 @@ Example: ``"http://media.example.com/"`` | |||
| MESSAGE_LEVEL | ||||
| ------------- | ||||
| 
 | ||||
| .. versionadded:: 1.2 | ||||
| 
 | ||||
| Default: `messages.INFO` | ||||
| 
 | ||||
| Sets the minimum message level that will be recorded by the messages | ||||
|  | @ -1437,8 +1399,6 @@ more details. | |||
| MESSAGE_STORAGE | ||||
| --------------- | ||||
| 
 | ||||
| .. versionadded:: 1.2 | ||||
| 
 | ||||
| Default: ``'django.contrib.messages.storage.user_messages.LegacyFallbackStorage'`` | ||||
| 
 | ||||
| Controls where Django stores message data.  See the | ||||
|  | @ -1447,8 +1407,6 @@ Controls where Django stores message data.  See the | |||
| MESSAGE_TAGS | ||||
| ------------ | ||||
| 
 | ||||
| .. versionadded:: 1.2 | ||||
| 
 | ||||
| Default:: | ||||
| 
 | ||||
|     {messages.DEBUG: 'debug', | ||||
|  | @ -1475,11 +1433,6 @@ Default:: | |||
| 
 | ||||
| A tuple of middleware classes to use. See :doc:`/topics/http/middleware`. | ||||
| 
 | ||||
| .. versionchanged:: 1.2 | ||||
|    ``'django.contrib.messages.middleware.MessageMiddleware'`` was added to the | ||||
|    default.  For more information, see the :doc:`messages documentation | ||||
|    </ref/contrib/messages>`. | ||||
| 
 | ||||
| .. setting:: MONTH_DAY_FORMAT | ||||
| 
 | ||||
| MONTH_DAY_FORMAT | ||||
|  | @ -1505,8 +1458,6 @@ See :tfilter:`allowed date format strings <date>`. See also | |||
| NUMBER_GROUPING | ||||
| ---------------- | ||||
| 
 | ||||
| .. versionadded:: 1.2 | ||||
| 
 | ||||
| Default: ``0`` | ||||
| 
 | ||||
| Number of digits grouped together on the integer part of a number. | ||||
|  | @ -1820,8 +1771,6 @@ Whether to save the session data on every request. See | |||
| SHORT_DATE_FORMAT | ||||
| ----------------- | ||||
| 
 | ||||
| .. versionadded:: 1.2 | ||||
| 
 | ||||
| Default: ``m/d/Y`` (e.g. ``12/31/2003``) | ||||
| 
 | ||||
| An available formatting that can be used for displaying date fields on | ||||
|  | @ -1836,8 +1785,6 @@ See also :setting:`DATE_FORMAT` and :setting:`SHORT_DATETIME_FORMAT`. | |||
| SHORT_DATETIME_FORMAT | ||||
| --------------------- | ||||
| 
 | ||||
| .. versionadded:: 1.2 | ||||
| 
 | ||||
| Default: ``m/d/Y P`` (e.g. ``12/31/2003 4 p.m.``) | ||||
| 
 | ||||
| An available formatting that can be used for displaying datetime fields on | ||||
|  | @ -1944,16 +1891,6 @@ A tuple of callables that are used to populate the context in ``RequestContext`` | |||
| These callables take a request object as their argument and return a dictionary | ||||
| of items to be merged into the context. | ||||
| 
 | ||||
| .. versionchanged:: 1.2 | ||||
|    ``django.contrib.messages.context_processors.messages`` was added to the | ||||
|    default.  For more information, see the :doc:`messages documentation | ||||
|    </ref/contrib/messages>`. | ||||
| 
 | ||||
| .. versionchanged:: 1.2 | ||||
|     The auth context processor was moved in this release from its old location | ||||
|     ``django.core.context_processors.auth`` to | ||||
|     ``django.contrib.auth.context_processors.auth``. | ||||
| 
 | ||||
| .. versionadded:: 1.3 | ||||
|     The ``django.core.context_processors.static`` context processor | ||||
|     was added in this release. | ||||
|  | @ -2009,12 +1946,6 @@ used instead of a string. The first item in the tuple should be the ``Loader``'s | |||
| module, subsequent items are passed to the ``Loader`` during initialization. See | ||||
| :doc:`/ref/templates/api`. | ||||
| 
 | ||||
| .. versionchanged:: 1.2 | ||||
|     The class-based API for template loaders was introduced in Django 1.2 | ||||
|     although  the :setting:`TEMPLATE_LOADERS` setting will accept strings | ||||
|     that specify function-based loaders until compatibility with them is | ||||
|     completely removed in Django 1.4. | ||||
| 
 | ||||
| .. setting:: TEMPLATE_STRING_IF_INVALID | ||||
| 
 | ||||
| TEMPLATE_STRING_IF_INVALID | ||||
|  | @ -2032,9 +1963,6 @@ TEST_RUNNER | |||
| 
 | ||||
| Default: ``'django.test.simple.DjangoTestSuiteRunner'`` | ||||
| 
 | ||||
| .. versionchanged:: 1.2 | ||||
|    Prior to 1.2, test runners were a function, not a class. | ||||
| 
 | ||||
| The name of the class to use for starting the test suite. See | ||||
| :doc:`/topics/testing`. | ||||
| 
 | ||||
|  | @ -2045,8 +1973,6 @@ The name of the class to use for starting the test suite. See | |||
| THOUSAND_SEPARATOR | ||||
| ------------------ | ||||
| 
 | ||||
| .. versionadded:: 1.2 | ||||
| 
 | ||||
| Default: ``,`` (Comma) | ||||
| 
 | ||||
| Default thousand separator used when formatting numbers. This setting is | ||||
|  | @ -2071,9 +1997,6 @@ system. Note that if :setting:`USE_L10N` is set to ``True``, then the | |||
| locale-dictated format has higher precedence and will be applied instead. See | ||||
| :tfilter:`allowed date format strings <date>`. | ||||
| 
 | ||||
| .. versionchanged:: 1.2 | ||||
|     This setting can now be overriden by setting :setting:`USE_L10N` to ``True``. | ||||
| 
 | ||||
| See also :setting:`DATE_FORMAT` and :setting:`DATETIME_FORMAT`. | ||||
| 
 | ||||
| .. setting:: TIME_INPUT_FORMATS | ||||
|  | @ -2081,8 +2004,6 @@ See also :setting:`DATE_FORMAT` and :setting:`DATETIME_FORMAT`. | |||
| TIME_INPUT_FORMATS | ||||
| ------------------ | ||||
| 
 | ||||
| .. versionadded:: 1.2 | ||||
| 
 | ||||
| Default: ``('%H:%M:%S', '%H:%M')`` | ||||
| 
 | ||||
| A tuple of formats that will be accepted when inputting data on a time field. | ||||
|  | @ -2104,9 +2025,6 @@ TIME_ZONE | |||
| 
 | ||||
| Default: ``'America/Chicago'`` | ||||
| 
 | ||||
| .. versionchanged:: 1.2 | ||||
|    ``None`` was added as an allowed value. | ||||
| 
 | ||||
| .. versionchanged:: 1.4 | ||||
|    The meaning of this setting now depends on the value of :setting:`USE_TZ`. | ||||
| 
 | ||||
|  | @ -2183,8 +2101,6 @@ See also :setting:`LANGUAGE_CODE`, :setting:`USE_L10N` and :setting:`USE_TZ`. | |||
| USE_L10N | ||||
| -------- | ||||
| 
 | ||||
| .. versionadded:: 1.2 | ||||
| 
 | ||||
| Default: ``False`` | ||||
| 
 | ||||
| A boolean that specifies if localized formatting of data will be enabled by | ||||
|  | @ -2203,8 +2119,6 @@ See also :setting:`LANGUAGE_CODE`, :setting:`USE_I18N` and :setting:`USE_TZ`. | |||
| USE_THOUSAND_SEPARATOR | ||||
| ---------------------- | ||||
| 
 | ||||
| .. versionadded:: 1.2 | ||||
| 
 | ||||
| Default: ``False`` | ||||
| 
 | ||||
| A boolean that specifies whether to display numbers using a thousand separator. | ||||
|  |  | |||
|  | @ -220,8 +220,6 @@ m2m_changed | |||
| .. data:: django.db.models.signals.m2m_changed | ||||
|    :module: | ||||
| 
 | ||||
| .. versionadded:: 1.2 | ||||
| 
 | ||||
| Sent when a :class:`ManyToManyField` is changed on a model instance. | ||||
| Strictly speaking, this is not a model signal since it is sent by the | ||||
| :class:`ManyToManyField`, but since it complements the | ||||
|  | @ -544,9 +542,6 @@ connection_created | |||
| .. data:: django.db.backends.signals.connection_created | ||||
|    :module: | ||||
| 
 | ||||
| .. versionchanged:: 1.2 | ||||
|    The connection argument was added | ||||
| 
 | ||||
| Sent when the database wrapper makes the initial connection to the | ||||
| database.  This is particularly useful if you'd like to send any post | ||||
| connection commands to the SQL backend. | ||||
|  |  | |||
|  | @ -372,21 +372,11 @@ and return a dictionary of items to be merged into the context. By default, | |||
|     "django.core.context_processors.static", | ||||
|     "django.contrib.messages.context_processors.messages") | ||||
| 
 | ||||
| .. versionadded:: 1.2 | ||||
|    In addition to these, ``RequestContext`` always uses | ||||
|    ``django.core.context_processors.csrf``.  This is a security | ||||
|    related context processor required by the admin and other contrib apps, and, | ||||
|    in case of accidental misconfiguration, it is deliberately hardcoded in and | ||||
|    cannot be turned off by the :setting:`TEMPLATE_CONTEXT_PROCESSORS` setting. | ||||
| 
 | ||||
| .. versionadded:: 1.2 | ||||
|    The ``'messages'`` context processor was added.  For more information, see | ||||
|    the :doc:`messages documentation </ref/contrib/messages>`. | ||||
| 
 | ||||
| .. versionchanged:: 1.2 | ||||
|     The auth context processor was moved in this release from its old location | ||||
|     ``django.core.context_processors.auth`` to | ||||
|     ``django.contrib.auth.context_processors.auth``. | ||||
| In addition to these, ``RequestContext`` always uses | ||||
| ``django.core.context_processors.csrf``.  This is a security | ||||
| related context processor required by the admin and other contrib apps, and, | ||||
| in case of accidental misconfiguration, it is deliberately hardcoded in and | ||||
| cannot be turned off by the :setting:`TEMPLATE_CONTEXT_PROCESSORS` setting. | ||||
| 
 | ||||
| Each processor is applied in order. That means, if one processor adds a | ||||
| variable to the context and a second processor adds a variable with the same | ||||
|  | @ -447,10 +437,6 @@ If :setting:`TEMPLATE_CONTEXT_PROCESSORS` contains this processor, every | |||
|   ``django.contrib.auth.context_processors.PermWrapper``, representing the | ||||
|   permissions that the currently logged-in user has. | ||||
| 
 | ||||
| .. versionchanged:: 1.2 | ||||
|     This context processor was moved in this release from | ||||
|     ``django.core.context_processors.auth`` to its current location. | ||||
| 
 | ||||
| .. versionchanged:: 1.3 | ||||
|     Prior to version 1.3, ``PermWrapper`` was located in | ||||
|     ``django.contrib.auth.context_processors``. | ||||
|  | @ -503,8 +489,6 @@ value of the :setting:`STATIC_URL` setting. | |||
| django.core.context_processors.csrf | ||||
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | ||||
| 
 | ||||
| .. versionadded:: 1.2 | ||||
| 
 | ||||
| This processor adds a token that is needed by the :ttag:`csrf_token` template | ||||
| tag for protection against :doc:`Cross Site Request Forgeries | ||||
| </ref/contrib/csrf>`. | ||||
|  | @ -527,15 +511,6 @@ If :setting:`TEMPLATE_CONTEXT_PROCESSORS` contains this processor, every | |||
|   via the user model (using ``user.message_set.create``) or through | ||||
|   the :doc:`messages framework </ref/contrib/messages>`. | ||||
| 
 | ||||
| .. versionadded:: 1.2 | ||||
|    This template context variable was previously supplied by the ``'auth'`` | ||||
|    context processor.  For backwards compatibility the ``'auth'`` context | ||||
|    processor will continue to supply the ``messages`` variable until Django | ||||
|    1.4.  If you use the ``messages`` variable, your project will work with | ||||
|    either (or both) context processors, but it is recommended to add | ||||
|    ``django.contrib.messages.context_processors.messages`` so your project | ||||
|    will be prepared for the future upgrade. | ||||
| 
 | ||||
| Writing your own context processors | ||||
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | ||||
| 
 | ||||
|  | @ -657,11 +632,6 @@ by editing your :setting:`TEMPLATE_LOADERS` setting. :setting:`TEMPLATE_LOADERS` | |||
| should be a tuple of strings, where each string represents a template loader | ||||
| class. Here are the template loaders that come with Django: | ||||
| 
 | ||||
| .. versionchanged:: 1.2 | ||||
|     Template loaders were based on callables (usually functions) before Django | ||||
|     1.2, starting with the 1.2 release there is a new class-based API, all the | ||||
|     loaders described below implement this new API. | ||||
| 
 | ||||
| ``django.template.loaders.filesystem.Loader`` | ||||
|     Loads templates from the filesystem, according to :setting:`TEMPLATE_DIRS`. | ||||
|     This loader is enabled by default. | ||||
|  | @ -800,8 +770,6 @@ and any setting starting with ``TEMPLATE_`` is of obvious interest. | |||
| Using an alternative template language | ||||
| ====================================== | ||||
| 
 | ||||
| .. versionadded:: 1.2 | ||||
| 
 | ||||
| The Django ``Template`` and ``Loader`` classes implement a simple API for | ||||
| loading and rendering templates. By providing some simple wrapper classes that | ||||
| implement this API we can use third party template systems like `Jinja2 | ||||
|  |  | |||
|  | @ -58,10 +58,8 @@ Ignores everything between ``{% comment %}`` and ``{% endcomment %}``. | |||
| csrf_token | ||||
| ^^^^^^^^^^ | ||||
| 
 | ||||
| In the Django 1.1.X series, this is a no-op tag that returns an empty string | ||||
| for future compatibility purposes.  In Django 1.2 and later, it is used for | ||||
| CSRF protection, as described in the documentation for :doc:`Cross Site Request | ||||
| Forgeries </ref/contrib/csrf>`. | ||||
| This tag is used for CSRF protection, as described in the documentation for | ||||
| :doc:`Cross Site Request Forgeries </ref/contrib/csrf>`. | ||||
| 
 | ||||
| .. templatetag:: cycle | ||||
| 
 | ||||
|  | @ -410,8 +408,6 @@ variables or to negate a given variable:: | |||
|         There are some athletes and absolutely no coaches. | ||||
|     {% endif %} | ||||
| 
 | ||||
| .. versionchanged:: 1.2 | ||||
| 
 | ||||
| Use of both ``and`` and ``or`` clauses within the same tag is allowed, with | ||||
| ``and`` having higher precedence than ``or`` e.g.:: | ||||
| 
 | ||||
|  | @ -426,9 +422,6 @@ will be interpreted like: | |||
| Use of actual brackets in the :ttag:`if` tag is invalid syntax.  If you need | ||||
| them to indicate precedence, you should use nested :ttag:`if` tags. | ||||
| 
 | ||||
| .. versionadded:: 1.2 | ||||
| 
 | ||||
| 
 | ||||
| :ttag:`if` tags may also use the operators ``==``, ``!=``, ``<``, ``>``, | ||||
| ``<=``, ``>=`` and ``in`` which work as follows: | ||||
| 
 | ||||
|  | @ -637,9 +630,8 @@ You cannot check for equality with Python objects such as ``True`` or | |||
| ``False``.  If you need to test if something is true or false, use the | ||||
| :ttag:`if` tag instead. | ||||
| 
 | ||||
| .. versionadded:: 1.2 | ||||
|    An alternative to the ``ifequal`` tag is to use the :ttag:`if` tag and the | ||||
|    ``==`` operator. | ||||
| An alternative to the ``ifequal`` tag is to use the :ttag:`if` tag and the | ||||
| ``==`` operator. | ||||
| 
 | ||||
| .. templatetag:: ifnotequal | ||||
| 
 | ||||
|  | @ -649,9 +641,8 @@ ifnotequal | |||
| Just like :ttag:`ifequal`, except it tests that the two arguments are not | ||||
| equal. | ||||
| 
 | ||||
| .. versionadded:: 1.2 | ||||
|    An alternative to the ``ifnotequal`` tag is to use the :ttag:`if` tag and | ||||
|    the ``!=`` operator. | ||||
| An alternative to the ``ifnotequal`` tag is to use the :ttag:`if` tag and | ||||
| the ``!=`` operator. | ||||
| 
 | ||||
| .. templatetag:: include | ||||
| 
 | ||||
|  | @ -1127,9 +1118,6 @@ For example:: | |||
| 
 | ||||
| If ``value`` is ``4``, then the output will be ``6``. | ||||
| 
 | ||||
| .. versionchanged:: 1.2 | ||||
|    The following behavior didn't exist in previous Django versions. | ||||
| 
 | ||||
| This filter will first try to coerce both values to integers. If this fails, | ||||
| it'll attempt to add the values together anyway. This will work on some data | ||||
| types (strings, list, etc.) and fail on others. If it fails, the result will | ||||
|  | @ -1289,10 +1277,6 @@ Z                 Time zone offset in seconds. The          ``-43200`` to ``4320 | |||
|                   UTC is always positive. | ||||
| ================  ========================================  ===================== | ||||
| 
 | ||||
| .. versionadded:: 1.2 | ||||
| 
 | ||||
| The ``c`` and ``u`` format specification characters were added in Django 1.2. | ||||
| 
 | ||||
| .. versionadded:: 1.4 | ||||
| 
 | ||||
| The ``e`` and ``o`` format specification characters were added in Django 1.4. | ||||
|  | @ -1326,9 +1310,6 @@ When used without a format string:: | |||
| ...the formatting string defined in the :setting:`DATE_FORMAT` setting will be | ||||
| used, without applying any localization. | ||||
| 
 | ||||
| .. versionchanged:: 1.2 | ||||
|     Predefined formats can now be influenced by the current locale. | ||||
| 
 | ||||
| .. templatefilter:: default | ||||
| 
 | ||||
| default | ||||
|  | @ -1985,9 +1966,6 @@ When used without a format string:: | |||
| ...the formatting string defined in the :setting:`TIME_FORMAT` setting will be | ||||
| used, without applying any localization. | ||||
| 
 | ||||
| .. versionchanged:: 1.2 | ||||
|     Predefined formats can now be influenced by the current locale. | ||||
| 
 | ||||
| .. templatefilter:: timesince | ||||
| 
 | ||||
| timesince | ||||
|  |  | |||
|  | @ -2,7 +2,6 @@ | |||
| Validators | ||||
| ========== | ||||
| 
 | ||||
| .. versionadded:: 1.2 | ||||
| .. module:: django.core.validators | ||||
|     :synopsis: Validation utilities and base classes | ||||
| 
 | ||||
|  |  | |||
|  | @ -64,11 +64,8 @@ Fields | |||
| 
 | ||||
|     .. attribute:: models.User.username | ||||
| 
 | ||||
|         Required. 30 characters or fewer. Alphanumeric characters only | ||||
|         (letters, digits and underscores). | ||||
| 
 | ||||
|         .. versionchanged:: 1.2 | ||||
|            Usernames may now contain ``@``, ``+``, ``.`` and ``-`` characters. | ||||
|         Required. 30 characters or fewer. Usernames may contain alphanumeric, | ||||
|         ``_``, ``@``, ``+``, ``.`` and ``-`` characters. | ||||
| 
 | ||||
|     .. attribute:: models.User.first_name | ||||
| 
 | ||||
|  | @ -207,8 +204,6 @@ Methods | |||
|         Returns a set of permission strings that the user has, through his/her | ||||
|         groups. | ||||
| 
 | ||||
|         .. versionadded:: 1.2 | ||||
| 
 | ||||
|         If ``obj`` is passed in, only returns the group permissions for | ||||
|         this specific object. | ||||
| 
 | ||||
|  | @ -217,8 +212,6 @@ Methods | |||
|         Returns a set of permission strings that the user has, both through | ||||
|         group and user permissions. | ||||
| 
 | ||||
|         .. versionadded:: 1.2 | ||||
| 
 | ||||
|         If ``obj`` is passed in, only returns the permissions for this | ||||
|         specific object. | ||||
| 
 | ||||
|  | @ -229,8 +222,6 @@ Methods | |||
|         `permissions`_ section below). If the user is inactive, this method will | ||||
|         always return ``False``. | ||||
| 
 | ||||
|         .. versionadded:: 1.2 | ||||
| 
 | ||||
|         If ``obj`` is passed in, this method won't check for a permission for | ||||
|         the model, but for this specific object. | ||||
| 
 | ||||
|  | @ -241,8 +232,6 @@ Methods | |||
|         ``"<app label>.<permission codename>"``. If the user is inactive, | ||||
|         this method will always return ``False``. | ||||
| 
 | ||||
|         .. versionadded:: 1.2 | ||||
| 
 | ||||
|         If ``obj`` is passed in, this method won't check for permissions for | ||||
|         the model, but for the specific object. | ||||
| 
 | ||||
|  | @ -349,9 +338,6 @@ Django requires add *and* change permissions as a slight security measure. | |||
| Changing passwords | ||||
| ~~~~~~~~~~~~~~~~~~ | ||||
| 
 | ||||
| .. versionadded:: 1.2 | ||||
|    The ``manage.py changepassword`` command was added. | ||||
| 
 | ||||
| :djadmin:`manage.py changepassword *username* <changepassword>` offers a method | ||||
| of changing a User's password from the command line. It prompts you to | ||||
| change the password of a given user which you must enter twice. If | ||||
|  | @ -1046,8 +1032,6 @@ The login_required decorator | |||
| 
 | ||||
|         {% endblock %} | ||||
| 
 | ||||
|     .. versionadded:: 1.2 | ||||
| 
 | ||||
|     If you are using alternate authentication (see | ||||
|     :ref:`authentication-backends`) you can pass a custom authentication form | ||||
|     to the login view via the ``authentication_form`` parameter. This form must | ||||
|  | @ -1140,8 +1124,6 @@ includes a few other useful built-in views located in | |||
|     * ``post_change_redirect``: The URL to redirect to after a successful | ||||
|       password change. | ||||
| 
 | ||||
|       .. versionadded:: 1.2 | ||||
| 
 | ||||
|     * ``password_change_form``: A custom "change password" form which must | ||||
|       accept a ``user`` keyword argument. The form is responsible for | ||||
|       actually changing the user's password. Defaults to | ||||
|  | @ -1899,8 +1881,6 @@ the ``auth_permission`` table most of the time. | |||
| Authorization for anonymous users | ||||
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | ||||
| 
 | ||||
| .. versionchanged:: 1.2 | ||||
| 
 | ||||
| An anonymous user is one that is not authenticated i.e. they have provided no | ||||
| valid authentication details. However, that does not necessarily mean they are | ||||
| not authorized to do anything. At the most basic level, most Web sites | ||||
|  |  | |||
|  | @ -83,12 +83,6 @@ two most common are `python-memcached`_ and `pylibmc`_. | |||
| .. _`python-memcached`: ftp://ftp.tummy.com/pub/python-memcached/ | ||||
| .. _`pylibmc`: http://sendapatch.se/projects/pylibmc/ | ||||
| 
 | ||||
| .. versionchanged:: 1.2 | ||||
|     In Django 1.0 and 1.1, you could also use ``cmemcache`` as a binding. | ||||
|     However, support for this library was deprecated in 1.2 due to | ||||
|     a lack of maintenance on the ``cmemcache`` library itself. Support for | ||||
|     ``cmemcache`` will be removed completely in Django 1.4. | ||||
| 
 | ||||
| .. versionchanged:: 1.3 | ||||
|     Support for ``pylibmc`` was added. | ||||
| 
 | ||||
|  | @ -493,8 +487,6 @@ more on these decorators. | |||
| 
 | ||||
| .. _i18n-cache-key: | ||||
| 
 | ||||
| .. versionadded:: 1.2 | ||||
| 
 | ||||
| If :setting:`USE_I18N` is set to ``True`` then the generated cache key will | ||||
| include the name of the active :term:`language<language code>` -- see also | ||||
| :ref:`how-django-discovers-language-preference`). This allows you to easily | ||||
|  | @ -737,8 +729,6 @@ actually exist in the cache (and haven't expired):: | |||
|     >>> cache.get_many(['a', 'b', 'c']) | ||||
|     {'a': 1, 'b': 2, 'c': 3} | ||||
| 
 | ||||
| .. versionadded:: 1.2 | ||||
| 
 | ||||
| To set multiple values more efficiently, use ``set_many()`` to pass a dictionary | ||||
| of key-value pairs:: | ||||
| 
 | ||||
|  | @ -753,15 +743,11 @@ clearing the cache for a particular object:: | |||
| 
 | ||||
|     >>> cache.delete('a') | ||||
| 
 | ||||
| .. versionadded:: 1.2 | ||||
| 
 | ||||
| If you want to clear a bunch of keys at once, ``delete_many()`` can take a list | ||||
| of keys to be cleared:: | ||||
| 
 | ||||
|     >>> cache.delete_many(['a', 'b', 'c']) | ||||
| 
 | ||||
| .. versionadded:: 1.2 | ||||
| 
 | ||||
| Finally, if you want to delete all the keys in the cache, use | ||||
| ``cache.clear()``.  Be careful with this; ``clear()`` will remove *everything* | ||||
| from the cache, not just the keys set by your application. :: | ||||
|  |  | |||
|  | @ -881,8 +881,6 @@ field. This would normally cause a problem in abstract base classes, since the | |||
| fields on this class are included into each of the child classes, with exactly | ||||
| the same values for the attributes (including :attr:`~django.db.models.ForeignKey.related_name`) each time. | ||||
| 
 | ||||
| .. versionchanged:: 1.2 | ||||
| 
 | ||||
| To work around this problem, when you are using :attr:`~django.db.models.ForeignKey.related_name` in an | ||||
| abstract base class (only), part of the name should contain | ||||
| ``'%(app_label)s'`` and ``'%(class)s'``. | ||||
|  |  | |||
|  | @ -2,8 +2,6 @@ | |||
| Multiple databases | ||||
| ================== | ||||
| 
 | ||||
| .. versionadded:: 1.2 | ||||
| 
 | ||||
| This topic guide describes Django's support for interacting with | ||||
| multiple databases. Most of the rest of Django's documentation assumes | ||||
| you are interacting with a single database. If you want to interact | ||||
|  |  | |||
|  | @ -18,8 +18,6 @@ __ `executing custom SQL directly`_ | |||
| Performing raw queries | ||||
| ====================== | ||||
| 
 | ||||
| .. versionadded:: 1.2 | ||||
| 
 | ||||
| The ``raw()`` manager method can be used to perform raw SQL queries that | ||||
| return model instances: | ||||
| 
 | ||||
|  |  | |||
|  | @ -365,8 +365,6 @@ subtype. For example:: | |||
| Email backends | ||||
| ============== | ||||
| 
 | ||||
| .. versionadded:: 1.2 | ||||
| 
 | ||||
| The actual sending of an email is handled by the email backend. | ||||
| 
 | ||||
| The email backend class has the following methods: | ||||
|  |  | |||
|  | @ -102,15 +102,12 @@ limit the maximum number of empty forms the formset will display:: | |||
|     <tr><th><label for="id_form-0-title">Title:</label></th><td><input type="text" name="form-0-title" id="id_form-0-title" /></td></tr> | ||||
|     <tr><th><label for="id_form-0-pub_date">Pub date:</label></th><td><input type="text" name="form-0-pub_date" id="id_form-0-pub_date" /></td></tr> | ||||
| 
 | ||||
| .. versionchanged:: 1.2 | ||||
| 
 | ||||
| If the value of ``max_num`` is greater than the number of existing | ||||
| objects, up to ``extra`` additional blank forms will be added to the formset, | ||||
| so long as the total number of forms does not exceed ``max_num``. | ||||
| 
 | ||||
| A ``max_num`` value of ``None`` (the default) puts no limit on the number of | ||||
| forms displayed. Please note that the default value of ``max_num`` was changed | ||||
| from ``0`` to ``None`` in version 1.2 to allow ``0`` as a valid value. | ||||
| forms displayed. | ||||
| 
 | ||||
| Formset validation | ||||
| ------------------ | ||||
|  | @ -210,8 +207,6 @@ pre-filled, and is also used to determine how many forms are required. You | |||
| will probably never need to override either of these methods, so please be | ||||
| sure you understand what they do before doing so. | ||||
| 
 | ||||
| .. versionadded:: 1.2 | ||||
| 
 | ||||
| ``empty_form`` | ||||
| ~~~~~~~~~~~~~~ | ||||
| 
 | ||||
|  |  | |||
|  | @ -109,9 +109,6 @@ Model field                      Form field | |||
| ``URLField``                     ``URLField`` | ||||
| ===============================  ======================================== | ||||
| 
 | ||||
| .. versionadded:: 1.2 | ||||
|     The ``BigIntegerField`` is new in Django 1.2. | ||||
| 
 | ||||
| 
 | ||||
| As you might expect, the ``ForeignKey`` and ``ManyToManyField`` model field | ||||
| types are special cases: | ||||
|  | @ -362,9 +359,6 @@ Since the Author model has only 3 fields, 'name', 'title', and | |||
| Overriding the default field types or widgets | ||||
| --------------------------------------------- | ||||
| 
 | ||||
| .. versionadded:: 1.2 | ||||
|     The ``widgets`` attribute is new in Django 1.2. | ||||
| 
 | ||||
| The default field types, as described in the `Field types`_ table above, are | ||||
| sensible defaults. If you have a ``DateField`` in your model, chances are you'd | ||||
| want that to be represented as a ``DateField`` in your form. But | ||||
|  | @ -670,8 +664,6 @@ are saved properly. | |||
| Limiting the number of editable objects | ||||
| --------------------------------------- | ||||
| 
 | ||||
| .. versionchanged:: 1.2 | ||||
| 
 | ||||
| As with regular formsets, you can use the ``max_num`` and ``extra`` parameters | ||||
| to ``modelformset_factory`` to limit the number of extra forms displayed. | ||||
| 
 | ||||
|  | @ -698,8 +690,6 @@ so long as the total number of forms does not exceed ``max_num``:: | |||
|     <tr><th><label for="id_form-2-name">Name:</label></th><td><input id="id_form-2-name" type="text" name="form-2-name" value="Walt Whitman" maxlength="100" /><input type="hidden" name="form-2-id" value="2" id="id_form-2-id" /></td></tr> | ||||
|     <tr><th><label for="id_form-3-name">Name:</label></th><td><input id="id_form-3-name" type="text" name="form-3-name" maxlength="100" /><input type="hidden" name="form-3-id" id="id_form-3-id" /></td></tr> | ||||
| 
 | ||||
| .. versionchanged:: 1.2 | ||||
| 
 | ||||
| A ``max_num`` value of ``None`` (the default) puts no limit on the number of | ||||
| forms displayed. | ||||
| 
 | ||||
|  |  | |||
|  | @ -314,9 +314,6 @@ that should be called if none of the URL patterns match. | |||
| By default, this is ``'django.views.defaults.page_not_found'``. That default | ||||
| value should suffice. | ||||
| 
 | ||||
| .. versionchanged:: 1.2 | ||||
|     Previous versions of Django only accepted strings representing import paths. | ||||
| 
 | ||||
| handler500 | ||||
| ---------- | ||||
| 
 | ||||
|  | @ -329,9 +326,6 @@ have runtime errors in view code. | |||
| By default, this is ``'django.views.defaults.server_error'``. That default | ||||
| value should suffice. | ||||
| 
 | ||||
| .. versionchanged:: 1.2 | ||||
|     Previous versions of Django only accepted strings representing import paths. | ||||
| 
 | ||||
| Notes on capturing text in URLs | ||||
| =============================== | ||||
| 
 | ||||
|  |  | |||
|  | @ -4,8 +4,6 @@ | |||
| Format localization | ||||
| =================== | ||||
| 
 | ||||
| .. versionadded:: 1.2 | ||||
| 
 | ||||
| Overview | ||||
| ======== | ||||
| 
 | ||||
|  |  | |||
|  | @ -1039,8 +1039,6 @@ Django comes with a tool, :djadmin:`django-admin.py makemessages | |||
|     commands from the GNU gettext toolset: ``xgettext``, ``msgfmt``, | ||||
|     ``msgmerge`` and ``msguniq``. | ||||
| 
 | ||||
|     .. versionchanged:: 1.2 | ||||
| 
 | ||||
|     The minimum version of the ``gettext`` utilities supported is 0.15. | ||||
| 
 | ||||
| To create or update a message file, run this command:: | ||||
|  |  | |||
|  | @ -188,11 +188,6 @@ In particular, :ref:`lazy translation objects <lazy-translations>` need a | |||
| Natural keys | ||||
| ------------ | ||||
| 
 | ||||
| .. versionadded:: 1.2 | ||||
| 
 | ||||
|    The ability to use natural keys when serializing/deserializing data was | ||||
|    added in the 1.2 release. | ||||
| 
 | ||||
| The default serialization strategy for foreign keys and many-to-many relations | ||||
| is to serialize the value of the primary key(s) of the objects in the relation. | ||||
| This strategy works well for most objects, but it can cause difficulty in some | ||||
|  |  | |||
|  | @ -291,9 +291,6 @@ label:: | |||
| 
 | ||||
|     $ ./manage.py test animals.AnimalTestCase.test_animals_can_speak | ||||
| 
 | ||||
| .. versionadded:: 1.2 | ||||
|    The ability to select individual doctests was added. | ||||
| 
 | ||||
| You can use the same rules if you're using doctests. Django will use the | ||||
| test label as a path to the test method or class that you want to run. | ||||
| If your ``models.py`` or ``tests.py`` has a function with a doctest, or | ||||
|  | @ -311,9 +308,6 @@ If you're using a ``__test__`` dictionary to specify doctests for a | |||
| module, Django will use the label as a key in the ``__test__`` dictionary | ||||
| for defined in ``models.py`` and ``tests.py``. | ||||
| 
 | ||||
| .. versionadded:: 1.2 | ||||
|    You can now trigger a graceful exit from a test run by pressing ``Ctrl-C``. | ||||
| 
 | ||||
| If you press ``Ctrl-C`` while the tests are running, the test runner will | ||||
| wait for the currently running test to complete and then exit gracefully. | ||||
| During a graceful exit the test runner will output details of any test | ||||
|  | @ -392,8 +386,6 @@ advanced settings. | |||
| Testing master/slave configurations | ||||
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | ||||
| 
 | ||||
| .. versionadded:: 1.2 | ||||
| 
 | ||||
| If you're testing a multiple database configuration with master/slave | ||||
| replication, this strategy of creating test databases poses a problem. | ||||
| When the test databases are created, there won't be any replication, | ||||
|  | @ -1387,8 +1379,6 @@ Multi-database support | |||
| 
 | ||||
| .. attribute:: TestCase.multi_db | ||||
| 
 | ||||
| .. versionadded:: 1.2 | ||||
| 
 | ||||
| Django sets up a test database corresponding to every database that is | ||||
| defined in the :setting:`DATABASES` definition in your settings | ||||
| file. However, a big part of the time taken to run a Django TestCase | ||||
|  | @ -1512,9 +1502,6 @@ Assertions | |||
| 
 | ||||
| .. currentmodule:: django.test | ||||
| 
 | ||||
| .. versionchanged:: 1.2 | ||||
|     Added ``msg_prefix`` argument. | ||||
| 
 | ||||
| As Python's normal :class:`unittest.TestCase` class implements assertion methods | ||||
| such as :meth:`~unittest.TestCase.assertTrue` and | ||||
| :meth:`~unittest.TestCase.assertEqual`, Django's custom :class:`TestCase` class | ||||
|  | @ -2022,9 +2009,6 @@ process to satisfy whatever testing requirements you may have. | |||
| Defining a test runner | ||||
| ---------------------- | ||||
| 
 | ||||
| .. versionchanged:: 1.2 | ||||
|    Prior to 1.2, test runners were a single function, not a class. | ||||
| 
 | ||||
| .. currentmodule:: django.test.simple | ||||
| 
 | ||||
| A test runner is a class defining a ``run_tests()`` method. Django ships | ||||
|  |  | |||
		Loading…
	
		Reference in New Issue
	
	Block a user