diff options
Diffstat (limited to 'docs/ref')
| -rw-r--r-- | docs/ref/class-based-views/mixins-editing.txt | 3 | ||||
| -rw-r--r-- | docs/ref/databases.txt | 6 | ||||
| -rw-r--r-- | docs/ref/models/expressions.txt | 4 | ||||
| -rw-r--r-- | docs/ref/models/fields.txt | 5 | ||||
| -rw-r--r-- | docs/ref/models/querysets.txt | 20 |
5 files changed, 20 insertions, 18 deletions
diff --git a/docs/ref/class-based-views/mixins-editing.txt b/docs/ref/class-based-views/mixins-editing.txt index aebbae04ae..f17253dfa7 100644 --- a/docs/ref/class-based-views/mixins-editing.txt +++ b/docs/ref/class-based-views/mixins-editing.txt @@ -97,7 +97,8 @@ The following mixins are used to construct Django's editing views: .. class:: django.views.generic.edit.ModelFormMixin - A form mixin that works on ``ModelForms``, rather than a standalone form. + A form mixin that provides facilities for working with a ``ModelForm``, + rather than a standalone form. Since this is a subclass of :class:`~django.views.generic.detail.SingleObjectMixin`, instances of this diff --git a/docs/ref/databases.txt b/docs/ref/databases.txt index 8a36ac9bad..36a541f212 100644 --- a/docs/ref/databases.txt +++ b/docs/ref/databases.txt @@ -824,7 +824,7 @@ Substring matching and case sensitivity For all SQLite versions, there is some slightly counterintuitive behavior when attempting to match some types of strings. These are triggered when using the -:lookup:`iexact` or :lookup:`contains` filters in Querysets. The behavior +:lookup:`iexact` or :lookup:`contains` filters in querysets. The behavior splits into two cases: 1. For substring matching, all matches are done case-insensitively. That is a @@ -1213,8 +1213,8 @@ string, and the data is silently converted to reflect this assumption. ``TextField`` limitations ------------------------- -The Oracle backend stores ``TextFields`` as ``NCLOB`` columns. Oracle imposes -some limitations on the usage of such LOB columns in general: +The Oracle backend stores each ``TextField`` as an ``NCLOB`` column. Oracle +imposes some limitations on the usage of such LOB columns in general: * LOB columns may not be used as primary keys. diff --git a/docs/ref/models/expressions.txt b/docs/ref/models/expressions.txt index c3c9ebba7a..060450b6d8 100644 --- a/docs/ref/models/expressions.txt +++ b/docs/ref/models/expressions.txt @@ -164,8 +164,8 @@ To access the new value saved this way, the object must be reloaded:: reporter.refresh_from_db() As well as being used in operations on single instances as above, ``F()`` can -be used on ``QuerySets`` of object instances, with ``update()``. This reduces -the two queries we were using above - the ``get()`` and the +be used with ``update()`` to perform bulk updates on a ``QuerySet``. This +reduces the two queries we were using above - the ``get()`` and the :meth:`~Model.save()` - to just one:: reporter = Reporters.objects.filter(name="Tintin") diff --git a/docs/ref/models/fields.txt b/docs/ref/models/fields.txt index c45688184d..6d4ca657fc 100644 --- a/docs/ref/models/fields.txt +++ b/docs/ref/models/fields.txt @@ -1836,8 +1836,9 @@ The possible values for :attr:`~ForeignKey.on_delete` are found in limit_choices_to={"is_staff": True}, ) - causes the corresponding field on the ``ModelForm`` to list only ``Users`` - that have ``is_staff=True``. This may be helpful in the Django admin. + causes the corresponding field on the ``ModelForm`` to list only ``User`` + instances that have ``is_staff=True``. This may be helpful in the Django + admin. The callable form can be helpful, for instance, when used in conjunction with the Python ``datetime`` module to limit selections by date range. For diff --git a/docs/ref/models/querysets.txt b/docs/ref/models/querysets.txt index f824b3050f..cb3f75afca 100644 --- a/docs/ref/models/querysets.txt +++ b/docs/ref/models/querysets.txt @@ -135,8 +135,8 @@ described here. .. admonition:: You can't share pickles between versions - Pickles of ``QuerySets`` are only valid for the version of Django that - was used to generate them. If you generate a pickle using Django + Pickles of ``QuerySet`` objects are only valid for the version of Django + that was used to generate them. If you generate a pickle using Django version N, there is no guarantee that pickle will be readable with Django version N+1. Pickles should not be used as part of a long-term archival strategy. @@ -1217,8 +1217,8 @@ the items, it will find them in a prefetched ``QuerySet`` cache that was populated in a single query. That is, all the relevant toppings will have been fetched in a single query, -and used to make ``QuerySets`` that have a pre-filled cache of the relevant -results; these ``QuerySets`` are then used in the ``self.toppings.all()`` calls. +and used to make ``QuerySet`` instances that have a pre-filled cache of the +relevant results; these are then used in the ``self.toppings.all()`` calls. The additional queries in ``prefetch_related()`` are executed after the ``QuerySet`` has begun to be evaluated and the primary query has been executed. @@ -1242,16 +1242,16 @@ function. Note that the result cache of the primary ``QuerySet`` and all specified related objects will then be fully loaded into memory. This changes the typical -behavior of ``QuerySets``, which normally try to avoid loading all objects into -memory before they are needed, even after a query has been executed in the +behavior of a ``QuerySet``, which normally tries to avoid loading all objects +into memory before they are needed, even after a query has been executed in the database. .. note:: - Remember that, as always with ``QuerySets``, any subsequent chained methods - which imply a different database query will ignore previously cached - results, and retrieve data using a fresh database query. So, if you write - the following: + Remember that, as always with ``QuerySet`` objects, any subsequent chained + methods which imply a different database query will ignore previously + cached results, and retrieve data using a fresh database query. So, if you + write the following: .. code-block:: pycon |