Well, there is CommonGrams and CommonGramsQuery filters (e.g.
http://www.solr-start.com/javadoc/solr-lucene/org/apache/lucene/analysis/commongrams/CommonGramsQueryFilter.html
). But I haven't seen them in use much.
If the description above (about the first/last token) would actually
be useful, it
Notice that I said "would be" rather than "is"!
Yeah, Solr is basically broken WRT intelligent stop word handling, but
nobody wants to admit it. edismax does have some limited support for the
case of the query being all stop words, but that doesn't work for more
complex queries with operators and
On 16 February 2015 at 19:12, Jack Krupansky wrote:
> In fact, it would be better to only remove stop words at query time
> when they are not at either end of the query.
And how is that achieved in Solr? This sounds interesting but
stretches my knowledge of the available filters.
Regards,
Ale
Specifically what is happening is that the query parser passes "of" to the
analyzer for the name field, which removes the stopwords, including "of",
which results in no term to be queried. A Lucene BooleanQuery with no terms
will match... nothing. But then when you add another clause, you have the
On Mon, Feb 16, 2015 at 4:32 PM, Arun Rangarajan
wrote:
[...]
> This query
> q=name:of&rows=0
> gives no results as expected.
>
> However, this query:
> q=name:of AND all_class_ids:(371)&rows=0
> gives results and is equal to the same number of results as
> q=all_class_ids:(371)&rows=0
>
> This is
Query parsing is not strict boolean logic, this trips up many people
even though AND, NOT and OR are used. See:
https://lucidworks.com/blog/why-not-and-or-and-not/
I think what you've really got at the top level is a single MUST
clause, namely all_class_ids:(371).
What is _not_ happening here is a
