lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hoss Man (JIRA)" <>
Subject [jira] [Commented] (SOLR-2724) Deprecate defaultSearchField and defaultOperator defined in schema.xml
Date Mon, 22 Aug 2011 18:43:29 GMT


Hoss Man commented on SOLR-2724:

FWIW: defaultSearchField and solrQueryParser/@defaultOperator both predate all of the QParser
stuff, and i agree that if we had QParsers from the begining, they probably would have never

Conceptually, when you think about schema design, and the roles of "schema maintainer" and
"solr instance maintainer" i view the defaultSearchField as a fairly important piece of information
the schema maintainer is providing for people who then consume the index.  It's a statement
(from the schema maintainer to any/all solr users) that in the absence of any more specific
use cases provided by the solr instance maintainer, this field can be used as a field to search

Is that conceptual meaning significant enough to warrant saying "this is a crucual feature
in solr" ? .. probably not, but it's how i think about it.

At this point though, i'm not sure that eliminating them really improves anything.  yes we
have the df param and the q.op param, but if/when those params aren't set, these values provide
system wide defaults.  We certain *can* deprecate them, but i don't know that that really
helps our users in anyway.  we could move them to solrconfig.xml, but that would require the
same amount of work from users to modify configs as just eliminating them.

i guess what i would propose is that since the only real issue with them is potential confusion
about where/why they exist, we:
* leave the code in to use them as fall back defaults
* leave tests in place to sanity check that they work
* stop advertising them in the examples quietly deprecate in 3x, but don't explicitly remove in 4x.  

bq. And <similarity> should move to solrconfig.xml. I am willing to do it, provided
there is consensus on it of course.

Similarity is a whole different ball of wax.  it's already per-fieldType on trunk, so it really
can't be moved to solrconfig.xml (even if it wasn't, it's something that's used at both index
time and query time so it *MUST* be consistent in master/slave type setups, which is the driving
force for when soemthing must live in schema.xml)

> Deprecate defaultSearchField and defaultOperator defined in schema.xml
> ----------------------------------------------------------------------
>                 Key: SOLR-2724
>                 URL:
>             Project: Solr
>          Issue Type: Improvement
>          Components: Schema and Analysis, search
>            Reporter: David Smiley
>            Assignee: David Smiley
>            Priority: Minor
>             Fix For: 3.4, 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.
For more information on JIRA, see:


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message