[Discussion] Meaning of "sort" and "order" in search URLs

[fenekku]

Is your feature request related to a problem? Please describe.

The search URLs with sorting are now:

Browser: https://127.0.0.1:5000/search?q=Richard%20smith&sort=bestmatch&order=asc&p=1&s=10&l=list API: https://127.0.0.1:5000/api/rdm-records?q=Richard%20smith&sort=bestmatch&page=1&size=10

Note how this is different from what it used to be:

Browser: https://127.0.0.1:5000/search?q=Richard%20smith&sort=bestmatch&order=desc&p=1&s=10&l=list API: https://127.0.0.1:5000/api/rdm-records?q=Richard%20smith&sort=-bestmatch&page=1&size=10

In other words: the meaning of sort=bestmatch on the API changed from meaning "lowest best match to highest best match" to mean "highest best match to lowest best match" just like sort=mostrecent means "highest updated date to lowest updated date".

Do we keep this change, or try to reproduce what Invenio-records-rest had?

I made those changes (target me :dart:) because ascending / descending logic didn't seem to make sense for both mostrecent and bestmatch. My take is that bestmatch and mostrecent imply an ordering, so "order" should be used to reverse that order (or keep it the same)... The goal was also to get something working for the release quickly. But I don't mind trying to keep same logic as invenio-records-rest (some more work in records-resources needed to achieve that though).

[lnielsen]

I agree with you. The ordering in Records-REST doesn't makes sense. Also it's complicated for a user to use.

UI wise we need just a single drop-down where each item has an implicit ordering:

Best match Most recent Publication date (newest to oldest) Publication date (oldest to newest)

Both UI and API should work only with a single sorting key, and you cannot change the order,