[
https://issues.apache.org/jira/browse/SOLR-218?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12492418
]
Hoss Man commented on SOLR-218:
-------------------------------
1) these options shouldn't be specified in the solrconfig.xml, they should come
from the schema.xml (since knowing whether you want these options tends to
depends on how you have configured the fields) ... the <solrQueryParser .. />
directive already exists for this purpose, and defaultOperator is already
supported.
2) these settings shouldn't be applied in the constructor for SolrQueryParser
per the contract described in it's comment...
/**
* Constructs a SolrQueryParser using the schema to understand the
* formats and datatypes of each field. Only the defaultSearchField
* will be used from the IndexSchema (unless overridden),
* <solrQueryParser> will not be used.
...changing that makes it very hard for plugin writers to subclass
SolrQueryParser to get a schema aware parser with no other changes. This is
what QueryParsing.parseQuery is for (although i fully support a new factory
method for returning an instance of a SolrQueryParser with these options set on
it.
3) options like dateResolution assume use of DateTools which is not what
DateField uses ... it's possible some users might be using StrField and using
DateTools to format it on the client side, but we should think carefully before
adding this option.
4) do we want another option to enable/disable the use of PrefixFilter for
prefix queries that is currently in SolrQueryParser? it does cause problems
with highlighting prefix queries.
5) regarding this comment...
> In addition, solr should not modify these values from the defaults provided
> by Lucene, as it currently does by
> calling setLowercaseExpandedTerms(false) in this method.
...while i fully agree with this sentiment, changing now to align ourselves
with the Lucene default would break backwards compatibility for existing Solr
users. if the option is not used i the schema.xml, we need to assume
setLowercaseExpandedTerms(false).
> Support for Lucene QueryParser properties via solrconfig.xml file
> -----------------------------------------------------------------
>
> Key: SOLR-218
> URL: https://issues.apache.org/jira/browse/SOLR-218
> Project: Solr
> Issue Type: Improvement
> Components: search
> Affects Versions: 1.1.0
> Reporter: Michael Pelz-Sherman
>
> The SolrQueryParser class, which extends Lucene's QueryParser class, does not
> provide any way of setting the various QueryParser properties via the solr
> config file (solrconfig.xml). These properties include:
> allowLeadingWildcard (Set to true to allow * and ? as the first character of
> a PrefixQuery and WildcardQuery)
> dateResolution: Sets the default date resolution used by RangeQueries for
> fields for which no specific date resolutions has been set.
> defaultOperator: Sets the boolean operator of the QueryParser.
> fuzzyMinSim: Set the minimum similarity for fuzzy queries.
> locale: Set locale used by date range parsing.
> lowercaseExpandedTerms: Whether terms of wildcard, prefix, fuzzy and range
> queries are to be automatically lower-cased or not.
> phraseSlop: Sets the default slop for phrases.
> useOldRangeQuery: By default QueryParser uses new ConstantScoreRangeQuery in
> preference to RangeQuery for range queries.
> This can be achieved by calling the setter methods for these properties in
> the SolrQueryParser constructor,
> public SolrQueryParser(IndexSchema schema, String defaultField) {
> super(defaultField == null ? schema.getDefaultSearchFieldName() :
> defaultField, schema.getQueryAnalyzer());
> this.schema = schema;
>
> setAllowLeadingWildcard(SolrConfig.config.getBool("query/setAllowLeadingWildcard"));
>
> setLowercaseExpandedTerms(SolrConfig.config.getBool("query/lowerCaseExpandedTerms"));
> }
> In addition, solr should not modify these values from the defaults provided
> by Lucene, as it currently does by calling setLowercaseExpandedTerms(false)
> in this method.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
