Allow overridesForField to be broken down in MUST term queries
Activity

Yoann Rodière May 27, 2020 at 8:37 AM
Duplicates
Emmanuel Bernard May 3, 2013 at 10:05 AM
I am not entirely following why you want the same Lucene field (not property) to be analyzed by one analyzer in a case and another in another case. This is what your latest code seems to express.

Marc Schipperheyn April 29, 2013 at 5:08 PM
Well, in my case, I now use an ugly workaround (splitting the string, adding as a must and catching the errors when I encounter a stopword term) in a number of places. But reviewing those things, yes, they are all autocomplete related. Personally, I feel the "overridesForField" method is not at a natural location. It would make more sense to me to have it at the field level. But perhaps there are scenarios where this is not possible? If it is at the field level, you could have something like
qb.keyword().onField("tag_kw_").useAnalyzer("autocompleteAnalyzer").matchEachTerm().matching(key).createQuery()
or
qb.keyword().onField("tag_kw_").overrideAnalyzer("autocompleteAnalyzer").matchEachTerm().matching(key).createQuery()
Emmanuel Bernard April 29, 2013 at 9:22 AM
Well we always had plan to offer native autocomplete support, do you see other use cases where using MUST makes sense?
Otherwise I wonder if we should not place this flag elsewhere in the API
Details
Details
Assignee

Reporter

The overridesForField option in the querybuilder provides a convenient way to break up input text into terms with which to construct queries. If multiple terms occur, these generate multiple queries combined with SHOULD.
There are cases where a MUST combination is more appropriate. For example in an autocomplete scenario. If you type in "Rio de Jan", you may want the autocomplete function to return "Rio de Janeiro", but not "Rio Grande do Sul".
I propose adding .overriodesForField(String fieldName, String analyzerName).requireAllTerms()
this scenario could also take care of and eliminate stopwords from being used as termqueries