I use the boolean logic heavily in a production app, because it's the grammar that my users understand (and they put together complex boolean queries in other apps too). Also, we're not using relevance ranking. A document either "matches the query" and gets returned, or "doesn't match" and doesn't get returned. We only want yes/no answers.
I haven't had time to really figure out what the earlier commenter meant with the + operators syntax conversion. I still thought it would have meant the same thing as the query I had posted, ie, article has to match all terms in the AND clauses, and at least one of the terms in the OR list. I guess I'm still missing what his explanation was trying to demonstrate. Anyway, just a note to say that boolean matching is important to me and my users; it'd be good if it worked the way it looks like it would. If it doesn't, I need to understand better what the current limitations are. I'll be out of town and away from net for 4 days, starting tomorrow, so I'll have to continue conversation once I'm back. Thanks for the help and comments thus far. Jenny Brown On Wed, Mar 11, 2009 at 8:58 PM, Mike Klaas <[email protected]> wrote: > > On 8-Mar-09, at 3:46 PM, Chris Hostetter wrote: >> >> it's important to rememebr that Lucene isn't a boolean matching system -- >> the undelrying semantics are MUST/MUST_NOT/SHOULD -- the AND/OR >> keywords are just syntactic sugar that attempt to apply underlying >> semantics as binary opperators. > > Has anyone (but me) considered ripping out this misleading (and imho not > terribly useful) syntactic sugar in Lucene 3.0? It seems that the boolean > operator support is little but an impediment to understanding the Lucene > query model. Analogies that only occasionally accord with a person's > intuition are among the most dangerous. > > There could always be a query parser mode or module that is devoted to > parsing boolean operators correctly. > > -Mike >
