[
https://issues.apache.org/jira/browse/SOLR-2724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13236941#comment-13236941
]
David Smiley commented on SOLR-2724:
------------------------------------
Erick,
First of all, anyone upgrading should examine CHANGES.txt which would
certainly have a note on this explicitly in the upgrading section of that
document. Secondly, most point-release upgrades people do are ones in which
the config stays the same. Thirdly, the scenario you present in which someone
copies a subset of their 3.5 schema would only error if that person ALSO chose
to omit the defaultSearchField declaration -- but why would they do that?
Besides, I don't think there should be any expectation of "it'll just work" if
you copy some arbitrary subset of an old schema into a new example config.
I didn't know we needed to retain backwards config capability across 3.x to 4.x
:-( That sucks and it'll make old code stick around longer. If that's true,
it'd be nice if we had a standard way to annotate such code so we can
methodically remove the old stuff. "@deprecated" isn't enough because it's
just at the method/class level, not an internal if branch.
> Deprecate defaultSearchField and defaultOperator defined in schema.xml
> ----------------------------------------------------------------------
>
> Key: SOLR-2724
> URL: https://issues.apache.org/jira/browse/SOLR-2724
> Project: Solr
> Issue Type: Improvement
> Components: Schema and Analysis, search
> Reporter: David Smiley
> Assignee: David Smiley
> Priority: Minor
> Fix For: 3.6, 4.0
>
> Original Estimate: 2h
> Remaining Estimate: 2h
>
> I've always been surprised to see the <defaultSearchField> element and
> <solrQueryParser defaultOperator="OR"/> defined in the schema.xml file since
> the first time I saw them. They just seem out of place to me since they are
> more query parser related than schema related. But not only are they
> misplaced, I feel they shouldn't exist. For query parsers, we already have a
> "df" parameter that works just fine, and explicit field references. And the
> default lucene query operator should stay at OR -- if a particular query
> wants different behavior then use q.op or simply use "OR".
> <similarity> Seems like something better placed in solrconfig.xml than in the
> schema.
> In my opinion, defaultSearchField and defaultOperator configuration elements
> should be deprecated in Solr 3.x and removed in Solr 4. And <similarity>
> should move to solrconfig.xml. I am willing to do it, provided there is
> consensus on it of course.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
