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/ >>