[
https://issues.apache.org/jira/browse/SOLR-2026?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12897994#action_12897994
]
Hoss Man commented on SOLR-2026:
--------------------------------
Skimming the thread that spawned this issue, the issue comments, and the patch
I'm a little confused as to what some of the main use cases for functionality
like this would be *unless* it was tied to a scripting system to dictate how
the params for each "query" (really a sub-request) should be driven by the
params for the first "quer". (Perhaps there is some static use case i'm just
not seeing where the distinct requests are independent of each other?)
In any case: adding this to SerachHandler actaully seems to be really
overly-complicated.
Wouldn't this be more straight forward as it's own distinct RequestHandler
(that didn't even know about SearchComponents?) There doesn't seem to be any
reason why the logic even needs to be aware of when it's used in a distributed
fashion, the new "SequentialRequestHandler" would always run on the
coordinator, and the individual sub-requests would be to SearchHandler
instances (probably with differnet components or default param configurations)
where the shards param would kick in if present and result in distributed
queries.
SearchHandler could remain untouched, and keep it's current focus (managing
SearchComponents) while the new SequentialRequestHandler would focus on
executing independdent sub queries in sequence.
does that make sense?
> Need infrastructure support in Solr for requests that perform multiple
> sequential queries
> -----------------------------------------------------------------------------------------
>
> Key: SOLR-2026
> URL: https://issues.apache.org/jira/browse/SOLR-2026
> Project: Solr
> Issue Type: Improvement
> Components: SearchComponents - other
> Reporter: Karl Wright
> Assignee: Simon Willnauer
> Attachments: SOLR-2026.patch, SOLR-2026.patch
>
>
> Several known cases exist where multiple index searches need to be performed
> in order to arrive at the final result. Typically, these have the constraint
> that the results from one search query are required in order to form a
> subsequent search query. While it is possible to write a custom
> QueryComponent or search handler to perform this task, an extension to the
> SearchHandler base class would readily permit such query sequences to be
> configured using solrconfig.xml.
> I will be therefore writing and attaching a patch tomorrow morning which
> supports this extended functionality in a backwards-compatible manner. The
> tricky part, which is figuring out how to funnel the output of the previous
> search result into the next query, can be readily achieved by use of the
> SolrRequestObject.getContext() functionality. The stipulation will therefore
> be that the SolrRequestObject's lifetime will be that of the entire request,
> which makes complete sense. (The SolrResponseObject's lifetime will, on the
> other hand, be limited to a single query, and the last response so formed
> will be what gets actually returned by SearchHandler.)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
