Erik Hatcher wrote:
On Oct 21, 2004, at 5:38 AM, sergiu gordea wrote:
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.
In my case is very usefull. Because my search has constaints like
1) has xxx file format attachment 2) has xxx type 3) was created by xxx 4) search in attachmets or not
so ... I cannot make this customization without indexing in more fields and searching in more fields.
Creating the queryString by adding "filed:keyword" pair is just a hardly maintainable way of reinventing the
wheel. So .. in may case, MultifieldQueryParser is very useful, because I haave to add some boolean clauses
after I create the base query.
Last month I just refactored the method that created the search query for our "extended search" functionality.
It was a method with 200 lines of structural code (no query parser used).
using Boolean clauses and MultifieldQueryParser helped me a lot ... and the result was a method with fewer, easily maintainable
lines of code.
Of course ... this is needed in my project, but I think that almost all lucene indexes contain more then 2-3 fileds.
So ... once again MultifieldQueryParser is an elegent solution.
Sergiu
Erik
--------------------------------------------------------------------- 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]
