lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sergiu gordea <>
Subject Re: Null or no analyzer
Date Thu, 21 Oct 2004 09:38:20 GMT
Erik Hatcher wrote:

> I don't like the idea of users having to know how a field was indexed 
> though.  That seems to defeat the purpose of a general-purpose 
> QueryParser.
>     Erik

I agree that, but maybe lucene should provide some subclasses of 
QueryParser that should deal this problems.
I'm just a lucene user, not a lucene developer, but I have had to 
implement a Extension for MultifieldQueryParser
to fix some not wanted behaviour that I already discussed in the mailing 
These problems that user face with creating the right qeury strings, 
(with the special case of untokenized fileds) togheter
with MultifieldQueryParser problems, MultiSearcher problems ... I think 
that all together suggest the idea of creating a
QueryParser class hierarchy.

  What do you think about that?

  All the best,


> On Oct 21, 2004, at 2:38 AM, Morus Walter wrote:
>> Erik Hatcher writes:
>>> however perhaps it should be.  Or perhaps there are other options to
>>> solve this recurring dilemma folks have with Field.Keyword indexed
>>> fields and QueryParser?
>> I think one could introduce a special syntax in query parser for
>> keyword fields. Query parser wouldn't analyze them at all in this case.
>> Something like
>> field#Keyword
>> or
>> field#"keyword containing blanks"
>> I haven't thought through all consequences for
>> field#(keywordA keywordB otherfield:noKeyword)
>> but I think it should be doable.
>> Doesn't make query parser simpler, on the other hand.
>> Morus
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message