In Django, how do you prefetch related objects for a list of model instances that did not come from a QuerySet?

## The gap prefetch_related() leaves `prefetch_related()` is a `QuerySet` method: it records lookups and applies them when that QuerySet is evaluated. Code often ends up holding model instances that no QuerySet will evaluate again: - a list of `Order` objects read back from a cache; - instances assembled from two QuerySets and merged or sorted in Python; - an object fetched earlier with `get()`, before anyone knew its items would be needed; - a helper function that receives `list[Order]` from its caller. Looping over `order.items.all()` on such a list runs one query per order, and there is no QuerySet left to call `prefetch_related()` on. ## prefetch_related_objects() `django.db.models.prefetch_related_objects(model_instances, *related_lookups)` runs the prefetch machinery against an iterable you already have. It is the same routine `prefetch_related()` uses internally after the main query, exposed as a function. ```python from django.db.models import Prefetch, prefetch_related_objects orders = load_cached_orders() # a list of Order instances prefetch_related_objects( orders, Prefetch('items', queryset=OrderItem.objects.select_related('product')), ) ``` What happens: 1. Django reads the lookups, which may be strings like `'items__product'` or `Prefetch` objects. 2. For each lookup level it skips instances whose relation is already fetched and runs one batched query for the rest. 3. It stores the results in each instance's prefetch cache, or on the `to_attr` attribute, exactly as `prefetch_related()` would. 4. It returns `None`: the instances are modified **in place**. ## Compared with prefetch_related() | | `QuerySet.prefetch_related()` | `prefetch_related_objects()` | |---|---|---| | Called on | an unevaluated QuerySet | a re-iterable collection of instances | | When queries run | when the QuerySet is evaluated | immediately, during the call | | Accepts `Prefetch` objects | yes | yes | | Returns | a new QuerySet | `None`; caches are filled in place | | Async form | evaluate the QuerySet with `async for` | `aprefetch_related_objects()` | ## Rules and limits - **Same model class.** Django documents that the instances must all be of the same class; the prefetch inspects the first instance and assumes the rest match. - **Iterable more than once.** Pass a list or tuple, not a generator, because the function walks the collection several times. - **Already-fetched relations are skipped.** An instance whose `items` were prefetched earlier is not queried again for that lookup. - **No joins.** There is no `select_related()` counterpart for plain lists; a `ForeignKey` named in the lookups is loaded with its own batched query. Put `select_related()` inside a `Prefetch` queryset to load the next hop within the prefetch query. - **Prefetch objects keep their power.** A custom queryset, a slice and `to_attr` behave exactly as they do with `prefetch_related()`. - **Database routing.** The prefetch query uses the database associated with the instances unless the `Prefetch` queryset names another with `using()`. ## Async code Since Django 5.0, `aprefetch_related_objects()` offers the same operation to async views: `await aprefetch_related_objects(orders, 'items')`. It wraps the synchronous function, so the queries are identical; it only moves the blocking ORM work off the event loop. ## A pitfall: calling it per instance The function batches across the collection it receives. Calling it inside a loop, one instance at a time, runs one query per call and recreates the per-row pattern it was meant to remove: ```python # Wrong: one prefetch query per order for order in orders: prefetch_related_objects([order], 'items') # Right: one prefetch query for the whole list prefetch_related_objects(orders, 'items') ``` Collect the instances first, then prefetch once. ## When it is the right answer The function earns its place wherever the loading decision is made after the instances exist. A typical example is an order list cached as instances for a few minutes: the cache stores orders, and the view calls `prefetch_related_objects()` on the cached list before rendering, so a cache hit costs one batched query per lookup hop instead of one query per order. It is also useful for a single instance: `prefetch_related_objects([order], 'items__product')` loads a detail page's graph without rewriting the earlier `get()`. In an interview, name the function, say it works in place on a re-iterable collection of same-class instances, and mention that it accepts `Prefetch` objects. That shows you understand prefetching as a separate step Django runs after the main query rather than something baked into the SQL.