The proposed patch adds very little extra API surface. Django admin in fact already support this, but for this arbitrary restriction in `get_ordering_field`. The patch just makes it possible to pass a list down to `get_queryset` method.
I would argue that this patch removes a special case in the API. Everywhere else (I think, pls correct me) devs can specify multiple fields for ordering. Except here. From a certain point of view, removing special cases means reducing API surface (: The patch could be even simpler, IMHO: just keep the name `get_ordering_field`, for compatibility with existing code. It is easier to document that the method "now also takes a list", especially since in most cases it is still going to be given a single string. Can power that be take another look at this issue? 🙏 +1 with an extra "cmon" from me! -- Fran On Friday, April 26, 2024 at 7:10:36 PM UTC+2 Mubarak Alrashidi wrote: Could you re-consider it please? it is really important, and we need it. I have started another project where I need to create a computed column (used_invitations / max_invitations) Best regards On Friday, June 23, 2023 at 10:39:51 AM UTC+3 Mubarak Alrashidi wrote: I really hope the developers implement the patch. On Monday, June 19, 2023 at 4:55:42 AM UTC+3 David Sanders wrote: Sorry to clarify I intended to respond with "niche solution" not "nice solution" lol. I didn't realise the phone's autocomplete had done that. On Monday, 19 June 2023 at 11:05:41 UTC+10 David Sanders wrote: Mariusz is a developer, so that's at least 1 developer's opinion :) Unless anybody else pipes up to counter this I'd consider it to be a nice solution. On Monday, 19 June 2023 at 05:01:52 UTC+10 Mubarak Alrashidi wrote: Can we at least know what the developers think about it? On Sunday, June 11, 2023 at 1:28:58 AM UTC+3 Mubarak Alrashidi wrote: Hello, I posted this StackOverflow question <https://stackoverflow.com/q/76425892/67579>, and @Willem Van Onsem <https://code.djangoproject.com/query?status=!closed&reporter=KommuSoft> tried to help by opening a ticket numbered #34646 <https://code.djangoproject.com/ticket/34646>, and creating a patch for supporting the order by multiple fields in admin.display decorator. But it got closed as a duplicate of #31975 <https://code.djangoproject.com/ticket/31975> which was reported about 3 years ago, and it got closed as wontfix by @Mariusz Felisiak <https://github.com/felixxm> because he said: *"We don't want to add unnecessary complexity to the API.".* And I agree with what @Petr Dlouhý <https://code.djangoproject.com/query?status=!closed&reporter=PetrDlouhy> says: *"it is small modification of Django code and small increase in API complexity (which is consistent with the logic of other order fields, BTW)."**.* The inconsistency is when somewhere we're able to order by multiple fields, and somewhere else we can't. If we can order by multiple fields in the modelAdmin classes, why can't we do so in the admin.display decorator? So, I do hope to reconsider implementing the patch <https://code.djangoproject.com/attachment/ticket/34646/django_ordering.py.diff> that @Willem Van Onsem <https://code.djangoproject.com/query?status=!closed&reporter=KommuSoft> created. Thanks -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/3c43fafb-a6e4-408c-89ff-4e35ad1afac7n%40googlegroups.com.
