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: Building queries
Date Wed, 17 May 2006 12:56:16 GMT
See below...

1) Are there any "best / common practises" for this that I've missed
> during my web searches and reading of Lucene in Action?


OF COURSE there are <G>, but I don't know where they are either..


2) I don't want to release the full query syntax to users: So I'll
> probably have multiple fields in the UI, and then construct them in to a
> query at the server side. One thing that is mentioned quite a bit in
> docs is that the same analyser needs to be used when querying as was
> used when indexing. Im guessing my FieldMetaData concept will help a bit
> here - as I'll be able to track the analyser type employed for a field.
> So, I just need to run the terms entered by the user in each field
> against the appropriate analyser, and build up the query that way. Does
> that sound like a sensible approach? Are there any code samples around
> showing how to run search phrases through analysers and build up a
> query?
>
> Warning! I'm relatively new to Lucene to, so you are warned.. What I did
was add in the underlying index terms to the string, and use a
PerFieldAnalyzerWrapper to "do the right thing" with QueryParser. Kinda like
this...

Let's say you have two fields, F1 and F2 that are indexed as IDX1 and IDX2.
The user enters "clause1" and "clause2" in the fields, respectively.
Construct something like
IDX1:(clause1) IDX2:(clause2) as a string.
Construct a PerFieldAnalyzerWrapper for fields IDX1 and IDX2, call it pFAW

Construct a QueryParser (qp) with the default field and analyzer wrapper
(pFAW), and then you can call qp.parse(constructed string);

Additional warning: watch out for TooManyClausesException if you intend to
allow wildcards. See the thread in this list "I just don't get wildcards at
all" for an exposition "the guys" gave me on this issue.

Best
Erick

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