lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Erik Hatcher <>
Subject Re: Limiting QueryParser
Date Wed, 22 Nov 2006 09:15:07 GMT

On Nov 21, 2006, at 10:34 PM, Antony Bowesman wrote:
> On the field specific fields, I want to control the parsing to  
> ensure that the parser will not interpret fields in the user  
> entered string, so in those fields it treats : as : all of the  
> time.  However, in the "free form" field, anything goes and : is a  
> field delimeter all of the time.  So, a user can seach for
> Subject  - important:conference agenda
> FieldA   - blah:abc
> FreeForm - fieldX:Xdata fieldY:Ydata
> in the above, the Subject and Field A would have been indexed using  
> configurable analysers and would have indexed "important" and  
> "blah", so these are relevant to the search.
> This should come out as a
> (+subject:important +subject:conference +subject:agenda)  
> (+fielda:blah +fielda:abc) (+fieldx:xdata +fieldy:ydata)
> My framework allows for field specific parsers as well as field  
> specific analysers, so having a different query parser for the  
> named fields and the free form field is fine.

It doesn't seem like you need a "parser" at all for your field- 
specific search fields.  Simply tokenize, using a Lucene Analyzer,  
the text field and build up a BooleanQuery of all the tokens.

QueryParser is over prescribed - and is often not the best fit for  
the job.  It's only a few lines of code to tokenize (look at the  
QueryParser code in how it creates a PhraseQuery, for example) and  
build a Query from the tokens.

If you need to support +/-/AND/OR syntax in your field-specific  
inputs that's a different story - though your example does not show  
this need.  If so, copying the QueryParser.jj file and removing the  
"field:" syntax and fixing all created Query objects to a specified  
single field might be the trick.


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

View raw message