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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
