Hi Ralf:

In message <20220531071724.njnskvgjs4l3ev5b@runtux.com>,
Ralf Schlatterbeck writes:
>On Mon, May 30, 2022 at 09:35:15PM +0000, John Rouillard wrote:
>> 
>> Also this is documented in customizing.txt:
>> 
>>    Note that if an "order" property is defined on a Class that is used for
>>    sorting, all items of that Class *must* have a value against the "order"
>>    property, or sorting will result in random ordering.
>> 
>> Is this still valid for items without a valid order property?
>
>Hmm, I don't think this has ever been valid but looking through the
>tests I'm not so sure. We *do* test for Link values being NULL on
>sorting and generate complicated SQL for postgresql to match the default
>sort order of NULL values of mysql (it sorts NULL values *last*).
>But I'm not sure we do the same for non-Link properties. So maybe we
>create an issue on this to investigate. It may well be that the
>different SQL backends behave differently:
>
>The python2 postgresql backend sorts NULL values in order attributes
>*first* (in the index view of a class) and python3 behaviour hasn't
>changed. So it might well be that postgres sorts NULL first while mysql
>sorts NULL last and the above statement comes from that observation.  I
>still find "NULL first" the more intuitive behaviour.

Different back ends sorting NULL values in different order can be
considered "random" ordering of the items without an explicit value.
If I have items A and B with a NULL order prop, does A sort before B
or B sort before A? It may be better to replace "random" with
"undefined" but I think the statement still stands.  If you think we
should open a ticket to investigate further I'll defer to you.

Interesting about ID's being integers in rdbms backends. I didn't
realize that but sqlite shows it to be true.  So we could use native
sorting. Are orderprops constrained to be integers? I assume not since
orderprop will fall back to labelprop which is a string not an int.

In your code the sort order could be on any field so we still need to
handle NULL/None correctly.