Fix CursorPagination OrderingFilter selection mechanism

[tuky]

Heyo! As requested I would like to discuss this issue I found: #9371

I wrote that this bug fix has the potential to be a backwards incompatible change. However, that is only true for Views with multiple ordering filters. And that should be rare.

Thank you for your input.

[tomchristie]

Okay perhaps you could start with a worked through example, or describe why you're bumping into this?

Seem like you might have a sensible suggestion here, tho we need to balance that against the impact of any behavioral change.

[tuky]

Sure: We have a custom PrioritySearchFilter filter backend which overrides the ordering if and only if the GET has a filled out search query parameter. To make it override the default ordering of OrderingFilter, we list it last:

filter_backends = (DjangoFilterBackend, OrderingFilter, PrioritySearchFilter)

With cursor pagination in place the ordering of OrderingFilter is used, with "normal" pagination, the ordering of PrioritySearchFilter is used.

[tomchristie]

Okay, so from how you've described this I assume you'd want to...

• reverse iterate through the filter classes.
• break out one the first occasion that get_ordering is defined and returns a value.

[tuky]

Yes, however I see 1 case that is not covered by this: filters can change the ordering without implementing any get_ordering implemented because that is only quite the undocumented common practice but not really part of any interface. Theoretically you could even have filters that have get_ordering implemented and return something without actually changing the qs in filter_queryset because filter_queryset is the only specified interface for filters.