The cheap solution here is to basically keep whole search function as is, but if absolutely nothing is found with a match_phrase, and there were multiple words, then just recurse over one more time and do it with a match query instead. In this implementation it tries to match using a match phrase query which basically tries to find matches where every word in the query matches. The default is to sort by the _score as ultimately dictated by Lucene. Elasticsearch takes care of everything else. It means that the "title" is 2 times more important than the "text".Īnd that's it! Now every match is scored based on how suggester's score and whether it be matched on the "title" or the "text" (or both).
The core is that it does Q('match_phrase' title='firefix', boost=2X) | Q('match_phrase', text='firefix', boost=X). Strategy = 'match_phrase' if original_q : strategy = 'match' search_term_boosts = ) if matcher is None : matcher = match else : matcher |= match search_query = search_query.
#Suggester elasticsearch how to#
Here's how to run the suggester for every defined doc type and generate a list of other search terms tuples (minimum score >=0.6). The initial goal is to not bury this spelling alternative too far back. Doesn't matter gravely and it's up for future tuning.
Quite likely I did, but why do I have to click it? Can't it just be clicked for me?Īlso, if there's ambiguity and possibly some results based on what you typed and multiple potential "Did you mean.?". One thing I really dislike in non-Google search engines is when you make a search and nothing is found and it says "Did you mean. This solution is very much focussed on typos. date format which finds Date formatting, date formats etc.īut if you search for something where the whole phrase can't match, it splits up the search an uses a match operator instead (minus any stop words).
0 kommentar(er)
