[
https://issues.apache.org/jira/browse/SOLR-2026?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12899154#action_12899154
]
Hoss Man commented on SOLR-2026:
--------------------------------
bq. 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...
I don't actually have any usecases ... but all of the use cases i can imagine
involve needing _some_ mechanism to specify in the configuration how the
outcome of the various requests in the sequence should influence the input to
the subsequent requests -- some form of scripting specified in the cofig files
seems like the most straight forward mechanism, but other more constrained
syntaxes could certainly work as well -- the key is I can't think of any use
cases where you don't need any mechanism at all -- at least not unless you plan
on writting a *lot* of one off special case SearchComponents.
bq. Maybe I miss something but where am I aware of if I'm distributed?
that's my point -- i only skimmed your code, but in glancing at it it wasn't
obvious to me if the changes you made were going to result in the "sequential"
type functionality being applied on the "coordinator" node of a distributed
request, or on the individual shards, or both. it's something that needs to be
considered if this logic lives in SearchHandler. (either making it config able,
or picking the "right" choice for every one)
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...
If:
* "/searchA" is mapped to an instance of SearchHandler with some
components/defaults
* "/searchB" is mapped to an instance of SearchHandler with some other
components/defaults
* "/sequence" is mapped to an instance of SequentialRequestHandler, that fires
sequential requsts to "/searchA" then "/searchB"
Then:
* http://coordinator/solr/sequence?shards=shard1,shard2 - executes "/sequence"
on the coordinator machine, where it (locally) executes "searchA" and "searchB"
which each (independently) fire distributed requests to
shard1/searchA+shard2/searchA and shard1/searchB+shard2/searchB
* http://coordinator/solr/searchA?shards=shard1,shard2&shards.qt=/sequence -
executes "/searchA" on the coordinator machine which fires distributed requests
to shard1/sequence and shard2/sequence which each (independendly) sequentially
run shard1/searchA+shard1/searchB and shard2/searchA+shard2/searchB
...the first use cases seems more straight forward and logical to me
personally, but the second seems equally plausible.
(of course: it's totally possible that i just radically don't understand the
goal at all ... as evident by my confusion about how this would possibly be
useful w/o some mechanism for configuring how each request is influenced by the
outcome of the previous request ... in which case feel free to ignore me)
> 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]
