lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "" <>
Subject Re: Trappy behavior with default search field
Date Thu, 05 Jun 2014 18:18:38 GMT
In my view, solrconfig.xml shouldn’t refer to any field by name out of the
box, except for the /browse handler, and perhaps pre-filling the query form
in the admin GUI.  That’s it.

A couple years ago at about the time I became a committer, I finally did
something about a feature I am very opinionated about something I hate (and
there are few things I hate; ‘qt’ is another) — specifying the default
search field and default operator in the schema. So thankfully it’s
commented out and deprecated now. I ideally would have have gone farther
such that the default solrconfig.xml doesn’t set “df” in /select.  Hoss
added that because, if I recall, some tests broke, amongst other possible
reasons.  In my view, the only reason to keep “df” pre-configured in
/select is for back-wards compatibility expectations with sample queries on
tutorials/websites, but I’d like to see it done for 5x at least.

Furthermore, in my view, “df” (and q.op) should only be “seen” as a
local-param, with the further modification that all top-level parameters
can become virtually local-params to the ‘q’ param.  I should be able to
write a “fq”, “facet.query”, or one of the other myriad of queries using
standard default Lucene syntax without a default field and with the
operator being assumed OR unless I locally change it in local-params.
 Doing otherwise is an ambiguous query if looking at the query by itself.

~ David

On Thu, Jun 5, 2014 at 12:48 PM, Erick Erickson <>

> We've all been bitten by the trappy problem with removing the "text" field
> from schema.xml and then Solr failing to start b/c various handlers
> specifically call it out.
> Problem is that as people build out (particularly) SolrCloud clusters,
> this innocent-seeming action is getting harder and harder to track down.
> Is it worth a JIRA to address? And any clues how to address it? I started
> thinking about in a _very_ superficial manner and I suspect that this is
> one of those things that _seems_ easy but turns into a sticky wicket.
> If we make sure and return a field that _is_ defined, then the problem
> becomes even harder to detect. I mean you don't even get any warning but
> don't find your docs b/c the default field isn't there and you're searching
> on a different field than you think. At least the current behavior
> sometimes causes Solr to not start at all.
> Im not even sure it's worth doing, we currently both print an error in the
> log and return an error message for a search, but wanted to gather other's
> thoughts.

View raw message