Mailing-List: contact java-user-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: java-user@lucene.apache.org
Received-SPF: pass (herse.apache.org: local policy)
Mime-Version: 1.0 (Apple Message framework v752.3)
In-Reply-To: <4563C54A.2010907@teamware.com>
References: <45637D01.7080000@teamware.com>
 <Pine.LNX.4.58.0611211626560.22671@hal.rescomp.berkeley.edu>
 <4563C54A.2010907@teamware.com>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <3CCDA72B-667B-4EC7-B4C0-EAF80842C87B@ehatchersolutions.com>
Content-Transfer-Encoding: 7bit
From: Erik Hatcher <erik@ehatchersolutions.com>
Subject: Re: Limiting QueryParser
Date: Wed, 22 Nov 2006 04:15:07 -0500
To: java-user@lucene.apache.org


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.

	Erik


---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org