[
https://issues.apache.org/jira/browse/SOLR-2724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13393436#comment-13393436
]
David Smiley commented on SOLR-2724:
------------------------------------
bq. Although, I'm not so sure we need to drag "Lucene" into this. I mean,
technically the Lucene query parser is completely innocent and it is the Solr
wrapper that "does the deed." Maybe it is sufficient to refer to "various query
parsers, including the default Solr query parser, dismax, and edismax."
The "Lucene query parser" is an accurate statement insofar as there being a
query parser named "lucene" (which is technically Solr's extension to the raw
Lucene one). But I agree with your recommendation on substituting "various
query parsers", and then I can remove the [*] note.
bq. I would suggest that we advise the user: "The preferred technique is to
revise the "df" parameter for the request handlers that your application will
use." (Hmmm... An advantage of defaultSearchField was that you do it in one
place and then it is set for all request handlers for which it is relevant!)
My recommendation / point of view doesn't coincide with yours. I think your
user queries ('q' param) should be [e]dismax and should specify "qf" and "mm".
Other queries (like 'fq', 'bq', 'facet.query', ...) are machine generated and I
think they should be explicit / unambiguously stand-alone without the need for
"df", "q.op" or these global deprecated ones here since they have sweeping
affects (potentially affect queries you didn't want them to) and reduce the
clarity of interpreting any one of these queries by itself because of
ambiguity. I do use 'df' and 'q.op' in my apps as local-params on occasion.
The fact that most of the request handlers in the default solrconfig.xml define
'df' as part of this patch is unfortunate, and has more to do with the legacy
of Solr usage. For example the "/browse" one has it because it includes an
unrealistic query -- facet.query=ipod Please! Even if I fix this query (and
I probably will if I remember), I expect to meet resistance from some on wether
to keep/exclude 'df' and I don't want to argue further on this subject.
> 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
>
> Attachments:
> SOLR-2724_deprecateDefaultSearchField_and_defaultOperator.patch,
> SOLR-2724_deprecateDefaultSearchField_and_defaultOperator.patch
>
> 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: [email protected]
For additional commands, e-mail: [email protected]
