How do you combine Django's SingleObjectMixin with ListView to paginate one podcast's episodes, and which pitfalls must you handle?

## The goal A podcast page shows the podcast's details and a paginated list of its episodes. `ListView` brings pagination; `SingleObjectMixin` brings the URL-based lookup of one object. The Django documentation shows this combination, and it is a favourite interview probe because every hook clashes once. ## The two querysets problem Both `SingleObjectMixin` and `MultipleObjectMixin` (inside `ListView`) use `get_queryset()`: | Needs a queryset | For | Model | |---|---|---| | `SingleObjectMixin.get_object()` | finding the podcast from the URL | `Podcast` | | `BaseListView.get()` | the list to paginate | `Episode` | There is only one `get_queryset()` on the class, and you override it to return episodes. So `get_object()` must be called with an explicit `queryset=Podcast.objects.all()`; otherwise it would look for an episode with the podcast's pk or slug. ## The ordering problem `BaseListView.get()` starts with `self.object_list = self.get_queryset()`. Your `get_queryset()` reads `self.object`, so the podcast has to be loaded first: 1. Override `get()`. 2. Set `self.object = self.get_object(queryset=Podcast.objects.all())`. 3. Call `super().get(request, *args, **kwargs)`, which builds the list, paginates it and renders. Setting `self.object` anywhere later (in `get_context_data()`, say) is too late. ## The context-name problem Both mixins implement `get_context_object_name()` and both read `context_object_name`: - With `SingleObjectMixin` first in the bases, its version of `get_context_object_name()` wins for both calls. For the list, it receives a queryset, which is not a model instance, and returns `None`, so **no `episode_list` key is added**. - The episodes are still available as `object_list` and, when paginating, `page_obj`. - Setting `context_object_name` would make both mixins write the same key. Leave it unset and add `context['podcast'] = self.object` yourself after calling `super().get_context_data(**kwargs)`, which also keeps `paginator` and `page_obj`. ## The template problem `ListView` knows nothing about podcasts. Its template naming uses the list's model, so the default template is the episode list template in the episodes' app. Set `template_name` explicitly if the page is really about the podcast. ## Checking it works Because every clash in this view is silent, a short test pins the behaviour down: - request the podcast's URL and assert the response uses the intended template and has `podcast` in its context; - assert that `page_obj` holds only that podcast's episodes, and that a second page exists when there are more episodes than `paginate_by`; - request an unknown slug or pk and assert a 404, which proves `get_object()` searched podcasts rather than episodes. If someone later sets `context_object_name`, reorders the bases, or moves the `self.object` assignment, one of these assertions fails instead of a template quietly rendering an empty list. ## When not to do this The Django docs close the section with a hint: use mixins from one group of generics per view (detail, list, editing or date), because combining a single-object mixin with a multiple-object mixin gets complex quickly. Simpler alternatives: - a plain `ListView` of episodes whose `get_queryset()` looks up the podcast with `get_object_or_404()` and filters by it, adding the podcast to the context; - a `DetailView` of the podcast that paginates the episodes itself in `get_context_data()`. Both avoid the double `get_queryset()` and the context-name collision, at the cost of a few explicit lines.