: 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
