Last ordering filter has the last say

[tuky]

Description

In

django-rest-framework/rest_framework/generics.py

Line 153 in 63063da

for backend in list(self.filter_backends):

every filter backend is called in the order as listed in the view's filter_backends. And since every order_by qs call clears the previous order (https://docs.djangoproject.com/en/5.0/ref/models/querysets/#django.db.models.query.QuerySet.order_by), the last ordering filter should have the final say for cursor pagination.

Although a bug fix, this poses the risk of being a major change for dependent projects.

PS:
IMO, the docs should have a warning somewhere about this. It seems uncommon or unexpected from DRF's side to have multiple ordering backends and even more unexpected with cursor pagination where you have to be extra careful anyways. And there should be a warning that CursorPagination only uses ordering[0] for the cursor although it would be possible to implement a cursor on multiple fields a la Q(ordering0__gt=cursor0) | Q(ordering0__gte=cursor0, ordering1__gt=cursor1) | ... (unfolded result QS).

[tomchristie]

this poses the risk of being a major change for dependent projects.

So... our default has to be that we wouldn't accept changes like this.

Furthermore we really need to push towards a high cutoff bar for accepting changes, and should be ensuring we've got really clear contribution guidelines that enforce a process of...

• Discussions first.
• Escalate to issues only if accepted by the team.
• Pull requests only once there's an associated issue.