.apache.org
> Subject: RE: Searching API: QueryParser vs Programatic queries
>
> Chris Hostetter wrote:
>
> > typically, when build queries up from form data, each piece of data
> > falls into one of 2 categories:
> >
> > 1) data which doesn't need an
Chris Hostetter wrote:
> typically, when build queries up from form data, each piece
> of data falls into one of 2 categories:
>
> 1) data which doesn't need analyzed because the field it's going to
> query on wasn't tokenized (ie: a date field, or a
> numeric field, or a
> boolean
J.J. Larrea wrote:
> I concur with your thoughts that there is room for such
> utility classes, and that those would increase the use of
> programmatic queries. I say this as a developer who also
> "lazed out" and opted to simply construct a string and let
> the QP do all the work (but who t
Erick Erickson wrote:
...
> It seems to me that you can always do something like:
> BooleanQuery bq;
> QueryParser qp1 = new QueryParser("field1", "", analyzer);
> Query q1 = qp1.parse("search term or clause); bq.add(q1,,,);
> QueryParser qp2 = new QueryParser("field2", "", analyzer);
> Query q
: Not quite. The user is presented with a list of (UI) fields, and each
: field already knows whether its an "OR" "AND" etc.
: So, there is no query String as such.
: For this reason, it seems to make more sense to build the query up
: programmatically - as my field meta data can drive this.
: How
There's a long scree that I'm leaving at the bottom because I put effort
into it and I like to rant. But here's, perhaps, an approach.
Maybe I'm mis-interpreting what you're trying to do. I'm assuming that you
have several search fields (I'm not exactly sure what "driven by meta-data"
means in th
At 10:15 AM +0100 5/22/06, Irving, Dave wrote:
>- Is there maybe some room for more utility classes in Lucene which make
>this easier? E.g: When building up a document, we don't have to worry
>about running content through an analyser - but unless we use
>QueryParser, there doesn't seem to be corre
On May 22, 2006, at 8:44 AM, Irving, Dave wrote:
So, right now, if Im being lazy, the easiest thing to do is
construct a
query string based on the meta data, and then run that through the
query
parser. This just doesn't -- feel right -- from a design perspective
though :o)
How about build
t would be some of the stuff in
QueryParser#getFieldQuery(String field, String queryText).
> -Original Message-
> From: Raghavendra Prabhu [mailto:[EMAIL PROTECTED]
> Sent: 22 May 2006 16:17
> To: java-user@lucene.apache.org
> Subject: Re: Searching API: QueryParser vs Programatic
java-user@lucene.apache.org
> Subject: Re: Searching API: QueryParser vs Programatic queries
>
> Dave,
> You said you are new to Lucene and you didn't mention this
> class explicitly, so you may not be aware of it yet:
> PerFieldAnalyzerWrapper.
> It sounds like this may be w
:59
> To: java-user@lucene.apache.org
> Subject: Re: Searching API: QueryParser vs Programatic queries
>
> Dave,
> You said you are new to Lucene and you didn't mention this
> class explicitly, so you may not be aware of it yet:
> PerFieldAnalyzerWrapper.
> It sound
ser@lucene.apache.org
Sent: Monday, May 22, 2006 5:15:23 AM
Subject: Searching API: QueryParser vs Programatic queries
Hi,
Im very new to Lucene - so sorry if my question seems pretty dumb.
In the application Im writing, I've been "struggling with myself" over
whether I should be
Hi,
Im very new to Lucene - so sorry if my question seems pretty dumb.
In the application Im writing, I've been "struggling with myself" over
whether I should be building up queries programatically, or using the
Query Parser.
My searchable fields are driven by meta-data, and I only want to suppo
13 matches
Mail list logo
