lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Smiley (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (SOLR-2724) Deprecate defaultSearchField and defaultOperator defined in schema.xml
Date Sun, 17 Jun 2012 04:26:43 GMT

    [ 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: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message