lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "J.J. Larrea" <>
Subject Re: Searching API: QueryParser vs Programatic queries
Date Mon, 22 May 2006 16:54:50 GMT
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 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.

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 then had to
subclass and finally copy-and-modify QP to make it conform to requirements).

The underlying issue may be that there are two quite different concerns bundled into QueryParser:
 - Parsing a string into a set of discrete query requests
 - Constructing Query objects to meet those requests

If you take a look at you'll see that someone
else (Matthew Denner) also had this belief, and went so far as to implement a QueryFactory
interface and a couple of implementing classes.  One has the construction logic now found
in QueryParser.  Then there is a decorator class which adds the functionality of MultiFieldQueryParser
and another which lower-cases terms.

Perhaps something along those lines that should be considered for the next break in API continuity
eg. Lucene 2.0.  It seems much cleaner than subclassing QP when all that is needed is a variant
in Query construction logic, and it also provides a higher-level interface for constructing
Query objects (especially TermQuery) like you were proposing.  Unfortunately the actual LUCENE-344
patch appears out of date with changes in QueryParser, MultiFieldQueryParser, etc.  But perhaps
just the QueryFactory part would be a good starting point for what you want to do.

Anyway, just a thought.

- J.J.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message