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 list. 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,
Sergiu
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
