Thanks everyone. For our use case in Rocana Search, we don't use scoring at all. We always sort by a timestamp field present in every Document, so for us Lucene query logic is always truly boolean - we only want exact matches using boolean logic like you would get from a database query.
That being said, I can see now why +/- operators are useful when wanting "should" vs. "must" for scoring. Trejkaz - thanks for the deeper explanation. We will, in fact, modify naked "NOT x" queries (where x might be a complex clause) to be (*:* AND NOT x) as that is exactly the interpretation we want. -Michael Peterson https://www.rocana.com/ On Thu, Feb 16, 2017 at 8:27 PM, Trejkaz <trej...@trypticon.org> wrote: > On Fri, Feb 17, 2017 at 11:14 AM, Erick Erickson > <erickerick...@gmail.com> wrote: > > Lucene query logic is not strict Boolean logic, the article above > explains why. > > tl;dr it mostly comes down to scoring and syntax. > > The scoring argument will depend on how much you care. (My care for > scoring is pretty close to zero, as I don't care whether the better > results come first, as long as the exact results come back and the > non-results don't.) > > For the syntax: > > * The article doesn't really address the (-NOT) problem, where > essentially Lucene could insert an implicit *:* when there isn't one, > to make those queries at least get a sane result. You can work around > this by customising the query parser, possible for both for the > classic one (subclass it and override the method to create the > BooleanQuery) and the flexible one (add a processor to the pipeline). > > * The article strongly encourages using the +/- syntax instead of > AND/OR/NOT, but the astute might notice that AND/OR/NOT is three > operators, whereas +/- is only two, so clearly one of the boolean > clause types does not have a prefix operator, making it literally > impossible to specify some queries using the prefix operators alone. > > TX > > --------------------------------------------------------------------- > To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org > For additional commands, e-mail: java-user-h...@lucene.apache.org > >
