Patch in exact search for meilisearch

[6543]

meilisearch does not have an search option to contorl fuzzynes per query right now:

• Fuzzyness value per search  meilisearch/meilisearch#1192
• https://github.com/orgs/meilisearch/discussions/377
• Does MeiliSearch has fuzzy queries? meilisearch/meilisearch#1096

so we have to create a workaround by post-filter the search result in gitea until this is addressed.

For future works I added an option in backend only atm, to enable fuzzynes for issue indexer too.
And also refactored the code so the fuzzy option is equal in logic to code indexer

---

Sponsored by Kithara Software GmbH

[6543]

@delvh the issue we talked at the TOC meeting about ...

the problem is within meilisearch, so I only did come up with an workaround until meilisearch do address that on there side :/

[6543]

@silverwind I optimized and simplified the idea ... now it should be flat and normal maintainers should understand

[6543]

Created a followup issue forexpose fuzzines via WebUI -> #29685

[Kerollmops]

Hey! I just realized that Gitea is using Meilisearch. However, I am not sure about the missing feature here. Can you explain your use case in great detail, please? It seems that reducing the typo tolerance is possible. It's also possible to disallow typos on specific fields. But it doesn't seem to fit your needs.

[6543]

@Kerollmops hi 👋

we have two modes "fuzzy" search and non-fuzzy "match".

the code indexer has it exposed to the UI already, as for searching issues/pulls we do not jet and use non-fuzzy search by default.

Meilisearch is currently only possible to be used for the issue/pull search but code-serch will be added ... (#25976).

So the problem here is, that in non-fuzzy mode, that meilisearch returns hits that have no direct hit.

let's say i'm searching abcode i expect to get issues returned that have that exact word (case insensitive) ... but without this patch here I also get a-code ...

If i understand the meilisearch-docs correctly you can adjust that behavior per index. So now we either have to have an index clone one with fuzzynes and one without, or we post-sort it.

In the long run there should be just an query option like we use e.g. with elasticsearch:

gitea/modules/indexer/issues/elasticsearch/elasticsearch.go

Lines 149 to 154 in 7f856d5

	searchType := esMultiMatchTypePhrasePrefix
	if options.IsFuzzyKeyword {
	searchType = esMultiMatchTypeBestFields
	}
	query.Must(elastic.NewMultiMatchQuery(options.Keyword, "title", "content", "comments").Type(searchType))

[6543]

or as with bleve ... (#29706)

[Kerollmops]

Hey @6543,

Thank you for the clear explanation. So, exposing the typoTolerance.enabled setting on the search route could fix the issue?

Another quick fix for your issue could be to double-quote every query word. Doing this disallows typos on those words and forces the documents to have all the double-quoted words. However, it's not that easy to put in place on your side.

[6543]

@Kerollmops would that work -> #29740 ?

PS: we should chat onwards in #29740 ... as it's discouraged to chat in merged/closed issues/pulls :)