lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hoss Man (JIRA)" <>
Subject [jira] [Commented] (SOLR-3534) dismax and edismax should default to "df" when "qf" is absent.
Date Thu, 14 Jun 2012 19:49:44 GMT


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)...

 * 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;

> dismax and edismax should default to "df" when "qf" is absent.
> --------------------------------------------------------------
>                 Key: SOLR-3534
>                 URL:
>             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:!default.jspa
For more information on JIRA, see:


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

View raw message