Code

Opened 2 years ago

Last modified 5 weeks ago

#18355 assigned New feature

Add ordering mixin for class based generic views

Reported by: aaugustin Owned by: pjrharley
Component: Generic views Version: master
Severity: Normal Keywords:
Cc: marc.tamlyn@… Triage Stage: Accepted
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: yes
Easy pickings: no UI/UX: no

Description

Currently, if the model used by by a date-based generic view doesn't have an ordering and pagination is enabled, results will be random. Defining an ordering on the model isn't totally satisfying because it has global effects, and it adds an overhead to every query involving the model.

Another workaround is to define queryset = MyModel.objects.order_by('-<date_field>') in every view. But CBVs are precisely about removing as much boilerplate as possible.

So here's a draft of an API for ordering:

class BaseDateListView(...):

    ordering = None

    def get_ordering(self):
        return self.get_date_field() if self.ordering is None else self.ordering
            
    def get_dated_queryset(self, **lookups):

    ...

    if not qs.ordered():
        qs = qs.order_by(self.get_ordering())

    ...

self.get_ordering() could return '-<date_field>' for the archive view for backwards compatibility.

This would be a better fix for #18354.

Attachments (0)

Change History (10)

comment:1 Changed 2 years ago by aaugustin

  • Owner changed from nobody to aaugustin

comment:2 Changed 2 years ago by jezdez

  • Triage Stage changed from Unreviewed to Accepted

I accept the problem in general, but don't see how this is limited to date based views. This is perfect for a mixin, so let's write a OrderingViewMixin or similar.

comment:3 Changed 2 years ago by jezdez

  • Summary changed from Date-based generic views should enforce ordering to Add ordering mixin for class based generic views

comment:4 Changed 14 months ago by mjtamlyn

  • Cc marc.tamlyn@… added

Would this functionality apply only to list views? This would certainly give a good advantage as one's instinct is to apply the get_queryset changes to every view with the same Model, but ordering is rather useless when we're simply doing a DetailView (and could impose a performance problem). So the code would perhaps live in BaseListView rather than MultipleObjectMixin.

That said, if this functionality is only hitting list views, it actually fits in with a larger subject area of search/ordering/filtering as defined by the user. In reality this is probably just one of the first hooks we might need to implement that kind of functionality well, but it may be worth considering the larger list-view-customisation issue.

comment:5 Changed 14 months ago by aaugustin

The goals were clear to me when I was working on the date-based views, but unfortunately I've lost track of it since then...

I think it's just about implementing the API in the ticket description, documenting it, and taking advantage of it in the date-based views while preserving backwards-compat.

You're very welcome to take over on this ticket if you'd like to as it's pretty low on my priority list.

comment:6 Changed 10 months ago by aaugustin

  • Status changed from new to assigned

comment:7 Changed 10 months ago by aaugustin

  • Owner aaugustin deleted
  • Status changed from assigned to new

comment:8 Changed 7 months ago by anonymous

  • Has patch set
  • Owner set to anonymous
  • Status changed from new to assigned

I've added a PR for this here:

https://github.com/django/django/pull/2097

Not sure if the approach is right - feedback welcome. I suspect the docs need improvement - more than happy to do that if the code is looking good.

comment:9 Changed 7 months ago by pjrharley

  • Owner changed from anonymous to pjrharley

Try assigning to myself while signed in instead...

comment:10 Changed 5 weeks ago by timo

  • Patch needs improvement set

I left comments for improvement on PR. Please uncheck "Patch needs improvement" when you update it, thanks.

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as assigned
The owner will be changed from pjrharley to anonymous. Next status will be 'assigned'
The ticket will be disowned. Next status will be 'new'
as The resolution will be set. Next status will be 'closed'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.