Opened 10 years ago

Closed 10 years ago

Last modified 9 years ago

#9222 closed (wontfix)

Allow callable queryset in generic views

Reported by: raffaele.salmaso@… Owned by: nobody
Component: Generic views Version: master
Severity: Keywords:
Cc: Triage Stage: Unreviewed
Has patch: yes Needs documentation: no
Needs tests: yes Patch needs improvement: no
Easy pickings: UI/UX:


I need to pass a variable queryset based on some external condition
(i.e. it can be Entry.objects.all() or Entry.objects.filter(...) or other), but with current implementation it is impossible,
because generic views want a queryset, which is set indefinitely (I'm thinking about the use in, not in
custom views).

Actually I wrote a simple wrapper, as

def obj_list(request, queryset, ...):
    if callable(queryset):
        queryset = queryset()
    return object_list(request, queryset, ...)


and pass a function which returns the queryset I need.

I found it could be useful if it is included directly in the generic views function.

The attached patch adds this functionality, and it doesn't break any previous code.

Attachments (1)

callable_queryset.diff (3.4 KB) - added by raffaele.salmaso@… 10 years ago.

Download all attachments as: .zip

Change History (4)

Changed 10 years ago by raffaele.salmaso@…

Attachment: callable_queryset.diff added

comment:1 Changed 10 years ago by andreas@…

Needs tests: set

Is this really neccessary? Since the queryset-function is not getting access to the request, this seems to be kind of limited.

Wouldn't a custom manager method do the trick much better? For more complex computations of the queryset it would often be useful to have access to the request and likely the view arguments too, hence a wrapper would be way more useful.


The patch is also missing tests.


comment:2 Changed 10 years ago by Malcolm Tredinnick

Resolution: wontfix
Status: newclosed

Thanks for the patch, but we aren't going to do this. The solution to any problem involving wanting to pass some kind of customised queryset to a generic view is to create your own view that creates the right queryset and then calls the generic view.

Although each little addition to generic views only feels like a few lines, it is a few extra lines each time that requires extra maintenance, prompts extra questions on the users list, adds extra documentation, requires extra tests, etc. It basically adds to the overhead when it's a three line function when the user needs it (which usually results in cleaner code, too, since it's clear what you're trying to do).

comment:3 Changed 9 years ago by (none)

milestone: post-1.0

Milestone post-1.0 deleted

Note: See TracTickets for help on using tickets.
Back to Top