lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Simon Willnauer (JIRA)" <j...@apache.org>
Subject [jira] Commented: (SOLR-2026) Need infrastructure support in Solr for requests that perform multiple sequential queries
Date Tue, 17 Aug 2010 12:03:17 GMT

    [ 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&params....
http://shard2/solr/sequence?requests=searchC,searchD&params....

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: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message