[
https://issues.apache.org/jira/browse/SOLR-2026?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12898195#action_12898195
]
Simon Willnauer commented on SOLR-2026:
---------------------------------------
bq. Wouldn't this be more straight forward as it's own distinct RequestHandler
(that didn't even know about SearchComponents?
It would be at least the cleaner solution and I like it. I am actually quiet
happy that some of the more "solr" experienced people (thanks hoss :) jumped in
and looked at that. I still don't understand what this has to do with
scripting engines but I guess it you folks have you usecase as I do...
bq. 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
Maybe I miss something but where am I aware of if I'm distributed? I don't see
this - enlighten me please! From the outside this looks like a single request
which can for sure be done via a "SequentialRequestHandler" which delegates
down to a list of SearHandler instances. If the request is distributed I
actually might not want the coordinator to fire a distributed request for each
SearchHandler it has configured but maybe fire the distributed request on a
higher level eg. the SequentialRequestHandler instance on the distributed nodes
it is talking to. It would safe a whole set of network roundtrips, right? I
guess both has valid use-cases so this should probably be configurable...
bq. 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.
+1 yeah that makes lots of sense to me, plus bw compat comes for free - I will
update the patch
simon
> 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
> Fix For: 4.0
>
> 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]
