lucene-solr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Yonik Seeley" <>
Subject Re: QueryParser default operator - AND
Date Thu, 20 Jul 2006 21:58:33 GMT
Ok, a factory method to get the "default" query parser isn't a bad
idea (as long as we can live with a global config for it, and it
doesn't need to change for different handlers).  Handlers like dismax
that know they need certain options could either not use the factory,
or reset the params it really cares about.

If it's global, I guess it could make sense to go in either schema.xml
or solrconfig.xml... any preferences?


On 7/20/06, Chris Hostetter <> wrote:
> : Maybe it belongs in solrconfig.xml as an option on the standard
> : request handler init()... after all, it wouldn't apply to the dismax
> : handler right (or could it...)?  If we ever got a handler that
> : accepted XML with explicit optional/required/prohibited, it wouldn't
> : apply there either.
> dismax already uses it's own subclass of SolrQueryParser with options
> configurable in it's init params ... and yes, there are certianly a lot of
> use cases where this wouldn't make sense -- but in those same use cases
> the "defaultSearchField" doesn't make sense either, but we have it for the
> simple case.
> i read Erik's suggestion as relating mainly to simple request handlers
> (including the StandardRequestHandler that want to use the basic query
> parser, but with some control over configuration -- allthough looking at
> his patch a little closer, i realze he is using the value in the
> constructor of SolrQueryParser ... perhaps a better place for that would
> be within QueryParser.parseQuery() ... or add a new
> IndexSchema.getDefaultQueryParser() method which looks at any config
> options in the schema and is called by QueryParser.parseQuery()
> : As far as the default being "AND", one problem besides breaking
> : existing queries is that the QueryParser with an AND default has less
> : expressive power than an "OR" default.  This is because there are "+"
> : and "-" symbols for required and prohibited, but no symbol for
> : optional.  So you can't currently express "+a -b c"
> aggreed ... making the default "AND" assumes strict boolean logic, and is
> not a good idea since lucene supports more flexibility then strict boolean
> matching.
> -Hoss

View raw message