mirror of
https://github.com/django/django.git
synced 2025-10-24 06:06:09 +00:00
Fixed incorrect formatting for inline pluralized code references in docs.
This commit is contained in:
@@ -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")
|
||||
|
||||
@@ -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
|
||||
|
||||
@@ -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
|
||||
|
||||
|
||||
Reference in New Issue
Block a user