: For both the SpellCheckComponent (SCC) and now for the new ClusteringComponent
: (SOLR-769) I think there are cases where the QueryComponent (QC) is not
: required. In the SpellCheckComponent case it is when building the spelling
: index. In the ClusteringComponent, it is possible to ask for document
: clusters without running any query (it also will be possible to get clusters
: _with_ a query as well, and it also is distinguished from the handling of
: search results clustering, too). Thus, it seems really weird to have to pass
: in a dummy query, yet that is what one has to do in order to avoid getting an
: NPE in the QC.
In my opinion the "right" way to deal with these use cases is to have
seperate request handlers configured for the differnet usecases ... if you
want to cluster "stuff" unrelated to a query, register a handler that uses
the ClusteringComponent but doesn't use the QueryComponent ... likewise
register a handler that knows about the SpellcheckComponent for triggering
rebuilds of the spellcheck index independent of doing queryies.
we could treat QueryComponent just like the FacetComponent and
HighlightComponent and say that it short circuts and does nothing unless
"doQuery=true" (which it would be by default) but i'm not convinced that's
the best way to approach things -- the typical case is that QueryComponent
is the meat of the request handling, it's probably okay that it be put on
a bit of a pedestal such that if your handler uses QueryComponent then
QueryComonent is "on" -- But it should absolutely be possible to have a
handler that doesn't use QueryComponent.
On a related topic: if we have any other Components that assume
QueryComponent has been executed, they should be changed. Components
should have contracts about pre-conditions and post-conditions relating to
data in the request, not how the data got there, ala...
https://issues.apache.org/jira/browse/SOLR-760
-Hoss
