lucene-solr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Walter Underwood <>
Subject Re: default text type and stop words
Date Mon, 05 Nov 2007 22:05:13 GMT
This isn't a problem in Lucene or Solr. It is a result of the analyzers
you have chosen to use. If you choose to remove stopwords, you will not
be able to match stopwords.

Stopword removal has benefits (smaller index, faster searches) and
drawbacks (missed matches, wrong matches). Solr and Lucene allow
you to decide.

Stopword removal is a reasonable default because it works fairly
well for a general text corpus.


On 11/5/07 1:33 PM, "Sundling, Paul" <> wrote:

> I don't know if the problem is in Lucene, I didn't investigate further.
> Maybe it's considered a feature, not a bug for someone with different
> expectations.
> Given that Solr and Lucene have different release schedules.  Even if
> the problem is in Lucene and it's addressed there, that doesn't
> guarentee it's solved with Solr.  You would have to change from using a
> known stable vresion of Lucene to some nightly release that included a
> hypothetical patch or a patched custom version for this one little edge
> case.  It's probably unlikely that either of those are going to happen.
> Or consider changing a line of XML...
> I only suggested considering it.  There is also the concept of an
> anti-corruption layer in domain driven design.  There are issues of time
> frames, release schedules, priorities and I'm not assuming this edge
> case is a high priority.  I merely pointed out an issue in the defaults.
> I also didn't say not to deal with a bug that hypothetically could be in
> a tightly coupled dependency.
> Paul
> -----Original Message-----
> From: []
> Sent: Friday, November 02, 2007 11:02 PM
> To:
> Subject: Re: default text type and stop words
> In a message dated 11/2/07 6:54:25 PM,
> writes:
>> Even if
>> the actual problem is at the Lucene level, perhaps it would be worth
>> considering changes to the default to get around it.
> newbie here. is this common practice? find a bug in a tightly coupled
> dependency and not deal with it there?
> regard,
> billy
> **************************************
>  See what's new at

View raw message