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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to