564088 - Sorting by product version is broken

Status: RESOLVED FIXED

(Socorro :: General, task)

Description

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

1) Consider this table of crash reports: https://crash-stats.mozilla.com/report/list?product=Firefox&platform=mac&query_search=signature&query_type=exact&query=pthread_mutex_lock&date=05%2F05%2F2010%2017%3A40%3A20&range_value=1&range_unit=weeks&process_type=all&plugin_field=&plugin_query_type=&plugin_query=&do_query=1&signature=pthread_mutex_lock

2) Sort by Version

AR: In ascending order, versions appear as: 

3.0.11
3.0b4 
3.0.10
3.0.19
3.0.1 
3.0.19
3.0.19
3.0.19
3.0.11
3.0.15

In descending order, they appear as:

3.6
3.6
3.6.3
[…]
3.6.3
3.6
3.6.3
[…]
3.6.3
3.6.4
3.6.3

(where additional 3.6.3 crashes have been collapsed into […]).

There is no way either of those sort orders can possibly be correct (even ignoring the beta issue, the 3.6.nothing vs. 3.6.0 issue, and the "is .11 bigger or smaller than .1" issue).

See also bug 547859, which seem to be the other "incorrect sort order" bug open right now.

I'm sure this used to work a while ago, but I haven't used it enough recently to have a good idea when it broke.

Comment 2

[Wayne Mery (:wsmwk)]

smokey is this still broken for you?

Today I encountered one query that doesn't sort by version. 
https://crash-stats.mozilla.com/report/list?product=Thunderbird&query_search=signature&query_type=exact&query=nsTransformedTextRun%3A%3ASetCapitalization%28unsigned%20int%2C%20unsigned%20int%2C%20unsigned%20char*%2C%20gfxContext*%29&date=02%2F16%2F2011%2013%3A03%3A03&range_value=4&range_unit=weeks&hang_type=any&process_type=all&plugin_field=&plugin_query_type=&plugin_query=&do_query=1&admin=1&signature=nsTransformedTextRun%3A%3ASetCapitalization%28unsigned%20int%2C%20unsigned%20int%2C%20unsigned%20char*%2C%20gfxContext*%29

But other query results sort OK. only the date in the query has changed
https://crash-stats.mozilla.com/report/list?product=Thunderbird&query_search=signature&query_type=exact&query=nsTransformedTextRun%3A%3ASetCapitalization%28unsigned%20int%2C%20unsigned%20int%2C%20unsigned%20char*%2C%20gfxContext*%29&date=01%2F16%2F2011%2013%3A10%3A48&range_value=4&range_unit=weeks&hang_type=any&process_type=any&plugin_field=&plugin_query_type=&plugin_query=&do_query=1&admin=1&signature=nsTransformedTextRun%3A%3ASetCapitalization%28unsigned%20int%2C%20unsigned%20int%2C%20unsigned%20char*%2C%20gfxContext*%29

Comment 3

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

https://crash-stats.mozilla.com/report/list?product=Firefox&platform=mac&query_search=signature&query_type=exact&query=pthread_mutex_lock&range_value=1&range_unit=weeks&process_type=all&plugin_field=&plugin_query_type=&plugin_query=&do_query=1&signature=pthread_mutex_lock is the query from comment 0 without the default date appended (which had long-since expired).

That one looks ok now, modulo the X.y.n, n>9 problem (where 3.0.11 and 3.0.19 come before 3.0.1).  I haven't really done much by-version sorting lately outside of Camino, and in Camino we're all n<9 currently.

However, if we close this, we need to reopen dupe bug 584803, because that specifically is about the sorting problem when n>9 (and possibly other cases?)

Comment 4

[Robert Kaiser]

Josh, will bug 629741 fix the remaining issue here?

Comment 5

[Laura Thomson :laura]

(In reply to comment #4)
> Josh, will bug 629741 fix the remaining issue here?

It won't.  That's a pure database change to enable another bug.  We may be able to use it here though.

Comment 6

[[:jberkus] Josh Berkus]

Sort of, requires UI and middleware work.

The table productdims will have a new integer column called "sort_key".  In the future, any application which accesses the PostgreSQL database for data can order its results by this column.  But we'll need to update the code to do this.

Comment 7

[Schalk Neethling [:espressive]]

Is this still an issue or can it be closed?

Comment 8

[Stephen Donner [:stephend] Not actively reading bugmail]

(In reply to Schalk Neethling from comment #7)
> Is this still an issue or can it be closed?

Very clearly still happening.

Comment 9

[Matt Brandt [:mbrandt]]

Attachment: screenshot

(In reply to Stephen Donner [:stephend] from comment #8)
> (In reply to Schalk Neethling from comment #7)
> > Is this still an issue or can it be closed?
> 
> [This is] very clearly still happening.
Steps to reproduce:
1. Goto https://crash-stats-dev.allizom.org/report/list?product=Firefox&query_search=signature&query_type=contains&query=pthread_mutex_lock&reason_type=contains&date=10%2F18%2F2011%2011%3A48%3A31&range_value=3&range_unit=weeks&hang_type=any&process_type=any&do_query=1&signature=pthread_mutex_lock
2. follow steps in comment 0

Comment 10

[Schalk Neethling [:espressive]]

Quick question, is it correct that the table at the below URL is initially sorted by the comments column desc?

https://crash-stats-dev.allizom.org/report/list?product=Firefox&query_search=signature&query_type=contains&query=pthread_mutex_lock&reason_type=contains&date=10%2F18%2F2011%2011%3A48%3A31&range_value=3&range_unit=weeks&hang_type=any&process_type=any&do_query=1&signature=pthread_mutex_lock

Comment 11

[Laura Thomson :laura]

Yes, crashes with comments are intended to be at the top.

Comment 12

[Schalk Neethling [:espressive]]

https://github.com/mozilla/socorro/pull/106

Comment 13

[[github robot]]

Commit pushed to https://github.com/mozilla/socorro

https://github.com/mozilla/socorro/commit/49f041256a3c3813c4086c95bcec7e97e330011b
Merge pull request #106 from ossreleasefeed/product-ver-sorting

fixes bug 564088 - sorting by product version incorrect