lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Erick Erickson" <erickerick...@gmail.com>
Subject Re: Lucene 2.2.0 Strange QueryParser behavior
Date Mon, 27 Oct 2008 14:43:02 GMT
OR is both a stopword and a reserved word.... In this
case you *probably* are getting hit by it being a stopword.
Changing your analyzer to not use stopwords is probably
the way to go, but beware that you should probably use the
same analyzer at index AND query time.

If you're using StandardAnalyzer, you're getting your case
folded, so if you change analyzers be aware of that.

Get a copy of Luke to see the effects of various analyzers on
queries and to examine the actual contents of your index, it's
invaluable.

PerFieldAnalyzerWrapper may be your friend <G>. It would
allow you to use a different analyzer for your "state" field than
others, which may be very useful.

Best
Erick

On Mon, Oct 27, 2008 at 10:20 AM, Bob Rhodes <Bob.Rhodes@choicepoint.com>wrote:

> Hi all,
> I'm hoping this is an easy question. I have a Lucene index that contains
> names and states, and I'm having an issue when the state is Oregon,
> specifically OR. Below is an example of the query I pass in and the
> query string that QueryParser builds below it.
>
> This works for every state except OR.
>
> String I build: lastname:"rhodes" AND state:"AK"
> QueryParser output: +lastname:rhodes +state:ak
>
> This is what OR look like:
>
> lastname:"Rhodes" AND state:"OR"
> lastname:rhodes
>
> As you can see the state:"OR" is cleaned off by QueryParser. Is there
> any way around this?
>
> Thanks for the time.
>
> Bob
>
>
>
> -----------------------------------------
> The information contained in this e-mail message is intended only
> for the personal and confidential use of the recipient(s) named
> above. This message may be an attorney-client communication and/or
> work product and as such is privileged and confidential. If the
> reader of this message is not the intended recipient or an agent
> responsible for delivering it to the intended recipient, you are
> hereby notified that you have received this document in error and
> that any review, dissemination, distribution, or copying of this
> message is strictly prohibited. If you have received this
> communication in error, please notify us immediately by e-mail, and
> delete the original message.

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message