Ability to sort by _rankingOrder and another field

[nicholaszuccarelli]

TLDR: Ability to perform a sort using syntax like: sort: ['_rankingScore:desc', 'field:desc'] so that results with the same ranking score can then be ordered a specific way through another field

---

Consider this scenario:

I've got a table of data with columns: [ID, Address, Date].
The table columns can be sorted by that column header in ascending and descending order, such as sort: ['address:asc']

My rankingRules array looks like this:

"rankingRules": [
    "sort",
    "words",
    "exactness",
    "proximity",
    "attribute"
]

Keep in mind that sort must be first to ensure the table can sort correctly by a selected column.

The table also has a search box at the top.
When the user types in the search box, the selected column sort is removed (so sort is ignored from rankingRules) and the results are ordered using their _rankingScore.

As an example, I type "3 Bent St Melbourne" into my search box, and the results appear as such (ranking scores are just examples):

"hits": [
    {
        "id": 1,
        "address": "3 Bent St, Melbourne",
        "date": "01-01-2024",
        "_rankingScore": 1
    },
    {
        "id": 2,
        "address": "3 Bent St, Melbourne",
        "date": "06-06-2024",
        "_rankingScore": 1
    },
    {
        "id": 3,
        "address": "13 Bent St, Sydney",
        "date": "15-02-2024",
        "_rankingScore": 0.5
    },
    {
        "id": 6,
        "address": "13 Bent St, Perth",
        "date": "02-05-2024",
        "_rankingScore": 0.5
    },
    {
        "id": 4,
        "address": "50 Bent Crt, Darwin",
        "date": "12-12-2023",
        "_rankingScore": 0.25
    },
    {
        "id": 5,
        "address": "8 Bent Road, Brisbane",
        "date": "01-01-2024",
        "_rankingScore": 0.2
    }
]

The problem I face is that while the first 2 results are technically "correct" results, I'd like the second result to appear first, because it has a more recent ID/date and is more relevant to our user.

This is a scenario with some of our users who may have many results which can appear, but the more "relevant" / newer data is lower in the list despite the ranking scores being the same.

A proposed solution I thought of was being able to perform a sort using sort: ['_rankingScore:desc', 'date:desc'] - where it will sort by _rankingScore first, and results with the same _rankingScore are then ordered by date in descending order.

In the case of the example I provided, the results would look as such:

"hits": [
    {
        "id": 2,
        "address": "3 Bent St, Melbourne",
        "date": "06-06-2024",
        "_rankingScore": 1
    },
    {
        "id": 1,
        "address": "3 Bent St, Melbourne",
        "date": "01-01-2024",
        "_rankingScore": 1
    },
    {
        "id": 6,
        "address": "13 Bent St, Perth",
        "date": "02-05-2024",
        "_rankingScore": 0.5
    },
    {
        "id": 3,
        "address": "13 Bent St, Sydney",
        "date": "15-02-2024",
        "_rankingScore": 0.5
    },
    {
        "id": 4,
        "address": "50 Bent Crt, Darwin",
        "date": "12-12-2023",
        "_rankingScore": 0.25
    },
    {
        "id": 5,
        "address": "8 Bent Road, Brisbane",
        "date": "01-01-2024",
        "_rankingScore": 0.2
    }
]

Interested to hear your thoughts on this!

[dureuill]

Hello @nicholaszuccarelli, interesting use case!

I think this can be solved in today's Meilisearch by using a custom ranking rule:

Set your rankingRules to the following:

"rankingRules": [
    "sort",
    "words",
    "exactness",
    "proximity",
    "attribute",
    'date:desc' // 👈 new
]

This way, documents that are identical score wise up to "attribute" will have their tie broken by "date:desc".

Would that solve your use case? If not, can you tell me why?

[nicholaszuccarelli]

Ahhh I feel stupid for not thinking of using rankingRules in such a way!
I even looked at the docs about binding a custom rule - but didn't think it would work for the sorting order.
That absolutely solves my use case. You're a legend!!