Bug 703860

Fixed in revision 4782.

Initial sort order of numeric columns (int, float, long, complex) is descending, others are ascending.

    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
Cause
    When sorting tables by column Cumin would sort in ascending order by default for most columns regardless of the column type.

Consequence
    Ascending (alphabetic) order is natural for strings but it makes sense to sort in descending order by default for most numeric columns in Cumin.

Change
    The initial sort order is chosen by column type when sorting a table by a particular column. 

Result:
     When a column is selected as the sort criteria for a table, the initial sort order will be descending for numeric columns and ascending for all other columns.

I thought if it should be another bug, but then I realized it is much
connected (in view of a user) with this one:

Many queues or exchanges have no numeric value assigned
to their column-values which are later sorted with
descending order with no-values as the first.

Examples of such exchanges: amq.fanout, amq.match, amq.topic.

Please make sure that they are ordered as last in case of
descending order, be it by fixing no-values to zeroes or not.

Jan,

  The "sort null values as last" problem in Postrgres 8.1 is a tough one.  Later versions of Postgres have a simple facility for this, but in 8.1 it's actually a pretty difficult task to move "no values" to the end.  Justin and I have looked at this before -- someday we will be on a later version of Postgres and the problem should resolve easily.

  Just to clarify -- so the null values at the top of the list for these columns is a direct result of changing the default sort order for numerics, and these columns would sort in ascending order before this change?

  I suppose it might be possible to check for null values in a column and flip the default sort order....

  The other option is to synthesize zeroes for display... there was another place where zeroes were *supposed* to be in the data but were shown as nulls because of an error, this could also be the case (I'll check)

Checked a few columns in Postgres, it appears that the values are actually null.

qpid-tool shows them as zeroes... precedent?

(future implementation note: it might be possible to populate the table with a data set merged from two separate queries.  Select all the non-null data first, then run a second query to get the nulls, and append).

qpid-tool's interpretation should be taken with a grain of salt

    Technical note updated. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    Diffed Contents:
@@ -1,11 +1 @@
-Cause
+When a column with numeric values was selected as the sort criterion for a table, Cumin sorted the rows in ascending order of the numeric values by default. With this update, Cumin sorts the tables in descending order if sorting according to a column with numeric values.-    When sorting tables by column Cumin would sort in ascending order by default for most columns regardless of the column type.
-
-Consequence
-    Ascending (alphabetic) order is natural for strings but it makes sense to sort in descending order by default for most numeric columns in Cumin.
-
-Change
-    The initial sort order is chosen by column type when sorting a table by a particular column. 
-
-Result:
-     When a column is selected as the sort criteria for a table, the initial sort order will be descending for numeric columns and ascending for all other columns.

An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHSA-2011-1249.html