lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sergiu gordea <gser...@ifit.uni-klu.ac.at>
Subject Re: Null or no analyzer
Date Thu, 21 Oct 2004 13:31:49 GMT
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: lucene-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: lucene-user-help@jakarta.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: lucene-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: lucene-user-help@jakarta.apache.org


Mime
View raw message