Removing "typo" from ranking rules does not disable typo tolerance while searching

[bhavyalatha26]

Describe the bug
To disable the typo tolerance while searching, it is recommended to remove the rule typo from the list of ranking rules. However this does not work. Even after removing it from the ranking rules, the results still seem to apply typo tolerance.

To Reproduce
Steps to reproduce the behavior:

1. Using Client update the settings

client = meilisearch.Client(url, apiKey=api_key)
client.get_index(index_name).update_ranking_rules([
        "words",
        "proximity",
        "attribute",
        "wordsPosition",
        "exactness"
    ])

2. Restart the server
3. See that the results still consider typo tolerance

Expected behavior
The search should ignore typo tolerance and follow only the required rules.

Screenshots

Additional context
I have also tried to use only ['exactness'] for raking rules, but still the typo tolerance is being applied.

[theo-lubert]

I agree with @bhavyalatha26, this should be possible:

• by removing the typo ranking rule (preferred)
• or, through an index setting
• or, through a search option
• It could also make sense to configure it for specific fields (enabled on title/description, but disabled on id/ean/trackingNumber for example). But that feels like another feature to me

Algolia, for exemple, allows this with typoTolerance: false (https://www.algolia.com/doc/api-reference/api-parameters/typoTolerance/)

[qdequele]

Hello, This issue will be fixed by a new feature/setting.

I will close this issue in favor of our public roadmap.

I invite everyone interested in this feature to upvote it on the roadmap.

[sirdharma]

@qdequele Thank you for your answer and for sharing your public roadmap, that's awesome 👍

Nonetheless, I am confused by your linked idea: how would the proposed policy for prefix search work exactly?

In a real-world use case, let's assume we have an index that contains only a UUID-type attribute. Is it possible to configure the index so that typo-tolerance is not applied at all?

Let's then consider we have an index that contains a UUID-type attribute and a name attribute. Is it possible to configure the index' attributes so that typo-tolerance is disabled on the first attribute, but enabled on the second?

As already mentioned by @theo-lubert in #1103 (comment), Algolia provides both typoTolerance and disableTypoToleranceOnAttributes for that exact purpose.

My apologies if I failed to see how prefix search policy would solve that. If that's the case, I'll definitely up-vote it 😄

[theo-lubert]

I agree with @sirdharma , it would make a lot more sense to me if this was field specific, like Algolia's "disableTypoToleranceOnAttributes", and also not limited to the prefix.
Btw, maybe this could also improve indexing performance.

@qdequele maybe this should be another feature on the roadmap.

[Sembiance]

Was this ever added into meilisearch?

The 3 things I'd love to see in meilisearch are:

• sortBy
• Disable typo tolerance per field, entirely or at search time
• A restrictSearchableAttributes at query time

[curquiza]

Hello @Sembiance! Thanks for your feedback, it might interest @gmourier 😇

Also, about the SortBy, it will be implemented in v0.22.0 available in the middle of September, here is the tracking issue: #1581

[curquiza]

About disable the typo tolerance: there is a workaround by using the phrase search (available in v0.21.0, the official release is next week). You have to surround each query word by " when sending the query to MeiliSearch.
Ex: if the user types meili search you will have to send "meili" "search" to the search engine

However there are some limits to this workaround: using the " the search engine will no try to gather words or to split them.
Ex: if the user types meili search, you send "meili" "search". But the search engine will not retrieve documents containing meilisearch, only documents containing meili and search separately.

FYI, I opened a feature request about it: meilisearch/product#176

[Sembiance]

@curquiza AWESOME workaround! That'll work great for the time being. Thanks!