René Hackl wrote:
>Bill,
>
>Thank you for clarifying on that issue. I missed the...
>
>
>
>>(title:cutting OR author:cutting) AND (title:lucene OR author:lucene)
>>
>>
> ...
>
>
>>(title:cutting OR title:lucene) AND (author:cutting OR author:lucene)
>>
>>Note that this would match even if only "lucene" occurred in the
>>
>>
>
>... "only lucene"/"only cutting" match.
>
>
>
>>I'd think that if a user specified a query "cutting lucene", with an
>>implicit AND and the default fields "title" and "author", they'd
>>expect to see a match in which both "cutting" and "lucene" appears.
>>
>>
>
>Hopefully they'd expect that. Sometimes users assume that e.g. "coffee OR
>tea" would provide matches with either term, but not both. But this is
>already "user-attune your application" territory. Your proposal makes
>perfect sense, of course.
>
>René
>
>
>
is it a problem if the users will search "coffee OR tea" as a search
string in the case that MultifieldQueryParser is
modifyed as Bill suggested?, and the default opperator is set to AND?
I don't think so ... I think that the resulting Query should be:
(title:cutting OR author:cutting) OR (title:lucene OR author:lucene)
And I think that the results will be correct.
Am I wrong?
I don't know exactly what will happen with more complex queries, the uses grouping, exact
matches and NOT operator
like:
(alcohol NOT tea) OR ("black tea" AND brandy)
what will happen if you send this to a MultifieldQueryParser that searches in an index with
the fields "drink" and "juices"
Maybe this kind of search constructions should be a part of JUnit tests, if they are not already
there.
Thanks,
Sergiu
---------------------------------------------------------------------
To unsubscribe, e-mail: lucene-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: lucene-user-help@jakarta.apache.org
|