lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shawn Heisey <>
Subject Re: Trappy behavior with default search field
Date Thu, 05 Jun 2014 17:50:38 GMT
On 6/5/2014 10:48 AM, Erick Erickson 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.

The minimum action here would be to put a comment on the text field in
the example schema alerting users to the fact that this field is
referenced in the example config as the default field, so removing it
will require config changes.

I've wondered whether we need to change the name of that field so it
actually contains the word "default."  A name of default_text or
defaultText would make the problem easier for a user to understand when
they look at their logs after removing the field.

I think the problem that happens when a user types a query like
"somefield:abc 123" is much harder.  If it's possible to detect this
specific kind of query (a search against a specific field, followed by a
space and a bare term), we could log a warning.  We'd need to provide a
config option to turn that warning off.  The warning should probably
reference a wiki or cwiki page explaining what the warning means and how
to disable it.  If we did this, the config option to disable the warning
should be in the example config, commented out.


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

View raw message