lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Raghavendra Prabhu" <rrpra...@gmail.com>
Subject Re: Searching API: QueryParser vs Programatic queries
Date Mon, 22 May 2006 15:16:33 GMT
If i understand correctly, is it that you dont want to make use of query
parse?

You need to parse a query string without using query parser and construct
the query and still want an analyzer applied on the outcome search.


On 5/22/0 p6, Irving, Dave <dave.irving@logicacmg.com> wrote:

> Hi Otis,
>
> Thanks for your reply.
> Yeah, Im aware of PerFieldAnalyserWrapper - and I think it could help in
> the solution - but not on its own.
> Here's what I mean:
>
> When we build a document Field, we suppy either a String or a Reader.
> The framework takes care of running the contents through an Analyser
> (per field or otherwise) when we add the document to an index.
>
> However, on the searching side of things, we don't have similar
> functionality unless we use the QueryParser.
> If we build queries programatically, then we have to make sure (by hand)
> that we run search terms through the appropriate analyser whilst
> constructing the query.
>
> Its in this area that I wonder whether additional utility classes could
> make programatic construction of queries somewhat easier.
>
> Dave
>
> > -----Original Message-----
> > From: Otis Gospodnetic [mailto:otis_gospodnetic@yahoo.com]
> > Sent: 22 May 2006 15: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 sounds like this may be what you are after.
> >
> > Otis
> >
> > ----- Original Message ----
> > From: "Irving, Dave" <dave.irving@logicacmg.com>
> > To: java-user@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 building up queries
> > programatically, or using the Query Parser.
> >
> > My searchable fields are driven by meta-data, and I only want
> > to support a few query types. It seems "cleaner" to build the
> > queries up programatically rather than converting the query
> > to a string and throwing it through the QueryParser.
> >
> > However, then we hit the problem that the QueryParser takes
> > care of Analysing the search strings - so to do this we'd
> > have to write some utility stuff to perform the analysis as
> > we're building up the queries / terms.
> >
> > And then I think "might as well just use the QueryParser!".
> >
> > So here's what Im wondering (which probably sounds very dumb
> > to experienced Lucene'rs):
> >
> > - 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
> > corresponding behaviour on the search side.
> > - So, Im thinking some kind of factory / builder or
> > something, where you can register an Analyser (possibly a per
> > field wrapper), and then it is applied per field as the query
> > is being built up programatically.
> >
> > Maybe this is just an "extraction" refactoring to take this
> > behaviour out of QueryParser (which could delegate to it).
> >
> > The result could be that more users opt for a programatic
> > build up of queries (because it's become easier to do..)
> > rather than falling back on QueryParser in cases where it may
> > not be the best choice.
> >
> >
> > Sorry if I rambled too much :o)
> >
> > Dave
> >
> >
> > This e-mail and any attachment is for authorised use by the
> > intended recipient(s) only. It may contain proprietary
> > material, confidential information and/or be subject to legal
> > privilege. It should not be copied, disclosed to, retained or
> > used by, any other party. If you are not an intended
> > recipient then please promptly delete this e-mail and any
> > attachment and all copies and inform the sender. Thank you.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
> > For additional commands, e-mail: java-user-help@lucene.apache.org
> >
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
> > For additional commands, e-mail: java-user-help@lucene.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-user-help@lucene.apache.org
>
>

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