Sort by downloads doesn't

[DanielKeep]

Right now, https://crates.io/search?q=mmap&sort=downloads looks like this to me:

Either this is wrong, or I've taken a serious blow to the head and can't ordering anymore.

[alexcrichton]

cc @lazypenguin

[rminderhoud]

That's strange as it's working on my local build. Looks like the results aren't coming back sorted from the API endpoint (https://crates.io/api/v1/crates?page=1&per_page=10&q=log&sort=downloads). Was the target re-built in production?

[alexcrichton]

Hm it should be yeah, maybe the sql query should be updated?

[rminderhoud]

@alexcrichton I'm running Postgres 9.5.3 on my system, I see in the travis build it's using 9.3, is that the same for production? Would you be able to test this query against that database? Should help us narrow down the issue.

SELECT crates.* FROM crates,
                               plainto_tsquery('test') q,
                               ts_rank_cd(textsearchable_index_col, q) rank
          WHERE q @@ textsearchable_index_col
          ORDER BY name = 'test' DESC, rank DESC, crates.downloads DESC
          LIMIT 0 OFFSET 10;

[alexcrichton]

Looks like Heroku is using Postgres 9.3.9 and that query itself doesn't return anything for me (LIMIT 0), but did you intend to test something else perhaps?

[rminderhoud]

My mistake, left off a digit on the limit. I've tested the front end with npm start --proxy https://crates.io and no dice, so the issue lies within the backend code as npm run start:local correctly sorts the objects. Trying to eliminate some possibilities here

SELECT crates.* FROM crates,
                               plainto_tsquery('test') q,
                               ts_rank_cd(textsearchable_index_col, q) rank
          WHERE q @@ textsearchable_index_col
          ORDER BY name = 'test' DESC, rank DESC, crates.downloads DESC
          LIMIT 10 OFFSET 10;

[alexcrichton]

Sure:

  id  |        name        | rank | downloads 
------+--------------------+------+-----------
 1498 | clap               |  2.3 |    184216
 5483 | alienlanguage      |  2.3 |        96
 2061 | compiletest_rs     |  1.9 |     27969
  654 | suffix             |  1.9 |      4403
 4341 | rotor-test         |  1.9 |       783
 2425 | stree_cmd          |  1.9 |       540
 5286 | fast_inv_sqrt      |  1.7 |       135
 3453 | modbus-test-server |  1.6 |       672
  868 | punkt              |  1.6 |       645
 3056 | ascii_set          |  1.6 |       553

[rminderhoud]

Alex, do you mind confirming that this produces the correct sort before I submit a new pull request?

SELECT crates.* FROM crates,
                               plainto_tsquery('test') q,
                               ts_rank_cd(textsearchable_index_col, q) rank
          WHERE q @@ textsearchable_index_col
          ORDER BY name = 'test' DESC, crates.downloads DESC, rank DESC,
          LIMIT 10 OFFSET 10;

Thanks for the patience.

[alexcrichton]

Oh yeah no worries, that generates:

│  id  |         name         | rank | downloads
│------+----------------------+------+----------
│ 1498 | clap                 |  2.3 |    184228
│  805 | nom                  |  0.4 |    160691
│  221 | rust-crypto          |  0.1 |    118499
│  102 | encoding_index_tests |  1.2 |     89635
│   70 | glutin               |  0.1 |     81530
│  196 | quickcheck           |  4.6 |     72530
│ 3119 | walkdir              |  0.4 |     59235
│  534 | deque                |  0.1 |     58326
│  426 | websocket            |  1.3 |     49056
│ 4519 | mempool              |  0.6 |     48401

[Keats]

Going to https://crates.io/search?q=markdown&sort=downloads it looks like it's still working correctly?

I see the following:

[carols10cents]

Going to https://crates.io/search?q=markdown&sort=downloads it looks like it's still working correctly?

I see the following:

@Keats I think what you're seeing is that there's a crate with the exact name that matches your query, and crates.io is ALWAYS putting that one first. This could be made clearer, want to file a new issue for that?

[Keats]

@carols10cents Done in #493