mirrors/django
1
0
Fork 0
mirror of https://github.com/django/django.git synced 2025-10-24 06:06:09 +00:00
Code Issues 32 Releases Wiki Activity

Fixed incorrect formatting for inline pluralized code references in docs.

Browse Source
This commit is contained in:
Clifford Gama
2025-03-13 20:18:35 +02:00
committed by GitHub
parent e7a9d756ee
commit efe3ca09e0
11 changed files with 64 additions and 58 deletions
Download Patch File Download Diff File Expand all files Collapse all files

3
docs/ref/class-based-views/mixins-editing.txt
View File

@@ -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

6
docs/ref/databases.txt
View File

@@ -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.

4
docs/ref/models/expressions.txt
View File

@@ -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")

5
docs/ref/models/fields.txt
View File

@@ -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

20
docs/ref/models/querysets.txt
View File

@@ -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