[
https://issues.apache.org/jira/browse/SOLR-3534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13295268#comment-13295268
]
Hoss Man commented on SOLR-3534:
--------------------------------
bq. dismax&edismax should look at 'df' before falling back to defaultSearchField
+1 ... i thought it already did that, but i guess not. If we are
"deprecating/discouraging" <defaultSearchField/> and instructing people to use
"df" instead, then we should absolutely make 100% certain any code path we ship
that currently consults <defaultSearchField/> checks "df" first. (if/when the
code paths that consult <defaultSearchField/> are removed, they should still
consult "df")
bq. dismax&edismax should throw an exception if neither 'qf', 'df', nor
defaultSearchField are specified, because these two query parsers are fairly
useless without them.
+1 .. (although i suppose edismax could still be usable if every clause is
fully qualified with a fieldname/alias and fail only when a clause that
requires a default is encountered ... just like the LuceneQParser)
bq. I ran all tests before committing and found the MinimalSchemaTest failed
related to the "dismaxNoDefaults" request handler in the test solrconfig.xml
which was added in SOLR-1776. The problem is throwing an exception if there's
no 'qf', 'df', or default search field. I disagree with that test – it is
erroneous/misleading to use dismax without setting specifying via any of those
3 mechanisms. I am inclined to delete the "dismaxNoDefaults" test request
handler (assuming there are no other ramifications). I want to get input from
Hoss who put it there so I'll wait.
As Bernd noted, that test was written at a time when the schema.xml used by the
test had a <defaultSearchField/> declared -- that was/is the entire point of
the test: that the Dismax(Handler|QParser) could work with a
"<defaultSearchField/>" and a "q" and no other params specified. As long as
"<defaultSearchField/>" is legal (even if it's deprecated and not mentioned in
the example schema.xml) a test like that should exist somewhere shouldn't it?
(if/when "<defaultSearchField/>" is no longer legal, then certainly change the
test to add a "df" param and assert that it fails if one isn't specified)
--
The current patch looks like a great start to me ... but i would suggest
refactoring this core little bit into it's own method in SolrPluginTools and
replacing every use of getDefaultSearchFieldName in the code base with it (and
add a link to it from getDefaultSearchFieldName javadocs encouraging people to
use it instead)...
{code}
/**
* returns the effective default field based on the params or
* hardcoded schema default. may be null if either exists specified.
* @see CommonParams#DF
* @see IndexSchema#getDefaultSearchFieldName
*/
public static String getDefaultField(final IndexSchema s, final SolrParams p) {
String df = p.get(CommonParams.DF);
if (df == null) {
df = s.getDefaultSearchFieldName();
}
return df;
}
{code}
> dismax and edismax should default to "df" when "qf" is absent.
> --------------------------------------------------------------
>
> Key: SOLR-3534
> URL: https://issues.apache.org/jira/browse/SOLR-3534
> Project: Solr
> Issue Type: Improvement
> Components: query parsers
> Affects Versions: 4.0
> Reporter: David Smiley
> Assignee: David Smiley
> Priority: Minor
> Attachments:
> SOLR-3534_dismax_and_edismax_should_default_to_df_if_qf_is_absent.patch
>
>
> The dismax and edismax query parsers should default to "df" when the "qf"
> parameter is absent. They only use the defaultSearchField in schema.xml as a
> fallback now.
--
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
