Scenario: A search containing an article (a, an, etc.), conjunction (and, or, but), preposition (in, on, etc.), form of the verb "to be," or other term stops a search
Zimbra Social's stopwords.txt file, which resides under Path_to_your_tomcat_installation\solr\conf, contains terms that will stop a search. They include the following terms:
Stop words | ||||
a | an | and | are | as |
at | be | but | by | for |
if | in | into | is | it |
no | not | of | on | or |
s | such | t | that | the |
their | then | there | these | they |
this | to | was | will | with |
Solution: Change the query not to use the term, or edit the stopwords.txt file
With our out-of-the-box setup, the "and" term in queries is removed for most of the fields we search by default. We search the title, content, attachment text and tags values on typical queries. For all of those fields except for the tag field, "and" is removed since its considered a stop word.
In other words, "and" is only considered for matches when it's in a tag. This is a unique, unfortunate aspect of how the DisMax handler (our main search handler) works in Solr in combination with our use of stop words, along with the minimum match setting that Zimbra Social leverages.
The out-of-the-box setup requires that all of the words in the query to be present to return a result. So if, for example, you search for "test results for 8.0 release," all of the terms have to be in the document before it returns results. This also applies to searches containing stop words. So, for example, if you search for "point and click", the "and" is removed - but the requirement for the number of words, 3, is not. Note: The situation described only affects searches with stop words.
Number of query terms | 75% (minimum terms required to match a document) |
2 | 2 |
3 | 2 |
4 | 3 |
5 | 3 |
6 | 4 |
7 | 5 |
8 | 6 |
9 | 6 |
10 | 7 |
11 | 8 |
12 | 9 |
13 | 9 |
14 | 10 |