lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Spencer <>
Subject Re: Refactoring suggestion for query parsing and creation
Date Mon, 07 Feb 2005 19:17:54 GMT

This is interesting and may match what I've wanted - a way to register 
customized query expansion modules w/ the query parser so that you can 
experiment with different ways of expanding the query e.g. I wrote a 
"WordNet" package that's in the sandbox that expands terms by adding 
their synonyms e.g. "big" might expand to "big large^.9 huge^.9".

So is it safe to assume I could use your code like this (with 2 lines 
changed from your example):

QueryParser parser =
   new QueryParser(
      "synonym",                 // pseudo field?
      new StandardAnalyzer(),
      new SpecialQueryFactory(new WordNetQueryFactoryImpl())); // 
wordnet factory?

Then a query can use the pseudo-field "synonym" any place:

"+synonym:big dog"

expands to:

"+(big large^.9 huge^.9) dog"

If so cool, I've wanted an extensible query parser for a while..


  When I wrote up my ideas on this a while ago I though the psuedo-field 
should look different from the normal fields e.g. it should have 2 
colons, not 1, but it's not a huge issue.

Matthew Denner wrote:

> Hi,
> I have been working with Lucene for about a month now and I am really 
> impressed by the work of the people involved.  I did, however, come across 
> something that I thought my be better refactored: extending the QueryParser 
> to add your own handling of various Query implementations.  So I had a go at 
> introducing a QueryFactory interface that classes can implement to provide 
> construction of these Query implementations, and then an instance can be 
> passed to a QueryParser instance for it to use.  I have a patch that provides 
> this if the developers of Lucene are interested but, because it is a quite 
> dramatic change (it removes alot of deprecated methods which I was very 
> worried about) I would prefer someone to take a look at it and see if they 
> think it is worthwhile.
> The reason I made this patch is that I wanted to deal with integer ranges for 
> a particular field in my application and, like I said, extending QueryParser 
> felt wrong to me (and took me almost a week to actually find!).  With the 
> patch I write:
> QueryParser parser = 
>   new QueryParser(
>     "description", 
>     new StandardAnalyzer(),
>     new SpecialQueryFactory(new QueryFactoryImpl()));
> And my specialised QueryFactory implementation gets used during parsing.  The 
> implementation of QueryFactoryImpl was created by moving those methods that 
> created Query instances in the original QueryFactory into a separate class.  
> I also created a MultiFieldQueryFactory implementation that takes the methods 
> from MultiFieldQueryParser (effectively making it now redundant).
> Personally I prefer the idea of composition over inheritance, in this 
> circumstance, but I can understand why other people would not want this.
> Anyway, if someone would like to see the patch (made against the HEAD of the 
> Lucene CVS code) I can provide it; or you can tell me where to go!  Either 
> way, Lucene has still made searching so much easier and I thank you.
> Matt
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message