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?
Query parsing/expansion is the holy grail. There are so many ways to do this sort of thing that I'm mostly of the opinion it is a per-project customization to get it tuned for the needs of that project.
Nutch has done some nice things with query parsing/expansion and extensibility.
I'm all for a more extensible base to work from, no question.
I'm personally not fond of MultiFieldQueryParser - I much prefer aggregate fields that are indexed (not stored) to be used for queries. Blindly expanding queries across fields doesn't seem that useful to me.
Erik
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
