SQLite and > 9 priorities values does not sort correctly

[StefanC]

When using assigning priorities like this

Text : Value
----------
Prio100 : 6
Prio90 : 7
Prio80 : 8
Prio70: 9
Prio60: 10
Prio50: 11

And you try to sort on the priority, it won't work as expected (they should fall from 100 down to 50). It is my suspicion that the problem lies in sqlite's "feature" to be un-typed. I have had the same problem before with sqlite and integer ordereing. It will think that 11 is less than 6, as it does character comparision or something.

[StefanC]

Additional information: This behavior is only found when clicking on active ticket for a report (query), not when browsing a report.

[Matthew Good]

Replying to StefanC:

Additional information: This behavior is only found when clicking on active ticket for a report (query), not when browsing a report.

Which is it, a report or query? I also don't understand what you mean by "clicking on active ticket" as opposed to "browsing a report". Can you be more explicit and provide the version of Trac and exactly where you're seeing this problem? If necessary make a list of steps to reproduce the problem e.g. "Click on View Tickets, Click on …" to make sure it's clear.

[StefanC]

Sorry, I must have been sleeping when I wrote that.

The behavior is found when clicking on "active tickets" for a roadmap, closed tickets is also erroneous. So, what I meant before was that the page "​http://ramses/cgi-bin/trac.cgi/query?" (query) does not order according to priority correctly (for me), whereas ticket reports (view tickets, click on a report) which leads "to ​http://ramses/cgi-bin/trac.cgi/report/16" (report), does not exhibit the erroneous behavior.

I hope this is a little bit more clear :-)

[Christian Boos]

He's right for the custom query, the numerical values are sorted as text ones.

For the reports, it's however quite likely that the order is correct "by chance", as the ordering is done on the field values (e.g. "high" before "highest" before "low" before "lowest", etc.)

Associating this with 0.12 for now, but could probably be backported to 0.11-stable once fixed.

[jim@…]

Replying to cboos:

He's right for the custom query, the numerical values are sorted as text ones.

For the reports, it's however quite likely that the order is correct "by chance", as the ordering is done on the field values (e.g. "high" before "highest" before "low" before "lowest", etc.)

Associating this with 0.12 for now, but could probably be backported to 0.11-stable once fixed.

I don't think it has anything to do with the text the user sees, but the rank order that the admin assigns. I changed our priorities from the default values to P1, P2, P3, P4, P5, Unknown, and Retest. The order value that I assign was 6 through 12 for these priorities. When I sort them they show up as P5, Unknown, Retest, P1, P2, P3, and P4. A textual sort is being done on the numerical order values. The 6 through 12 values were used because that is all the system would allow me. The original default strings used up 1 through 5, and even though I deleted the orginal values the only choices left to me were 6 through 12.

The order is correct when the individual ticket is viewed. This problem only shows up in the query.

[vnaum@…]

fixes enum sorting for "custom query"

[vnaum@…]

fixes enum sorting for "click on table header" sorts

[vnaum@…]

I confirm this bug. PostgreSQL also affected. These fields also affected: 'status', 'resolution', 'priority', 'severity'.

query_sortorder.diff​ fixes "custom query" sort issue. Tested on Trac 0.10.3 and Trac 0.10.4 with PostgreSQL databases.

Don't forget to remove query.pyc if you have one and restart Apache if you're using mod_python.

BTW, this problem also appears when one is sorting report results by clicking table header "priority" (or any other enum field). sort_reports_on_enums.diff​ must solve this (again, tested on Tested on Trac 0.10.3 and Trac 0.10.4 with PostgreSQL database).

Patches do not apply to SVN trunk code, but still will be useful for users of 0.10.x versions. I'll try to make patches for trunk / 0.11b1 in a couple of days, too.

[Christian Boos]

Patches are looking good, so please have a try for the 0.11 version, as we probably won't apply them to 0.10.5dev (only "critical bug" fixing for 0.10.x, at this point).

For 0.12 though we should seriously consider having an change in the data model so that those casts won't be necessary in the first place (e.g. by using an enum_int table).

[vnaum@…]

fixes enum sorting for "custom query", patch against trac-0.11b1 (SVN revision 6673)

[vnaum@…]

fixes enum sorting for "click on table header" sorts, patch against trac-0.11b1 (SVN revision 6673)

[anonymous]

Patches I promised for trac-0.11b1 (SVN revision 6673):

• query_sortorder011.diff​
• sort_reports_on_enums011.diff​

[vnaum@…]

patch for default reports to use CAST p.value AS INT for sorting

[vnaum@…]

Default reports were also affected by this bug (weird sorting for >9 priorities)

Patch​ for default reports to use CAST p.value AS INT for sorting.

Also fixes #2123 (aka #3038).

Tested with Postgres 7.4 and SQLite 2.8.17.

[Christian Boos]

• query_sortorder011.diff looks good.
• sort_reports_on_enums011.diff has a few minor nits concerning our coding style, and I have to have a look if there's no simpler way to do it

I'll try to get them in for 0.11.