p31829507
/
django
mirror of https://github.com/django/django.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

Refs #30052 -- Clarified that defer() and only() do not work with aggregated fields.

This commit is contained in:
Vyacheslav Dmitriev 2023-07-20 20:02:17 +03:00 committed by GitHub
parent d7d80040c1
commit b126f69416
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 8 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

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

@ -1709,6 +1709,11 @@ never defer the loading of the primary key. If you are using
loading of the field that connects from the primary model to the related
one, doing so will result in an error.
Similarly, calling ``defer()`` (or its counterpart :meth:`only()`) including an
argument from an aggregation (e.g. using the result of :meth:`annotate()`)
doesn't make sense: doing so will raise an exception. The aggregated values
will always be fetched into the resulting queryset.
.. note::
The ``defer()`` method (and its cousin, :meth:`only()`, below) are only for
@ -1803,8 +1808,9 @@ All of the cautions in the note for the :meth:`defer` documentation apply to
``only()`` as well. Use it cautiously and only after exhausting your other
options.
Using :meth:`only` and omitting a field requested using :meth:`select_related`
is an error as well.
Using ``only()`` and omitting a field requested using :meth:`select_related` is
an error as well. On the other hand, invoking ``only()`` without any arguments,
will return every field (including annotations) fetched by the queryset.
As with ``defer()``, you cannot access the non-loaded fields from asynchronous
code and expect them to load. Instead, you will get a