Description of problem: Columns that are used as a sort criteria for tables and have numerical values should sort in descending order by default. The Load Average column in the slot table is an example of a column/table that is set up this way; check for other columns/tables that are inconsistent.
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