The reason I thought StatsComponent is "default" while SpellCheck is
not is that SpellChecking necessarily requires some configuration.
Stats can be there without doing anything -- it is just the cost of
checking if "stats=true" in the request.
I suggest that we add *all* Components that are generally useful off
the shelf to the StandardRequestHandler. We should add documentation
to say: "if you know exactly what features you need, you should
configure the RequestHandler to use only those features." The
SearchHandler should not register any components by default.
I disagree with Erik that we should have people explicitly configure
the components.
As for component registration precedence, it is the configured
Component that has precedence. The Component initialization code only
adds the default Component if that name is not already used.
Registering your own "spellcheck" Component will use your component.
ryan
On Oct 1, 2008, at 4:28 PM, Grant Ingersoll wrote:
SOLR-680 proposes to add StatsComponent to the set of "standard"
search components. Initially, the SpellCheckComponent did this as
well. At the time, I thought we shouldn't add them to the standard
set, but clearly others think differently.
So, I think we should have a discussion of the merits of doing so,
and try to come to some type of understanding of when something
should be "standard" and when it should be optional. I suspect, the
answer is Erik's "It depends", but let's discuss.
On the plus side, people get the new functionality without having to
configure anything. On the negative, it adds one or more if clauses
(to see if the component is on) per query per "added" component.
Not necessarily a big deal, but it is a few extra instructions that
weren't being executed before...
It also, theoretically, could cause a name clash with an existing
component that someone developed on their own. For instance, if I
had my own "spellcheck" Component, and then all of a sudden Solr put
in a new one by default, what would that mean? Would it be obvious
to me which one is being used? Is that back-compatible?
My inclination is to err on not including them by default, yet I do
think there are things that are highly valuable by default, and part
of our job as developers is to provide a good out of the box
experience. And, to me, part of that is having to do as little
configuration as possible.
Thoughts?
-Grant
