Django detailview get_queryset and get_object

Sandesh Ghanta picture Sandesh Ghanta · Sep 28, 2018 · Viewed 9.8k times · Source

I am using Django detailview. initially, I used the URL pattern

url(r'^todo/details/(?P<pk>[\d]+)', views.todoDetailView.as_view(), name='detail_todo'),

my view is

class todoDetailView(DetailView):
model = models.todo

It worked fine.

In the second case, my URL is

url(r'^todo/details/(?P<id>[\d]+)', views.todoDetailView.as_view(), name='detail_todo'),

this time, I modified my view to

class todoDetailView(DetailView):
model = models.todo
# context_object_name = 'todo_detail'

 def get_object(self, **kwargs):
    print(kwargs)
    return models.todo.objects.get(id=self.kwargs['id'])

It worked fine, I modified the second case to

class todoDetailView(DetailView):
model = models.todo
# context_object_name = 'todo_detail'

def get_queryset(self):
    return models.todo.objects.get(id=self.kwargs['id'])

then I get an error,

Generic detail view todoDetailView must be called with either an object pk or a slug.

I know that there is no proper slug or pk provided. So, initially I added get_object() (it worked) but get_queryset() is not working. What is the difference in their working ??

And also if a user is getting details only based on the slug, I read on StackOverflow that

this can be used

slug_field = 'param_name'
slug_url_kwarg = 'param_name'

link - Generic detail view ProfileView must be called with either an object pk or a slug

Can anyone explain me actual working of get_object() and get_queryset() (also get_slug_field() if possible)

Along with the terms slug_field and slug_url_kwarg

Thanks in advance

Answer

Ariel picture Ariel · Sep 28, 2018

get_object returns an object (an instance of your model), while get_queryset returns a QuerySet object mapping to a set of potentially multiple instances of your model. In the case of the DetailView (or in fact any class that inherits from the SingleObjectMixin, the purpose of the get_queryset is to restrict the set of objects from which you'll try to fetch your instance.

If you want to show details of an instance, you have to somehow tell Django how to fetch that instance. By default, as the error message indicates, Django calls the get_object method which looks for a pk or slug parameter in the URL. In your first example, where you had pk in the URL, Django managed to fetch your instance automatically, so everything worked fine. In your second example, you overrode the get_object method and manually used the id passed as parameter to fetch the object, which also worked. In the third example, however, you didn't provide a get_object method, so Django executed the default one. SingleObjectMixin's default get_object method didn't find either a pk or a slug, so it failed.

There are multiple ways to fix it:

1. Use pk in the URL

The simplest one is to simply use the code you provided in your first example. I don't know why you were unsatisfied with that, it is perfectly fine. If you're not happy, please explain why in more detail.

2. Override get_object

This is the second solution you provided. It is overkill because if you properly configured your view with the correct options (as you will see in the following alternatives), Django would take care of fetching the object for you.

3. Provide the pk_url_kwarg option

If you really want to use id in the URL for some reason, you can indicate that in your view by specifying the pk_url_kwarg option:

class todoDetailView(DetailView):
    model = models.todo
    pk_url_kwarg = 'id'

4. Provide the slug_field and slug_url_kwarg options [DON'T DO THIS]

This is a terrible solution because you are not really using a slug, but an id, but it should in theory work. You will basically "fool" Django into using the id field as if it was a slug. I am only mentioning it because you explicitly asked about these options in your question.

class todoDetailView(DetailView):
    model = models.todo
    slug_field = 'id'
    slug_url_kwarg = 'id'

Regarding your get_queryset method: in your example, it doesn't even get to be executed, but in any case it is broken because it returns an individual object instead of a queryset (that's what objects.get does). My guess is you probably don't need a custom get_queryset method at all. This would be useful for example if you had a complex permission system in which different users can only access a different subset of todo objects, which I assume is not your case. Currently, if you provide this get_queryset method, even if everything else is configured properly, you will get an error. Probably an AttributeError saying that the queryset object has no attribute filter (because it will actually be a todo object and not a QuerySet object as Django expects).