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? -Yonik On 7/20/06, Chris Hostetter <[EMAIL PROTECTED]> 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
