I'd be very much -1 if the framework modified my sorting parameters (by 
adding 'pk' at the end of the ordering).  As mentioned, it can certainly 
break queries that can be handled by a covering index...  but mostly 
because 'pk' isn't the field we would prefer to use in this case anyway. 
 For example, when sorting a list of products, the final parameter ought to 
be the product's stocking number; when looking at items by store, the final 
parameter needs to be both stocking number and store.  There wouldn't seem 
to be -any- meaningful "always right" answer.

We have something like 20,000 tests running today (and will probably hit 
40,000 over time), many of which do pagination and sorting.   I'd really, 
really hate to have to go fix all of those tests -- it would be thousands 
of them.  If there was a way to disable this proposed warning, I could live 
with that for a while.

baj
-------------
Barry Johnson

On Wednesday, January 11, 2023 at 6:55:25 AM UTC-6 tatari...@gmail.com 
wrote:

> As described in https://code.djangoproject.com/ticket/34251, some 
> database backends (incl. PostgreSQL) will produce non-deterministic 
> ordering when sorting by columns with non-unique values.
> This leads to inconsistent pagination, which I argue falls under the same 
> category as paginating by unordered QuerySet. 
>
> I suggest we add a warning similar to the UnorderedObjectListWarning when 
> total deterministic ordering is not specified (PK or unique/unique_together 
> not null fields).
>
> The consequence of this change is that *a lot* of projects will receive a 
> warning. This issue is easy to overlook since non-unique columns like 
> "name" can have mostly unique values and you need to have duplicates at the 
> page borders to get into trouble. While seemingly hard to reproduce, I 
> believe it impacts a lot of production systems out there.
>
> Correctly handling it requires some thought, especially when exposing 
> sorting options to the end user. Whether 3rd-party tools like 
> django-sortable-listview 
> <https://github.com/aptivate/django-sortable-listview> or DRF 
> <https://github.com/encode/django-rest-framework> (OrderingFilter) should 
> automatically enforce the correct ordering by adding "pk"? This brings 
> problems with indexing like in this ticket 
> <https://code.djangoproject.com/ticket/29943>. Another option with these 
> tools is adding *pk* or another unique field to the query string when 
> specifying desired sorting, which looks just wrong to me, pushing 
> responsibility to the front end.
>
> What do you folks think? I've been bitten by this issue several times, in 
> a production environment after smoothly running for a while. The first time 
> was a complete surprise to me, and I believe it's may surprise quite a lot 
> of developers as well, so adding a warning will at least bring the 
> attention. 
>

-- 
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/b0e89cc8-e9f2-48c5-8d7f-3a3093a8e6bfn%40googlegroups.com.
  • In... tatari...@gmail.com
    • ... 'Barry Johnson' via Django developers (Contributions to Django itself)
      • ... tatari...@gmail.com
        • ... Adrian Torres
          • ... Jörg Breitbart

Reply via email to