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 is probably implementable in a similar fashion. But it
would need a bunch of use-cases and/or reference material to check the
benefits against.

Or it could be just a matter of marking first/last token as keywords.
Well, would have been if StopWordFilter actually checked for
*isKeyword()*. It does not seem to.

Regards,
   Alex.
----
Sign up for my Solr resources newsletter at http://www.solr-start.com/


On 16 February 2015 at 20:33, Jack Krupansky <jack.krupan...@gmail.com> wrote:
> 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 the case of a leading or trailing
> stopword. The old Lucid query parser did have better support for queries
> with stop words, but that's no longer available in their current product.
>
> -- Jack Krupansky
>
> On Mon, Feb 16, 2015 at 8:16 PM, Alexandre Rafalovitch <arafa...@gmail.com>
> wrote:
>
>> On 16 February 2015 at 19:12, Jack Krupansky <jack.krupan...@gmail.com>
>> 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,
>>    Alex.
>>
>> ----
>> Sign up for my Solr resources newsletter at http://www.solr-start.com/
>>

Reply via email to