[
https://issues.apache.org/jira/browse/SOLR-2026?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12899382#action_12899382
]
Simon Willnauer commented on SOLR-2026:
---------------------------------------
bq. But if it's a distinct RequestHandler, then there is a nice seperation of
logic, and the contrl over where it is used in a distributed setup is all
controlled by solrconfig.xml and existing request params. ie...
100% agreement, moving the logic to do that up to a dedicated RequestHandler is
a the way to go.
bq. ...the first use cases seems more straight forward and logical to me
personally, but the second seems equally plausible.
I understand those use-cases but I still have a hard time to understand why
this would require something like a scripting engine. IMO adding scripting
support just for the sake of being able to fire more than one query seems to be
over-engineered. The use-cases you outlined can be handled by a way easier and
at the same time more consistent way IMO. (@hoss - don't get me wrong I am not
saying you explicitly asked for a scripting engine :)
Both use-cases we where talking about could be covered by simple configuration.
In a "SequentialRequestHandler" each sub-request could refere to another
requestHandler configured somewhere else with distinct default values. Requests
which should be fired as 2 successive queries on each shard would be enclosed
by a <combine> tag while all others are considered to be executed one after
another on all shards.
{code}
<requestHandler name="/sequential" class="solr.SequentialRequestHandler" >
<requests>
<requestHandler>searchA</requestHandler>
<requestHandler>searchB</requestHandler>
<combine>
<requestHandler>searchC</requestHandler>
<requestHandler>searchD</requestHandler>
</combine>
</requests>
</requestHandler>
{code}
A request to /sequential could then be (reqeusts param is optional and would
override the configuration):
http://coordinator/solr/sequence?shards=shard1,shard2&requests=searchA,searchB,{searchC,searchD}
subsequent requests to shards would be:
http://shard1/solr/searchA?params....
http://shard2/solr/searchA?params....
http://shard1/solr/searchB?params....
http://shard2/solr/searchB?params....
http://shard1/solr/sequence?requests=searchC,searchD¶ms....
http://shard2/solr/sequence?requests=searchC,searchD¶ms....
the coordinator can then handle all the logic required to build params for
subsequent request. By default it would just fire one after another and render
the results returned from the last request. Users should be able to subclass
the SequentialRequestHandler to add more sophisticated logic.
Lance, would that fit your needs too?
> 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: New Feature
> Components: SearchComponents - other
> Reporter: Karl Wright
> Assignee: Simon Willnauer
> Priority: Minor
> 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]
