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 <[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
