lucene-solr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Erik Hatcher <e...@ehatchersolutions.com>
Subject Re: QueryParser default operator - AND
Date Thu, 20 Jul 2006 23:46:39 GMT
I think solrconfig.xml makes more sense, leaving schema.xml to field  
configuration and solrconfig.xml for system settings like caching and  
request/response handling.

	Erik


On Jul 20, 2006, at 5:58 PM, Yonik Seeley wrote:

> 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 <hossman_lucene@fucit.org> 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


Mime
View raw message