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 <erickerick...@gmail.com> wrote: > 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. > > > > >
