You are viewing a plain text version of this content. The canonical link for it is here.
Posted to solr-dev@lucene.apache.org by Grant Ingersoll <gs...@apache.org> on 2008/10/01 22:28:36 UTC
What is a "Standard" SearchComponent? (SOLR-680)
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
Re: What is a "Standard" SearchComponent? (SOLR-680)
Posted by Ryan McKinley <ry...@gmail.com>.
>
> On Oct 1, 2008, at 5:33 PM, Ryan McKinley wrote:
>> I disagree with Erik that we should have people explicitly
>> configure the components.
>
> Folks don't have to explicitly configure them, if they are just
> running with the example configuration - which is more likely than
> not.
>
> Oh, another thing about search components, I don't like the first/
> last thing - I like it to be explicit, less magic.
>
>> 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.
>
> Right, but what if someone has a "stats" component now in 1.3 wired
> into a custom request handler (but not /select), then upgrades to
> 1.4 with the new implicit "stats" built-in - then all of a sudden a
> request to /select will use _their_ stats component, not the built
> in one. Right?
Ok, I see you point... since we are past 1.3, this may a moot point,
but how about something like:
* SearchHandler has no components registered and must be configured
manually.
* StandardRequestHandler (currently nothing more then extends
SearchHandler) would register all components with no dependancies - it
would not support things like first/last components.
Users extending SearchHandler would have absolute control -- users
extending StandardRequestHandler would have standard configuration -
features may be added between major releases, but not removed.
ryan
Re: What is a "Standard" SearchComponent? (SOLR-680)
Posted by Chris Hostetter <ho...@fucit.org>.
: > 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.
:
: Right, but what if someone has a "stats" component now in 1.3 wired into a
: custom request handler (but not /select), then upgrades to 1.4 with the new
: implicit "stats" built-in - then all of a sudden a request to /select will use
: _their_ stats component, not the built in one. Right?
this never really sit well with me before either ... but i couldn't
really place why it didn't sit well untill you gave that example.
we can't undo the current behavior because it has it's legitimate use
cases: i've subclassed QueryComponent to modify it with some custom
behavior, and i've registered an instance of MyQueryComponent with the
name "query" and now i'm relying on it to get used by default.
I think the "solution" to this problem is education and documentation ...
people customizing Solr may occasionally have to make some changes when
upgrading, it's a fact of life that can't be completely avoided.
Consider another equally plausible situation: i have custom response
writer in my Solr 1.2 and it uses a request param named "defType" -- which
when i upgrade to Solr 1.3 suddenly causes all sorts of things to break,
because the param name i picked collides with a new param that all the
request handlers i use pay attention to.
In the rewuest param collision situation users are *really* screwed,
because they have to change the params their clients send ... by
comparison, the component name collision situation is trivial to deal
with, just search and replace "stats" with "mystats" everywhere in your
solrconfig.xml.
-Hoss
Re: What is a "Standard" SearchComponent? (SOLR-680)
Posted by Erik Hatcher <er...@ehatchersolutions.com>.
On Oct 1, 2008, at 5:33 PM, Ryan McKinley wrote:
> I disagree with Erik that we should have people explicitly configure
> the components.
Folks don't have to explicitly configure them, if they are just
running with the example configuration - which is more likely than not.
Oh, another thing about search components, I don't like the first/last
thing - I like it to be explicit, less magic.
> 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.
Right, but what if someone has a "stats" component now in 1.3 wired
into a custom request handler (but not /select), then upgrades to 1.4
with the new implicit "stats" built-in - then all of a sudden a
request to /select will use _their_ stats component, not the built in
one. Right?
Erik
Re: What is a "Standard" SearchComponent? (SOLR-680)
Posted by Chris Hostetter <ho...@fucit.org>.
: 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
I think that general philosophy is what makes the most sense ... as long
as a component can be used without special configuration add it by
default, but Components should be NOOPs unless activated by params (ie:
facet=true).
people worried about saving every last cycle can create an explicit list
of components and trust that no new components will get added to the
pipeline when they upgrade. ... but for people who upgrade without
modifying their configs, and may not even know anything about search
components, give them the new hotness by default, so when they ask "how do
i...?" and someone says "try adding @foo=true&foo.this=that to your
request" the hotness starts to work for them without them needing to
change anything.
(just like when features got added to standard/dismax before we had
components)
-Hoss
Re: What is a "Standard" SearchComponent? (SOLR-680)
Posted by Ryan McKinley <ry...@gmail.com>.
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
Re: What is a "Standard" SearchComponent? (SOLR-680)
Posted by Erik Hatcher <er...@ehatchersolutions.com>.
One thought is that there isn't a "standard" set of components in the
request handler pipeline, but that they are spelled out entirely
explicitly in the request handler mapping. At that point we can
simply put in everything and the kitchen sink into the _example_
solrconfig.xml and let users prune back as desired from there.
Erik
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