Bug 6004

I can see the problem with the Set in file column, but not with the Value column. 

David: would it be easier to disable the "Set in file" sorting?

Created attachment 1840 [details]
See the second column(Value).

buildhistory_...
kernel...
...
...
...
Poky...
buildhistory_...

It is obvious that the sort can't work well.

(In reply to comment #2)
> Created attachment 1840 [details]
> See the second column(Value).
> 
> buildhistory_...
> kernel...
> ...
> ...
> ...
> Poky...
> buildhistory_...
> 
> It is obvious that the sort can't work well.

Indeed, there is something not quite right there. Thanks!

In reviewing this, I have two observations.

1) "Set in file"

The existing queryset sort will always sort against the first member of the table of files, but where there is more than one file, that sorting file is invisible, so the results will never look correct. So, until we support a custom sort for querysets, we have two choices:

  (a) Always show all files with the sort if by files. That way the sort criteria is visible, though this will make the display very busy.

  (b) Disable the "Set in file" sorting

I vote for disabling the sort. Minimal work, safest choice, little lost functionality.

2) "Value"

This is very odd. We are doing nothing special with this sort, as per the other working columns.

I observe almost 90% of the list of values are in order, though in ASCII order where the lower case are separate from the upper case, and the leading symbols are in their own order, which may seem unnatural or at least unexpected to some.

However, I do find some 10% of the values falling randomly before the symbols start. I cannot help but wonder if there are hidden characters.

I will investigate further.

(In reply to comment #4)
> In reviewing this, I have two observations.
> 
> 1) "Set in file"
> 
> The existing queryset sort will always sort against the first member of the
> table of files, but where there is more than one file, that sorting file is
> invisible, so the results will never look correct. So, until we support a
> custom sort for querysets, we have two choices:
> 
>   (a) Always show all files with the sort if by files. That way the sort
> criteria is visible, though this will make the display very busy.
> 
>   (b) Disable the "Set in file" sorting
> 
> I vote for disabling the sort. Minimal work, safest choice, little lost
> functionality.

+1. I completely agree disabling this is the way to go.

> 
> 2) "Value"
> 
> This is very odd. We are doing nothing special with this sort, as per the
> other working columns.
> 
> I observe almost 90% of the list of values are in order, though in ASCII
> order where the lower case are separate from the upper case, and the leading
> symbols are in their own order, which may seem unnatural or at least
> unexpected to some.
> 
> However, I do find some 10% of the values falling randomly before the
> symbols start. I cannot help but wonder if there are hidden characters.
> 
> I will investigate further.

If we cannot find an easy solution, we might also consider disabling it.

The reason for the apparent "out-of-place" values is that they have leading spaces, which put them into an unexpected separate section of the sort, especially since the leading spaces are for all intents and purposes invisible to the casual eye. 

This, plus the fact that the sorting method is controlled by the database ("Django will order results however your database backend normally orders them") and in our case it is in literal ASCII order, means that while the sort is working as advertised, it will look odd and broken to the non-ASCII-aware user.

Since the value sort (a) will always look odd, (b) the search function does work, and (c) while interesting I cannot see much immediate value in the sorted values, I think we should disable it for 1.6 and look at implementing support for custom sorts in 1.7.

- David

> Since the value sort (a) will always look odd, (b) the search function does
> work, and (c) while interesting I cannot see much immediate value in the
> sorted values, I think we should disable it for 1.6 and look at implementing
> support for custom sorts in 1.7.

This seems the way to go. Thanks!

commit 7920219543f80ef14385420c11d7d9a110944ac1

verified in master:3e528d3e4bc542ca2f654c54363c56af0fb9f61b